-----Original Message-----
From: Russ Housley [mailto:housley(_at_)vigilsec(_dot_)com]
Sent: Wednesday, November 08, 2006 10:48 AM
To: Joseph Salowey (jsalowey); ietf(_at_)ietf(_dot_)org
Subject: RE: Last Call: 'Guidance for AAA Key Management' to
BCP (draft-housley-aaa-key-mgmt)
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.
[Joe] OK
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.
[Joe] Neither do I. Would it be useful in the document to show how these
requirements are met/not met/conditionally met with an existing AAA key
management protocol such as RADIUS/EAP/802.11?
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.
[Joe] OK, we might want to clarify that AAA key management protocol
involves more than just the AAA protocol.
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.
[Joe] OK, If I understand correctly this would refer to some yet to be
defined protocol that does not use EAP?
Also wouldn't key caching be relevant on the EAP server
rather than the
"AAA server"?
Is "AAA/EAP server" better?
[Joe] Yes.
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.
[Joe] I think I wanted to get at that the link between authentication
and authorization may not be direct. As the section alludes to, the
identity that is authenticated may not be useful for authorization. In
this case it is not necessarily authentication of identity that is
important, but rather the binding of the entity to authorization
information (such as a key in existing systems).
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.
[Joe] The PMKID is a function of the PMK and the addresses of the
participants and may be vulnerable to what you describe.
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?
[Joe] OK makes sense.
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.
[Joe] OK I think this could use some re-wording. I'll try to put some
text together after I get through Bernard's message.
Russ
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf