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

[Adrangi, Farid (farid.adrangi]

Hi Jari, Artur

Regarding to the last paragraph in Artur's e-mail:

> 
> 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).
> 

In the context of the network discovery draft, we need to make sure that
an implementation can extract NAIRealms information.  Given the
following facts in the draft:

1) NAIRealms is always placed at the end
2) NAIRealm follows by a NUL
3) NAIREALM data does not include NUL

an implementation should always be able to extract the NAIRealms
information.  For the rest of stuff (i.e., displayable string or other
proprietary stuff), we don't need to worry about the use of NUL (e.g.,
should it be used as delimiter?  Can it be included in data?) in this
draft - do we?

Are we agreeing that this is not an issue and hence to changes required
to the draft?

BR,
Farid





> -----Original Message-----
> From: eap-admin [at] frascone.com [mailto:eap-admin [at] frascone.com] 
> On Behalf Of Jari Arkko
> Sent: Wednesday, November 17, 2004 12:59 PM
> To: Artur Hecker
> Cc: eap [at] frascone.com
> Subject: Re: [eap] Re: Issue 281: Backward compatibility problem
> 
> 
> 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
> 
> Artur Hecker wrote:
> > hello
> > 
> > 
> > we've already discussed that in the 2248bis scope.
> > 
> > Bernard Aboba wrote:
> > 
> >> 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?
> > 
> > 
> > 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
> > 
> > 
> > 
> >>
> >> 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
> > 
> > _______________________________________________
> > eap mailing list
> > eap [at] frascone.com
> > http://mail.frascone.com/mailman/listinfo/eap
> > 
> > 
> 
> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap
>