Subject: [eap] Issue 262: MSK Naming

From: Bernard Aboba <[email-masked]>
Date: Tue, 19 Oct 2004 19:22:31 -0700 (PDT)

Issue 262: MSK Naming
Submitter name: Florent Bersani
Submitter email address: [email-masked]
Date first submitted: 7/30/2004
Reference: http://mail.frascone.com/pipermail/eap/2004-July/002697.html
Document: Keying-03
Comment type: T
Priority: S
Section: 2.4, 6.1.1
Rationale/Explanation of issue
Section 2.4

*"This key is created between the EAP peer and EAP server, and is
uniquely named by the concatenation of the string "MSK", EAP Method
Type, EAP peer name, EAP server name, EAP peer nonce, and the EAP server
nonce."*

<>This imposes that all EAP methods exchange two nonces (one from the
peer and one from the server) and identify uniquely the parties (i.e.,
no "group key" for an EAP method). While this seems pretty natural, I do
not remember any text in RFC 3748 placing such requirements on EAP
methods. It is only recommended, e.g. in RFC 3748 section 7.10: "A
RECOMMENDED method is for each party to provide a nonce of at least 128
bits, used in the derivation of the MSK and EMSK.". Seems like we are
drifting from RECOMMENDED to MUST, aren't we? So as for the EAP state
machine, if the KMF is informative (which I believe because I read
"Category: informational" on the cover page of the KMF), we should make
sure that we don't (normatively) exclude EAP methods (e.g. those that
cannot name the MSK in the specified way). I bet this is worth more
discussion.

Section 6.1.1

"The EAP mechanism SHOULD provide a way of naming the EMSK"

What about the naming of the MSK?

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

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 19 Oct 2004 19:29:50 -0700 (PDT)

Some comments on this issue:

I agree that the EAP mechanism SHOULD provide a way of naming both MSK and
EMSK.  However, there are a few issues here:

[a] What are the constraints on name construction by EAP methods?  For
example, the name cannot be specific to a particular lower layer since
that would violate EAP media independence.

[b] Is there a general framework for name construction that applies
automatically to methods that currently don't include names?  For example,
where the method provides nonces and/or counters, and names both the EAP
peer and server, then the suggested naming mechanism will apply.  But is
this a requirement or a guideline?

[c] Is there a requirement for EAP method specifications?  For example, if
the EAP method doesn't meet the criteria for the name template does it
need to specify a key naming scheme for the MSK and EMSK?

As far as the two nonces is concerned, this is just one way of achieving
temporal and possibly global uniqueness. Depending on the method, it might
also be acceptable to have one or more counters used instead, assuming that
state is kept so they don't wrap.

[d] What are the uniqueness requirements on the name? For example, it
would appear to be required that key names be globally and temporally
unique for any EAP method. The global uniqueness component is accomplished
by the inclusion of the "MSK", EAP Method Type, EAP peer name and EAP
server name in the key name, and temporal uniqueness is contributed by the
peer and server nonces/counters.

However, there may be EAP methods that only identify the EAP peer
(either in the method or in the EAP-Request/Identity), but not the
EAP server. Does this compromise the uniqueness requirements?

I think not; if the peer and server nonces/counter are guaranteed
to be globally and temporally unique, then the name will also
have these properties even though the server name is not included.
In particular, it seems like the server nonce/counter now needs
to be globally as well as temporally unique, to counteract the
lack of explicit server identification.

With respect to normative language -- the EAP key framework is
informational but this doesn't preclude normative language. Most
requirements documents use normative language yet are informational.

It seems like some normative language is required under all scenarios,
because even if EAP methods need to define the name, then there is
an implied requirement that they define this in the specification,
which few if any specifications do today.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Tue, 26 Oct 2004 14:52:03 +0300

> that would violate EAP media independence.

Yes, although this does not appear to be a current problem.
We are not specifying them in lower layer terms (at least in
IETF documents).

> need to specify a key naming scheme for the MSK and EMSK?

I think we need to be pragmatic. One observation is that current
implementations (EAP itself plus any methods) don't do this
at the moment. So there's going to be an implementation change
when someone needs to do something that needs a name. Fortunately,
nothing needs a name, currently, so we just need to prepare for
this.

The second observation is that method specifications have
been published prior to the invention of the keying framework. And
probably some methods will still be published before the keying
framework becomes an RFC. So we are left with the possibilities of

   (a) specifying naming in the key framework so that its fully
       defined for every method (e.g. a hash of the key itself)
   (b) specifying naming in the key framework itself, with a
       rule plus the intepretation for existing methods, or
   (c) allowing older methods to not have names until some
       addendum to their specifications have been published

I'm inclined to go for option b.

> state is kept so they don't wrap.

I agree.

> EAP server. Does this compromise the uniqueness requirements?

I think you may be too optimistic in assuming that the inclusion of
the peer or server names accomplishes a guaranteed notion of
uniqueness.

On the client side I don't think it is mandatory to use a NAI.
NAIs would be guaranteed to have some uniqueness properties
due to the requirement to use DNS names, but on other types
of identifiers there is no guarantee about that. I might use
"jari" as my userid in EAP Identity Response, and so might
lots of other people in Finland.

