eap Mailing List: RE: Re: EAP-Keying Draft Issues

[Walker, Jesse (jesse.walker]

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