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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf