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

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

Sam Hartman writes...

> 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.

Authorization, as I use the term, is permission granted by an
authoritative entity (the grantor) to a specific authenticated entity
(the grantee) for access to some specific service or object, to be
validated by the relying party.

One example of such an authorization in the physical world is an entry
visa to a foreign country.  Typically the visa stamp is placed in your
passport.  The passport is a means of authentication (verification of
identity) that the customs agent can easily validate.  Placing the entry
visa (an authorization for access to the country's borders) in the
passport binds the visa issuance (authorization) to the identity of the
passport holder (authentication).

The reason it is important, in many application environments, to bind
the authorization message to the authentication message is to ensure
that the authorization may be used for access only by the original
grantee.  There are many ways in which this binding can take place, of
course.

In my passport example, if the visa were stamped on a blank sheet of
paper that was loosely stuck in my passport, then I might be able to
pass along a visa validly issue issued to me to some bad guy who would
not otherwise be allowed into the country.

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

Yes, I believe that is true.  I also believe that it is possible to
avoid this issue, but still include the authorization data along with
the authentication acceptance message.

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

---

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

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

    Nelson,> Sam Hartman writes...
    >> 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.

    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.

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.

    Nelson,> One example of such an authorization in the physical
    Nelson,> world is an entry visa to a foreign country.  Typically
    Nelson,> the visa stamp is placed in your passport.  The passport
    Nelson,> is a means of authentication (verification of identity)
    Nelson,> that the customs agent can easily validate.  Placing the
    Nelson,> entry visa (an authorization for access to the country's
    Nelson,> borders) in the passport binds the visa issuance
    Nelson,> (authorization) to the identity of the passport holder
    Nelson,> (authentication).

Here, though, the grantor is interested in bindingthe permission to
the grantee.  I think this is carried in pasports because it is
convenient to to do so and because it avoids naming problems in
identifying the name of the grantee.

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.

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,> The reason it is important, in many application
    Nelson,> environments, to bind the authorization message to the
    Nelson,> authentication message is to ensure that the
    Nelson,> authorization may be used for access only by the original
    Nelson,> grantee.  There are many ways in which this binding can
    Nelson,> take place, of course.

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.

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

    Nelson,> Yes, I believe that is true.  I also believe that it is
    Nelson,> possible to avoid this issue, but still include the
    Nelson,> authorization data along with the authentication
    Nelson,> acceptance message.