Re: Issue: Use of a label in derivation of keys from the MSK
From: Dan Harkins (dharkinslounge.org)
Date: Mon, 19 Nov 2007 23:07:38 -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, 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


Results generated by Tiger Technologies using MHonArc.