eap Mailing List: Re: EAP-Keying Draft Issues

[Bernard Aboba (aboba]

> I will summarize my understanding of NIST's critique of the 802.11i key
> management scheme as follows:

Over the last few months, a number of individuals not affiliated with NIST
have made representations on behalf of NIST, which we were subsequently
unable to confirm.  As a result,  we will be requesting a definitive
statement from NIST on the issues you raise.

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

Key Naming is indeed  part of the EAP WGs charter, particularly since the
PMK is just another name for the AAA-Key.

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

If all keys need to be deleted after key derivation then IKE would not
pass muster either, and IPsec would not be possible, so surely the issue
is not this simple.  Perhaps you are referring to persistence of the
PMK/AAA-Key.

>       This is in part the IETF's problem, and a problem for the draft.

The draft does not require PMK/AAA-Key persistance, and EAP has been
defined to run over lower layers that do not persist the PMK/AAA-Key.  For
example, IKEv2 uses EAP for authentication but does not persist the
AAA-Key/PMK.

What the draft does do is to examine the persistance issue and point out
pitfalls and flaws.  This includes issues of key lifetime negotiation and
the security vulnerabilities created by fast handoff, as well as potential
solutions.

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

RFC 3748 describes how Channel Bindings may be used to deliver the
authenticated identity of the AP to the STA and vice versa.  In addition,
the keying draft describes potential key scoping issues and why secure
association protocols need to identify both the authenticator and
peer, rather than their ports.  Furthermore, the keying draft suggests a
solution -- namely use of consistent identifiers within the secure
association protocol, AAA protocol and lower layer discovery
mechanisms.

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

We have specifically asked NIST whether they will confirm this
requirement, and so far we have not heard back from them.

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

There are multiple issues here.  One issue is the persistence of
on an authenticator, and the manner in which the parties agree on
the lifetime and scope of those keys.

Another issue relates to how keys are established on multiple
authenticators.

Yet another issue is the persistence of SAs on the AAA server.

The EAP Keying draft does not require persistence of the AAA-Key on a
single authenticator. However, it does suggest that keys that are
derived have well defined key lifetimes, and it talks about how this can
be achieved.

In terms of establishment of keys on multiple authenticators, the draft
discusses potential approaches, including mechanisms by which
cryptographic separation can be achieved.

The draft also discusses the persistence of SAs on the AAA server.  This
is not something that is done today, but it has been suggested in the
research literature.

Note that persistence of SAs on the AAA server (e.g. the "push" model) is
not required for establishment of keys on multiple authenticators and
indeed for a number of  practical reasons some prefer the "pull" model.
The next version of the keying draft will discuss both models and their
implications.

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

I'd suggest that this conclusion is quite a leap.  802.11i already
supports pre-authentication which enables key state to be established
ahead of time, and extensions have been proposed for enabling derivation
of transient session keys via pre-authentication, which would presumably
address the NIST objection to caching of PMKs/AAA-Keys.

In addition, the EAP Keying framework suggests a number of mechanisms for
"fast handoff" and analyzes their security implications.

Without seeing NIST's analysis in detail, it's hard to tell which one of
these approaches would work, but the EAP Keying Framework provides wide
latitude in developing a solution.

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

Individual methods are free to do this.

> As I said, we can push back on NIST on this requirement

Without seeing the NIST analysis in detail it is hard to say whether to
"push back" or not.  But from what you've said so far, the NIST objections
seem to map well to the  security issues pointed out in the EAP Keying
draft.

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

Early on in the keying design team, an analysis of the difference between
EAP keying and traditional 3-way key derivation schemes such as Kerberos
was presented.  If it would help improve clarity, the details of this
analysis could be presented.  The analysis did identify a number of issues
which were included in the draft, but perhaps the connection is not clear.

> We can pick up and use (e.g., Needham-Schroeder, Otway-Rees,
> Bellare-Rogaway) if only we want to.

As I recall, the analysis of the differences between EAP and
Needham-Schroeder showed that the main deficit was in the binding area.
This motivated the section on Channel bindings.

Pasi -- Can you provide details here?

> To reach a solution that will be acceptable to NIST and to the 802.11
> community

To reach a solution, the first thing that needs to occur is for NIST to
issue a ruling describing their requirements.  The EAP WG will then
incorporate those requirements into the EAP Key Framework document, and
will analyze the implications for EAP and associated protocols, such as
AAA and secure association protocols.

802.11 can then build on those conclusions to revise 802.11i in a manner
that will satisfy NIST.