eap Mailing List: Re: Strawman -10

[Rafa Marin Lopez (rafa]

Bernard Aboba wrote:

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

Yes i noticed that. My thought was  that,  depending on the case, 
authenticator lower layer would receive MSK, EMSK or not. Your answers 
confirm that.

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

In the case of pass-through authenticator, MSK is available, but when 
you say quantity (of EMSK I guess),  you mean any AMSK derived from EMSK?? .

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

Well, actually, lower layer authenticator implementation should expect 
(MSK,EMSK) in the case EAP method is executed by the standalone 
authenticator or (MSK,AMSK) in the case EAP method is executed by 
backend authentication server. If it receives (MSK,EMSK) should create 
AMSK and delete EMSK. If it receives (MSK,AMSK) , that's all, correct?

> If that is done, the end cryptographic state on the authenticator is 
> the same in either the pass-through or standalone case.

About the end state,  I agree.

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

This makes sense for me. Personally I think clarifying this in some 
place might be useful.

Thanks.

>


--
------------------------------------------------------
Rafael Marin Lopez
Faculty of Computer Science-University of Murcia
30071 Murcia - Spain
Telf: +34968367645    e-mail: rafa [at] dif.um.es
------------------------------------------------------