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

From: "Adrangi, Farid" <[email-masked]>
Date: Thu, 18 Nov 2004 09:42:31 -0800

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: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Jari Arkko
> Sent: Wednesday, November 17, 2004 12:59 PM
> To: Artur Hecker
> Cc: [email-masked]
> 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: [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
> > 
> > 
> 
> _______________________________________________
> 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: Artur Hecker <[email-masked]>
Date: Thu, 18 Nov 2004 19:38:41 +0100

Farid,

my remark was meant to say that i do not agree with the Issue 281. in my 
opinion it is wrong to change the ABNF as proposed in the issue 281.

so, i agree with you.

the only thing to clarify would be perhaps the coexistence with other 
implementations using the same mechanism. any implementation of your 
draft SHOULD be prepared for presence of other extensions using the same 
mechanism.

personally, i think it is quite easy to relax the requirements and to 
get the same result: i am not sure requiring NAIRealms at the end is the 
best choice - it could be easily violated by some proprietary mechanism. 
i think it is more robust and not really complicated to require parsing 
from 0 to length of the EAP message, searching for "\0NAIRealms" and 
extracting the data from the found position till to the next NUL or the 
message end.

however, i let the final decision to authors. in _any_ case, an 
implementation MUST handle NAIRealms data correctly. perhaps, you could 
provide a pseudo-code routine for that. (i am not sure this is already 
in the draft in any form; but in my opinion it has little to do with 
issue 281).

regards
artur