Alper:
I think this is a good and much-needed document. Thanks to the authors and
whoever else contributed to it.
Thanks for your review.
The title and the abstract starts reading like a general AAA key management
guideline, but later the document gets too EAP-specific. Is the intent to
provide general guidelines that should also be followed by non-EAP-based
systems? Can we clarify that?
I agree, the document is really addressing AAA/EAP key management.
4-Way Handshake
A pairwise Authentication and Key Management Protocol (AKMP)
defined in [802.11i], which confirms mutual possession of a
Pairwise Master Key by two parties and distributes a Group Key.
Isn't "4-way handshake" a specific example of "secure association" protocol?
If so, probably we can present this as an example of the latter in the
terminology section.
Yes it is. The definitions already include:
Secure Association Protocol
A protocol for managing security associations derived from EAP
and/or AAA exchanges. The protocol establishes a security
association, which includes symmetric keys and a context for
the use of the keys. An example of a Secure Association
Protocol is the 4-way handshake defined within [802.11i].
I think that the 4-way Handshake definition should repeat this fact.
Cryptographic algorithm independent
The AAA key management protocol MUST be cryptographic algorithm
independent. However, an EAP method MAY depend on a specific
cryptographic algorithm.
Why is the requirement softer on the EAP methods?
Because the EAP methods are negotiable. So, EAP methods are, by
design, allowed to be very algorithm dependent.
Limit key scope
Following the principle of least privilege, parties MUST NOT
have access to keying material that is not needed to perform
their own role. A party has access to a particular key if it
has access to all of the secret information needed to derive
it.
When a secure association protocol is used to establish session
keys, the secure association protocol MUST specify the scope
for session keys, clearly identifying the parties to whom the
session key is available.
The second paragraph reads as if it is a specific application of the
requirement stated in the first paragraph. Do we really want to make a
specific requirement on the "secure association protocols", or are we using
this as an example of how the aforementioned requirement is applied to a
protocol?
Yes it is. For clarity, I think it is important to make the
statement about keys established with a secure association protocol.
If the intent is the latter one, how about a more general statement like
"Any protocol that establishes sessions keys MUST specify the scope of these
keys, clearly identifying the parties to whom the session key is available."
This is fine with me.
And how would we apply this to EAP? There is no authenticator ID known to
EAP peer, yet they share an MSK.
I believe that this is being addressed in draft-ietf-eap-keying.
Prevent the Domino effect
Compromise of a single peer MUST NOT compromise keying material
held by any other peer within the system, including session
keys and long-term keys. Likewise, compromise of a single
authenticator MUST NOT compromise keying material held by any
other authenticator within the system.
In the context of a key
hierarchy, this means that the compromise of one node in the
key hierarchy must not disclose the information necessary to
compromise other branches in the key hierarchy. Obviously, the
compromise of the root of the key hierarchy will compromise all
of the keys; however, a compromise in one branch MUST NOT
result in the compromise of other branches. There are many
implications of this requirement; however, two implications
deserve highlighting. First, the scope of the keying material
must be defined and understood by all parties that communicate
with a party that holds that keying material. Second, a party
that holds keying material in a key hierarchy must not share
that keying material with parties that are associated with
other branches in the key hierarchy.
The second paragraph makes sense. But somehow the requirements in the first
paragraph are more restrictive than the general requirement in the second
paragraph. More specifically, if a solution derives one set of keys on an
authenticator and passes it to another one (effectively identifying the
second one as its child in the key hierarchy), that's allowed by the second
paragraph, but not the first one. Is that the intent?
Yes, that is the intent. The paragraph break was added by you.
Bind key to its context
Keying material MUST be bound to the appropriate context, which
includes:
o The manner in which the keying material is expected to
be used;
o The other parties that are expected to have access to
the keying material; and
Isn't this same as key scoping? If so, we can say that key scooping is a
subset of binding key to its context.
The two are clearly related. I do not think that removing the
earlier section will add clarity.
o The expected lifetime of the keying material.
Does it make sense to mention something like "Lifetime of a child key MUST
NOT be greater than the lifetime of its parent in the key hierarchy."?
This is a very good principle, but I think SHOULD NOT is more appropriate.
For this reason, EAP methods SHOULD
provide a mechanism for identity protection of EAP peers, but
such protection is not a requirement.
"SHOULD" and "not a requirement" seem to clash. We should either make it a
"MAY", or remove the ",but ...".
All methods do not have to have a mechanism for identity protection,
but we encourage them to have one.
Russ
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf