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

[Artur Hecker (hecker]

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