Subject: [eap] Issues 49 & 62: Strawman Section 4.2.1

From: [email-masked] (Bernard Aboba)
Date: Thu, 9 Jan 2003 11:00:03 -0800 (PST)

In 2002, a University of Maryland team, lead by Bill Arbaugh, the EAP WG
Security Advisor, found a security flaw in the IEEE 802.1X state machine
that allowed a rogue authenticator to convince the peer to bypass mutual
authentication. This involved sending an EAP Success in the middle of a
mutually authenticating EAP method such as EAP TLS, prior to when the
authenticator would provide its credentials.

As described in the ESTEEM document, the EAP State Machine Design Team has
been debating how to handle this. I've struggled to come up with
appropriate text that doesn't seem too clumsy or impose too many
requirements on the implementation.

The text below is not very good, but I thought I'd send it to the list
anyway, so that we get started in improving it.

The basic idea is to cause the peer to silently discard EAP Success or
Failure packets that arrive in the middle of an EAP conversation, as well
as to require consistency between those indications and any method
specific result indications that may have previously arrived.

=====================================================================
4.2.1.  Processing of success and failure

Within EAP, success and failure indications may be protected or unpro-
tected. Unless protected by an underlying link layer ciphersuite, EAP
Success and Failure packets are unprotected indications which may be
spoofed, since they contain no embedded message integrity check.

However, EAP methods MAY include support for acknowledged and protected
success and failure indications. This enables the authenticator to indi-
cate whether the peer has successfully authenticated to it, as well as
for the peer to acknowledge receipt, and to indicate whether the authen-
ticator has successfully authenticated to it. If a key has previously
been derived, these messages MAY be protected by a Message Integrity
Check (MIC).

Where a protected success/failure indication has been received at the
EAP layer by an EAP peer, it MUST accept and process the protected indi-
cation.

The following mechanisms are available to protect against spoofing of
unprotected success and failure indications:

[a]  Link layer ciphersuite. If a link layer ciphersuite providing
     integrity protection is in use, then spoofed EAP Success or Failure
     packets can be detected and silently discarded by the link layer.

[b]  Message validation. EAP Failure and Success messages are never sent
     by the EAP peer, only the authenticator. Therefore, EAP Failure and
     Success messages received by the authenticator MUST be silently
     discarded.

[c]  Mandatory authentication.  Whether authentication is mandatory is
     determined by the authenticator and peer configurations. If authen-
     tication is not required by the authenticator, or if the identity
     of the peer is verified by another mechanism (e.g. Calling-Station-
     ID or MAC address), then the authenticator MAY send a "canned" EAP
     Success message. These messages are highly vulnerable to spoofing.
     However, the peer may be configured to require the authenticator to
     authenticate itself prior to being willing to process an unpro-
     tected EAP Success message.

[d]  Completion indications. An EAP method requesting transmission of an
     EAP messsage by the EAP layer SHOULD indicate whether the message
     represents completion of the EAP conversation. A peer EAP implemen-
     tation that has not yet received a completion indication MUST
     silently discard unprotected EAP Success packets and SHOULD
     silently discard EAP Failure packets.

[e]  Method indications. An EAP method supporting protected success and
     failure indications MAY indicate to the EAP layer the authentica-
     tion status in each direction: SUCCESS, FAILURE or UNKNOWN, as part
     of the message transport primitive. An EAP method indicating an
     authentication FAILURE in either direction MUST cause the EAP layer
     to silently discard unprotected EAP Success packets. The EAP con-
     versation MUST also be unsuccessfully terminated. An EAP method
     indicating authentication SUCCESS in both directions SHOULD cause
     the EAP layer to silently discard unprotected EAP Failure packets.

In the absence of the above mechanisms, unprotected failure indications
MAY be accepted and processed by the peer EAP layer. This can result in
a denial of service attack.

---

From: [email-masked] (James Carlson)
Date: Thu, 9 Jan 2003 16:13:13 -0500

> specific result indications that may have previously arrived.

First, I think that EAP Failure MUST NOT be discarded at any time.  If
you get one, then the peer is clearly trying to tell you something.
It's not a security risk because you're not going to enable the link
because of it.  If you're worried about spoofed EAP Failure as a DoS,
I think the only way to win there is with some sort of link security
-- a MIC or something equivalent.

Since a *proper* (i.e., one from the Authenticator) EAP Success or
Failure is the very last message you'll get from the EAP peer (well,
other than far-future rechallenges, if any), there seems to me to be
some badness in ignoring this message.  You'll need to have some sort
of crufty timeout to say, "well, I got Success, and I didn't expect
it, and no other Requests showed up; shutting down now."  Otherwise,
this invokes the possibility of a deadlock: if an Authenticator sends
Success (and *really* means it), but the Authenticatee doesn't
"expect" it, the link is left in limbo.

So, I think the right thing to do is to say (as we already have) that
if the Authenticatee gets EAP Success and (for any reason) doesn't
like that message, then it disconnects.

If you have a MIC, or some other way of guaranteeing that messages on
the link can't be forged, you can clearly avoid this problem without
having to change anything.

Note also that if you get an unexpected EAP Success this means that
(A) the peer is an idiot and doesn't implement the chosen method
correctly or (B) someone is attacking you.  Either way, failing out
the link sounds like the right sort of handling.

> tected. Unless protected by an underlying link layer ciphersuite,
                                            ^^^^^^^^^^^^^^^^^^^^^^

I think that's a little too strong.  Unless the link itself is known
to have sufficient security, which might consist of physical or
cryptographic methods, then the messages received might be spoofed.

The analysis for each medium will almost certainly differ in some
respects, perhaps even for different deployments.

