eap Mailing List: Re: Issue 281: Backward compatibility problem

[Bernard Aboba (aboba]

I have now captured a trace of an Access Point using a NULL character
within the EAP-Request/Identity.  The dump below is in hex, the decode is
in decimal.  A JPG screen capture (from Airopeek) is available at:
http://www.drizzle.com/~aboba/EAP/eapreq.jpg

            01 37 00 36 01 00 6E 65 74 77 6F 72      .7.6..networ
6B 69 64 3D 4D 53 46 54 57 4C 41 4E 2C 6E 61 73  kid=MSFTWLAN,nas
69 64 3D 43 55 53 52 45 44 30 34 30 43 33 34 32  id=CUSRED040C342
30 2C 70 6F 72 74 69 64 3D 30 00 00 00 00        0,portid=0

Here is a decode of the above EAP packet:

Code: 1 (Request, one octet)
Identifier: 55 (one octet)
Length: 54 (two octets)
Type: 1 (Identity, one octet)
Type-Data:
NULL (one octet)
networkid=MSFTWLAN,nasid=CUSRED040C3420,portid=0
NULLs (4 octets)

There are a number of issues brought up by this trace:

a. Existing implementations place data after the NULL character
within the EAP-Request/Identity packet.
b. There can be multiple NULL characters in the
EAP-Request/Identity packet.  In this particular trace, there is one at
the beginning of the Type-Data field, and four NULLs at the end.
c. Existing access points place the networkid string first in the
packet, with the nasid and portid strings second and third.
d. A comma is used as a field separator.

As a result it would seem to me that this specification cannot require
that the NAIRealms string be placed first in the list; an arbitrary
series of other strings, separated by "," could be placed prior to
NAIRealms.

Also, Section 2.1 is not correct.


On Tue, 16 Nov 2004, Bernard Aboba wrote:

> Issue 281: Backward compatibility problem
> Submitter name: Bernard Aboba
> Submitter email address: aboba [at] internaut.com
> Date first submitted: 11/16/2004
> Reference:
> Document: IDSEL-05
> Comment type: T
> Priority: S
> Section: 2.1
> Rationale/Explanation of issue
>
> I think that there is a problem with the ABNF defined in Section 2.1.
>
>     identity-request-data = [ displayable-string ]
>                               [ %x00 "NAIRealms=" realm-list  ]
>       displayable-string    = *OCTET
>       realm-list            = realm /
>                               ( realm-list ";" realm )
> Section 2.1 states:
>
> "Some existing systems are known to use EAP Identity/Request messages
> to send proprietary information to the peer. This proprietary
> information is considered to be part of the displayable-string in the
> ABNF shown above. In other words, the NUL character followed by the
> NAIRealms list MUST be placed at the end."
>
> Actually, existing implementations send information such as the
> NAS-Identity *after* the NUL character. Requiring the NAIRealms list to be
> sent first is therefore not backward compatible with existing
> implementations.
>
> I'd suggest that you need to change the ABNF to enable the NAI-Realms
> attribute to be separated from the NUL character by text other than the 
> attribute
> separator used by existing implementations.
>
>