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

[Russ Housley <housley at vigilsec.com>]

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.

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.

> 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.


> 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.

Good point.  I'll add "security association protocol designers" too.


> 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.

> Also wouldn't key caching be relevant on the EAP server rather than the
> "AAA server"?

Is "AAA/EAP server" better?


> 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.


> 4. Keying material confidentiality
>
> It seems that a system should also preserve key material integrity
> (perhaps this is assumed in confidentiality).

Good point.  (confidentially certainly does not automatically assume 
integrity).  I'll update it.


> 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.


> 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?


> 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.

Russ


_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf