Subject: [eap] Re: EAP-Keying Draft Issues

From: Bernard Aboba <[email-masked]>
Date: Thu, 7 Oct 2004 10:56:23 -0700 (PDT)

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

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

---

From: "Walker, Jesse" <[email-masked]>
Date: Fri, 8 Oct 2004 07:31:52 -0700

Bernard:

>> This is not any attempt to speak for NIST.
>
>Do we know who *is* authorized to speak for NIST? It
>would be good to try to engage them, and the sooner the better.
[Walker, Jesse] The request to review the content was from Elaine Barker
of NIST. Elaine appears to the person responsible for getting SP 800-56
released. The text I was asked to review was SP 800-56 Clause 5.8.

>> [Walker, Jesse] No. I am referring to a statement in the text I was
>> asked to review. There are two cases. We can push back on NIST here,
and
>> they will replace the requirement with something more directed. Or
else
>> they will not. In either case, it appears to me there is an issue to
be
>> worked.
>
>Note that FIPS certification may be provided only when protocols
negotiate
>particular parameters.  For example, TLS certification is only provided
>when FIPS-compliant ciphersuites are negotiated.  So the issue is
>really whether it is feasible to certify the system as FIPS compliant
with
>*any* set of parameters, and whether those parameters are mandatory to
>implement, rather than whether certification is possible in
>all circumstances.  In this respect, negotiation is often the safest
>course; if one set of parameters cannot be certified, then another set
may
>be chosen instead.
[Walker, Jesse] It does not appear hard to specify a technical solution
that works in both commercial and FIPS settings (although it will take a
lot of work to tell whether we got it right). The main barrier is will.
If the industry cannot muster the will, then you are right; we will have
to live with separate cipher suites for the different markets. Having
said that, there will always be WEP, WPA, and original 802.11i, because
millions of systems implementing each are deployed.

-- snip -- 

>> [Walker, Jesse] Right; so it says. But this does not go nearly far
>> enough. What is still missing is a mandatory mechanism to deliver the
>> authenticated identities to the Peer and to the NAS.
>
>I agree that lack of a mandatory authentication mechanism is an issue,
if
>only because this translates to a requirement for an external AAA
server
>that is somewhat of a burden for small installations.

I was talking about a mandatory key binding mechanism, not
authentication. If we provision a PMK, my position is we need to do the
binding step, and this should be mandatory. This is the issue I raised.
To me it is the central technical problem remaining.

>Now that RFC 3748 is done, publication of methods is now possible so
that
>there will be a wider range of methods to choose from.  There is also
some
>interest in standardization of methods.

This would be a constructive next step, too.

>If NIST is interested in raising the bar for method security beyond
what
>is in the 802.11 WLAN Requirements document, then one way to go would
be
>to write a requirements document for FIPS-compliant methods.  Such a
>document could have Channel Bindings as a MUST, for example.
>
>This would enable FIPS certification for some set of methods.  Making
one
>or more of those FIPS-compliant methods "mandatory to implement" for
FIPS
>compliance certification is a different thing than making
implementation a
>requirement for *all* 802.11 APs and STAs.

>> Under EAP the Peer does not know it is communicating to the same NAS
the
>> AAA Server is, and vice versa.
>
>This is known as the "lying NAS problem" in the document.  Solutions
are
>proposed (such as Channel Bindings), but we do not yet have running
code
>to demonstrate feasibility.  Given that the Kerberos binding facility
>doesn't work that well either (e.g. validation of IP addresses in
tickets
>creates problems with NATs) there is reason for concern.

I think we have lots of operational experience from other areas (e.g.,
Kerberos) that says we should be able to find something. It is not
difficult to adapt any number of schemes to our environment.

>> Either we need NIST to add them to the list of approved key wrapping
>> algorithms, or else we need to define a PMK transfer mechanism based
on
>> an approved key wrap, at least for environments that care about FIPS.
>
>It would be helpful if NIST would provide some guidance on this.
[Walker, Jesse] Right. We should encourage NIST to issue SP 800-56 for
comments.

-- snip --

