Subject: EAP methods and key hierarchy

From: Bernard Aboba <[email-masked]>
Date: Wed, 13 Feb 2002 09:08:06 -0800 (PST)

draft-ietf-pppext-eap-srp-03.txt has some issues relating to generation of
keys and key hierarchy. These problems are common to a many of the EAP
method specifications which derive keys. 

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. 

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-00.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. I would also suggest that
discussion of ciphersuite-specific key derivation be removed and
put into a separate document. That way, PPP ciphersuites can have a
consistent method for deriving their keys from  master session keys
provided by *any* EAP method. 

In the case of SRP, it looks to me like something close to the IKE or NIST
key derivation mechanism could be made to work. The question I have is
what takes the place of the "cookies" CKY-I and CKY-R in the formula
above. 

I'd note that some of the same issues have come up with EAP GSS -- and we
had to add a nonce exchange to the protocol in order to address this.

---

From: James Carlson <[email-masked]>
Date: Wed, 13 Feb 2002 16:43:15 -0500 (EST)

> method specifications which derive keys. 
[...much good explanation deleted...]

Yep; I fully agree.  If there's more than one EAP method that can do
this, then it ought to be in a separate document.  I'll rip out the
affected subsections on the assumption that they'll be put (in some
form) into a more general document.

On the draft:

> Knowledge assymmetry [sic]
>                In practice, an EAP method may not have knowledge of the
>                ciphersuite that has been negotiated. In PPP, negotiation
>                of the ciphersuite is accomplished via the Encryption
>                Control Protocol (ECP), described in [10].  Since ECP
>                negotiation occurs after authentication, unless an EAP
>                method is utilized that supports ciphersuite negotiation
>                (such as EAP-TLS [32]), the client, NAS and backend
>                authentication server may not be able to anticipate the
>                ciphersuite that will be used and therefore this
>                information cannot be provided to the EAP method.

Actually, it was my assumption that it was the master session key that
would be sent from the AAA server to the NAS, and then the NAS would
apply the rules I gave to calculate the per-algorithm keys during ECP
negotiation time.  Clearly, it would not be good to have the AAA
server try to "guess" at the ECP negotiation outcome.

> provided by *any* EAP method. 

That makes sense to me.  Actually, these key derivations for the PPP
ciphersuites should be put into new versions of the PPP ECP method
RFCs.  There's no reason to have a "master list" of these that will
need to be maintained.

> what takes the place of the "cookies" CKY-I and CKY-R in the formula

If the prf() is sound, do they need to have special properties?  (And
is there any reason not to copy that method directly?)

-- 
James Carlson, Solaris Networking         <[email-masked]>
SUN Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677

---

From: James Carlson <[email-masked]>
Date: Wed, 13 Feb 2002 16:54:08 -0500 (EST)

> RFCs.  There's no reason to have a "master list" of these that will

In the "spoke too soon" department:

Failing to send the actual master key to the NAS (which is what I
assumed for the AAA usage with EAP SRP-SHA1) breaks the lightweight
rechallenge mechanism: you need that master key at the NAS to prove
you are still who you say you are.

I think the AAA server should return the master key material that it
has without attempting to "regularize" it in any form.  The NAS side
should (1) determine if it has enough material to use a ciphersuite
securely and (2) use a per-ciphersuite fixed algorithm to derive any
necessary keying.

In other words, the 'K' from SRP should be sent by the AAA server to
the NAS.  There should be separate documents for each of ECP DES, ECP
3DES, et cetera, that describe:

	- the minimum number of bits that are needed to form the
          session keys -- if the AAA server provides fewer, then don't
          negotiate with that encryption method.

	- the mechanism that is used (regardless of the number of
          bits) to cobble together the keys needed.  This part could
          be based on the NIST algorithm (or, really, any hash with
          suitable properties).

	- the specific ways in which the derived keys are used (which
          bits are key, which are IV, and which apply in which
          direction on the link).

---

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

> server try to "guess" at the ECP negotiation outcome.

Yes, that is correct.

> RFCs.  There's no reason to have a "master list" of these that will

Yes, I think that's the logical place for them to go. If there is no plan
to revise the methods, then they can go in a separate RFC (see RFC 3079
for an example of such a specification). 

> is there any reason not to copy that method directly?)

In this case, I believe that the cookies serve to ensure "liveness" of the
key for that particular session. Since they are sent in the clear, they
don't really add entropy. 

Perhaps someone familiar with the recent work on NIST key derivation
work can comment on what makes a good key derivation function?

---

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

> you are still who you say you are.

It is not necessary to send the master key in order to implement a
lightweight rechallenge mechanism. For example, EAP TLS supports
session resumption without having to send the TLS master secret to the
NAS. In that case, new nonces are exchanged, and are used to calculate
another master secret, from which new master session keys can be derived. 

Among other things, sending the master key to the NAS is a security issue,
since it can enable the NAS and Proxy to impersonate the user. Sending the
master session key does not present this same risk, since the master key
cannot be derived from the master session key if a secure one-way function
is used in the derivation.

---

From: James Carlson <[email-masked]>
Date: Wed, 13 Feb 2002 20:46:13 -0500 (EST)

> for an example of such a specification). 

OK.

> don't really add entropy. 

Of course ...

> another master secret, from which new master session keys can be derived. 

Hmm.  OK, that's another part of the update that's needed.

> is used in the derivation. 

Yep; that makes some sense.  I wasn't happy with sending the master
key in the first place.  (Of course, even this derived key has risks
associated with it: if someone can steal it, then he can impersonate
the user for purposes of doing the rechallenge.)