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

[Bernard_Aboba (Bernard_Aboba]

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