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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]