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