eap Mailing List: EMSK Transport Text

[Narayanan, Vidya (vidyan]

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