Subject: [eap] Recommended Resolution of Issue 23: Reject

From: [email-masked] (Bernard Aboba)
Date: Wed, 27 Nov 2002 14:59:01 -0800 (PST)

Issue 23: Contents of Identity Request Payload
Submitter: Jesse Walker
Submitter email address: [email-masked]
Date first submitted: May 3, 2002
Reference: http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue 23
Document: RFC2284bis-04
Comment type: T
Priority: S
Section: 5.1

Resolution:

This issue was discussed in depth within the EAP State Machine design team
and consensus was not reached.

In most cases (though not all), EAP is used in situations where the
network to which the peer is connecting is known, either because it is
preconfigured (PPP, L2TP, PIC), or due to an advertisement that is
received out-of-band (PPPOE, 802.11, 802.1ad, CARD).

A possible exception to this is IEEE 802 wired networks where there
is currently no advertisement/discovery mechanism. However, one is under
development, so that it is possible that it too may provide the peer with
indication of what network it is connected to.

Another possible exception is IEEE 802.1X pre-authentication which occurs
prior to association. Where multiple SSIDs are advertised, each with the
same BSSID, it may not be possible to know which network is being
pre-authenticated to. However, advertising multiple SSIDs with a single
BSSID does not work reliably today anyway, due to station limitations and
if each SSID has its own BSSID then the problem goes away.

Given that it already appears that a solution exists without adding
functionality to EAP, the case for adding this to the
EAP-Request/Identity message cannot be made.

If there is another reason for doing this, please open another issue
describing that (new) case.