eap Mailing List: Re: Issue: Use of a label in derivation of keys from the MSK

[Narayanan, Vidya (vidyan]

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

> -----Original Message-----
> From: Bernard_Aboba [at] hotmail.com [mailto:Bernard_Aboba [at] hotmail.com] 
> Sent: Tuesday, November 20, 2007 4:40 AM
> To: Dan Harkins
> Cc: 'eap-WG'
> Subject: Re: [eap] Issue: Use of a label in derivation of 
> keys from the MSK
> 
> 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" <dharkins [at] lounge.org>
> Sent: Monday, November 19, 2007 11:07 PM
> To: <Bernard_Aboba [at] hotmail.com>
> Cc: "'eap-WG'" <eap [at] frascone.com>
> Subject: Re: [eap] Issue: Use of a label in derivation of 
> keys from the MSK
> 
> >
> >  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, Bernard_Aboba [at] hotmail.com 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 
> >> 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
> >
> >
> > _________________________________________________________________
> > To unsubscribe or modify your subscription options, please visit:
> > http://lists.frascone.com/mailman/listinfo/eap
> >
> > Arhives: http://lists.frascone.com/pipermail/eap
> > 
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/eap
> 
> Arhives: http://lists.frascone.com/pipermail/eap
>