Subject: [eap] Proposed Resolution to Issue 142

From: [email-masked] (Bernard Aboba)
Date: Thu, 12 Jun 2003 13:27:23 -0700 (PDT)

Issue 142 is enclosed below. For the full text of all issues, see:
http://www.drizzle.com/~aboba/EAP/eapissues.html

I am concerned that the material proposed for Appendix A.2 is
currently not specified well enough, and would require considerable
additional work in order to complete, delaying RFC 2284bis. What we need
is:

a) An ABNF describing the grammar for the parameters and values;
b) IANA considerations for allocation of parameters and values.

This material is likely to require enough work (and be large enough)
to warrant a separate document on the subject. Therefore my recommendation
is that we only take the changes to Section 5.1 at this point, and
examine whether there is sufficient WG consensus to start work on
a separate document to handle a) and b).

Here are the proposed fixes:

In Section 5.1, change:

"This field MAY contain a displayable message in the Request,
containing UTF-8 encoded ISO 10646 characters [RFC2279]. The
Response uses this field to return the Identity. If the Identity
is unknown, this field should be zero bytes in length. The field
MUST NOT be null terminated. The length of this field is derived
from the Length field of the Request/Response packet and hence a
null is not required."

To:

"This field MAY contain a displayable message in the Request,
containing UTF-8 encoded ISO 10646 characters [RFC2279]. Where
the Request contains a null, only the portion of the field prior to
the null is displayed. If the Identity is unknown, the Identity Response
field should be zero bytes in length. The Identity Response field
MUST NOT be null terminated. In all cases, the length of the
Type-Data field is derived from the Length field of the
Request/Response packet."

--------------------------------------------------------------
Issue 142: Contents of EAP-Request/Identity
Submitter name: Tim Moore
Submitter email address: [email-masked]
Date first submitted: June 9, 2003
Reference:
Document: EAP-03
Comment type: T
Priority: S
Section: 5.1, Appendix A
Rationale/Explanation of issue:
In Section 5.1, change:

"This field MAY contain a displayable message in the Request,
containing UTF-8 encoded ISO 10646 characters [RFC2279]. The
Response uses this field to return the Identity. If the Identity
is unknown, this field should be zero bytes in length. The field
MUST NOT be null terminated. The length of this field is derived
from the Length field of the Request/Response packet and hence a
null is not required."

To:

"This field MAY contain a displayable message in the Request,
containing UTF-8 encoded ISO 10646 characters [RFC2279]. Where
the Request contains a null, only the portion of the field prior to
the null is displayed, with portion after the null used as a hint to the
peer as to the identity to be provided in the Response, as described
in Appendix A.2. If the Identity is unknown, the Identity Response
field should be zero bytes in length. The Identity Response field
MUST NOT be null terminated. In all cases, the length of the
Type-Data field is derived from the Length field of the
Request/Response packet."

Add to Appendix A:

"A.2 Contents of the EAP Request/Identity Type-Data field

In addition to providing a displayable message to the peer, the
authenticator may wish to provide a
hint as to the appropriate identity to place in the Type-Data field of the
EAP-Response/Identity.

To allow for both a displayable message as well as potential hints, the
EAP-Request/Identity message is formatted as follows:

<display-string>\0networkid=<network-name>,nasid=<nas-name>,portid=<port-id>

Where:

network-name: Name(s) of the network(s) to which the authenticator
connects. For 802.11, this will typically correspond to the SSID.

nas-name: Name or address of the NAS.

port-id: port that the EAP session is on.

The EAP peer should display display-string before the null termination
(\0)"

[Jari Arkko]:
Several issues relate to this problem. One issue is that
there's existing deployment where the nul character is
used to separate a message and a some other information
in EAP Identity Request.

Another issue is how to represent AUPs.

A third issue is how to represent parameters to the
peer, and if such parameters are needed in the first
place.

Given that we have a deployed protocol, I'd suggest
the following approach:

1. We need to document that there can be a nul character
in the data part of EAP Identity Request, and that
the message should only be displayed until the nul.

2. Perhaps we should not say too much about the
use of the field after the nul. Certainly no
normative text.

I don't think appendix A is the right place for
this text. I would try to cut the text down and
just place it as a note in the place where the
EAP Identity REquest is discussed. Like this,
for example:

Note: Some existing implementations are known to
pass parameters after the nul character. Support
for such parameters is implementation specific,
but where used their format SHOULD be a comma
separated list of parameter=value assignments.

3. Lets not claim anything about the AUP in the text.
I agree that its probably best done at the link layer,
but this may not always be possible. If it isn't
possible then the message in the identity request
may be used for that purpose. However, I wouldn't
write that down in the spec as I don't think that
would the recommended practice.