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

[Bhawani Sapkota (bsapkota]

Hi Bernard,

I think there is only one positive action in this case. Since the client has 
already
abandoned the on-going eap conversation, and most likely has already reset its 
eap
state machine, by retransmitting original eap request (id=2 in your original 
email)
does not fix any problem. The correct action must therefore be the second 
option.

The question about what the server is supposed to do when it receives
Access-Request/EAP-Response/Identity, since it is an EAP-Response/Identity, the
server can unambiguously determine that this is not a continuation of the 
existing
session. However, if the state attribute is included, based on server's
implementation, it can further utilize that information to gain additional
information about the client's previous state.


Thanks and best regards
Bhawani Sapkota





> -----Original Message-----
> From: eap-admin [at] frascone.com [mailto:eap-admin [at] frascone.com] 
> On Behalf Of Jari Arkko
> Sent: Saturday, May 08, 2004 10:40 AM
> To: Bernard Aboba
> Cc: eap [at] frascone.com
> Subject: Re: [eap] [Issue] Corner case in 802.1X/EAP State Machines
> 
> 
> Bernard Aboba wrote:
> > Jari Arkko wrote:
> > 
> > 
> >>I don't know whether IEEE 802.1X is doing (a) or (b).
> > 
> > 
> > This raises the question of how the Authenticator/AAA server 
> > distinguishes EAP authentication instances.  My asssumption is that 
> > there can just be one EAP authentication instance ongoing 
> on a given 
> > port between two peers, so that the tuple <EAP peer, EAP 
> server, port> 
> > identifies an EAP authentication instance.
> 
> This makes sense, but I'm not sure if this has been
> written down anywhere. Has it?
> 
> > In that case, there can't be two instances of EAP authentication 
> > ongoing between the two peers at the same time, right?
> > 
> > Therefore the first instance must therefore be terminated.
> 
> Right.
> 
> >>Right. This implies that if the EAP authentication is 
> aborted, the AAA 
> >>transaction has to be abandoned as well, and a new one started.
> > 
> > 
> > The question is how this occurs.  The AAA server has sent an 
> > Access-Challenge/EAP-Request with ID=2, so responding with an 
> > Access-Request/EAP-Response/Identity of ID=3 doesn't match.
> > 
> > How does the AAA server know that this is a new session as 
> opposed to 
> > a continuation of an old one?  For example, is it supposed 
> to look for 
> > the presence/absence of a STATE attribute?
> 
> I suppose in Diameter this would be possible by sending a 
> Session-Termination-Request, or by just using a different 
> Session-Id AVP on the new request.
> 
> In RADIUS... I don't immediately see a way to do it.
> 
> > What we see today is that the AAA server will typically 
> send back an 
> > Access-Reject, because there is no way for a lower layer 
> "abort" to be 
> > passed to the AAA server.
> > 
> > This particular case is based on actual Supplicant behavior, not a 
> > malicious attacker.  While an EAPOL-Start might be sent as 
> the result 
> > of a reboot, change of user, etc. in this particular case, 
> it seems to 
> > be sent in the normal course of operations.
> 
> Yes. Which means that it should work. Somehow. I guess
> this leaves us with option 1 from your original e-mail.
> 
> Note: I think this is a larger issue than just with
> Identity Requests. If the peer committed to an EAP
> method before rebooting and resending EAPOL-Start
> (assuming there is no way to abort a session in RADIUS),
> the authenticator can only retransmit current
> request. It will not be able to start a new
> authentication, resulting in a lengthy timeout
> before the user can actually connect.
> 
> --Jari
> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap
>