eap Mailing List: Re: [Issue] Corner case in 802.1X/EAP State Machines

[Yoshihiro Ohba (yohba]

On Mon, May 10, 2004 at 03:48:04PM -0700, Congdon, Paul T (ProCurve) wrote:
> 
> I think we are getting back to the fundamental issue of using the
> initial EAP-Req packet as both a means to determine if a supplicant is
> out there to communicate with and as a way to start an EAP session.
> Ideally, the authenticator would first aquire a supplicant to talk with,
> and then initiate the EAP session.  Since there is no way within EAPOL
> to have the authenticator start the conversation other than also
> initiating the EAP session, there is no way to avoid forcing the restart
> when the EAPOL-Start is received.  

I am not sure if there is no way to avoid forcing the restart when the
EAPOL-Start is received.  If the proposed variable eapBegun is defined
within 802.1X state machine with its initial value set to FALSE, and
the variable is set to TRUE when the first 802.1X EAP-Packet (which
carries the first EAP-Response from the EAP peer) is received, I think
it could function as expected without changing EAP state machine.

Yoshihiro Ohba


> Typically, the EAPOL-Start will be
> received before things even get going, so the back-end AS is never
> notified.  The scenario that Bernard originally described seems like it
> should be a pretty rare corner case and I don't see anywhere else it
> could be addressed other than the EAP machines.
> 
> Paul
> 
> > -----Original Message-----
> > From: eap-admin [at] frascone.com [mailto:eap-admin [at] frascone.com] 
> > On Behalf Of Yoshihiro Ohba
> > Sent: Monday, May 10, 2004 8:30 AM
> > To: Jim Burns
> > Cc: Paul Funk; Bernard Aboba; eap [at] frascone.com
> > Subject: Re: [eap] [Issue] Corner case in 802.1X/EAP State Machines
> > 
> > 
> > Hi Jim,
> > 
> > On Mon, May 10, 2004 at 10:32:46AM -0400, Jim Burns wrote:
> > > 
> > > An initial suggestion (I have not fully hand traced this) as to how 
> > > this
> > > might be done  would be to modify the EAP Authenticator 
> > state machine 
> > > with the following:
> > > 1.  add an internal variable:  eapBegun.
> > > 2.  Set eapBegun to FALSE in INITIALIZE state.
> > > 3.  On the transition from IDLE to RETRANSMIT alter the logic from 
> > > 'retransWhile==0' to be '(retransWhile==0 || ((eapBegun=FALSE) && 
> > > (eapRestart )))'
> > 
> > The eapRestart variable is set to FALSE in INITILIZE state, 
> > so I don't think this logic change does not change the actual 
> > behavior.
> > 
> > > 4.  Change unconditional transition into INITIALIZE from 
> > 'eapRestart 
> > > &&
> > > portEnabled' to '(eapRestart && (eapBegun=TRUE)) && portEnabled)'
> > > 5.  Set eapBegun to TRUE in RECEIVED state.
> > > 
> > > I doubt this catches all the nuances, and I am sure the EAP state
> > > machine folks might do it more elegantly, but I believe that this 
> > > achieves the goal that Paul has discussed.
> > 
> > As EAP always assumes that EAP authentication is initiated 
> > from EAP authenticator, I believe it should be the task of an 
> > EAP transport protocol (e.g., IEEE 802.1X) to have its own 
> > mechanism to avoid the race condition in initiaton of an EAP 
> > transport session.  As an example, PANA has its own mechanism 
> > to avoid a similar race condition in initiaton of a PANA 
> > session.  Thus, I don't think changing EAP state machine as 
> > suggested is the right solution.
> > 
> > Best regards,
> > 
> > Yoshihiro Ohba
> > 
> > 
> > > 
> > > Hope this helps,
> > > Jim B.
> > > 
> > > _______________________________________________
> > > eap mailing list
> > > eap [at] frascone.com http://mail.frascone.com/mailman/listinfo/eap
> > _______________________________________________
> > eap mailing list
> > eap [at] frascone.com
> > http://mail.frascone.com/mailman/listinfo/eap
> >