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

[Joseph Salowey (jsalowey]

Florent Bersani wrote:
> 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?
> 

[Joe] Here I mean an EAP-Method

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

[Joe] I look at this slightly differently. I think the EAP-Method should be
responsible for naming the state resulting from an instance of an EAP
Transaction. The framework should be responsible for creating names for the
MSK and EMSK (if it needs it) and the applications should be responsible for
naming the AMSK.  These names should be based on the name that the
EAP-Method exported. However I'm not sure if framework is a "standard"
concept so it may be that the method must generate these names. 

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

[Joe] I think I agree with you, but I think these subfields may be best
added by the framework.  

> 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"
> 

[Joe] I agree that a fixed length value would be useful to export

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

[Joe] There needs to be an interface from the application to the
EAP-Framework to retrieve AMSKs.  This could be done in several ways.  In
general an application would probably specify which AMSKs it wanted to
retrieve from the framework during the EAP transaction.  The EAP-Framework
would return these keys at the end of the transaction along with the MSK.
This basically assumes that the AMSKs that are needed are known ahead of
time and the EAP-Framework can delete its knowledge of the EMSK after the
transaction is complete.  In this case a name could be returned with a key
as a way to identify the or the application can generate its own identifier
in an application.  It would also be possible to keep the EAP-keying
material within the framework for an extended period of time.  In this case
an application could request the key after the transaction has passed.  In
this case a standard way of naming the key is probably necessary, but I
don't prefer this mode of operation. 

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

[Joe] So we can create a standards track document (either this one or
perhaps we split this one into normative and informative) that contains the
details of how to create names and EMSKs for methods already specified such
as EAP-TLS (and hopefully) EAP-SIM and EAP-AKA. 

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

[Joe] Yes, at least the normative parts. 

> Other solution: drop key naming ;-)
> 
> Florent, what a mess

[Joe] Given that there aren't too many methods finalized and that the EMSK
usage is just starting to be defined I think we have an opportunity to clean
this up.