802.1x State machine eapol_sm.c in wpa_supplicant-0.4.9

[Jouni Malinen]

On Fri, Jun 16, 2006 at 05:46:48PM -0700, Aditya Pandey wrote:

> Going over the state machine in eapol_sm.c. The supplicant backend machine
> should have state transitions from state REQUEST to State FAIL and SUCCESS
> based on eapfail and eapSuccess. This is from IEEE Std 802.1x-2004 Figure
> 8-18.

Interesting..

> Could any one clarify as to why these are not there and what implication it
> has on the EAP process.

I think the reason for these transitions missing from eapol_sm.c is that
they were added to IEEE Std 802.1X-2004 only after the initial
implementation which was based on a draft version (IEEE 802.1aa/D6.1).

As far as I can tell, these direct transitions from REQUEST to
FAIL/SUCCESS are not correct. In most cases, the EAP method would have a
response to send back to the EAP server when determining that the
authentication was successful. Skipping RESPONSE state in such a case
would mean that the reply was not sent out. In addition, skipping
RECEIVE would mean that eapolEap is not cleared to FALSE which can cause
problems later. In addition, IEEE Std 802.1X-2004 seems to indicate that
EAP layer should always set eapNoResp when either eapFail or eapSuccess
is set. This would mean that there are two possible transitions from
REQUEST at the same time.

Adding eapFail/eapSuccess verification to the beginning of the
transition list (i.e., before eapNoResp -> RECEIVE) would break
wpa_supplicant. Adding them to the end of the list would be fine since
they should never really be called in that case.. I ended up adding
these here with a comment describing the details of this issue. If
eapResp and eapNoResp would not be set for some reason, these
transitions will allow the state machine to continue. I have never seen
such a case, so I don't think that this would actually change anything
for the EAP process.


Going a bit more into details why this change was done.. It was changed
in sponsor ballot in 802-1X-REV-d9 based on following comment:

http://www.ieee802.org/1/files/private/x-REV-drafts/d8/802-1X-rev-d8-dis.pdf
---
Comment 8 Jim Burns

There is a minor state machine change that needs to be made to the
supplicant back end machine.
The change is:
  Add a transition from the REQUEST state to the FAIL state with the logic
  'eapFail'
  Add a transition from the REQUEST state to the SUCCESS state with the
  logic 'eapSuccess'

This change is needed because there is a case with the current EAP
machine that is not handled and could cause deadlock problems between
the two machines. Specifically, if we give a just-received EAP frame to
EAP and then get the supplicant response with getSuppRsp() then it is
quite reasonable to expect that the response from EAP would be eap-Fail
or eapSuccess. We don't currently handle this. This was really a
miscommunication during the state machine development...we assumed one
behavior, the EAP state machine assumed another.

Disposition of Comment 8

Accept.
---


wpa_supplicant has resolved this in a different way, i.e., by changing
EAP state machine to set eapNoResp when eapSuccess/eapFail is set (see
eap.c SM_STATE(EAP, SUCCESS) and SM_STATE(EAP, FAILURE). This seems to
be the behavior that 802.1X expected originally.

I tested removing the wpa_supplicant-specific change from EAP state
machine with the added REQUEST->SUCCESS/FAIL transitions in the EAPOL
state machine. This allows EAP to complete successfully, but breaks the
connection by triggering a restart of authentication because eapolEap
was not cleared (RECEIVE state skipped). Because of this, I do not think
that the changes accepted for 802-1X-REV-d9 were actually correct and
the proper fix would have been to change the EAP state machine.

-- 
Jouni Malinen                                            PGP id EFC895FA