> -----Original Message----- > From: Russ Housley [mailto:housley@xxxxxxxxxxxx] > Sent: Wednesday, November 08, 2006 10:48 AM > To: Joseph Salowey (jsalowey); ietf@xxxxxxxx > Subject: RE: Last Call: 'Guidance for AAA Key Management' to > BCP (draft-housley-aaa-key-mgmt) > > Joe: > > >I'm not really clear on the purpose of the document. What does it > >apply to? Does it require changes to existing AAA > protocols? Does it > >add new requirements to EAP methods that are not in RFC3748? > It would > >probably be good to reference 3748 when it applies to a > requirement in > >this document (such as replay protection, strong fresh > session keys, etc.). > > This is really asking for two things, if I am reading it properly. > > First, you seem to want some additional text in the > Introduction about the things to which the BCP will apply. > The intent was broad applicability. It is intended to become a BCP. > [Joe] OK > Second, you seem to want a tighter coupling to EAP. While > EAP is clearly an important aspect of AAA, the requirements > are intended to be met by the system as a whole. Maybe I am > missing something in your comment, but I do not want a > tighter binding than necessary. > [Joe] Neither do I. Would it be useful in the document to show how these requirements are met/not met/conditionally met with an existing AAA key management protocol such as RADIUS/EAP/802.11? > >What does AAA key management protocol refer to? Is it the > combination > >of EAP, AAA and Security Association Protocol? > > Other Last Call comments suggest that a broad interpretation > is appropriate. All three of these are certainly included, > but other things might be included too. > [Joe] OK, we might want to clarify that AAA key management protocol involves more than just the AAA protocol. > >2. Strong fresh session keys > > > >In this section it is not clear what the subject session > keys are. It > >is not clear to me what role the AAA protocol plays in > "ensure that the > >keying material supplied as an input to session key > derivation is fresh" > > Bernard and I discussed this at great length with Sam before > IETF Last Call. In this context, "session" is a vague. I > think it is vague because of the large number of places where > AAA is employed. This document inherits this purposeful > vagueness too. > [Joe] OK, If I understand correctly this would refer to some yet to be defined protocol that does not use EAP? > >Also wouldn't key caching be relevant on the EAP server > rather than the > >"AAA server"? > > Is "AAA/EAP server" better? > [Joe] Yes. > > >3. Authenticate all parties > > > >What is the AAA key management protocol? It seems that some of this > >section is about validating keys are used within they > correct context > >and not necessarily authentication. Maybe part of this > section should > >belong with the context binding section. > > I do not understand your point here. > [Joe] I think I wanted to get at that the link between authentication and authorization may not be direct. As the section alludes to, the identity that is authenticated may not be useful for authorization. In this case it is not necessarily authentication of identity that is important, but rather the binding of the entity to authorization information (such as a key in existing systems). > > >5. Unique Key Names > > > >This section states "the key name MUST NOT be based on the keying > >material itself." 802.11i uses this technique; are there > vulnerabilities > >associated with this? > > Maybe I have forgotten too much about 802.11i. Please give > your example. > > Yes, there are several way to base the name on the key value that > discloses information about the key value. We do not want the key > name to aid the attacker in a brute force search by trimming > the search space. > [Joe] The PMKID is a function of the PMK and the addresses of the participants and may be vulnerable to what you describe. > > > >6. Bind key to its context > > > >In this section it is not clear what the "protocol" is or how the > >binding would occur. What is meant by "The manner in which > the keying > >material is expected to be used." > > Is it an integrity key, an encryption key, a key derivation key, a > key-encrypting key, etc? In which protocol will the key > perform this role? > [Joe] OK makes sense. > > >7. Security considerations > > > >The first paragraph is difficult to understand. It seems to > be stating > >that the authenticator can be separated from a AAA client as > long as the > >context of the request is communicated correctly between parties. Is > >this it? > > I think so. Also, the split would need to be done in such a way that > naming ambiguities are not introduced. > [Joe] OK I think this could use some re-wording. I'll try to put some text together after I get through Bernard's message. > Russ > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf