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

From: Russ Housley <[email-masked]>
Date: Mon, 06 Nov 2006 22:15:59 -0500

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 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 7 Nov 2006 07:35:05 -0800

Hi Russ,
 
> I agree, the document is really addressing AAA/EAP key management.

Why would the scope be limited to EAP? It seems to me that most, if not
all, of the requirements would be applicable to just about any AAA-based
key management protocol. Would it not be useful to generalize it? 

Vidya

---

From: Russ Housley <[email-masked]>
Date: Tue, 07 Nov 2006 11:00:22 -0500

>key management protocol. Would it not be useful to generalize it?

You are right.  It is about AAA key management protocols, which 
includes various features of EAP, RADIUS, Diameter, and secure 
association protocols.

Is the document introduction clear about the scope?

Russ

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 7 Nov 2006 12:54:27 -0800

> >all, of the requirements would be applicable to just about any 
> >AAA-based key management protocol. Would it not be useful to 
> generalize it?
> 
> You are right.  It is about AAA key management protocols, 
> which includes various features of EAP, RADIUS, Diameter, and 
> secure association protocols.
> 

Hmmm, I was thinking that the scope could be broader than that. There
are key management protocols that try to re-use the AAA framework, some
just for transport and others for more than that. Many of these may
start with a PSK and define derivation of keys needed for the specific
application, but then use AAA for transport of the exchange and
generated keys. 

Is there a reason why this document would not be applicable to such
scenarios? 

Vidya

---

From: Russ Housley <[email-masked]>
Date: Tue, 07 Nov 2006 17:54:30 -0500

Vidya:

My concern is the origins of this whole effort.

In March 2003, I was asked to put together criteria for acceptable 
AAA key management.  I received this request at the beginning of IETF 
56, and it resulted in the "Key Management in AAA" presentation to 
the AAA WG a few days later.  This was the meeting where I was 
appointed to the position of Security Area Director.  The slides are 
the basis of this document:
    http://www.ietf.org/proceedings/03mar/slides/aaa-5/index.html

People asked for explanation of the bullets on two slides.  This 
document captures the verbal explanation that has been given many 
times.  The goal is to generate a BCP, putting an end to verbal lore.

As a result, this document is focused on AAA-based key management, 
and while the principles surely apply to other contexts, it uses AAA 
jargon and other AAA-specific stuff.

Russ

---

From: Russ Housley <[email-masked]>
Date: Tue, 07 Nov 2006 17:54:30 -0500

Vidya:

Russ

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 17 Nov 2006 19:02:54 +0200

Hi Russ,

> I believe that this is being addressed in draft-ietf-eap-keying.

Can you please provide a pointer? 

It has peer-id and server-ids defined. But even that has issues, as these
are EAP-method exports, and not always available. 

> This is a very good principle, but I think SHOULD NOT is more appropriate.

I'm wondering why we open the door for children keys living longer than the
parent key.
 
> but we encourage them to have one.

I understand. What is the affect of "SHOULD but not a requirement"? Is this
like a "SHOULD-"? I mean, what do we lose if we drop the "but such a
protection is not a requirement"? 

Regards,

Alper

---

From: Russ Housley <[email-masked]>
Date: Fri, 17 Nov 2006 12:33:59 -0500

>are EAP-method exports, and not always available.

I'll let Bernard handle this part of your message.  I'm responding to 
the next part.

>protection is not a requirement"?

The next version of the document will say:

In many environments it is important to provide confidentiality protection
for identities.  However, this is not important in other environments.  For
this reason, EAP methods are encouraged to provide a mechanism for identity
protection of EAP peers, but such protection is not a requirement.

I hope this resolves your concern with the RFC 2119 terms.

Russ