eap Mailing List: RE: Re: potential resolution to Issue 317

[Nakhjiri Madjid-MNAKHJI1 (Madjid.Nakhjiri]

Not sure if I have the full context, but do I understand correctly that
the following text says, EMSK is not to be used to derive other keys??
So we cannot use EMSK to derive AMSKs?

Madjid
 
 The EMSK is reserved for future use and MUST remain on the EAP
      peer and EAP server where it is derived; it MUST NOT be
      transported to, or shared with, additional parties, or used to
      derive any other keys.



-----Original Message-----
From: Bernard Aboba [mailto:bernard_aboba [at] hotmail.com] 
Sent: Wednesday, March 22, 2006 10:15 AM
To: jari.arkko [at] piuha.net
Cc: eap [at] frascone.com
Subject: [eap] Re: potential resolution to Issue 317

>Also fine.

Here are the proposed changes:

Remove figures 3 and 4.

Rewrite Section 2.2 as follows:

2.2  Layering

   On completion of EAP authentication, keying material and
   material and parameters exported by the EAP method are provided
   to the lower layer and AAA layer (if present).  These include the
   Master Session Key (MSK), Extended Master Session Key (EMSK),
   Peer-ID, Server-ID, Session-ID and Key-Lifetime. The Initialization
   Vector (IV) is deprecated.

   In order to preserve the security of keys derived within EAP methods,
   lower layers MUST NOT export keys passed down by EAP methods.  This
   implies that EAP keying material or parameters passed down to a lower
   layer are for the exclusive use of that lower layer and MUST NOT be
   used within another lower layer.  This prevents compromise of one
   lower layer from compromising other applications using EAP keying
   parameters.

   EAP keying material and parameters provided to a lower layer MUST NOT
   be transported to another entity.  For example, EAP keying material
   and parameters passed down to the EAP peer lower layer MUST NOT leave
   the peer;  EAP keying material and parameters passed down or
   transported to the EAP authenticator lower layer MUST NOT leave the
   authenticator.

   On the EAP server, keying material requested by and passed down to
   the AAA layer may be replicated to the AAA layer on the
   authenticator.   On the authenticator, the AAA layer provides the
   replicated keying material to the lower layer over which the EAP
   authentication conversation took place.  This enables "mode
   independence" to be maintained.

   The EMSK MUST NOT be provided to an entity outside the EAP server or
   peer,  nor is it permitted to pass any quantity to an entity outside
   the EAP server or peer from which the EMSK could be computed without
   breaking some cryptographic assumption, such as inverting a one-way
   function.  The EMSK MUST NOT be transported by the AAA layer.
   As noted in [RFC3748] Section 7.10:

      The EMSK is reserved for future use and MUST remain on the EAP
      peer and EAP server where it is derived; it MUST NOT be
      transported to, or shared with, additional parties, or used to
      derive any other keys.

   The EAP layer as well as the peer and authenticator layers MUST NOT
   modify or cache keying material or parameters (including Channel
   Bindings) passing in either direction between the EAP method layer
   and the lower layer or AAA layer.


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

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