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

[Florent Bersani (florent.bersani]

Hi joe, there's sth I'd like to understand:

Joseph Salowey wrote:

> Jari Arkko wrote:
>  
>
> > First, I agree with Florent's suggested change.
> >
> > But the issue you bring up Joe seems indeed a separate one,
> > or maybe even multiple ones:
> >
> > o  We can require support of a specific naming scheme in EAP, but
> >    does this imply that the keys can only be referred to these names
> >    in other protocols, or are those protocols free to choose what
> >    they want? Other candidate naming schemes the protocols could used
> >    include a hash of the EAP defined name, a hash of the key itself,
> >    time of day when the key was created, and user's shoe size.
> >
> >    Tentative suggestion: It seems sufficient that EAP provides keys
> >    and key names with the specified format and that applications can
> >    use this information or some other identifiers as best suits that
> > particular application. 
> >
> >    
>
> [Joe] In general I have issues with the format which I expressed previously.
> In particular I don't think we should specify a particular format for the
> name exported from an EAP-Mechanism.  How the name is formatted is up to the
> EAP mechanism.  We can place requirements on uniqueness and give
> recommendations on construction.  The EAP mechanism will know how best to
> generate interoperable names based on its specification.  If we need to
> specify additional names for keys etc. then we can make recommendations for
> how applications should construct a name based on the exported name.  I
> thought there was an issue open on this, I can open another one if the
> current one is not appropriate.
>  
When you speak of "an EAP-Mechanism", do you intend to refer to an EAP method or the EAP framework?

My understanding is that it is the EAP method that should be responsible for the TEK, MSK & EMSK naming and that the EAP framework should be responsible for the AMSK naming.

Indeed, as is currently specified in eap-keying section 2.4, the EAP method knows best the elements that are involved in the TEK (that's obvious) and MSK&EMSK names (e.g. the peer and server nonces).

I support the specification of a naming format for the MSK and EMSK that leaves some responsibility to the method for the details, provided we are precise enough on the format, e.g. sth like the following for the MSK.

"The MSK name is a 176 bit string that is comprised of the following fields:
o 8 bit key type subfield (e.g. type 1 for MSK, type 2 for EMSK and type 3 for 
AMSK - the other values/bits reserved)
o 8 bit EAP method type subfield - here we have probably to be careful because 
of the expanded type 254
o 160 bit method specific key identifier

The 160 bit method specific identifier MUST be an identifier that allows to refer unambiguously to the specific MSK that has been derived during this session by this method type.

Typically this identifier can be constructed as a hash of the concatenation of:
o the EAP peer name
o the EAP server name
o the EAP peer nonce
o the EAP server nonce"

Of course the cryptographic details of the construction have to be 
proof-checked and the wording wordsmithed but the intent here is to have :
o a short name that can be used in practice by protocols to refer to the key, 
if needed
o a generic construct that fosters interoperability
o a construct that leaves some details up to the EAP method, which is in best 
place to do some naming derivation

Does anybody buy this?

For AMSK, I think that, provided we resolve Issue 267 (probable outcome, which I lightly disagreed on, use a mandatory PRF), we should fully specify the naming scheme.

Last, if we fully specify the MSK/EMSK naming scheme and we put the responsibility of it on the EAP method, then 
o we have to give some "standards" authority to the document
o we have to discuss how this impacts EAP methods, for instance EAP-SIM and EAP-AKA that IIRC do not specify MSK and EMSK names, do they?

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

:-(((

Would a new EAP method which requests an EAP method type be compelled to follow eap-keying and name its keys?

Other solution: drop key naming ;-)

Florent, what a mess