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

[John Vollbrecht (jrv]

--On Monday, May 10, 2004 11:29 PM -0400 Nick Petroni <npetroni [at] cs.umd.edu> 
wrote:

> Sorry I am just playing catchup. This is an interesting conversation, but
> I am not sure we have yet captured the essence of what is going wrong in
> this scenario. First and foremost, I think the 802.1X-REV document is very
> clear what it *intends* EAP to do when an EAPOL-Start is received-
> everything should be reset. The informative section of that document
> reads:
>
> F.3.2 eapRestart
> The authenticator state machine sets this signal to indicate to the higher
> layer that PAE is restarting. It is expected that the higher layer will
> reset its state to remain synchronized with the PAE state machine. The
> higher layer must reset this signal to indicate it has completed its own
> restart. This signal is required to inform the higher layer of a PAE event
> that should cause the termination of in-progress or outstanding
> authentications. The higher layer must reset eapSuccess and eapFail after
> eapRestart is set true by the PAE layer.
>
> On Mon, 10 May 2004, Jim Burns wrote:
>
> > I believe the correct fix would be as follows:
> > The EAP state machine (not the .1X state machine) differentiates between
> > its initial EAP request and subsequent requests following receipt of a
> > response to its initial request.  If  EAP is in the initial state and
> > receives an 'eapRestart' then it ignores it and just resends its initial
> > request with the same ID.  In other words, put the resend of the initial
> > request that used to reside in the .1X-2001 machine in the EAP machine.
>
> If I understand this correctly, this seems to violate the informative
> section of 802.1X-REV and the spirit of what is meant in the 802.1X-REV
> machines IMHO. EAPOL-Start means game over as far as I can tell.
>
> The issue from my point of view seems to center around the interaction
> between EAP and the backend. One of my primary reasons for this conclusion
> is that a standalone authenticator is not likely to have this issue.
> eapRestart will be able to reset all state, including policy and the
> method, which cannot occur in the backend case. Furthermore, I am not sure
> if this really is 802.1X specific. What would happen if there were a
> backend authentication server in the PPP case and your phone line
> suddenly dropped, followed by the user dialing back in to the same modem?
> It seems there must be some way for the authenticator to "reset" the
> backend. Perhaps someone can help me distinguish these two scenarios?
>
> It seems to me that either
> (1) 802.1X wrongly assumes there is such a thing as "completely reset EAP"
> or
> (2) EAP is not quite clear how to implement this for passthrough.
>
> # 2 seems more likely and my guess is this is RADIUS-EAP specific, but I
> could certainly be missing some things in my analysis.
>
> Thanks,
> nick
I agree with your analysis.    I think this is a very interesting case and 
the discussion has been very informative.  I think there are differences in 
opinion on how this should work as well as problem with the handling of 
this on the backend.

In looking at this is seems that 802.1X does set eapRestart at appropriate 
places, and EAP does handle this in both the standalone and full 
authenticator, resetting variables and starting EAP again.   In my opinion 
this is correct.

There are two other cases where it seems a problem.

1) In the passthrough case it is not clear whether eapRestart goes to the 
INITIALIZE state for the full Authenticator or just falls through.  In this 
case I think it should go to the INITIALIZE state, and the fix might be to 
include an INITIALIZE-2 state in the passthrough diagram that would 
indicate this.  Other ways to fix it might be possible, but the requirement 
seems to be that eapRestart reset the authentication.

2) In the backend case (which is I think what Bernard was talking about), 
there is no way in the state machine to signal that the authentication 
should be restarted.  My understanding of what happens in the case where 
the  Passthrough authenticator/NAS has gone to restart and then sends a new 
RADIUS Request with new EAP message is that the RADIUS server passes the 
new eap message to the EAP machine.

2.1) If the RADIUS/EAP request has no EAP message - i.e. it is an initial 
request - the backend server could go to INITIALIZE and reset variables and 
start a new authentication.  It does not do this right now, but this seems 
a reasonable thing to change.

2.2) If the RADIUS/EAP request has an EAP Response message, the server does 
not seem to have any way to know if the EAP Response is for a new EAP 
authentication or a continuation of the old authentication.  Here there 
seem to be two cases, one where the EAP method in the request is identical 
to the  one waiting to respond, and one where the methods are different.

2.2.1) When the EAP method in the new request is the same as that in the 
old request, I see no way signal to the state machine that it should reset. 
In this case it seems that some additional information in the RADIUS 
Request may be needed - a "first EAP message" attribute.  This would allow 
the backend server to know that this a first request and go to INITIALIZE. 
Alternatively one might do something iffy like sendig a RADIUS Accounting 
Done message prior to sending the first EAP message.  I am interested if 
there are better ideas.

2.2.2) When the EAP methods are different, one could assume that a new 
authentication is started and go to INITIALIZE.  This uses the idea that 
EAP methods cannot be chained.   However, whatever fix for 2.2.1 gets 
implemented will probably fix this as well, so finding an appropriate fix 
for 2.2.1 seems the right approach.

The above is an attempt to suggest changes to support Nick's idea that 
there is a problem between the authenticator and backend.  I think the 
suggested change to 1) and 2.1) seem fairly minor and probably should be 
done.  I am not sure about the fix to 2.2.1, but it seems that one is 
needed.

Comments?

-- John