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

From: Bernard Aboba <[email-masked]>
Date: Sat, 8 May 2004 09:36:55 -0700 (PDT)

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.

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. 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?

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.

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

---

From: Jari Arkko <[email-masked]>
Date: Sat, 08 May 2004 20:40:18 +0300

> so that the tuple <EAP peer, EAP server, port> identifies an EAP authentication

This makes sense, but I'm not sure if this has been
written down anywhere. Has it?

> Therefore the first instance must therefore be terminated.

Right.

> 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.

> 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

---

From: "Bhawani Sapkota" <[email-masked]>
Date: Sat, 8 May 2004 15:51:05 -0700

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: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Jari Arkko
> Sent: Saturday, May 08, 2004 10:40 AM
> To: Bernard Aboba
> Cc: [email-masked]
> Subject: Re: [eap] [Issue] Corner case in 802.1X/EAP State Machines
> 
> 
> Bernard Aboba wrote:
> > Jari Arkko wrote:
> > 
> > 
> > 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.
> 
> > In that case, there can't be two instances of EAP authentication 
> > ongoing between the two peers at the same time, 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.
> > 
> > 
> > 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?
> 
> > 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.
>

---

From: Jari Arkko <[email-masked]>
Date: Sun, 09 May 2004 02:51:00 +0300

> abandoned the on-going eap conversation, and most likely has already reset its eap

Yes.

> does not fix any problem. The correct action must therefore be the second option.

You may have a point there.

There appears to be a few cases where the retransmission would
work:

- We are still in the EAP identity request phase at the time
   the EAPOL-Start arrives.

- We are sending the first message in a method, the peer
   is OK with skipping the identity request phase, and the
   EAP server is the right one for the peer.

But in general, it doesn't work. A lengthy timeout will
result.

> information about the client's previous state.

Maybe. Too bad RFC 3579 doesn't say anything about this matter.

--Jari