On Wed, Nov 08, 2006 at 02:00:14PM -0800, Bernard Aboba wrote: > 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. > > 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. Does 'AAA key management' protocol also include EAP lower layer protocols such as 802.1X, PANA and IKEv2? Yoshihiro Ohba > > 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. > > 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. > > 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. > > 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). > > ----------------------------------------------------------------- > 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 mailing list > Ietf@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf