Subject: [eap] Issue 142: Contents of the EAP-Request/Identity

From: [email-masked] (CONGDON,PAUL (HP-Roseville,ex1))
Date: Wed, 11 Jun 2003 10:46:38 -0400

Seems like this should really be considered at the link layer?   New
EAPOL-Start or EAPOL-Hello messages could contain the discovery
information...

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Tuesday, June 10, 2003 11:16 PM
> To: [email-masked]
> Subject: [eap] Issue 142: Contents of the 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
> Rationale/Explanation of issue:
> 
> 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 preceeding the null is displayed, with 
> the rest 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 Request/Identity Type-Data field
> 
> So as to provide the peer with a hint as to the appropriate 
> identity to place in the Type-Data field of the 
> EAP-Response/Identity, the authenticator may wish to identity 
> itself EAP-Request/Identity, in addition to providing a 
> displayable message to the peer, such as an Appropriate Use 
> Policy (AUP).
> 
> The following format is proposed for the null-terminated 
> displayable string and the comma-separated portion of the 
> EAP-Request/Identity message
> string:
> 
> <display-string>\0networkid=<network-name>,nasid=<nas-name>,po
> rtid=<port-id>
> 
> Where:
> 
> network-name: Name of the network to which the authenticator connects.
>               This is typically the SSID for IEEE 802.11.
> 
> 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) to enable administrators to display network 
> identification messages or appropriate use policies (AUPs)."
> 
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap
>

---

From: [email-masked] (Yoshihiro Ohba)
Date: Tue, 10 Jun 2003 09:19:35 -0700

I agree with Paul on not including the information (AUP, networkid,
nasid, portid) in EAP message.  Such information should be provided
before a peer chooses an appropriate authenticaticator with which it
starts EAP conversation.  In this sense, including the information in
802.1X frame might also be too late.  On the other hand, AUP should be
provided in a stateless fashon, because a user on a peer device tends to
take more time to read the AUP and make a decision to whether it
should start EAP conversation with the EAP authenticator that
originated the AUP.

Thus, I think the appropriate place is containing it in Beacon frame
in the case of 802.11 and in PANA authentication agent discovery
exchange in the case of PANA.  Of course the size of AUP text should
be as small as possible so that it does not consume the bandwidth.
 
Yoshihiro Ohba

---

From: [email-masked] (Jari Arkko)
Date: Thu, 12 Jun 2003 16:38:06 +0300

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 practise.

--Jari

---

From: [email-masked] (Bernard Aboba)
Date: Thu, 12 Jun 2003 10:24:05 -0700 (PDT)

>    the message should only be displayed until the nul.

I agree.

>    separated list of parameter=value assignments.

If we say even this much, we still have to define a grammar for the
parameters and the value assignments.  For example, I presume that
a value can't include a "," or "=" value without some sort of escape
mechanism. And the question will arise as to what characters are legal
within the parameters. And once we have an ABNF, then we'll need to make
sure it compiles and is actually correct.

I also suspect that even going this far will require some sort of IANA
registry to be set up, even if no parameters are defined in RFC 2284bis.

>    would the recommended practise.

Sure. It's just displayable text. It could be used for an AUP, or
alternatively, a witty Message of the Day :)

---

From: [email-masked] (Jari Arkko)
Date: Thu, 12 Jun 2003 22:28:48 +0300

> sure it compiles and is actually correct.

And probably also what information should be put in...

> registry to be set up, even if no parameters are defined in RFC 2284bis.

Point taken.

It looks like we have two alternatives.

1) Just say that there's some implementation dependent
    data after the nul.
2) Define the syntax, semantics, and IANA considerations
    for the parameters.

So, if you think we need interoperability for the parameters,
we need to go for alternative #2. Perhaps the text that you
posted earlier is good enough for that, though I'd move the
syntax text from appendix to the main document.

--Jari

---

From: [email-masked] (Bernard Aboba)
Date: Thu, 12 Jun 2003 12:19:43 -0700 (PDT)

> syntax text from appendix to the main document.

How about this:

a) In RFC 2284bis, we only do #1.
b) In a separate document, go for alternative #2 (assuming that there is
WG consensus), including all the work of specifying (and checking) the
ABNF, specifying parameters, writing the IANA considerations section, etc.

I'm just somewhat wary that task b) may be considerably larger than we
might imagine at the moment, and I don't want to delay RFC 2284bis until
it is done.

---

From: [email-masked] (Jari Arkko)
Date: Thu, 12 Jun 2003 23:03:32 +0300

> might imagine at the moment, and I don't want to delay RFC 2284bis until

Yes, that's what I also worried about. I'm OK with your suggestion
above.

--Jari