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

[Bernard Aboba (aboba]

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?

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