eap Mailing List

View Index by: Date - Thread - Author
Re: Re: Issue 281: Backward compatibility problem
From: Artur Hecker (heckerenst.fr)
Date: Thu, 18 Nov 2004 13:38:47 -0500 (EST)
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


Results generated by Tiger Technologies using MHonArc.