Subject: RE: [eap] Re: Issue 281: Backward compatibility problem

From: "Adrangi, Farid" <[email-masked]>
Date: Wed, 1 Dec 2004 11:54:12 -0800

Section 2.1 says:
"
   Some existing systems are known to use EAP-Request/Identity 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.
"

Please note the last sentence.  This means that the client can always
start at the end of the string and extract realms until it encounters a
"\0NAIRealms=".  Does this make sense?  Or am I missing your point here?
BR,
Farid

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Bernard Aboba
> Sent: Tuesday, November 30, 2004 7:25 PM
> To: [email-masked]
> Subject: [eap] Re: Issue 281: Backward compatibility problem
> 
> 
> 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: [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
> 
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 1 Dec 2004 19:40:12 -0800 (PST)

> "\0NAIRealms=".  Does this make sense?  Or am I missing your point here?

I think you're proposing that a NULL be used as a separator.  Given
current practice, I'm not sure why this is necessary.  Is there a reason
why an implementation couldn't just parse the data after a NULL and look
for "NAIRealms=" and then check whether the previous character was a NULL
or a comma?  This seems simple enough, and it would be interoperable with
existing implementations.