Subject: [eap] Issue on eap-keying: naming of AMSks

From: Florent Bersani <[email-masked]>
Date: Mon, 04 Oct 2004 15:40:59 +0200

Description of issue: should AMSK naming be mandatory?

    Submitter name: Florent Bersani

    Submitter email address: [email-masked]

    Date first submitted: 10/04/2004

    Document: Keying Framework

    Comment type: 'E'ditorial

    Priority: 1 should fix

    Section: 2.4

    Rationale/Explanation of issue:

section 2.4 reads:  "AMSK Name

       AMSKs, if any, may be named by the concatenation of the string
       "AMSK", key label, application data (see Appendix F), and EMSK
       Name."

However, I think it is sound practice to name keys. Since AMSK are new, 
we shouldn't be bothered with legacy reasons. Hence, why not make this 
AMSK naming "mandatory"

Requested change

Replace the previous text by
"AMSK Name

AMSKs, if any, are named by concatenating the string
       "AMSK", key label, application data (see Appendix F), and EMSK
       Name."

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Tue, 05 Oct 2004 00:04:30 +0300

I agree with the suggested resolution. --Jari

---

From: "Joseph Salowey" <[email-masked]>
Date: Mon, 4 Oct 2004 21:04:22 -0700

It seems that the definition of the AMSK name may be up to the application
that is using the key.  I suppose it is fine to define a name, but I'm not
sure it is good to expect application to use that name.  This brings up
another topic.  I think in many cases a fixed length name may be more useful
(perhaps this is an ID, who knows).   The current naming schemes can lead to
long variable length names.  I would rather (or also) like to see schemes
that result in a fixed length name (or ID).

---

From: Jari Arkko <[email-masked]>
Date: Tue, 05 Oct 2004 14:53:28 +0300

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.

o  String concatenation names vs. hash results. Should we have short
    or long names, or possibly both? (Didn't we discuss this at one time?
    Or was it about the use of the keys themselves as a basis for the
    names?)

    Tentative suggestion 1: We could require the support and delivery of
    the specified long names from EAP point of view, but allow application
    protocols to perform a hash to shorten the name, if appropriate.

    Tentative suggestion 2: Specify that names are hashes of the currently
    defined strings. It seems that the issue of deciding which hash function
    to use is not a problem, because we have already chosen a particular
    function for the AMSK generation.

--Jari

---

From: Florent Bersani <[email-masked]>
Date: Tue, 05 Oct 2004 16:29:58 +0200

Joe, Jari

>    use this information or some other identifiers as best suits that

I agree. Perhaps we capture that in eap-keying. By including sth in the 
key naming section, saying that:
"It is RECOMMENDED that Applications use the key names defined in this 
document to refer to specific EAP Keying material, however applications 
may very well use their own naming scheme to refer to this keys"
Does that sound good?

>    Or was it about the use of the keys themselves as a basis for the

IIRC, the latter. It was feared that using some hash of the key to name 
it would lead to some vulnerability (e.g. brute force/dictionary attack).
I don't recall any definite conclusion on this one. My two cents: while 
their may be correct ways to do this (OWF), it is true that from an 
information theoretic PoV, there is some leakage, which probably 
accounts for this option not being conservative (if the hash function's 
one-wayness is in trouble then the key naming scheme is in great trouble).
I'll take this to the CFRG to get educated advice

>    function for the AMSK generation.

I'd favor #2
If we don't provide usable names. Applications will either define their 
own ones from scratch or hash ours (and make possibly some mistake here).
So I'd favor a 128 or 160 bit key name.

---

From: Jari Arkko <[email-masked]>
Date: Tue, 05 Oct 2004 18:29:05 +0300

> may very well use their own naming scheme to refer to this keys"

Ok.

> So I'd favor a 128 or 160 bit key name.

Fine with me!

--Jari

---

From: "Joseph Salowey" <[email-masked]>
Date: Tue, 5 Oct 2004 14:18:01 -0700

>     use this information or some other identifiers as best suits that

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

>     to use is not a problem, because we have already chosen a
>     particular function for the AMSK generation.
> 

[Joe] Yes we did have a discussion before.  I still think short names or IDs
are useful.  I think we will probably have to limit the length of names
anyway.  In particular I also think this is more of an issue for names
exported from the EAP mechanism rather than names for the AMSK.   

> --Jari
> 
>> It seems that the definition of the AMSK name may be up to the
>> application that is using the key.  I suppose it is fine to define a
>> name, but I'm not sure it is good to expect application to use that
>> name.  This brings up another topic.  I think in many cases
> a fixed length name may be more useful
>> (perhaps this is an ID, who knows).   The current naming schemes can
>> lead to long variable length names.  I would rather (or also) like
>> to see schemes that result in a fixed length name (or ID).
>> 
>>>       "AMSK", key label, application data (see Appendix F), and
>>> EMSK Name." 
>>> 
>>> However, I think it is sound practice to name keys. Since AMSK are
>>> new, we shouldn't be bothered with legacy reasons. Hence, why not
>>> make this AMSK naming "mandatory"
>>> 
>>> 
>>> 
>>> Requested change
>>> 
>>>       "AMSK", key label, application data (see Appendix F), and
>>> EMSK Name."

---

From: Florent Bersani <[email-masked]>
Date: Wed, 06 Oct 2004 11:10:04 +0200

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

>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

---

From: "Joseph Salowey" <[email-masked]>
Date: Wed, 6 Oct 2004 04:55:48 -0700

Florent Bersani wrote:
>>> But the issue you bring up Joe seems indeed a separate one, or
>>> maybe even multiple ones: 
>>> 
>>>    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. 
>>> 
>>>    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. 
>> 
>> 

[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 discuss how this impacts EAP methods, for
> instance EAP-SIM and EAP-AKA that IIRC do not specify MSK and EMSK
> names, do they? 
> 
> 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 ;-)

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

---

From: Thomas Otto <[email-masked]>
Date: Wed, 6 Oct 2004 22:55:02 +0200

> o those which derive MSK and EMSK but do not name them

The last two items ... should it be
o those which derive MSK and EMSK and name them ?

---

From: Florent Bersani <[email-masked]>
Date: Thu, 07 Oct 2004 08:35:37 +0200

>o those which derive MSK and EMSK and name them ?
Yes, the last two bullets should indeed read:
<>o those which derive MSK and EMSK but do not name them
o those which derive MSK and EMSK and name them

Thanks for spotting this typo and my apologies for making it!
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Thu, 07 Oct 2004 16:12:33 +0300

> 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