Subject: [eap] Issue 23: Contents of Identity Request Payload

From: [email-masked] (Bernard Aboba)
Date: Mon, 19 Aug 2002 05:59:57 -0700 (PDT)

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
Document: RFC2284bis-04
Comment type: T
Priority: S
Section: 5.1
Rationale/Explanation of issue:
Section 5.1 page 13 describes the Identity Type thusly:

The Identity Type is used to query the identity of the peer.
Generally, the Authenticator will issue this as the initial Request.
An optional displayable message MAY be included to prompt the Peer in
the case where there expectation of interaction with a user. A
Response MUST be sent to this Request with a Type of 1 (Identity).

This language is good as far as it goes, but I wonder if more formal rules
should be specified to enable the more mobile enviroments where EAP is
being
applied? What I have in mind is that it is likely that many (most?)
users/devices will have different sets of credentials for many of the
security domains they visit. Each of these credentials will assign to the
user/device a different artificial and arbitrary "identity".

In the wireless roaming case, it is likely that a user will sometimes
cross
domain boundaries without even knowing it, so the commonly cited industry
goal of "seamless" roaming would imply that the Identity Request from the
Authenticator should provide some hint as to which "identity" it is
expecting, i.e., which domain is in use. While the cited language above
does
not preclude this, it does not specify any interoperable way of
accomplishing this goal.

The obvious suggestion would be to insert the domain name portion of the
NAI
of the Authenticator in some standard way into the Identity Request. The
Peer could parse and then attempt to map this to the credentials it should
present to this particular Authenticator.
[BA] I think that there are a number of issues here:

1. How the Supplicant knows what NAI to present to the Authenticator,
if more than one is available.
2. What certificate the Supplicant presents when queried by the
Authenticator.
3. How to route the authentication itself, particularly
if EAP pre-authentication is used. (In this case, the
selected access point (and in the case of 802.11, SSID) is
not known at the time of authentication (assuming
that we are talking about a shared use AP advertising multiple
SSIDs).

Note that knowing the NAI of the Authenticator may not by itself
help answer these questions. In the case of wireless the AP is
also typically advertising its characteristics, which in the
case of 802.11 can include the SSID. Similar advertisements
have also been discussed in SEAMOBY.

So at the point at which EAP authentication occurs, the Supplicant
may have learned information about the AP, based on the L2 or
L3 advertisements.

So the question is how information to be added in the EAP
Identity-Request adds to (or possibly conflicts) with the
information in the advertisement.

For example, in 802.11 there are quite a few ways to implement
a shared use AP that can advertise multiple SSIDs. SSIDs
represent the networks to which the AP connects, which may is
often more useful than the NAI of the Authenticator itself.
For example, a single AP may advertise a roaming consortia SSID,
a WISP SSID, and maybe the SSID for a secure network. Each of
these SSIDs correspond to a different VLAN and access network.