eap Mailing List: Analysis of DoS Attack on EAP State Machine (fwd)

[Bernard Aboba (aboba]

---------- Forwarded message ----------
Date: Wed, 12 Nov 2003 16:23:31 -0700
From: Jim Burns <jeb [at] mtghouse.com>
To: Bernard Aboba <aboba [at] internaut.com>
Cc: Paul Congdon <paul_congdon [at] hp.com>
Subject: 802.1X Rev D7.1 State Machine Comment 30

Hello Bernard,
We have analyzed your comment 30 on 802.1X Rev D7.1 (reappears below)
and would like to discuss our understanding with you.   If you feel it
would be useful to forward this to the EAP state machine folks please
feel free to do so.
------------------------------------------------------------------
Summary:
The summary of our analysis is that you were either attempting to ensure
that the 802.1X and EAP state machines stayed synchronized or that you
wished to avoid a denial of service attack.
If it was the former, this is already handled by passing through the
RESTART state and the two state machines handshaking on the eapRestart
variable.
If it is the latter, then we agree that you have detected a potential
denial of service attack against EAP running over EAPoL, but that
security is not compromised and the state machines continue to operate.
In addition, the changes required to prevent this denial of service
attack would be extensive and would not prevent other denial of service
attacks so is not worth the effort in the current revision of 802.1X.
Although Link Security will certainly be taking on this and other
issues.  Due to this analysis we have rejected this comment, but we want
to pass along our complete analysis.
------------------------------------------------------------------
Details:
Bernard's original comment 30:
CLAUSE: 8.2.11
PAGE: 65
LINE: 15
COMMENT START:
A transition is made to RESTART state from several states (CONNECTING,
AUTHENTICATED,
HELD) based on receipt of *any* EAP packet (eapolEap). It seems like this
should only occur if an EAP Request is received and EAP indicates that
method-
State==INIT within the EAP state machine.
COMMENT END:
SUGGESTED CHANGES START:
Change the condition for transition to RESTART from "eapolEap" to
"eapolEap &&
methodState==INIT". Include definition of the methodState variable from
the EAP state
machine.
SUGGESTED CHANGES END:

-----------------------------------------------------------------
802.1X Philosophy:
We are a transport for EAP and carry out this transport without
intruding on the EAP header which means that EAP may freely change
without affecting the transport on which it is carried.  It is our
assumption that EAP is prepared to handle the arrival of unexpected EAP
frames and the EAP state machines reflect this and the connection
between the two machines allow EAP to indicate an unexpected frame
without causing a problem in the machines.

Our analysis of what happens today if an unexpected eapolEAP frame arrives:
SUPPLICANT STATE MACHINES (FS=Front End Supplicant, BS=Back End Supplicant)
- Assume we begin in 1X FS CONNECTING
- eapEAPOL frame arrives, assume it is an unexpected EAP for a
supplicant, such as an EAP response , it could just as easily be a bogus
EAP request (either maliciously created or a glitch)
- 1X FS RESTART - set eapRestart
- EAP DISABLED - reset eapRestart
- EAP INITIALIZE
- EAP IDLE
- 1X FS AUTHENTICATING - set suppStart
- 1X BS REQUEST - set eapReq
- EAP RECEIVED - attempts to parse eapReq, fails due to it being a response
- EAP DISCARD - reset eapReq, set eapNoResp
- EAP IDLE - begin idleWhile Timeout set to ClientTimeout
- 1X BS RECEIVE - begin authWhile Timeout set to authPeriod
<<< at this point, either we receive an EAP request, another unexpected
EAP frame, EAP times out or 1X times out >>>
** If we receive an EAP request then, assuming it is a valid first
request then we will authenticate.
** If we receive another unexpected EAP frame then we will repeat
beginning at the EAP RECEIVED state above
** If EAP times out then:
- EAP Failure - set eapFail
- 1X BS FAIL - set suppFail
- 1X BS IDLE - reset suppStart
- 1X FS HELD - after held period
- 1X FS CONNECTING
** If 1X times out then:
- 1X BS TIMEOUT - set suppTimeout
- 1X BS IDLE - reset suppStart
- 1X FS CONNECTING

The are no differences in the above state machine traces for the case
that you start in the HELD or AUTHENTICATED other than the starting
state.  So in all the cases, the DoS attack of sending an unexpected EAP
frame will result in an attempt to do another authentication.  If there
had been a pre-existing authenticated connection (in the case that we
began in the AUTHENTICATED state) this connection will not be broken
during the reauthentication.

Furthermore, if we begin in the AUTHENTICATED state, the DoS attack is
made less likely in .11i  because the EAPOL frame will arrive encrypted
using the current keys and will be more difficult for a malicious
attacker to spoof an EAPOL frame.  So, this attack appears to mostly be
against clients who have not begun authentication (are in the CONNECTING
state) or who have failed an authentication (are in the HELD state).

Sincerely,
Jim Burns