Hi Russ and Bernard, 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.). What does AAA key management protocol refer to? Is it the combination of EAP, AAA and Security Association Protocol? A few comments on this document 1. Section 3 states "This section provides guidance to AAA protocol designers and EAP method designers." This should include designers of "security association protocols" as well since many of the requirements apply to them. 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" Also wouldn't key caching be relevant on the EAP server rather than the "AAA server"? 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. 4. Keying material confidentiality It seems that a system should also preserve key material integrity (perhaps this is assumed in confidentiality). 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? 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." 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? Joe > -----Original Message----- > From: Russ Housley [mailto:housley@xxxxxxxxxxxx] > Sent: Tuesday, November 07, 2006 8:00 AM > To: Narayanan, Vidya; ietf@xxxxxxxx > Subject: RE: Last Call: 'Guidance for AAA Key Management' to > BCP (draft-housley-aaa-key-mgmt) > > Vidya: > > > > I agree, the document is really addressing AAA/EAP key management. > > > >Why would the scope be limited to EAP? It seems to me that > most, if not > >all, of the requirements would be applicable to just about any > >AAA-based key management protocol. Would it not be useful to > generalize it? > > You are right. It is about AAA key management protocols, > which includes various features of EAP, RADIUS, Diameter, and > secure association protocols. > > Is the document introduction clear about the scope? > > Russ > > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf