Subject: Re: RFC 2284bis issues

From: Paal Engelstad <[email-masked]>
Date: Wed, 27 Feb 2002 21:10:53 +0100

> A further document, draft-aboba-pppext-key-problem-01.txt provides
> details on the nature of the "keys" provided by EAP methods, and the
> requirements for EAP methods deriving keys. 
> 

I pointed out on the list a couple of weeks ago that PANA should take this key-problem draft into consideration, and clarify issues around session keys:

On one hand "key distribution or key agreement protocols, or key derivation" is defined as outside the PANA charter. On the other hand, the requirements draft suggests a local SA for re-authentication to optimize performance. I have problems seeing this done without using some local, temporary session key. 

Could anyone clarify this for me?

Thanks,
Paal

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 27 Feb 2002 13:22:53 -0800

Paal,

> I pointed out on the list a couple of weeks ago that PANA should take this
key-problem draft into consideration, and clarify issues around session
keys:
>
> On one hand "key distribution or key agreement protocols, or key
derivation" is defined as outside the PANA charter. On the other hand, the
requirements draft suggests a local SA for re-authentication to optimize
performance. I have problems seeing this done without using some local,
temporary session key.
> Could anyone clarify this for me?

PANA is not going to *define* such methods, but can *use* existing methods.

alper

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 27 Feb 2002 13:34:35 -0800 (PST)

There are several types of keys that are used with EAP, and a lot of
confusion about the distinctions between them. The draft attempts to
explain the distinctions. 

Within individual EAP methods there is typically a "master secret" which
is derived, but which is often not exportable. An example is the TLS
master secret. 

Very often, it is possible to support "fast reconnect" by doing a nonce
exchange and proving possession of the master secret. This is supported by
TLS, for example. The result is that the resumption requires no public key
operations and many fewer round-trips as well. 

Because the "master secret" is typically not exportable, it is never sent
over the wire, and the NAS never obtains access to it. This is deliberate,
because otherwise the NAS would be able to impersonate the client. 

Instead, "master session keys" are derived from the master secret via a
one-way function. It is this keying material that is provided to the
NAS by the AAA server, and used to generate the ciphersuite-specific keys. 
Because the master secret cannot be obtained from the master session keys
(that's guaranteed by use of a one-way function), the NAS cannot
impersonate the client in the "fast reconnect" exchange, because it
doesn't possess the master secret. 

The key derivation algorithm that generates the master session keys must
provide cryptographic separation between encryption, authentication and
IVs in each direction, so that the same key isn't used for different
purposes. It also must guarantee that sufficient entropy is available in
the master session key derivation to guard against compromise. 

For example, you would not want to derive the 6 32B master session keys
from a master secret that only had 40 bits of entropy. Even though each of
the 6 master session keys would be 256-bits long the aggregate would still
only have 40 bits of entropy and the keys could be easily cracked. 

This implies, among other things, that the key derivation mechanisms in
individual EAP methods need to be *very* carefully reviewed. Unless there
is a compelling reason to the contrary, it is probably best to reuse
existing well understood key derivation mechanisms such as TLS and IKE,
rather than inventing, analyzing and validating new ones. 

Part of the reason for the interest in crytographic wrappers for EAP (as
described in PIC, PEAP and EAP TTLS) is that using IKE or TLS as a wrapper
makes it possible to leverage "known good" key derivation algorithms, as
well as providing other benefits such as cryptographic protection of the
EAP exchange, immunity against dictionary attacks (for password based
methods), etc.