On the server side we have no requirement that the server have
an identity. And even if there is an identity, there is no
guarantee that its unique globally. The server might have a
certificate that associates a public key with the identity
of, say, IP address 10.0.0.1. So, if a "jari" roams from
his home server at 10.0.0.1 to a neighbor's server that
is also at 10.0.1. and the neighbor happens to be called
"jari" too, we have a potential collision.

> lack of explicit server identification.

I don't think we should shoot for a guaranteed, managed notion
of uniqueness. Statistical uniqueness is sufficient.

What is in practise required is that we include
enough method type numbers and peer identifiers so that in
method implemenations with broken random number generators
don't lead to an immediate catastrophy. The rest is handled
with the inclusion of a random component. If the random
number is good enough then it will be both temporally and
globally unique. Note that we probably shouldn't specify
too much of where this number comes from -- on cellular
networks, for instance, the servers are better equipped
to generate good random numbers than small client devices.

Note that all the above still leaves one case where
things will fail -- when John Smith roams from his
10.0.0.1 server to another John Smith's 10.0.0.1
server and everyone involved has a bad random number
generator. But there's nothing we can do about
this, short of mandating that EAP is only used
within a global, administered name space; the cure
would be worse than the disease. And I don't feel
like we need to rescue people who have bad
implementations either.

I'll propose some text about name generation later
today.

> requirements documents use normative language yet are informational.

Right.

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Tue, 26 Oct 2004 16:48:05 +0300

Here's my text proposal. Note that this is orthogonal
to other discussion items that also may have to deal with,
such as whether the names should be of fixed size. If they
need to be, a computation with the below data as input may
be way to go.

In 2.4, change:

       This key is created between the EAP peer and EAP server, and is
       uniquely named by the concatenation of the string "MSK", EAP
       Method Type, EAP peer name, EAP server name, EAP peer nonce, and
       the EAP server nonce.  Here the EAP peer name and EAP server name
       are the identifiers securely exchanged within the EAP method.
       Since multiple MSKs may exist between an EAP peer and EAP server,
       the EAP peer nonce and EAP server nonce allow MSKs to be
       differentiated; at least one of these nonces is necessary. The
       inclusion of the Method Type in the name ensures that each EAP
       method has a distinct name space.

=>

       This key is created between the EAP peer and EAP server, and is
       uniquely named by the concatenation of the string "MSK", EAP
       Method Type, EAP peer name, EAP server name, and unique material
       defined by the method. The EAP peer name is included only if
       it is securely exchanged within the method. Otherwise a null
       string is used as the EAP peer name. The same rule applies to
       the EAP server name. The definition of "unique material" is
       left to method specifications (appendix X defines this material
       for methods that have been published prior to this specification),
       but typically consists of nonces or sequence numbers exchanged
       within the method. Since multiple MSKs may exist between an EAP
       peer and EAP server, the unique material allows MSKs to be
       differentiated; it also provides uniqueness for methods that
       do not exchange peer/server names. The inclusion of the
       Method Type in the name ensures that each EAP method has a
       distinct name space.

and

       The EMSK is named similarly to the above. Its name is the
       concatenation of the string "EMSK", the EAP Method Type, EAP peer
       name, EAP server name, EAP peer nonce, and the EAP server nonce.

=>

       The EMSK is named similarly to the above. Its name is the
       concatenation of the string "EMSK", the EAP Method Type,
       EAP peer name (if securely exchanged), EAP server name
       (also only if securely exchanged), and unique material
       defined by the method.

Also, add Appendix X:

   Appendix X. Key naming in methods published prior to naming requirements

     This appendix provides an informative specification of key
     names in methods that have been published prior to the publication
     of this RFC. What is needed in addition to the rules in Section
     2.4 is the definition of what EAP peer and server names are used,
     what method-specific unique material is used, and how these are
     encoded.

     EAP-TLS

       ... (maybe you Bernard can fill this?) ...

     EAP-AKA

       The EAP peer name is the contents of the Identity field from
       the AT_IDENTITY attribute, using only the Actual Identity Length
       octets from the beginning, however. Note that the contents are
       used as they are transmitted, regardless of whether the transmitted
       identity was a permanent, pseudonym, or fast reauthentication
       identity.

       The EAP server name is an empty string.

       The unique material is the contents of the RAND field from the
       AT_RAND attribute, followed by the contents of the AUTN field
       in the AT_AUTN attribute.

     EAP-SIM

       The EAP peer name is the contents of the Identity field from
       the AT_IDENTITY attribute, using only the Actual Identity Length
       octets from the beginning, however. Note that the contents are
       used as they are transmitted, regardless of whether the transmitted
       identity was a permanent, pseudonym, or fast reauthentication
       identity.

       The EAP server name is an empty string.

       The unique material is the contents of the RAND field from the
       AT_RAND attribute, followed by the contents of the NONCE_MT field
       in the AT_NONCE_MT attribute.

     ... others are free to submit additional items here ...
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap