Subject: [eap] Re: NULL character in EAP Identity Request/Response

From: Bernard Aboba <[email-masked]>
Date: Mon, 8 Mar 2004 09:34:11 -0800 (PST)

> Bernard Aboba wrote:
>
> > The difference is that the MUST NOT be null terminated directive applies
> > only to the Response, not to the Request.  I believe you are correct in
> > that a NULL can be present in the EAP Response. The Appendix appears
> > incorrect on this issue.
>
> thank you very much for the confirmation. since i am not familiar with
> WG procedures, is there anything i should/could do to correct the
> appendix (if it is possible at this stage anyway)?
>
>
> thank you
> artur hecker

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).
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Artur Hecker <[email-masked]>
Date: Tue, 09 Mar 2004 12:27:52 +0100

Hello

> 48 hours, since it's just an error in the change log (not in the actual

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

-- 
[email-masked]