Subject: [eap] Issue: Use of a label in derivation of keys from the MSK

From: <[email-masked]>
Date: Fri, 16 Nov 2007 06:47:58 -0800

To date, EAP lower layers utilizing the MSK have often utilized a label within the PRF used for deriving other keys in order to ensure 
uniqueness of key branches.  This includes 802.11i, 802.11r, and now 802.1af.  

However, this "unwritten rule" has not been included the EKMF document.  This seems like a fairly important omission. 

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 19 Nov 2007 17:14:32 -0800

While I agree this is good practice, I think we have to be careful about
relying upon this to always be the case.  Not all uses of the MSK may
currently use a label (I'm not sure if PANA does).  Since this rule has
not been around for long a particular lower layer should not assume that
using a key label will have any effect on guaranteeing uniqueness from
any keys it doesn't control the derivation of.  It will help in
guaranteeing uniqueness in keys that it does control the derivation of. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Friday, November 16, 2007 6:48 AM
> To: 'eap-WG'
> Subject: [eap] Issue: Use of a label in derivation of keys 
> from the MSK
> 
> To date, EAP lower layers utilizing the MSK have often 
> utilized a label within the PRF used for deriving other keys 
> in order to ensure uniqueness of key branches.  This includes 
> 802.11i, 802.11r, and now 802.1af.  
>  
> However, this "unwritten rule" has not been included the EKMF 
> document.  This seems like a fairly important omission. 
>

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 19 Nov 2007 23:07:34 -0800 (PST)

Lower layers derive session keys from an MSK via a secure association
protocol (like 802.11i's "4 way handshake"). RFC4962 says,

    "The AAA protocol and EAP method MUST ensure that the keying material
     supplied as an input to session key derivation is fresh, and the
     secure association protocol MUST generate a separate session key
     for each session, even if the keying material provided by EAP is
     cached....
    "Session keys MUST NOT be dependent on one another.  Multiple
     session keys may be derived from a higher-level shared secret
     as long as a one-time value, usually called a nonce, is used to
     ensure that each session key is fresh.  The mechanism used to
     generate session keys MUST ensure that the disclosure of one
     session key does not aid the attacker in discovering any other
     session keys."

  So it seems to me that the label is not the thing that ensures
uniqueness as that would tend to be constant among multiple session
keys. It is the nonce that ensures uniqueness.

  If the label is not a nonce-- a number only used once-- then it's
not providing the uniqueness you describe. If it is a nonce then there
is already text to describe this requirement in RFC4962 and there is
no issue.

  Dan.

On Fri, November 16, 2007 6:47 am, [email-masked] wrote:
> To date, EAP lower layers utilizing the MSK have often utilized a label
> within the PRF used for deriving other keys in order to ensure
> However, this "unwritten rule" has not been included the EKMF document.
> This seems like a fairly important omission.

---

From: <[email-masked]>
Date: Tue, 20 Nov 2007 04:37:06 -0800

802.11i, 802.11r, 802.1af all use labels.  The lack of a label in the
PANA protocol has been flagged as an errata and will presumably 
be fixed in AUTH 48.  So in effect, this practice has been around 
for a while, but was not written down. 

I agree about the lower layer assumptions. 

--------------------------------------------------
From: "Joseph Salowey (jsalowey)" <[email-masked]>
Sent: Monday, November 19, 2007 5:14 PM
To: <[email-masked]>; "eap-WG" <[email-masked]>
Subject: Re: [eap] Issue: Use of a label in derivation of keys from the MSK

---

From: <[email-masked]>
Date: Tue, 20 Nov 2007 04:40:07 -0800

I would agree that the label does not guarantee key freshness, as a nonce 
would.

But doesn't it provide the ability to derive crypto-graphically separate 
keys from the MSK
or portions of it?

--------------------------------------------------
From: "Dan Harkins" <[email-masked]>
Sent: Monday, November 19, 2007 11:07 PM
To: <[email-masked]>
Cc: "'eap-WG'" <[email-masked]>
Subject: Re: [eap] Issue: Use of a label in derivation of keys from the MSK

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 20 Nov 2007 12:32:52 -0800

We haven't restricted the use of the MSK in IETF documentation thus far
and hence, several lower layers have used it in different ways.  I think
it is dangerous now to provide any normative text on the use of labels.
Each lower layer has the responsibility to ensure cryptographically
separate keys are dervied from the MSK and I think that's where it
should be left.  If the MSK is only used in a single context, this may
just use nonces as Dan points out.  If the MSK is used for deriving keys
used in different contexts, it is feasible that labels or a combination
of labels and nonces within each label space gets used.  In essence, it
very much depends on the usage of the MSK by the lower layer and I don't
think we should be writing something that is tied to particular usage
models. 

Vidya

> Sent: Tuesday, November 20, 2007 4:40 AM
> To: Dan Harkins
> Cc: 'eap-WG'
> I would agree that the label does not guarantee key 
> freshness, as a nonce would.
> 
> But doesn't it provide the ability to derive 
> crypto-graphically separate keys from the MSK or portions of it?
> 
> >  If the label is not a nonce-- a number only used once-- 
> then it's not 
> > providing the uniqueness you describe. If it is a nonce 
> then there is 
> > already text to describe this requirement in RFC4962 and 
> there is no 
> > issue.
> >
> >  Dan.
> >
> >> To date, EAP lower layers utilizing the MSK have often utilized a 
> >> label within the PRF used for deriving other keys in order 
> to ensure 
> >> uniqueness of key branches.  This includes 802.11i, 
> 802.11r, and now 
> >> 802.1af.
> >>

---

From: <[email-masked]>
Date: Tue, 20 Nov 2007 14:06:44 -0800

> and hence, several lower layers have used it in different ways. 

I believe that all existing uses of the MSK utilize labels for
key derivation.  Can you name a specific exception?  
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

---

From: <[email-masked]>
Date: Tue, 20 Nov 2007 14:06:44 -0800

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 22 Nov 2007 11:49:45 -0800

If we are to do this, we should summarize all the known uses of the MSK: 
  In some cases it is used for deriving traffic keys and in other cases, 
traffic keys along with other MSK-equivalent keys.  Some specifications 
achieve key separation by using different parts of the MSK for different 
purposes and use key labels for key separation thereafter.  Others use 
labels alone for key separation.  The MSK is also used as a substitute 
for LTCs in the IKEv2 context.

Given the complexity of the state of affairs, a simple statement along 
the lines of "use key labels for key separation" is not really accurate.

regards,
Lakshminath

---

From: <[email-masked]>
Date: Thu, 22 Nov 2007 17:00:05 -0800

> traffic keys along with other MSK-equivalent keys.

Not sure what "MSK-equivalent" means here.  Can you explain?

> Some specifications
> purposes and use key labels for key separation thereafter.

Can you give an example of an EAP lower layer that does this?  IEEE 802.11i, 
r
and 16e all use a portion of the MSK (PMK) as a root and don't use the rest.
I think they do this to enable future key hierarchy extensions.

> Others use labels alone for key separation.

802.11i, 11r, and 1af would fall into this category.

>The MSK is also used as a substitute for LTCs in the IKEv2 context.

Yes.

> the lines of "use key labels for key separation" is not really accurate.

The document already describes existing practices, so the
issue is not really "accuracy".  The issue is having advice
that could have guided the PANA protocol specification
(where there was no root key derived from the MSK, and also
no label used, so that cryptographically separate branches
could not be created).

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 23 Nov 2007 16:02:35 -0800

> Not sure what "MSK-equivalent" means here.  Can you explain?

It depends on the link layer.  I will try and stick to the link layer we 
are all familiar with, but the wording gets a bit fuzzy in that case.

In 802.11 networks (my knowledge may be a bit rusty here, so please 
correct me)
PMK = MSK[0 .. 255],
PTK = f(PMK, <additional-data>)

PMK-R0 = MSK[256 .. 511]
PMK-R1 = f(PMK-R0, <...>)
PTK = f(PMK-R1, <additional-data>)

So, key separation is achieved by using different parts (first 256 and 
the second 256 bits) of the MSK and then key labels from thereon.

> Can you give an example of an EAP lower layer that does this?  IEEE 
> 802.11i, r

I agree that we should specify the requirement for key separation.  I 
don't think it is necessary to say anything about key labels per se.

regards,
Lakshminath

regards,
Lakshminath