Subject: [eap] Proposed resolution to Issue 23: Reject

From: [email-masked] (Bernard Aboba)
Date: Tue, 7 Jan 2003 18:38:21 -0800 (PST)

Issue 23 relates to the contents of the identity request payload. In RFC
2284, Section 3.1, it says:

"An optional displayable message MAY be included to
prompt the peer in the case where there expectation of interaction
with a user."

and

"optionally, the failure MAY be indicated within the message of
the new Identity Request itself"

I read this as indicating that the primary purpose of the Identity Request
is for user display, and that it is treated as undistinguished octets,
rather than interpretted by the protocol itself.

My recommendation is therefore that the proposed change be REJECTED.
Comments welcome:

Further information on the issue and subsequent discussion can be found
at:
http://www.drizzle.com/~aboba/EAP/eapissues.html

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