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

[Adrangi, Farid (farid.adrangi]

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: eap-admin [at] frascone.com [mailto:eap-admin [at] frascone.com] 
> On Behalf Of Bernard Aboba
> Sent: Tuesday, November 30, 2004 7:25 PM
> To: eap [at] frascone.com
> 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: 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.
> >
> >
> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap
>