Subject: [eap] Issue 281: Backward compatibility problem

From: Bernard Aboba <[email-masked]>
Date: Tue, 16 Nov 2004 16:35:06 -0800 (PST)

Issue 281: Backward compatibility problem
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
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.

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 16 Nov 2004 19:18:15 -0800 (PST)

Actually, I've rechecked the traces of existing implementations, and in
the cases I've looked at there is no NUL character.  So this may not be an
issue after all.

Can vendors who send info in the EAP-Request/Identity verify that a NUL
character is never sent?

---

From: Artur Hecker <[email-masked]>
Date: Wed, 17 Nov 2004 10:37:00 +0100

hello

we've already discussed that in the 2248bis scope.

> Can vendors who send info in the EAP-Request/Identity verify that a NUL

there is never a NUL character as long as the only sent data is the user 
identity (which is usually that displayable string). the NUL-char 
termination was prohibited by the RFC2248. the length field had to be 
used for that.

hence, the NUL-char can always be part of the sent data (imho, that was 
the original intention). thus, using the NUL char and _length from the 
message, an implementation can find the \0 at _pos and determine the 
length of the realm-list by substration: _length - _pos - 
length("NAIRealms").

this NUL character is thus indispensable in the ABNF at the place where 
it is. otherwise the string NAIRealms has to be excluded as possible 
identity part. if another implementation has to add something else, i 
suggest it includes a second NUL char at the end of the proposed format.

generally, every implementation using this mechanism has to be prepared 
to parse the whole length of data searching for the NUL characters and 
trying to parse what follows. it can never reasonably be assumed that it 
is the only one using NUL chars. this also presumes that NO 
implementation will ever use the NUL char for data (since it is now used 
as delimiter).

regards
artur

---

From: Jari Arkko <[email-masked]>
Date: Wed, 17 Nov 2004 22:59:27 +0200

I agree with this. And yes it is necessary to prepare
for the case that there's something else than this
particular piece of data.

--Jari

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 30 Nov 2004 19:25:25 -0800 (PST)

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.