Subject: RE: [Isms] Re: securityName/groupName

From: "Nelson, David" <[email-masked]>
Date: Wed, 24 Aug 2005 14:00:15 -0400

Sam Hartman Writes...

> How would you invision authentication methods like gssapi-with-mic or
> publickey working if we don't separate authorization from
> authentication?

In order to answer your question directly, I'll need to do some
research.  To provide a meta-answer, I would note that there is a
crucial difference between AAA systems and authentication (A) systems -
and that's the two additional "A"s, authorization and accounting.  While
there is no identified need in ISMS for accounting, we have identified a
need for authorization.  The detailed answer to your question is based
on what provisions authentication systems, such as those you've
mentioned, make for authorization data.

Generally speaking, authorization data needs to be cryptographically
bound to the authentication result, in order to provide robust security
of the access controls.  In AAA systems, this requirement is met by
placing the authorization data in the integrity protected authentication
acceptance message.

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

---

From: Kaushik Narayan <[email-masked]>
Date: Wed, 24 Aug 2005 12:21:01 -0700

>placing the authorization data in the integrity protected authentication

I am not sure about the statement "authorization data needs to be 
cryptographically
bound to the authentication result" applies to all cases.

I agree to the applicability of this to authorization data pertaining to 
network access use
cases where in there needs to be a binding between the user "session" and 
authorization
data specific to the session. I also agree to this binding in 
administrative security use cases
where a privilege level or group-name needs to be provided for an 
authenticated user. However,
there are certain use cases where this binding is not necessary for e.g. 
authorization of CLI
commands or a per-command basis via TACACS+ does not require a binding to 
an already
authenticated user.

regards,
   kaushik!

---

From: Sam Hartman <[email-masked]>
Date: Wed, 24 Aug 2005 15:22:03 -0400

>>>>> "Nelson," == Nelson, David <[email-masked]> writes:

    Nelson,> Generally speaking, authorization data needs to be
    Nelson,> cryptographically bound to the authentication result, in
    Nelson,> order to provide robust security of the access controls.
    Nelson,> In AAA systems, this requirement is met by placing the
    Nelson,> authorization data in the integrity protected
    Nelson,> authentication acceptance message.

I understand that authorization data needs to be integrity protected
between the authorizing agent and the relying party.  I don't
understand why it needs to be bound to the authentication though.

I'm actually aware of cases where for example using the same keying
material resulting from authentication weakens authorization.

--Sam

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 24 Aug 2005 15:23:59 -0400

> To provide a meta-answer, I would note that there is a
> need for authorization.  

A historical note: One of the prime reasons we adopted a
human-readable securityName was to accommodate the requirement for a
logging/user-accountability capability in SNMP. 

I think accounting frequently includes the accountability function.
YMMV.

David Harrington
[email-masked]

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 24 Aug 2005 15:37:28 -0400

Hi,

In the SNMPv3 WG, we recognized that authentication and authorization
needed to be bound together; In SNMPv2, they were explicitly bound
together, but they were bound so tightly it caused us problems because
we could not choose one solution that met the requirements of all
industry segments, and there were slight differences in the
interpretations of the semantics of the shared variables utilized by
various authentication and authorization functions.

We saw the benefit of being able to separate them into different
subsystems/models, such that each function (AA) and each method had it
own variables, except those variables necessary to provide a
(cryptographic?) binding between the assertions of the authentication
system and the access control functions. The passing of
securityModel/securityName/securityLevel is the binding used in SNMPv3
between the authentication and authorization functions. It was also
intended to serve as the binding to accounting, if and when that was
addressed.

There is a fundamental acceptance that the interface between
subsystems is trusted.

David Harrington
[email-masked]

> -----Original Message-----
> From: Sam Hartman [mailto:[email-masked]] 
> Sent: Wednesday, August 24, 2005 3:22 PM
> To: Nelson, David
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Isms] Re: securityName/groupName
>