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

From: "Walker, Jesse" <[email-masked]>
Date: Thu, 7 Oct 2004 21:22:09 -0700

Bernard,

--- snip ---
>> 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.
[Walker, Jesse] I chose my language very carefully and wrote "I will
summarize my understanding of NIST's critique of the 802.11i key
management scheme." This is not any attempt to speak for NIST.

>>    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.
[Walker, Jesse] I said this because the key naming scheme in the draft
creates no issue, and so I cannot see how anyone can complain about it.
The key name in 802.11i does create an issue. It is defined in 802.11i
clause 8.5.1.2 as

	PMKID = HMAC-SHA1-128(PMK, "PMK Name" || AA || SPA)

This does not conform to my understanding of the requirements NIST will
make, nor does it conform with the naming scheme in the EAP keying
draft.

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

>>       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.
[Walker, Jesse] I do not understand the relevance of this discussion,
and I have no quibble with this part of the text.

>>    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.
[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. Under EAP the Peer
does not know it is communicating to the same NAS the AAA Server is, and
vice versa. The requirement is that both the NAS and the Peer receive
attestation from the AAA Server that indeed this is indeed taking place,
and the AAA server must further bind this attestation to whatever
session key (a.k.a. PMK) the two will use to protect their session. The
purpose of the attestation is to assure the client there is no
man-in-the-middle.

>>    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.
[Walker, Jesse] This is fair. Neither, however, are listed among
approved key wrap algorithms, which is the basis of my statement. 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.

>> 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.
[Walker, Jesse] I don't think I ever suggested that the "push" model is
required. You seem to be arguing against some position I have not
advocated. Please help me understand what you are saying. It seems to be
a non-sequitor to the statement you are referring to.

>> 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.
[Walker, Jesse] Hopefully NIST will post the document soon. Obviously
you and I disagree on whether the NIST requirements map to the
EAP-Keying requirements. I have tried to point out some areas where I
believe there is a disconnect. Where there is a disconnect we need to
work. It will do no good to hide our heads in the sand.

>> 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.
[Walker, Jesse] This is not the issue. The issue is that we have not
mandated a mechanism. The requirement is that the Peer and the NAS both
need some sort of attestation from the AAA Server that they are
communicating with one another and that the PMK is bound to them for use
during this session.
>
>> 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.
[Walker, Jesse] I expect this is so. This is exactly the issue raised.

>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.
[Walker, Jesse] I am happy to hear these assurances. Obviously reading
the key draft on the heals of reading NIST's proposed text made a very
big impression on me, and I thought it very much worthwhile to raise
issues that I see. It would be very good not to rush the keying document
to completion until this analysis can be undertaken, and to address any
conflicts that might arise. 

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

---

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

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

> make, nor does it conform with the naming scheme in the EAP keying

This does indeed appear to be an issue with 802.11i.  Perhaps more
justification for the position taken in the EAP Keying Framework is
required.

> they will not. In either case, it appears to me there is an issue to be

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.

It may be that certain applications are no longer feasible when the system
is configured for FIPS compliance, but support for negotation provides a
way out here as well -- the customer gets to make the choice about whether
they are willing to pay the price or not.  For example, when TLS is
configured to select 3DES ciphersuites, there is a large performance hit.
This would significantly increase costs on a large-scale ecommerce system,
which is why those systems typically negotiate RC4 instead.  But if a
government system wants FIPS compliance and is willing to pay for it, they
can negotiate it.

Out of curiosity, does NIST require the use of PFS within IKE in the
creation of IPsec SAs?  It would seem that without PFS IKE has the same
issue, particularly in IKEv2 which now supports EAP (albeit without PMK
persistance).

As for the impact on on latency, my understanding is that there are
sufficient concerns over VoWLAN security within the DoD that deployment
would be unlikely in the near term even if 802.11 were to achieve FIPS
certification.  If this is true then there may be a requirement for a
FIPS-compliant mode of operation but not necessarily a large demand
FIPS-compliant VoWLAN devices, at least in the near term.

> I have no quibble with this part of the text.

OK.

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

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.

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.

> Either we need NIST to add them to the list of approved key wrapping

It would be helpful if NIST would provide some guidance on this.

> required.

I mentioned this because the "push" model implies AAA-Key persistance on
the AAA server -- and if persistance on the authenticator is an issue for
NIST, then persistance on the AAA server might also be an issue.

> We can push back on NIST on this requirement

By definition, EAP enables users to select varying levels of security.
One size doesn't fit all;  802.11 defined its EAP method requirements, but
NIST will no doubt have more stringent requirements for FIPS compliance.
The key thing is to understand what changes are needed on APs,
STAs and AAA Server in order to enable FIPS certification with one
or more EAP methods.

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

> conflicts that might arise.

Given average time to completion in the IETF, I'd suggest you need not
worry about a "rush to publication".  The main purpose of the keying
framework document is to provide the level of security analysis required
to fully understand the security properties of the system.  We've made
good progress on this, but more input is definitely needed.

---

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

Bernard:

There are many cases where protocols can be used in a manner that is 
FIPS-compliant and also used in a manner that is not.  Last week, NIST 
published some draft guidance about TLS, but I have not had an opportunity 
to review it in detail yet, but it does say:

    While SSL 3.0 is the most secure of the SSL protocol versions, it is 
not approved
    for use in the protection of Federal information because it relies in 
part on the use
    of cryptographic algorithms that are not FIPS-Approved. TLS when properly
    configured is approved for the protection of Federal information.

The document includes recommended cipher suites for the protection of 
government information.

I do not think that NIST has published similar documentation for IPsec.

Russ

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 10 Oct 2004 08:13:41 -0700 (PDT)

Right.  So the question is whether 802.11i/EAP can be "properly
configured" and if not, what changes need to be made to enable this.

On Sun, 10 Oct 2004, Russ Housley wrote:

> not approved for use in the protection of Federal information because it
> relies in part on the use of cryptographic algorithms that are not
> FIPS-Approved. TLS when properly configured is approved for the
> protection of Federal information.
>