eap Mailing List: 802.1X/EAP State Machine Issues (fwd)

[Bernard Aboba (aboba]

Note the following excerpts from recent 802.1X ballots, relating to issues
with the 802.1X and EAP state machines.

NAME:           Les Bell
COMMENT TYPE:   TR
CLAUSE:         9.4.1.1.3
PAGE:           76
LINE:           19
COMMENT START:
The value txPeriod is not used in any of the state machines.  I think this
may now belong to the EAP state machine, which is not in this document, so
it should not be referenced in this section.
COMMENT END:
SUGGESTED CHANGES START:
Remove the definition of txPeriod from this section and section 9.4.1.2.2.
Deprecate the equivalent MIB object, dot1xAuthTxPeriod.
Update the reference for this object in the MIB to 802.1X-2001.
SUGGESTED CHANGES END:

NAME:           Les Bell
COMMENT TYPE:   TR
CLAUSE:         9.4.1.1.3
PAGE:           76
LINE:           25
COMMENT START:
The value maxReq is not used in any of the state machines.  I think this
may now belong to the EAP state machine, which is not in this document, so
it should not be referenced in this section.
COMMENT END:
SUGGESTED CHANGES START:
Remove the definition of maxReq from this section and section 9.4.1.2.2.
Deprecate the equivalent MIB object, dot1xAuthMaxReq.
Update the reference for this object in the MIB to 802.1X-2001.
SUGGESTED CHANGES END:

NAME: Bernard Aboba
COMMENT TYPE: T
CLAUSE: 8.1.9
PAGE: 40
LINE: 13
COMMENT START:
Definition appears missing.
COMMENT END:
SUGGESTED CHANGES START:
Figure 4-6 refers to "txWhen" but this does not appear defined anywhere.
Should the reference be removed or should a definition be added? Or did I
miss the definition?
SUGGESTED CHANGES END:

NAME: Bernard Aboba
COMMENT TYPE: T
CLAUSE: 8.2.9.4
PAGE: 61
LINE: 38-42
COMMENT START:
As noted in the EAP state machine document, the eapSuccess state can be
reached without receiving an EAP Success and the eapFail state can be
reached without receiving an EAP Failure.  So I think the text is
misleading.
COMMENT END:
SUGGESTED CHANGES START:
Recommend that this be rephrased to say:
"If the higher layer indicates that authentication has been successful
(eapSuccess) then the state machine transitions to the SUCCESS state.
If the higher layer indicates that authentication has been unsuccessful
(eapFail) then the state machine transitions to the FAIL state."
SUGGESTED CHANGES END:

NAME: Bernard Aboba
COMMENT TYPE: T
CLAUSE: 8.2.2.2
PAGE: 45
LINE: 21
COMMENT START:
The definition of eapolEap does not take into account the Code field in
the EAP packet.  For example, the Backend authenticator (Figure 8-15)  machine 
should not
transition from REQUEST to RESPONSE state based on receipt of *any*  EAP 
packet, only
EAP packets with Code=2 (Response). Similarly, only packets with Code=1 
(Request), 3
(Success) or 4 (Failure) are relevant to the Supplicant state machine.
COMMENT END:
SUGGESTED CHANGES START:
Change definition to the following:
eapolEap.  This variable is set TRUE by an external entity if an EAPOL PDU
carrying a Packet Type of EAP-Packet, and an appropriate Code field is
received.  In the Backend Authentication State Machine, eapolEap is set
TRUE when Code=2 (Response).  In the Supplicant State Machine, eapolEap is
set TRUE when Code=1 (Request), 3 (Success) or 4 (Failure).
SUGGESTED CHANGES END:

NAME: Bernard Aboba
COMMENT TYPE: T
CLAUSE: 8.2.4.1.1
PAGE: 50
LINE: 15
COMMENT START:
The definition of portMode does not seem right since the values
in the text do not include the value "portControl" included in
Figure 8-10.  I suspect that this was actually the definition of
portControl, and that the definition of portMode was ommitted.
COMMENT END:
SUGGESTED CHANGES START:
Change "portMode" to "portControl".  Add definition of portMode, which
according to Figure 8-10 can take the value "portControl".
SUGGESTED CHANGES END:

NAME: Bernard Aboba
COMMENT TYPE: T
CLAUSE: 8.2.4
PAGE: 49
LINE: 19
COMMENT START:
The transition should be from the HELD state to the RESTART state on
quietWhile==0, not to the CONNECTING state.  Once this is done it is not
clear why RESTART and CONNECTING need to be separate states.
COMMENT END:
SUGGESTED CHANGES START:
Change arrow from HELD to CONNECTING on quietWhile==0 to point to the
RESTART state instead.  Merge the RESTART and CONNECTING states into a
CONNECTING state.
SUGGESTED CHANGES END:

NAME: Bernard Aboba
COMMENT TYPE: T
CLAUSE: 8.2.4.6
PAGE: 53
LINE: 11
COMMENT START:
I don't understand why the Authenticator PAE state machine transitions
from CONNECTING to AUTHENTICATING state on eapSuccess or eapFail. It
seems like the only cases in which this can occur are the canned Success
or canned Failure cases.
COMMENT END:
SUGGESTED CHANGES START:
Change the text to "If the higher layer is ready to send an initial
EAP-Request message, the state machine transitions to the AUTHENTICATING
state."
SUGGESTED CHANGES END:

NAME: Bernard Aboba
COMMENT TYPE: T
CLAUSE: 8.2.4
PAGE: 49
LINE: 27
COMMENT START:
I don't understand why the Authenticator PAE state machine transitions
from CONNECTING to AUTHENTICATING state on eapSuccess or eapFail. It
seems like the only cases in which this can occur are the canned Success
or canned Failure cases.
COMMENT END:
SUGGESTED CHANGES START:
Delete eapSuccess || eapFail from Figure 8-10 as a condition for the
transition from CONNECTING to AUTHENTICATING.
SUGGESTED CHANGES END:

NAME: Bernard Aboba
COMMENT TYPE: T
CLAUSE: 8.2.11.4
PAGE: 67
LINE: 19
COMMENT START:
I don't understand why the Supplicant PAE state machine transitions
from CONNECTING to AUTHENTICATING state on eapSuccess or eapFail. It
seems like the only cases in which this can occur are the canned Success
or canned Failure cases.
COMMENT END:
SUGGESTED CHANGES START:
Delte the sentence: "If the higher layer has decided it is satisfied with
an eapSuccess or eapFail, the Supplicant transitions directly to the
AUTHENTICATING state."
SUGGESTED CHANGES END:

NAME: Bernard Aboba
COMMENT TYPE: T
CLAUSE: 8.2.11
PAGE: 65
LINE: 23
COMMENT START:
I don't understand why the Supplicant PAE state machine transitions
from CONNECTING to AUTHENTICATING state on eapSuccess or eapFail. It
seems like the only cases in which this can occur are the canned Success
or canned Failure cases.
COMMENT END:
SUGGESTED CHANGES START:
Delete eapSuccess || eapFail from Figure 8-17 as a condition for the
transition fromnCONNECTING to AUTHENTICATING.
SUGGESTED CHANGES END:

NAME: Bernard Aboba
COMMENT TYPE: T
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 methodState==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: