Subject: [eap] Re: Issue 362: Lower layer parameters and EMSK text

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 08 May 2006 07:32:57 -0700

Move the following text from Section 2 to Section 1.4:

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

Change the last four paragraphs of Section 2 to the following:

" 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 passed down to a lower layer is 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 provided to a lower layer MUST NOT be transported
to another entity. For example, EAP keying material passed down to
the EAP peer lower layer MUST NOT leave the peer; EAP keying
material passed down or transported to the EAP authenticator lower
layer MUST NOT leave the authenticator.

On the EAP server, keying material and parameters 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 and parameters to the lower layer over
which the EAP authentication conversation took place. This enables
"mode independence" to be maintained.

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

-------------------------------------------------------------------------------------
Issue 362:  Lower layer parameters and EMSK text
Submitter name: Joe Salowey
Submitter email address: [email-masked]
Date Submitted: May 2, 2006
Reference: http://lists.frascone.com/pipermail/eap/msg04247.html
Document: KEYING-12
Comment type: 'E'ditorial
Priority: '1' Should fix
Section: 2
Rationale/Explanation of issue:

1. Passing of parameters to lower layer.  It seems that there may be
some parameters passed to lower layers that could be usable elsewhere.
For example the Session-ID might be usable.  If the session-id is
included in parameters then I think the  following may be to
restrictive:

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

Suggested change:

"This implies that EAP keying material passed down to a lower
layer are for the exclusive use of that lower layer and MUST NOT be
used within another lower layer."

If this change is accepted there are several other places in the section
where this should be changed.

2. EMSK text

The First paragraph still mentions exporting the EMSK to the lower layer
which seems to be problematic when considered with the rest of the text
of this section.  I don't think the EMSK should be discussed in the
lower layer section.

My suggestion would be to remove references to the EMSK in this section
and move the paragraph discussing the EMSK to Section 1.4 EAP Key
hierarchy.

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

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

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 9 May 2006 10:33:35 -0700

> "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. As noted in 
> [RFC3748] Section 7.10:
> 

Are we sticking to this rule that the EMSK MUST NOT be used to derive
any other keys? Given that there is agreement in general about potential
derivation of keys from the EMSK, what implications does this text have
to future documents specifying derived keys from the EMSK? 

> " 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 passed 
> down to a lower layer is 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 provided to a lower layer MUST NOT be 
> transported to another entity. For example, EAP keying 
> material passed down to the EAP peer lower layer MUST NOT 
> leave the peer; EAP keying material passed down or 
> transported to the EAP authenticator lower layer MUST NOT 
> leave the authenticator.
> 
> On the EAP server, keying material and parameters requested 
> by and passed down to the AAA layer may be replicated to the 
> AAA layer on the authenticator. 

I understand what the above is trying to say - however, this does
conflict with the fact that the EMSK MUST NOT be transported to the
authenticator (even though it may be passed down to the AAA layer on the
server). I wonder if some clarification is necessary to avoid confusion.

> On the authenticator, the AAA 
> layer provides the replicated keying material and parameters 
> to the lower layer over which the EAP authentication 
> conversation took place. This enables "mode independence" to 
> be maintained.
> 
> 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."
> 

The above works for the MSK, but may not work for the EMSK - as we flush
out the usage for EMSK, we may find that caching may need to be allowed.
So, a MUST NOT seems too strong - MUST NOT modify makes sense; whereas,
SHOULD NOT cache keying material may be more appropriate. 

Regards,
Vidya

> Issue 362:  Lower layer parameters and EMSK text Submitter 
> name: Joe Salowey Submitter email address: [email-masked] 
> 1. Passing of parameters to lower layer.  It seems that there 
> may be some parameters passed to lower layers that could be 
> usable elsewhere.
> For example the Session-ID might be usable.  If the 
> session-id is included in parameters then I think the  
> following may be to
> restrictive:
> 
> "This
> layer are for the exclusive use of that lower layer and MUST 
> NOT be used within another lower layer."
> 
> If this change is accepted there are several other places in 
> the section where this should be changed.
> 
> 2. EMSK text
> 
> The First paragraph still mentions exporting the EMSK to the 
> lower layer which seems to be problematic when considered 
> with the rest of the text of this section.  I don't think the 
> EMSK should be discussed in the lower layer section.
> 
> My suggestion would be to remove references to the EMSK in 
> this section and move the paragraph discussing the EMSK to 
> Section 1.4 EAP Key hierarchy.
> 
>

---

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Tue, 9 May 2006 18:17:58 -0400

-----Original Message-----
From: Bernard Aboba [mailto:[email-masked]] 
Sent: Monday, May 08, 2006 9:33 AM
To: [email-masked]
Subject: [eap] Re: Issue 362: Lower layer parameters and EMSK text

Madjid>>Why do we prohibit use of EMSK in deriving other keys? I was
under the assumption that it was the intention to leave to specification
of EAP keying fwk extensions, such as derivation of AMSK to future
activities. The current text prohibits any such derivation. Is this the
intent?

"prohibiting" something is different from saying "it will be defined
later".

Why can't we replace the last phrase with:

"The Use of EMSK in deriving any other keys will be part of future
specifications"?

Thanks,

Madjid