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

[Bari, Farooq (Farooq.Bari]

If there is no disagreement then maybe we can close the issue 281 with
no changes to the draft. I have not seen any disagreement to it so far.

BR,

Farooq
-----Original Message-----
From: eap-admin [at] frascone.com [mailto:eap-admin [at] frascone.com] On Behalf
Of Artur Hecker
Sent: Thursday, November 18, 2004 10:39 AM
To: Adrangi, Farid
Cc: eap [at] frascone.com
Subject: Re: [eap] Re: Issue 281: Backward compatibility problem

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


> 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
>>
_______________________________________________
eap mailing list
eap [at] frascone.com
http://mail.frascone.com/mailman/listinfo/eap