Re: Strawman -10
From: Yoshihiro Ohba (yohbatari.toshiba.com)
Date: Wed, 1 Feb 2006 07:56:23 -0800 (PST)
On Tue, Jan 31, 2006 at 02:01:26PM -0800, Salowey, Joe wrote:
> 
> > 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.  

The channel-binding draft allows KDF to be provided by an EAP method
while still satisfying the requirements of mode independence.

Yoshihiro Ohba


> 
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/eap
> 
> Arhives: http://lists.frascone.com/pipermail/eap
> 
> 

Results generated by Tiger Technologies using MHonArc.