eap Mailing List: RE: Strawman -10

[Salowey, Joe (jsalowey]

> -----Original Message-----
> From: Bernard Aboba [mailto:bernard_aboba [at] hotmail.com] 
> Sent: Tuesday, January 31, 2006 1:37 PM
> To: Salowey, Joe
> Cc: eap [at] frascone.com
> Subject: RE: [eap] Strawman -10
> 
> >[Joe] I must not have been clear. That was not my intent, 
> which change
> >request was this?  The EMSK must not be directly used by the lower
> >layer.  If it is then you might as well just eliminate it since it
> >serves the same purpose as the MSK.
> 
> Issue 320, which you submitted on December 1, 2005 removes 
> the prohibition 
> on lower layers obtaining the EMSK.
> 
> It is possible to say that the EMSK "must not be directly 
> used by the lower 
> layer" without prohibiting lower layer access to the EMSK.  
> So those two 
> statements are not necessarily inconsistent.
> 

[Joe] yes. From an implementation point of view it is possible, however
architecturally there needs to be separation. In a particular local
authenticator implementation the lower layer may have access to the
EMSK, however things should not be defined such that a lower layer must
have access to the EMSK. 


> For example, the lower layer could be allowed to obtain the 
> EMSK but be 
> prohibited from transporting it or using it directly.
> 
> The difference is subtle, but potentially important for 
> issues such as 
> crypto-agility.  Allowing the lower layer to obtain the EMSK 
> enables the 
> lower layer to negotiate the PRFs used in AMSK generation, 
> whereas this is 
> not possible if AMSK generation is handled in the EAP layer.  It also 
> maintains backward compatibility so that a lower layer using 
> the AMSK can be 
> introduced without requiring changes to existing EAP implementations.
> 
> As long as the EAP peer does not need to be aware of whether the 
> authenticator is configured in standalone or pass-through 
> mode, I think that 
> the requirements of mode independence have been met.

[Joe] This worries me.  It ties the key derivation to the lower layer,
which could be problematic.  A goal of the EMSK to AMSK derivation is to
contain the problem of a misbehaving lower layer to the lower layer
itself.  A lower layer that determines the key derivation algorithm
conflicts with this goal.  What happens if there are multiple AMSKs
being derived for different purposes? Who decides the KDF?   

I think I would prefer to see a default KDF specified with the
capability of an EAP method to override it with a KDF of its own.