eap Mailing List: Re: Strawman -10

[Bernard Aboba (bernard_aboba]

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

Is the MSK *always* replicated to the authenticator?  Or can the 
authenticator ask for another key to be replicated instead?  This would 
imply that AAA servers would need to be modified to support this.