eap Mailing List: Re: Issue on eap-keying: naming of AMSks

[Jari Arkko (jari.arkko]

Florent Bersani wrote:

> So we would now have an even bushier jungle of EAP methods:
> o those which do not derive keys
> o those which derive keys but do not speak of EMSK... e.g.
> EAP-TLS o those which derive MSK and EMSK but do not name
> them o those which derive MSK and EMSK but do not name them

Hold it. We need to be clear about what the situation is
in the current RFCs already. Here's what RFC 3748 says:

   "... an EAP method supporting key
   derivation MUST export a Master Session Key (MSK) of at least 64
   octets, and an Extended Master Session Key (EMSK) of at least 64
   octets."

So, EMSK derivation is already required. Secondly,
we also need to be clear about what is NOT specified.
RFC 3748 also says "The EMSK is reserved for future
uses that are not defined yet." Also, RFC 3748 did
not specify any naming scheme for the keys. This is
not a problem for MSK because such name isn't currently
used. And it isn't a problem for future use of MSK
or EMSK because that is yet to be defined, and it should
be the job of the EAP keying framework to do this.

Yesterday we also discussed the mandatory nature of
the naming schemes. I thought we concluded that one
standard set of names is exported out of EAP. There
may be uses of EAP where grandmother's shoe size
is used as a key name, but all we care about is that
we gave them the unique name.

Finally, we need to separate specifications and
implementations. It might be the case that the
generation of a key name for EMSK coming out of
EAP TLS implies a change to the implementation of
EAP TLS. However, I don't see it as implying a change
to the specification -- as long as we do a good job
at the keying framework and make sure that we fully
specify the naming, and make it compatible with whatever
has been published before (which appears easy as past
methods did not say anything about this). So I think
this means that the classification of EAP methods is
{non-kg, kg} and the classification of EAP implementations
is {rfc3748compliant, rfc3748andkeyframeworkcompliant}.

Comments?

--Jari