ietf
[Top] [All Lists]

Re: [Dan Harkins] comments on draft-houseley-aaa-key-mgmt-07.txt

2007-03-07 11:18:52

  Hi Sam,

  Thanks for the update. My original comment never made it to the ietf
list because I wasn't a member at the time of posting. I was informed that
if the moderator approved my posting it would be sent to the list,
unfortunately it wasn't. :-(

  In the new "Peer and authenticator authorization" section the last
paragraph has no keywords signifying a requirement. That seems strange
to me considering the message the paragraph is trying to convey seems
important. "...key management protocols need to demonstrate..." seems
like it should be "...key management protocols MUST demonstrate..." The
final sentence says "...channel binding is required..." and that should
be "...channel binding MUST be performed..." I bring this up because I
have seen people attempt to maneuver in such weasel room in an attempt
to not do The Right Thing.

  Also, my comment on the "Authenticate all parties" section regarding
authenticator impersonation was because the only mention of identities
is in the context of generating session keys. My concern is around key
distribution from a AAA server to an authenticator. I asked for the
following text to be added:

    When a security association is used to distribute keying material
    the security association SHOULD be bound to a unique identity that
    can be commonly known by all the parties-- including the peer. If the
    security association cannot be based on such an identity then it MUST
    be statically configured to be an attribute of the security
    association.

And that unique identity was then to be used as follows in a new section:

    When another party requires access to keying material the
    identity of that party MUST be authenticated prior to distribution
    of the keying material. The distributor MUST ensure that the
    keying material is not disclosed to the wrong party. This can be
    accomplished, for example, by verifying the identity of the party
    to whom the keying material is being disclosed with the identity
    bound to the security association under which it will be sent.

    When keying material is disclosed the other party on whose behalf
    it is being disclosed MUST confirm disclosure. For example, a peer
    MUST acknowledge disclosure of keying material from a AAA server
    to an authenticator and the identity of the authenticator MUST be
    confirmed by the peer and AAA server.

  I think my first two points are serious objections but will accept the
fact that other people don't. Also, I reiterate my suggestion for text
regarding identities because the post never made it to the list. If
the authors considered my suggestion but did not accept it then that's
all I could ask for. So I would still like to see some changes but
understand if no one else views these as serious objections.

  thanks,

  Dan.

On Wed, March 7, 2007 8:05 am, Sam Hartman wrote:

Hi, folks.  The following last call comment was received and based on
discussion the draft was updated.  This comment never seems to have
made it to the ietf list though.


The following text was added to address the comment.  Please confirm
that this text addresses the comment and that from the following text
it is clear that these requirements prohibit authenticator
impersonination:

      Peer and authenticator authorization

       Peer and authenticator authorization MUST be performed.  These
       entities MUST demonstrate possession of the appropriate keying
       material, without disclosing it.  Authorization is REQUIRED
       whenever a peer associates with a new authenticator.  The
       authorization checking prevents an elevation of privilege
       attack, and it ensures that an unauthorized authenticator is
       detected.

       Authorizations SHOULD be synchronized between the peer, NAS,
       and backend authentication server.  Once the AAA key management
       protocol exchanges are complete, all of these parties should
       hold a common view of the authorizations associated the other
       parties.

       In addition to authenticating all parties, key management
       protocols need to demonstrate that the parties are authorized
       to possess keying material.  Note that proof of possession of
       keying material does not necessarily prove authorization to
       hold that keying material.  For example, within an IEEE
       802.11i, the 4-way handshake demonstrates that both the peer
       and authenticator possess the same EAP keying material.
         However, by itself, this possession proof does not demonstrate
         that the authenticator was authorized by the backend
         authentication server to possess that keying material.  As
         noted in RFC 3579 in section 4.3.7, where AAA proxies are
         present, it is possible for one authenticator to impersonate
         another, unless each link in the AAA chain implements checks
         against impersonation.  Even with these checks in place, an
         authenticator may still claim different identities to the peer
         and the backend authentication server.  As described in RFC
         3748 in section 7.15, channel binding is required to enable the
         peer to verify that the authenticator claim of identity is both
         consistent and correct.


If no serious objections are raised, I'll finally be able to approve
this draft next week








_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf