eap Mailing List: RE: Strawman -10

[Bernard Aboba (bernard_aboba]

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

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.