eap Mailing List: RE: Re: Rewrite of Section 2 of the EAP Key Management Framework

[Salowey, Joe (jsalowey]

> -----Original Message-----
> From: Bernard Aboba [mailto:aboba [at] internaut.com] 
> Sent: Thursday, October 06, 2005 10:36 PM
> To: Salowey, Joe
> Cc: eap [at] frascone.com
> Subject: RE: [eap] Re: Rewrite of Section 2 of the EAP Key 
> Management Framework
> 
> > - I am not sure that a lower layer MUST NOT export keys 
> passed down by 
> > EAP methods to other lower layers.  It should at least be 
> possible for 
> > a lower layer to export keys derived from keys passed down by EAP 
> > methods to other lower layers.
> 
> The problem with sharing keys between media is that it 
> creates cascading vulnerabilities.  If one media has a weak 
> ciphersuite that results in key compromise, then if keys are 
> shared between media, this could result in compromise of a 
> key used on another media with a strong ciphersuite. 
> 
> At IETF 62, Sam Hartman brought up this point. 
> 
> The one exception to this is AAA, which shares keying 
> material received by the AAA client with the EAP authenticator. 
> 

[Joe] I agree that the same key should not be used for two different
purposes, however it should be possible for an implementation of a
"lower layer" to use a key to derive keying material to be used within
it's domain of applicability.  These derived keys may actually be used
by different entities.  Here is a possible revision to clarify this:

" In order to preserve separation of keying material and security
considerations fort lower layers separate,
   lower layers MUST NOT export keys passed down by EAP methods outside
their domain of control.  This implies that EAP keying material or
parameters passed down to a lower layer are for the exclusive use of
that lower and MUST NOT be used within another lower layer for a
different purpose."


> > - The EMSK MUST NOT be exported to a lower layer.  AMSKs 
> derived form 
> > the EMSK may be exported.
> 
> The EAP method calculates the EMSK and exports it.  Methods 
> do not calculate AMSKs.  The EAP layer cannot know whether 
> the lower layer will calculate AMSKs or not.  So the EAP 
> layer really has no choice but to pass the EMSK down to the 
> lower layer. 
> 

[Joe] Perhaps methods should deal with derivation of AMSKs.  I don't
think it is appropriate for the EMSK to be passed down to any lower
layer.  I also don't think it is appropriate to call AAA a lower layer
as it is a bit confusing and a special case.  I think between the
EAP-Server and EAP-Authenticator is a key distribution (or perhaps
parameter distribution) "layer" which controls the distribution (and
perhaps derivation) of keys.  When there is AAA involved this
distribution layer uses the AAA protocol between the AAA server and AAA
client.  When there is no AAA involved then the distribution layer is
local between the EAP implementation in the lower layer.  The
distribution layer may help clarify the above exception to lower layers
and exported key material. 

> On the other hand, I think it makes sense to say that AAA 
> MUST NOT transport the EMSK, or that the EAP peer or 
> authenticator MUST NOT use the EMSK directly.  It also makes 
> sense to say that existing lower layers (including AAA) do 
> not cache the EMSK. 

[Joe] I agree with this.