eap Mailing List: Re: Issue 262: MSK Naming

[Bernard Aboba (aboba]

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.