> for the peer to acknowledge receipt,

Receipt of what?

> and to indicate whether the authen-

This should probably say something about where the MIC goes.  There's
no provision in EAP for this, so it has to be an L2 issue, right?

> EAP layer by an EAP peer, it MUST accept and process the protected indi-

I think "protected success/failure" isn't well enough defined.  Is
this a method-specific Request/Response exchange?  Is it an EAP
Success message where the implementation happens to have independent
knowledge that the link layer is "acceptably secure?"  Is it a new
message entirely?

>      packets can be detected and silently discarded by the link layer.

Actually, *all* spoofed messages, including EAP Success or Failure,
can be detected, right?

>      Success messages received by the authenticator MUST be silently

That disallows bidirectional authentication.

>      tected EAP Success message.

Actually, I think that the Authenticatee ought to disconnect rather
than just leave "unprocessed" this unexpected EAP Success message.  If
it's expecting some sort of authentication that the peer isn't
providing, there's no sense in ignoring the condition.  Alerting a
human (or an administrator) is the only way out.

>      silently discard EAP Failure packets.

I disagree with both parts of that for different reasons.

EAP Failure before the method is complete is entirely possible.  It
means "go away" and could be the result of administrative reset.

EAP Success before the method is complete depends on the method, and I
don't think (except by convention) that it needs to be "indicated"
anywhere in the message itself; just in the method documentation.  In
this case, the prudent thing to do is to shut down: you're under
active attack, so stop.

>      the EAP layer to silently discard unprotected EAP Failure packets.

I think that's basically an implementation choice for (d).

> a denial of service attack.

It's one of several different DoSes available (including Requests with
rotating Identifier values), and perhaps not even the most effective
one.

-- 
James Carlson, Solaris Networking         <[email-masked]>
Sun Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677

---

From: [email-masked] (Bernard Aboba)
Date: Sat, 11 Jan 2003 08:57:16 -0800 (PST)

> -- a MIC or something equivalent.

Link security can often be enabled as soon as keys are derived, which can
be *before* the arrival of a success/failure indication. So this can work
sometimes.

At various points we have also discussed how a method could include its
own protected success/failure indication. The question is whether such a
protected indication can take precedence over an unprotected EAP result
indication if they conflict.

In particular:

What if the authenticator has, through a protected method-specific result
indication, previously told the peer that authentication was successful.
Could that be a reason to regard a subsequent EAP Failure with suspicion?
If so, when?

> of crufty timeout, saying "well, I got Success, and I didn't expect
> it, and no other Requests showed up; shutting down now."

Yes, a timeout will result where the bogus Success comes from a rogue
authenticator. Where it comes from a third party, presumably a legitimate
Request will eventually arrive.

> Otherwise,

The question is what "expect" means. If the peer and authenticator have
negotiated a method that provides mutual authentication, and the
authenticator has not yet authenticated to the peer, can it just bypass
that by sending an EAP Success? That would create a vulnerability to a
rogue authenticator.

> like that message, then it disconnects.

Why wouldn't an invalid EAP Success be treated like any other invalid
packet -- silent discard? The disconnect approach does result in a quicker
disconnect in the case of a rogue authenticator, but where the attacker is
a third party, peer disconnection results in denial of service, where
otherwise authentication would succeed (the legitimate Request would
eventually arrive and authentication would continue).

> having to change anything.

The link layer ciphersuite may not be enabled until after the Success or
Failure indication is sent. Also, it is possible for EAP to be used
in pre-authentication mode, where EAP packets may be forwarded over
an unprotected link. So I think this technique may not be universally
employable.

> the link sounds like the right sort of handling.

In case (B), I'd argue that failure is preferred only when there is
insufficient security available, so that compromise is likely. That is the
approach taken by IEEE 802.11 TKIP, which has a weak MIC, so that if
attempts to compromise the MIC are found, then countermeasures (a timeout)
are put into effect. This is also the approach in TLS, where MIC errors
are fatal, since TLS relies on the underlying TCP transport, and cannot
protected against transport attacks (bogus RST, etc.).

However, other protocols such as IPsec AH the MIC is calculated over the
immutable fields of the IP header as well as the rest of the packet, and
in 802.11 CCMP, MIC security is thought to be strong. In both these cases,
MIC failures result in silent discard, not countermeasures or failure.
This is generally considered a strength of those approaches.

> > tected. Unless protected by an underlying link layer ciphersuite,

Agreed.

> > for the peer to acknowledge receipt,

Receipt of the result indication from the authenticator.

> no provision in EAP for this, so it has to be an L2 issue, right?

The MIC could be done in L2, or it could be done within the EAP method.

> this a method-specific Request/Response exchange?

In this case, I think the text is referring to a protected EAP Success or
Failure packet -- protected at L2, or perhaps by some other means (a
tunnel?)

> Is it an EAP

In this case, I think it is the existing EAP Success or Failure message
when the link layer is "acceptably secure?"

> Actually, *all* spoofed messages, including EAP Success or Failure,

Yes.

> That disallows bidirectional authentication.

Yes, this should be removed.

> human (or an administrator) is the only way out.

Some sort of logging is definitely appropriate, yes.

> means "go away" and could be the result of administrative reset.

Sure. Even if the method derives keys and could protect a result
indication, failure can occur early before keys are derived. So this
always results in a timeout when an early failure occurs.

> I think that's basically an implementation choice for (d).

Yes, it does seem somewhat heavy handed, especially since I don't know any
implementation that actually does this (though several implementations do
silently discard EAP Success messages prior to completion).

> rotating Identifier values), and perhaps not even the most effective

Yes, there are other potential DoS attacks.