Subject: [eap] Re: Issue 74: Concern on invalid MIC

From: [email-masked] (Bernard Aboba)
Date: Tue, 4 Feb 2003 17:32:11 -0800 (PST)

Yoshi wrote:

> I think the policy of silently discarding packets with invalid MIC
> might not work as expected when a pass-through authenticator is used.
>
> Since the pass-through authenticator is not able to perform integrity
> check for EAP Response messages, when an attacker Peer sends an EAP
> Response with invalid MIC, the authenticator will pass it to the
> backend EAP server as long as it is valid except for MIC.  Once this
> happens, an EAP Response message sent from the legitimate Peer will be
> treated as duplicate Response and thus silently discarded at the
> pass-through authenticator.

Yes, I think this is right.

> The policy of silently discarding packets with invalid MIC does not
> seem to work anything good for this type of DoS attack, and this
> problem seems to be common to all methods.  It seems that lower-layer
> needs to be secure to EAP, or the EAP server might need to inform the
> pass-through authenticator whenever it finds an EAP Response with
> invalid MIC so that the authenticator can treat the already forwarded
> EAP Response as "invalid".

But by then it is presumably too late, no?

Do you have a recommendation?

---

From: [email-masked] (Yoshihiro Ohba)
Date: Wed, 5 Feb 2003 01:28:27 -0500

> But by then it is presumably too late, no?

Actually not too late.  In general, it is the responsibility of each
method to perform validity check for the payload of Request/Response
and to inform the switch of the result of the method-specific validity
check.  The switch should wait until the result of the method-specific
validity check is obtained from the method.  In the case of
path-through authenticator, it is the "pass-through method" that
performs validity check which is specific to the pass-through method.

The method-specific validity check for the pass-through authenticator
method would be a bit different from other methods in that it would
requires the EAP server to return the validity check result from the
actual method.  A new EAP Request sent from the EAP server can be used
as an indication that previously forwarded EAP Response was valid.
However, if the EAP server silently discards the invalid EAP Response,
the pass-through authenticator will be stuck until the EAP
conversation times out.  

Based on this, the requirement is that (a) lower-layer needs to be
secure to carry EAP whatever method is used, or (b) a AAA protocol
needs to provide a way for the EAP server to inform the NAS whenever
it finds an EAP Response invalid.  If neither requirement is
satisfied, it will be a broken EAP usage.  The other alternative might
be that (c) the EAP server shuts down the EAP conversation whenever it
finds an EAP Response invalid but this is not much different from
silent discard in that both ends up with EAP conversation failure,
but c) might be better than silent discard since quick reaction to
errornous case is possible with c).

> Do you have a recommendation?

a) + c) would be perfect, but unfortunately IEEE 802.11i does not
satisfy a).

So I think b) might be the next choice.  But I'm not sure how b)
impacts on the RADIUS/Diameter EAP application protocol design.

Yoshihiro Ohba

---

From: [email-masked] (Bernard Aboba)
Date: Tue, 4 Feb 2003 21:31:55 -0800 (PST)

> performs validity check which is specific to the pass-through method.

Let us assume that The NAS sends an Access-Request to the AAA
server, containing an EAP Response with a bad MIC, injected by an
attacker. The AAA server checks the MIC, and finds that it is bad. If it
silently discards the packet, then the NAS will retransmit, thinking that
the packet did not arrive. So that does not work. If the AAA servers sends
an Access-Reject, then the conversation is over the authentication needs
to be rerun. With one packet, the attacker gets the AAA server and client
to rerun authentication, which could involve public key operations. So
that is not so good either.

> it finds an EAP Response invalid.

The question is: what good does it do for the AAA server to tell the NAS
that the packet was invalid? The NAS has already silently discarded the
good packet, no?

> errornous case is possible with c).

Yes. At least the conversation will die quickly :(

> impacts on the RADIUS/Diameter EAP application protocol design.

I guess my question is what the NAS can do with the information that would
help the situation. If the NAS discards duplicate Responses before sending
them to the AAA server, I think it will not do any good. If it doesn't,
then the AAA server can say "that one was bad, send me another one". If
the NAS doesn't have another one, I'm not sure what it can do with that
information either :(

---

From: [email-masked] (Yoshihiro Ohba)
Date: Wed, 5 Feb 2003 02:07:10 -0500

> that the packet was invalid? The NAS has already silently discarded the

I think the NAS might need to queue incoming Response messages until
the Response sent to the AAA server is determined to be valid by the
AAA server.

Yoshihiro Ohba

---

From: [email-masked] (Bernard Aboba)
Date: Tue, 4 Feb 2003 22:32:58 -0800 (PST)

> the Response sent to the AAA server is determined to be valid by the

So you are saying that duplicate detection should be turned off when going
into pass-through mode?

I am curious whether any NASes implement this today.

---

From: [email-masked] (Yoshihiro Ohba)
Date: Wed, 5 Feb 2003 11:00:38 -0500

> So you are saying that duplicate detection should be turned off when going

I would say that duplicate detection might need to be delayed (not be
turned off) until the validation result comes back from the AAA
server.

Yoshihiro Ohba

---

From: [email-masked] (Bernard Aboba)
Date: Wed, 5 Feb 2003 06:50:56 -0800 (PST)

> turned off) until the validation result comes back from the AAA

I think we are going to have to hear about how authenticators currently
interpret the RFC 2284 text to see if something like this is feasible or
not.