Subject: RE: Last Call: 'Guidance for AAA Key management' to BCP (draft-housley-aaa-key-mgmt)

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Fri, 10 Nov 2006 10:55:18 -0800

Thanks Bernard,

Comments inline.  

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Wednesday, November 08, 2006 2:00 PM
> To: [email-masked]
> 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 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Russ Housley <[email-masked]>
Date: Wed, 15 Nov 2006 18:13:23 -0500

> > there vulnerabilities associated with this?

Does this proposed text resolve your concern?

AAA key management proposals require a robust key naming scheme,
particularly where key caching is supported.  The key name provides a
way to refer to a key in a protocol so that it is clear to all parties
which key is being referenced.  Objects that cannot be named cannot be
managed.  All keys MUST be uniquely named, and the key name MUST NOT
directly or indirectly disclose the keying material.  If the key name
is not based on the keying material, then one can be sure that it cannot
be used to assist in a search for the key value.

Russ