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

[Adrangi, Farid (farid.adrangi]

Bernard, all
Please see my reponse at the end.
BR,
Farid

> -----Original Message-----
> From: Bernard Aboba [mailto:aboba [at] internaut.com] 
> Sent: Thursday, December 02, 2004 11:37 PM
> To: Adrangi, Farid
> Cc: eap [at] frascone.com
> Subject: RE: [eap] Re: Issue 281: Backward compatibility problem
> 
> 
> > I agree with you that the current restriction of placing 
> NAIRealms at
> > the end is not necessary.  At the same time, I am not clear what
> > practical benefit your suggested grammar brings.
> 
> The "suggested grammar" is already in use, so this isn't a
> greenfield design.  Unless there is a good reason, why are we
> changing the separator from a comma to a NULL character?  It 
> seems quite
> unusual to use the NULL character this way.
> 
> > advantage of the current grammar is that it provides an 
> unambiguous way
> > to handle the case where the proprietary data for some 
> reason includes
> > the string "\0NAIRealms=".
> 
> To my knowledge, no existing implementation utilizes the "NAIRealms"
> string, so I'm not sure why an ambiguity would exist, except perhaps
> that the existing "networkid" string already serves a similar 
> function.
> However, since this is typically used to advertise a flat 
> name such as an
> SSID rather than an FQDN, I don't think this overlaps with 
> the proposed
> "NAIRealms" functionality.
> 
> > Anyhow, going forward, I see two options:
> >
> > 1) Leave the ABNF as it is, and make the following clarification
> > (enclosed in **) to the last paragraph in 2.1:
> >
> > Some existing systems are known to use EAP-Request/Identity 
> messages to
> > send proprietary information to the peer.  This proprietary 
> information
> > is considered to be part of the displayable-string *(which 
> can contain
> > any octets including NULs)* in the ABNF shown above.  In 
> other words,
> > the NUL character followed by the NAIRealms list MUST be 
> placed at the
> > end.
> 
> I think this part of the spec is in conflict with RFC 3748 
> Section 5.1:
> 
>       This field MAY contain a displayable message in the Request,
>       containing UTF-8 encoded ISO 10646 characters [RFC2279].  Where
>       the Request contains a null, only the portion of the field prior
>       to the null is displayed.
> 
> So RFC 3748 seems to imply that the "displayable string" is 
> the portion
> prior to the first null, not that portion prior to the last 
> null.  That's
> how current implementations operate anyway, and I don't think it's
> appropriate for this specification to modify that.
> 
> > 2) Modify the grammar to allow the NAIRealms to be placed 
> anywhere after
> > displayable message.
> 
> I'd prefer this.  It's more consistent with RFC 3748, as well 
> as existing
> implementations.
> 

Ok.  I think we can live with #2 as well :-)  So, how about if we
replace the current grammar and text after it in section 2.1 with the
following?  Would that address your concern?



identity-request-data = [ displayable-string ] %0x00 [ Network-Info ]   

displayable-string    = *CHAR

Network-Info          = *OCTET ["," "NAIRealms=" realm-list "," ] *OCTET

             
realm-list            = realm /
                        ( realm-list ";" realm )

The "OCTET" and "CHAR" rules are defined in [RFC2234] and the "realm"
rule is defined in [rfc2486bis].

A sample hex dump of an EAP-Request/Identity packet is shown below.

      01                        ; Code: Request
      00                        ; Identifier: 0
      00 43                     ; Length: 67 octets
      01                        ; Type: Identity
      48 65 6c 6c 6f 00 2C 4e   ; "Hello\0,NAIRealms=example.com;mnc014.
      41 49 52 65 61 6c 6d 73   ; mcc310.3gppnetwork.org,"
      3d 69 73 70 2e 65 78 61
      6d 70 6c 65 2e 63 6f 6d
      3b 6d 6e 63 30 31 34 2e
      6d 63 63 33 31 30 2e 33
      67 70 70 6e 65 74 77 6f
      72 6b 2e 6f 72 67 2C

The Network-Info can contain NAIRealms list in addition to proprietary
information. The proprietary information can be placed before or after
NAIRealms list.  To extract NAIRelams list, an implementation can parse
the data after a NUL and look for "NAIRealms=" and then check whether
the previous character was a comma.  Once "NAIRealms=" immediately
followed by a comma is found, the implementation can read the realms
until it encounters a comma character.