eap Mailing List: Re: Strawman -10

[Jari Arkko (jari.arkko]

Salowey, Joe wrote:

> [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.  
>  
I share these concerns, and would also like to see the
default scheme rather than move EMSK to the lower
layers.

The problem with the lower layer usage of EMSK is that
we know that its quite likely there will be some link layer
which gets the key generation wrong. At that point, the
EMSK is compromised for other link layers, too.

At a high level, we have currently two quantities, the MSK
and the EMSK. The MSK is being used by lower layers, whereas
the EMSK is not. We are thinking of possible applications
of EMSK. But I would caution freeing up its use to lower
layers. This is the only remaining quantity that we have
left in EAP, and there's no going back from that decision
if we take it. In a sense, what I understand the strawman
says is that EMSK would become similar to MSK, but have
stricter requirements (e.g., no direct use). [If we really
wanted to get a MSK++ we could define MSK++ = prf(EMSK),
but I'm not sure its worth the trouble.]

--Jari