Subject: [eap] Issue 25: Spoofing and duplicate detection

From: [email-masked] (Bernard Aboba)
Date: Sun, 6 Oct 2002 03:35:35 -0700 (PDT)

Issue 25: Spoofing and duplicate detection
Submitter: Jesse Walker
Submitter email address: [email-masked]
Date first submitted: May 3, 2002
Reference:
Document: RFC2284bis-04
Comment type: T
Priority: S
Section: 9.3
Rationale/Explanation of issue:
Section 9.3 page 23, point 1 says:

Silent discard. Since only a single EAP Request can be in progress
between an Authenticator and a Peer at a given time, if a Peer
receives a new Request before sending a Response, the new Request
can be silently discarded. This increases resilience against
spoofed Requests. Similarly, an Authenticator can silently discard
Responses with Identifiers that do not correspond to the Identifier
included in the last Request, or that represent duplicate
Responses.

This advice seems effective only if both the Authenticator and the Peer
respond significantly more rapidly than does the active attacker, or their
responses are delivered more expeditiously than the attacker's, i.e., you
can't depend on it. The Success and Negotiate messages in particular
require their own protection. I suggest noting this method does not work
except in very constrained environments because of the race conditions
cited.

Resolution: Possible Reject

[BA] For a new Request that arrives before the Response
is sent, it seems to me that the proposed
behavior is appropriate.

Since a compliant Authenticator will never send a
new Request before receiving a Response, if the
Supplicant sees this, it either implies that the
Request has been spoofed, or that a Response was
spoofed that caused the new Request to be sent.
This behavior cannot be caused merely by a poor
RTO estimator since EAP is an ACK/NAK protocol.

If the method is protected, then presumably a
spoofed Response is not possible. If the Request
is spoofed, then silent discard is appropriate.

For a Response that does not match the Identifier
of the Request the indicated behavior also appears
correct.

Assuming that we have a compliant EAP client, this
can happen in high latency networks where the
Response is sent in answer to a retransmitted Request,
with the original Response arriving after the
Request is retransmitted. If the original Response
was invalid, then a new Request would not have been
sent, so that discarding the duplicate Response has
no ill effect.

If Requests are being spoofed, and the EAP method
is not protected, then the EAP client
may Respond to the bogus Requests, causing the
observed behavior. By discarding Responses to
bogus Requests, the Authenticator can avoid becoming
confused, but the outlook on the client is less
sanguine; it seems likely that authentication will
fail.

So it seems that in this case the specified behavior
does no harm, although it may not do much good either.