My 2 cents inline... > -----Message d'origine----- > De : Lakshminath Dondeti [mailto:ldondeti@xxxxxxxxxxxx] Envoyé : > mercredi 7 mars 2007 23:50 À : Sam Hartman Cc : ietf@xxxxxxxx Objet : > Re: [Dan Harkins] comments on draft-houseley-aaa-key-mgmt-07.txt > > Hi Sam, > > Many thanks for the opportunity to comment on the proposed text before > approval. > > I do have concerns with the proposed text. Some of the new > requirements are overly burdensome. In other places, it is not clear what is expected. > > Some notes below: > > 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. > > I must say I do not fully understand the paragraph above. I took a > quick look at 2906 and that RFC has a more nuanced take on > authorization. If we are going to require something we need to be > more specific. > > Specifically, what does it mean to say "Peer and authenticator > authorization MUST be performed?" Who is authorizing whom to do what? > > Is proof of possession of keying material proof of authorization? Not > according to the text below (on the 4-way exchange etc.). > > > > > 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. > > This is better. (Nit: There is an editorial mistake in the last > sentence.) > > > > > In addition to authenticating all parties, key management > > protocols need to demonstrate that the parties are authorized > > to possess keying material. > > What does this mean? How do key management protocols demonstrate that > the parties are authorized to possess keying material? Does this mean > that key management protocols must facilitate carrying authorization > information? Or must carry authorization information? Or that a > party requesting a key must prove that it is authorized to possess > that 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. > > The example is helpful, but are we then saying that 802.11i and the > 4-way handshake are non-compliant? Or put differently, how do we fix > the 4-way handshake so that the authenticator can prove to the peer > that it was authorized to possess the keying material it has? Does > the peer need to prove to the authenticator of its authorization to > hold the same keying material? > [Christian TC] I don't see how the 4-way handshake in 802.11i would not be compliant. The temporal keys obtained through the 4-way handshake are derived from the PMK (Pairwise Master Key). Lets recall that the PMK is mutually and exclusively derived by the supplicant and the AS. The AS then has the responsibility to transfer the PMK to the authenticator so as to enable this latter to do the 4-way handshake. In other words, the authenticator can not do the 4-way handshake succesfully if the AS doesn't provide the PMK. Regards, Christian. > > 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. > > Consistent sure, but why is correctness of the claim of identity > necessary? Put another way, is there a way to solve the problem of > the authenticator providing the same incorrect identity to the peer > and the server. I think there is in a number of usage scenarios, and > therefore propose that the requirement on correctness should be > relaxed. More specifically, I think we should stick to the guidance level of RFC 3579. > > > > > > > If no serious objections are raised, I'll finally be able to approve > > this draft next week > > Once again thanks for the opportunity. Please do consider this as an > objection to the new text. > > regards, > Lakshminath > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf