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

From: [email-masked] (Bernard Aboba)
Date: Tue, 7 May 2002 17:50:54 -0700 (PDT)

Issue 23: Contents of Identity Request Payload
Submitter: Jesse Walker
Submitter email address: [email-masked]
Date first submitted: May 3, 2002
Reference: 
Document: RFC2869bis-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.