Subject: [eap] Issue: Identifier conflict

From: [email-masked] (Bernard Aboba)
Date: Fri, 4 Apr 2003 12:11:58 -0800 (PST)

Maybe the right thing to do here is to prohibit use of EAP-Start in this
circumstance? We could instead require that the Access-Request contain an
EAP-Response/Nak. This would provide the Identifier so that the conflict
would not occur.

---

From: [email-masked] (Bernard Aboba)
Date: Fri, 4 Apr 2003 12:35:53 -0800 (PST)

I've taken a shot at eliminating use of EAP-Start when a Nak Response is
received. A strawman version of RFC 2869bis-12 including the fix is
available for inspection here:

http://www.drizzle.com/~aboba/EAP/draft-aboba-radius-rfc2869bis-12.txt

---

From: [email-masked] (Jari Arkko)
Date: Sat, 05 Apr 2003 10:00:06 +0300

> EAP-Response/Nak. This would provide the Identifier so that the conflict

Works for me. (But has the use of EAP-Start for this been implemented
already somewhere, and if so, what are the backwards compatibility
issues?)

Jari

---

From: [email-masked] (Bernard Aboba)
Date: Fri, 4 Apr 2003 23:04:56 -0800 (PST)

> already somewhere, and if so, what are the backwards compatibility

No, it hasn't been implemented yet, because this wasn't in RFC 2869. It
came up because IEEE 802.1aa didn't like the idea of requiring an
EAP-Start in the case where EAP-Request/Identity might not be the first
packet sent.

The reasons for this was that although 802.1X Supplicants *can* begin with
an EAPOL-Start, on wired networks they typically do not do this (because
of the effect that an EAPOL-Start had on an early version of some popular
hardware). As a result, the Authenticator needs to begin the conversation
and until the Supplicant responds, it doesn't know whether the Supplicant
is EAP-capable or not. In an environment with lots of EAP-incapable
clients, doing an EAP-Start on each "carrier sense" could inundate the
RADIUS server with requests, many of which would never be answered and
would therefore sit using up memory until they timed out.

The alternative is to have the NAS initiate with an EAP-Request, but this
too has issues. Unless the EAP-Request is just a "wakeup" packet, or the
first EAP-Reponse encapsulates the important fields of the initial
EAP-Request, an EAP method will not work well. This is because the NAS
only sends the EAP-Response in its Access-Request, *not* the original
EAP-Request. If that EAP-Request is content-free (as it is in EAP-TLS),
then this works fine. However, if the EAP-Request contains essential
information (as it does in EAP-Archie) then there is a problem unless that
information is replicated in the Response (e.g. the nonce in the
EAP-Request is repeated in the EAP Response).

Make sense?

---

From: [email-masked] (Jo Hermans)
Date: Fri, 11 Apr 2003 18:28:16 +0200

>On Fri, 4 Apr 2003, Bernard Aboba wrote:
Note that the scenario that causes this problem can be found in 
RFC2869bis-10, on page 34 (Nas sends EAT-Request/EAP-TLS to peer, who 
refuses).

So if the RADIUS server receives an Access-Request/EAP-Response/Nak, 
that doesn't match any previous request send by this RADIUS-server, it 
has to assume this scenario, and start a new EAP-conversation (most 
likely a EAP-Request/Indentity) ?

Then we'll also have to change paragraph 4.1 ("The Identifier Field of 
the Response MUST match that of the currently oustanding Request ..."), 
which forces us to silently discared 'unknown' responses.

-- 
Jo Hermans

That's not encrypted - that's a perl script I'm working on