>> [Walker, Jesse] The issue is that we have not mandated a mechanism.
>
>NIST is free to describe their requirements, or even to mandate one or
>more EAP methods for FIPS compliance certification.  However, requiring
>802.11 to mandate a FIPS compliant method is another kettle of fish.
The
>current 802.11 WLAN requirements document does not even mention FIPS
>compliance at all, not even in the optional category.
[Walker, Jesse] The point of looking to NIST at all is that they are a
very good repository of institutional wisdom on security. My belief is
the wisdom accumulated here is that key binding is a critical issue for
the symmetric key problem. It is worth trying to do something to fill
this gap.

-- Jesse

---

From: "Walker, Jesse" <[email-masked]>
Date: Mon, 11 Oct 2004 14:15:43 -0700

Russ,

-- snip --

>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.
[Walker, Jesse] I share your point about 1 use per key. My point was not
to suggest using keys for multiple purposes, although I can see how that
interpretation is possible. My point was to raise the question of
whether the current architecture is where we want to end up. My reasons
for asking the question at this time were (a) the keying draft appears
to be in last call and (b) there appeared to me to be a conflict between
requirements that may be forthcoming from NIST and the performance
requirements for new applications like fast AP-to-AP transition.

-- snip --

>>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,
>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.
[Walker, Jesse] This is a fair request. I will work toward this end.

---

From: <[email-masked]>
Date: Tue, 12 Oct 2004 19:06:45 +0300

Bernard Aboba wrote:
> 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.
> 
> Needham-Schroeder showed that the main deficit was in the 
> binding area. This motivated the section on Channel bindings.
> 

I think you're referring to this email:
http://mail.frascone.com/pipermail/eap/2003-August/001596.html

Reading what I wrote over a year ago, there are some thing I'd
perhaps phrase differently today, but the basic source of
complexity (and difference from traditional 3-way stuff) 
is still valid: the entities involved do not have a single 
identifier, but several.

The AAA server can authenticate the NAI of the user, but the AP
is more interested in the MAC address. And when using RADIUS or
Diameter, the AAA server might authenticate an FQDN or IP
address of the AP, but the client is not interested in those. 

There is always BSSID, but the AAA server cannot produce an
attestation about that (for the client) unless it knows that
it's sending the PMK to the entity identified by that BSSID
(i.e., the key wrapping key is only known by that BSSID).  

We've of course been through this many times before, and 
I think every time the conclusion has been roughly that
"this isn't a problem worth solving"... since it e.g. 
requires configuring BSSIDs in the AAA server, or 
alternatively putting BSSIDs into certificates (since 
the attestation should be about _authenticated_ identities, 
not claimed identitites).

(And yet another story is that having an attestation about
SSID is probably more useful to the client than BSSID.)

Best regards
Pasi

---

From: "Walker, Jesse" <[email-masked]>
Date: Wed, 27 Oct 2004 10:34:14 -0700

Alper:

-- snip --

I see two levels of binding in here:

1- binding user name and NAS id to the authentication session. This is
where we need AAA server's attestation.
2- binding MAC addresses (or, some other device identifiers) to the
authentication session. This is where we can get away without having to
get an attestation from AAA server.
[Walker, Jesse] This seems reasonable to me.

Eventually we need to bind the MAC addresses to the session. My point
is, we can get there in two steps too (not necessarily having to run the
MAC addresses via the AAA server).
[Walker, Jesse] I'm not sure we have to worry about step 2. Or rather, I
don't see (yet) why the Peer and the NAS cannot do the binding
themselves. If the AAA server attests that the identities are bound to
the MSK, then any exchange confirming possession of the key can also
confirm that the key holder (a) is using any address it claims it is
using and (b) that these are bound to the identifiers for the purpose of
this session. It is up to the consumers of the binding information (like
802.11) to do the right thing with it.

IKEv1 takes this tack and no one has raised a security issue. IKEv1
phase 1 verifies that the identities are bound to a key. IKEv1 phase 2
binds the IP addresses each endpoint wants to use to a particular IPsec
SA.

-- Jesse

-- snip --