Subject: [eap] EAP methods and key hierarchy

From: [email-masked] (Bernard Aboba)
Date: Tue, 26 Feb 2002 06:40:51 -0800 (PST)

Several of the existing EAP method drafts have issues relating to
generation of keys and key hierarchy. 

In general EAP methods cannot make assumptions about the ciphersuites that
they will be used with. Some ciphersuites (PPP DESEbis, PPP 3DES, MPPE
WEP) require only encryption keys. Other ciphersuites will require both
encryption and authentication keys. Some ciphersuites require keys unique
in each direction, others do not. 

As a result, it is a bad idea for EAP methods to include their own
ciphersuite-specific key derivation within the method specification. That
would require the EAP method to be revised for each ciphersuite. The EAP
SRP -03 draft does this, for example.

Rather, it makes more sense for the EAP method to supply generic "master
session keys", from which ciphersuite-specific keys can subsequently be
derived. In this approach, it is "master session keys" that are passed 
back from the EAP method, not the master key itself. 

The client and NAS can then derive ciphersuite-specific keys from these
master session keys. This enables the AAA server to avoid having to
implement ciphersuite-specific code. Instead this code goes on the NAS and
client (both of which need to implement the ciphersuite). 

This insulates the AAA server EAP method from having to change in response
to new ciphersuites. It also insulates the NAS from having to have any EAP
method-specific knowledge. These issues are discussed in more depth in:

http://www.ietf.org/internet-drafts/draft-aboba-pppext-key-problem-01.txt

The goal of "master session keys" is to provide sufficient
keying material to key *any* ciphersuite. For example, RFC 2716 specifies
the derivation of 6 master session keys, each 32B in length. These
correspond to Encryption, Authentication and Initialization Vectors, in
each direction. RFC 2548 describes how two of these keys (the Encryption
keys in each direction) are passed back from the AAA server to the NAS. 

In deriving master session keys from the master key, it is important that
the 6 master session keys maintain cryptographic separation from each
other. This is accomplished in RFC 2716 by deriving the master session
keys from the master key via the PRF. IKE does something similar in RFC
2409 in its derivation of SKEYID_a, SKEYID_e and SKEYID_d from SKEYID:

SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0)
SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1)
SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2)

I would like to suggest that EAP method specifications that derive keys  
need to describe how the "master session keys" (equivalent to SKEYID_d, a,
e given above) are derived from the master key (SKEYID). I would also
suggest that discussion of ciphersuite-specific key derivation, if
present, be removed and put into a separate document. That way,
ciphersuites can have a consistent method for deriving their keys from
master session keys provided by *any* EAP method. 

Unfortunately, there is no "magic bullet" that can be used to provide a
key hierarchy for a generic method. The formula above assumes a DH
exchange with cookies, for example. It *may* be possible to adapt this for
use by SRP, but in other cases, changes to the method may be
necessary. In EAP GSS, for example, a nonce exchange had to be added, and
even then, it's still not clear that the SKEYID equivalent has sufficient
entropy in all cases. 

The lesson from all this may be that sound key derivation is
quite difficult, and that rather than having each EAP method attempt to
provide a sound key hierarchy, it may make more sense to use a
cryptographic wrapper such as EAP TTLS, PEAP or PIC which both protects
the method as well as providing key derivation in a well reviewed manner. 

Comments?