Re: Strawman -10
From: Yoshihiro Ohba (yohbatari.toshiba.com)
Date: Tue, 7 Feb 2006 09:32:53 -0800 (PST)
On Tue, Feb 07, 2006 at 06:58:07AM -0800, Bernard Aboba wrote:
> >Do we really want to require EAP methods to support KDFs in order to 
> >enable the lower layer to generate keys from the EMSK?  That would mean 
> >that existing EAP methods wouldn't be usable on some lower layers.   One 
> >of the major advantages of EAP is the ability to support many lower layers.
> >
> >What Joe proposes does not lead to that problem. He said "default + 
> >optional negotiation ability in methods".
> 
> Are we saying that the EAP method would negotiate the KDF to be used by the 
> EAP layer in generating AMSKs?  Wouldn't this require EAP methods to be 
> aware of what KDFs are supported by the EAP layer?  

Yes, this is true.

> What if an EAP method 
> didn't support KDF negotiation and yet the default KDF is not legal for use 
> in a given environment?  I ask because HMAC-SHA1 (on which the default KDF 
> is based) may be phased out by NIST.
> 
> The original thread was actually discussing Yoshi's proposal, I think.  In 
> that proposal, the MSK is not replicated to the authenticator.  Instead, a 
> new "Channel Binding" key is replicated instead.  Presumably the use of the 
> "Channel Binding" key is negotiated by the lower layer, so that it is 

In draft-ohba-eap-channel-binding-00.txt, the use of the "Channel
Binding" key does not need to be negotiated by the lower layer.
Instead, the negotiation is required by EAP method.

> generated from the MSK on both the EAP peer and server.  However, this 
> implies that the key state will not be identical in the pass-through and 
> standalone cases, since the authenticator would obtain the MSK in the 
> standalone case and generate the "Channel Binding" key from it, whereas in 
> the pass-through case it would only obtain the Channel Binding key.

I would mention that the final key state is identical in the
pass-through and standalone cases.  This is similar to how EMSK/AMSK
is supposed to be maintained in the EAP keying framework, isn't it?

> 
> Is the MSK *always* replicated to the authenticator?  

The negotiation on the use of "Channel Binding" key by EAP method will
determine which key is used.

> Or can the 
> authenticator ask for another key to be replicated instead?  

I don't expect it at least when "Channel Binding" key is applied to
MSK branch.  When "Channel Binding" key is applied to EMSK branch, I
don't know what authenticator should behave, because I don't know
(yet) how EMSK is going to be used :)

> This would 
> imply that AAA servers would need to be modified to support this.
> 

Yoshihiro Ohba



Results generated by Tiger Technologies using MHonArc.