Subject: [eap] EMSK Transport Text

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 6 Apr 2006 01:08:36 -0700

Section 2 in draft-ietf-eap-keying-11 says: 

"   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." 

Also, figure 2 shows an export of the EMSK outside the EAP method,
without actually showing the layer that receives it. 

I realize that this may be intentionally left unspecified to allow
either the EAP layer or the AAA layer to receive the key, depending on
which layer made the m.getKey() call. However, I wonder if it leads to
this situation: 

A. When the EAP server and the AAA server are collocated, the AAA layer
may get the EMSK.
B. When the EAP server and the AAA server are NOT collocated, it may be
the EAP layer or the AAA layer in the EAP server that gets the EMSK. 

If the goal is to intentionally leave this open to be specified in a
future spec, that would be fine. However, if this text is going to
restrict future specs, that would be a problem. This also applies to the
"MUST NOT be ... Used to derive any other keys". Is there a reason why
we cannot leave it at "MUST NOT be transported to, or shared with,
additional parties"? Also, I wonder if it makes sense to state that a
future spec may define different usage of the EMSK (without violating
the transport requirement, of course)?

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

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

---

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Thu, 6 Apr 2006 17:57:13 -0400

While I have no issue with the first paragraph, I don't understand the
composition of the subparagraph. Sure it is understandable to prohibit
EMSK distribution to third parties, but why are we prohibiting its use
within the parties who derived it?
Don't we think saying EMSK is future use and then say EMSK is not to be
used for this or that is a bit contradictory? 
Either its future use is undefined and is to be defined by other docs or
we have some idea about its future use. Why are going to length
prohibiting the most probable use case of the EMSK while leaving the
rest of use cases open??