Subject: [eap] EAP-Keying draft issues

From: "Walker, Jesse" <[email-masked]>
Date: Thu, 7 Oct 2004 05:05:28 -0700

The draft contains a lot of very good work, but I also believe we should
contemplate some changes.

My issues come in response to a request from NIST to review text for
NIST SP 800-56, which will provide key management guidelines for FIPS
140 certification. We spent a lot of effort to try to make 802.11i
compatible with FIPS 140, but apparently we failed. The failure appears
due entirely to the 802.11i key management scheme. I will summarize my
understanding of NIST's critique of the 802.11i key management scheme as
follows:

   a. The key derivation function we defined is not a prefix-free
      construction. This is not the IETF's problem, and 802.11 will have
      to address this issue itself.

   b. 802.11i uses the PMK to name the PMK. This is also not the IETF's
      problem, and 802.11 will have to address this itself as well.

   c. The 802.11i key caching scheme will not be allowed under FIPS. In
      particular, NIST requires keys to be deleted after a key
derivation.
      This is in part the IETF's problem, and a problem for the draft.

   d. Key derivation must use the authenticated identities of the
parties
      that are intended to consume the keys. The existing EAP, 802.1X,
and
      802.11i architectures provide no way to deliver the authenticated
      identity of the AP to the STA nor the STA to the AP, so this
implies
      a deployment constraint: the authenticated identities in the 4-Way
      Handshake must be the MAC addresses of the two parties. This is
      certainly not compatible with the advice the keying draft gives,
      and it is incompatible with the way people deploy EAP, 802.1X, and
      802.11i. I think this is a problem for the keying draft.

   e. IPSec (used by RADIUS) and TLS (used by DIAMETER) are not approved
      key wrapping algorithms. This is a problem for the IETF, but not
      pertinent to the draft.

The NIST requirement (c) to destroy the key derivation key after each
key derivation stands out for me. If this NIST requirement remains, it
means that the draft's key derivation scheme will not scale to AP-to-AP
transitions, because we can use any particular key only once for key
derivation; the device will have to undergo a re-authentication for
every transition, and the entire key hierarchy will have to be
re-derived. This will not lead to fast transition times nor low cost
STAs, regardless of the transition techniques adopted.

This reasoning suggests that a better scheme might be use the TEKs as
end-to-end key wrapping keys, instead of the MSK and EMSK as key
derivation keys (or else perhaps use the MSK or EMSK as key wrapping
keys, since TEKs live only during the EAP conversation).

As I said, we can push back on NIST on this requirement, but performance
is still a reason to consider key wrapping instead of key derivation. If
my back-of-the envelop calculation is correct, a single key derivation
using a mechanism like 802.11i's costs roughly 30000 instructions. We
know the TLS key derivation function is roughly 50% more expensive than
802.11's for deriving the same amount of keying material, so we are
looking at something in the neighborhood of 200K to 250K instructions
minimum just to set up the key hierarchy (MK ~ 90000 instructions--twice
as much keying material at 50% higher cost, MSK ~ 90000, PMK ~ 45000).
By contrast, an AES key wrap of a 64 octet key costs roughly 10000
instructions, even with key schedule setup. The draft has made the right
tradeoff for high power devices operating over low speed links. It has
made the wrong tradeoff for low power device that operate over high
speed speed links.

Concern (d) I think gets to the heart of a much more fundamental
problem. This is that the draft does not address the central issue that
motivated it. Keying is a three-party problem, and no three-party
solution has been offered or even hinted at, and no process to lead to a
three-party construction seems to have been erected, enunciated, or even
envisioned. Section 5.3 waves its hands at the issue, but elsewhere the
document coexists at best uncomfortably with the issues raised by having
three parties in the equation. The document seems like a mish-mash of
requirements mixed together with rationales why we have to keep on doing
things the way we have always done them before.

People have pointed out before that EAP is a two-party protocol, and
that we can't change the EAP model, and I am sure they will again.
However, the reality is we don't have to change EAP authentication one
whit to address this problem, because it has nothing to do with
authentication; it is about what to do with the results of
authentication and the resulting authorization decision. All we need is
one three-party scheme to deliver keys (properly bound to the
authenticated identities of the NAS and Peer) to the NAS and to the
Peer; we don't want some indeterminate number or 15 or 5 or even 2; just
1 proper key delivery that will allow applications to meet the SP 800-56
requirements. Even if EAP is itself two-party, the key distribution
scheme can very well be three-party. And there are ready-made algorithms
we can pick up and use (e.g., Needham-Schroeder, Otway-Rees,
Bellare-Rogaway) if only we want to.

To reach a solution that will be acceptable to NIST and to the 802.11
community, I beleive we need to define a 3-party protocol that involves
the Peer, the NAS, and the AAA server; we would need to define how this
consumes the EAP keys, and we would have to define a migration strategy
to get from the current practice to the new mechanism. The document has
not done this. I am willing to create time in my schedule to work with
people to remedy this if there is any will in the group to take on the
problem. If we need a different document to accomplish these ends, then
that is ok, too.

I am going to go get on an airplane now. I expect an interesting set of
responses when I get back into range of the Internet.

-- Jesse Walker

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Alper Yegin <[email-masked]>
Date: Thu, 07 Oct 2004 15:22:10 -0700

Hi Jesse,

> things the way we have always done them before.

Could this be solved by the EAP lower layer design? 

PANA-Bind exchange (which carries the EAP Success) carries device
identifiers of the PANA client and enforcement point(s). The message is
integrity protected as well. This provides identification of the
consumers of the keys (if I got the NIST problem right....).

The latest PANA spec is here:
http://www.toshiba.com/tari/pana/draft-ietf-pana-pana-06c.txt

Alper

---

From: Russ Housley <[email-masked]>
Date: Sun, 10 Oct 2004 10:27:01 -0400

>       key wrapping algorithms. This is a problem for the IETF, but not

Thank you very much for sharing your review with us.

>STAs, regardless of the transition techniques adopted.

I encourage everyone to perform a review of the draft document from 
NIST.  I believe that this constraint will impact many IETF security 
protocols, not just EAP methods.  For example, TLS restart depends on the 
two peers saving the master key to derive a subsequent session key.  This 
is a valuable feature.  So, while I understand the conservative design 
principle that leads to the NIST requirement, I think it is important for 
the IETF community to make sure that NIST knows what important features 
will be eliminated by this requirement.

>keys, since TEKs live only during the EAP conversation).

I am not sure.  I like the fact that the TEK has only one purpose in the 
current architecture.  This is also a conservative design principle.  I am 
not sure that NIST would want this one sacrificed for the one discussed 
above.  It sounds like open dialogue is needed.

>made the wrong tradeoff for low power device that operate over high

While the performance number indicate that we should look at this more 
closely, I think that we need to preserve the one purpose foe each key 
principle that is present in the current design.  Perhaps using a key other 
than the TEK is the right approach.  I need to spend more time with the 
EAO-Keying  draft to have a firm opinion.

>Bellare-Rogaway) if only we want to.

It is not clear to me the exact requirements.  Jesse, I ask you to 
coordinate with other people in IEEE 802.11 to state them clearly.  It 
would be ideal if they come to the IETF in a liaison letter.

>problem. If we need a different document to accomplish these ends, then

I am willing to help too.

Russ