eap Mailing List: Re: Re: NULL character in EAP Identity Request/Response

[Artur Hecker (hecker]

Hello


Bernard Aboba wrote:

> You might suggest alternate text.  We should be able to fix this in Author
> 48 hours, since it's just an error in the change log (not in the actual
> text).

ok, thanks.

the old text in the current 2284bis is:

   o  The null character is forbidden in the Type-Data field of an
      Identity Response message, as it is in RFC 2284.  However, this
      rule has been relaxed for Identity Requests, and it is now
      required in Section 5.1 that if the Type-Data field of an Identity
      Request contains a null character, only the part before the null
      is displayed.

there is no distinction between Identity Request and Response in RFC2284 
(s. RFC2284/Section 3.1). however, 2284bis introduces that distinction 
in 2285bis/Section 5.1. thus, i suggest to change it to:

   o  It is now required in Section 5.1 that if the Type-Data field of
      an Identity Request contains a null character, only the part
      before the null is displayed. RFC 2284 prohibits the Null
      termination of the Type-Data field of Identity messages. This
      rule has been relaxed for Identity Request messages and the
      Identity Request Type-Data field may now be null terminated.


That would reflect what is written in the current 2284bis.

However, I tend to question this explicit distinction of Requests and 
Responses. What would speak against an equivalent change for the 
Identity Response? As we agreed, the Null character could be present in 
Response/Identity fields. How does a usual NAS displays that today? 
Would it change anything if we added the equivalent _Recommendation_ to 
not _display_ the portion of the Response after the (already allowed) 
Null character without changing anything else?

Currently, 2284bis states (page 28, Section 5.1):

Type-Data

      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.

First, note that the phrasing is quite imprecise: e.g. "where the 
Request contains a null" is misleading (since it does not mention the 
field); also, strictly speaking there is no "Identity Response" field - 
it should be "Type-Data field of the Identity Response message". Sorry 
if i'm being a nitpicker...

Second, because of the possible presence of the Null-character in 
Responses, I would suggest to change this section to:

Type-Data

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


Finally, one last remark: back in "Appendix A. Changes from RFC 2284" 
the current 2284bis states:

   o  In Section 5, Section 5.1 and Section 5.2, requirements has been
      added that fields with displayable messages should contain UTF-8
      encoded ISO 10646 characters.

Looking at the text of Section 5.1, I don't see a SHOULD requirement. It 
is rather a MAY (s. above). If it was supposed to be a "SHOULD", the 
first phrase in Section 5.1 should be changed, stressing out the SHOULD 
notion:

      This field MAY contain a displayable message in the Request.
      Such displayable message SHOULD contain UTF-8 encoded ISO 10646
      characters [RFC2279].

The same applies to Section 5.2 though it is clearer since there is no 
explicit MAY notion in 5.2.

I'm sorry if my comments are too quibbling and, especially, if they come 
too late.


thank you for your attention
artur

--
hecker [at] enst.fr