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

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

Sam Hartman writes...

>     Nelson,> Authorization, as I use the term, is permission granted
>     Nelson,> by an authoritative entity (the grantor) to a specific
>     Nelson,> authenticated entity (the grantee) for access to some
>     Nelson,> specific service or object, to be validated by the
>     Nelson,> relying party.
> 
> Mmm.  I don't like that formulation much for protocol design although
> I agree it is formally correct.

Well...  Doesn't my formal definition pretty much describe a Kerberos
Ticket?

> I think of authorization as a statement from a grantor to a set of
> relying parties that the grantee is allowed to perform some action.

... a Kerberos Ticket-Granting-Ticket?

> I agree that authorization needs to be cryptographically bound to the
> grantee and to any contingent conditions (time of day, network port,
> etc) that are factors in the authorization decision.

OK.
 
> What I don't see and what your message does not explain is why I need
> to bind the authorization message to the authentication message.

Well, as you point out, you don't... or at least there are other ways to
design a system with the property that the authorization data is
cryptographically bound to the identity of the grantee, besides
including the authorization data in an integrity protected message
indicating successful completion of authentication.  However, that is
the way RADIUS does it.

>       I don't see how the desired goal (binding permission to grantee)
>       creates a requirement on binding messages.  I do agree that
>       binding messages is sometimes a convenient implementation
>       strategy.

Yes, I would agree with that statement.  Note, however, that, as I
indicated above, this is the way RADIUS and Diameter do it.

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

---

From: Sam Hartman <[email-masked]>
Date: Wed, 24 Aug 2005 16:50:48 -0400

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

    Nelson,> Sam Hartman writes...
    >> Nelson,> Authorization, as I use the term, is permission
    >> granted Nelson,> by an authoritative entity (the grantor) to a
    >> specific Nelson,> authenticated entity (the grantee) for access
    >> to some Nelson,> specific service or object, to be validated by
    >> the Nelson,> relying party.
    >> 
    >> Mmm.  I don't like that formulation much for protocol design
    >> although I agree it is formally correct.

    Nelson,> Well...  Doesn't my formal definition pretty much
    Nelson,> describe a Kerberos Ticket?

No.  a grantee cannot even read a Kerberos ticket.  The tickte is a
message from the KDC to the relying party.

    >> I think of authorization as a statement from a grantor to a set
    >> to the grantee and to any contingent conditions (time of day,
    >> network port, etc) that are factors in the authorization
    >> decision.

    Nelson,> OK.
 
    >> What I don't see and what your message does not explain is why
    >> I need to bind the authorization message to the authentication
    >> message.

    Nelson,> Well, as you point out, you don't... or at least there
    Nelson,> are other ways to design a system with the property that
    Nelson,> the authorization data is cryptographically bound to the
    Nelson,> identity of the grantee, besides including the
    Nelson,> authorization data in an integrity protected message
    Nelson,> indicating successful completion of authentication.

Like including it in an integrity protected message indicating
successful completion of authorization?