Thanks Bernard, Comments inline. > -----Original Message----- > From: Bernard Aboba [mailto:aboba@xxxxxxxxxxxxx] > Sent: Wednesday, November 08, 2006 2:00 PM > To: ietf@xxxxxxxx > Cc: Joseph Salowey (jsalowey) > Subject: Re: Last Call: 'Guidance for AAA Key management' to > BCP (draft-housley-aaa-key-mgmt) > > I believe that the document will have implications for the > RADIUS protocol. For example, during the RADEXT WG meeting > at IETF 67, we discussed the need for crypto-agility in > RADIUS, and the current lack of ability to negotiate > cryptographic algorithms. This is why Crypto-agility was > added as a RADEXT WG work item. > > Since Diameter already supports cryptographic algorithm > negotiation, I do not believe that crypto-agility is an issue there. > > My reading of the document is that it does not impose any > security requirements on EAP methods beyond those described > in RFC 4017 and RFC 3748. At least that is what is being > assumed in the EAP Key Management Framework document, which > cites RFC 4017 and RFC 3748 as meeting the requirements. > [Joe] I think it would be helpful to include an appendix on how existing commonly deployed mechanisms compare against these requirements. What do you think? > I think that the term 'AAA key management' applies to > situations which involve use of AAA for derivation or > transport of keying material. In the case of EAP, that would > include EAP methods, AAA protocols as well as the SAP. > > 1. I do think that SAP designers are an audience, > particularly since that work often occurs outside of IETF. > > 2. The AAA protocol does play a role in freshness, because it > can support replay protection, preventing the same key > transport message from being replayed, thereby introducing > stale keys. > > 3. I think that "authentication of all parties" is distinct > from context binding, although it is certainly a > pre-requisite for it. Without defining the parties to the > key management exchange and authenticating them, it is not > possible to protect against key usage outside of the > authorized scope. > [Joe] I don't think this is always the case. Authenticating identity is different that authorizing scope. They may depend upon one another, but do not necessarily have to. > 4. Agree that integrity should also be called out. > > 5. There are vulnerabilities associated with the 802.11i key > naming scheme. For example, I believe that PSK cracking > tools have been built that perform offline dictionary attacks > on the 802.11i key names. > EAP methods satisfying RFC 4017 criteria are not vulnerable, > but I do think it illustrates the potential dangers. The > problem is fixed in 802.11r. > [Joe] OK, how does .11r solve the problem? > 6. I believe this section applies to binding within all > phases, including AAA, EAP and SAP. Generally AAA integrity > protection mechanisms should satisfy the binding requirements > (or at least that is what is assumed in the EAP Key > Management Framework document). For EAP, the requirements > are met by RFC 4017 requirements (including Channel Binding > support). So in practice the issue has mostly arisen within > SAP designs, some of which have not properly handled key > scoping and binding. For example, within IEEE 802.11i, the > authenticator is not identified, only the port/BSSID so that > the peer cannot properly determine the authenticator key > scope. This is also fixed in 802.11r. > [Joe] OK, I need to look at .11r. > 7. I think some clarification may be needed here. As stated > in the EAP Key Management Framework document, the > authenticator and AAA client are always co-located (though > these entities may both be distributed as in some CAPWAP > architectures). > [Joe] OK, this needs clarification. This section also mentions the keying draft without referencing it. > ----------------------------------------------------------------- > 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 > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf