eap Mailing List: Re: Re: Issue 262: MSK Naming

[Jari Arkko (jari.arkko]

Bernard Aboba wrote:

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

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

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

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.

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

I agree.

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

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

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.

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

Right.

--Jari