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

[Jari Arkko (jari.arkko]

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