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

From: "Adrangi, Farid" <[email-masked]>
Date: Mon, 6 Dec 2004 14:11:52 -0800

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

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Thursday, December 02, 2004 11:37 PM
> To: Adrangi, Farid
> Cc: [email-masked]
> 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.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Tue, 07 Dec 2004 12:58:04 +0200

Bernard, Farid,

>>    anywhere after displayable message.
>
> as existing implementations.

I would prefer #2 as well.

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

The general approach is correct, but I'd prefer making the
NAIRealms data start with either directly after the NUL character
or after a comma -- not always with a comma. How about this:

Network-Info     =   "NAIRealms=" realm-list
Network-Info     =/  1*OCTET ",NAIRealms=" realm-list
Network-Info     =/  "NAIRealms=" realm-list "," 1*OCTET
Network-Info     =/  1*OCTET ",NAIRealms=" realm-list "," 1*OCTET

Note that this still allows multiple %0x00's to be present
at various places. For instance, the following would all be
legal

     foo\0NAIRealms=snaap.com
     bar\0NAIRealms=fryyp.com\0\0\0\0
     foobar\0\0\0\0,NAIRealms=example.com
     \0APQuality=0,NAIRealms=arkko.com

>       41 49 52 65 61 6c 6d 73   ; mcc310.3gppnetwork.org,"

Ok otherwise but I'd prefer getting rid of the "," after
"\0".

> until it encounters a comma character.

Slightly revised:

   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 either
   finds the "NAIRealms=" immediately after the NUL or seeks forward to
   find ",NAIRealms" somewhere in the string. The realms data ends either
   at first "," or at the end of the string, whichever comes first.

--Jari