eap Mailing List: Re: Strawman -10

[Bernard Aboba (bernard_aboba]

> > The text forbidding the export was removed in Issue 320 with the following 
> > proposed change, so it would appear to me that the export is now allowed.
>
> I see. But I was wondering for example in the case of standalone 
> authenticator : will only MSK be available to lower layer as usual or both 
> (MSK,EMSK) now?

Note that the language relating to transport of the EMSK has not been 
touched so that restriction remains.

In the passthrough case, the authenticator lower layer will not receive the 
EMSK, whereas it will receive it in the standalone case.  Since the peer 
does not know which case is being run, this implies that the lower layer 
cannot derive the TSKs directly from the EMSK, but only from a quantity that 
is always available within the authenticator lower layer.

As long as the keys that the lower layer depends on are always available on 
the authenticator, this doesn't violate mode independence from the  peer's 
point of view.  I'm not sure it necessarily violates it on the authenticator 
either, as long as the EMSK is destroyed after computation of the AMSK.  If 
that is done, the end cryptographic state on the authenticator is the same 
in either the pass-through or standalone case.

One advantage of this approach is that it keeps implementation of 
cryptography out of the EAP layer.  Allowing cryptographic operations in the 
EAP layer is a problem because EAP does not  support cryptographic 
negotiation, so that negotiation of cryptographic algorithms such as PRFs 
would require changes to existing EAP methods.  By doing those calculations 
in the lower layer, instead, the Secure Association Protocol can negotiate 
the cryptographic algorithms and this problem is avoided.