Subject: RE: [802.1] [eap] [Issue] Corner case in 802.1X/EAP State Machines

From: "Congdon, Paul T (ProCurve)" <[email-masked]>
Date: Tue, 11 May 2004 11:15:44 -0700

> I think there is some problem in case 2 (not exactly the same 
> as case 1, but essentially the same in terms of state 
> synchronization), i.e., how the Supplicant can tell whether 
> ID Req(113) is the first EAP request of the second 
> authentication or the second EAP request of the first authentication?
> 

From the transport's point of view (e.g. 802.1X), it doesn't care if
this is the 1st or 2nd EAP-Request.  This is EAP's job to figure this
out and get the conversation going.

> It seems to me that it is not a good idea to use EAPOL-Start 
> message for multiple purposes, i.e., initiating a session and 
> aborting a session (and then reinitiating a new one).  To 
> accomplish a better state synchronization, I believe that a 
> different message should be used for aborting session and 
> that message should be acknowledged (with some retransmission).
> 

The EAPOL-Start is not really being used for multiple purposes.  It is,
as it always has been, used to speed-up the conversation which is
ultimately driven by the authenticator.  It is therefore only used to
initiate a session, and actually, does not need to be sent at all.  In
fact, implementations would be best served if they put some form of
jitter in their sending of EAPOL-Start to avoid this potential race.

At the end of the day, there is no infinite loop here at start-up.  A
slight hick-up can occur when EAP is trying to get the initial request
out, but nothing is actually broken and no changes are needed to
802.1X/REV.

Paul

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 11 May 2004 18:08:46 -0700

> out and get the conversation going.

EAP state machines defines eapRestart variable to reset the
conversation (except for the EAP backend authenticator state machine,
as Nick pointed out, which should be resolved in EAP).  This means
that it is the transport's job (e.g., 802.1X) to set the eapRestart
when the conversation needs to be reset (as specified in 802.1X).  In
addition, the timing to set the variable at each end should be
synchronized as much as possible, and the synchronization should be
maintained by the entities that set the variable.  It is a bit strange
to me to see a transport that resets its application (i.e., EAP) but
without synchronizing itself in its normal operation (I think Jim's
case 2 is a normal operation that occurs at an unfortunate timing).

Yoshihiro Ohba