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

From: "Adrangi, Farid" <[email-masked]>
Date: Thu, 2 Dec 2004 11:08:22 -0800

Bernard, all

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Wednesday, December 01, 2004 7:40 PM
> To: Adrangi, Farid
> Cc: [email-masked]
> Subject: RE: [eap] Re: Issue 281: Backward compatibility problem
> 
> 
> > Section 2.1 says:
> > "
> >    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 in the
> >    ABNF shown above.  In other words, the NUL character 
> followed by the
> >    NAIRealms list MUST be placed at the end.
> > "
> >
> > Please note the last sentence.  This means that the client 
> can always
> > start at the end of the string and extract realms until it 
> encounters a
> > "\0NAIRealms=".  Does this make sense?  Or am I missing 
> your point here?
> > BR,
> > Farid
> 
> I think you're proposing that a NULL be used as a separator.  Given
> current practice, I'm not sure why this is necessary.  Is 
> there a reason
> why an implementation couldn't just parse the data after a 
> NULL and look
> for "NAIRealms=" and then check whether the previous 
> character was a NULL
> or a comma?  This seems simple enough, and it would be 
> interoperable with
> existing implementations.
> 
> 

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.  And also, I am not
clear why the current grammar breaks interoperability with existing
implementation, and why it is not simple enough!   Please note that one
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=".   

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.   

2) Modify the grammar to allow the NAIRealms to be placed anywhere after
displayable message.

My preference is (1).  It would also be nice to know other people's
opinion on this.

BR,
Farid  
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 2 Dec 2004 23:37:07 -0800 (PST)

> 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.

> 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.

> the NUL character followed by the NAIRealms list MUST be placed at the

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

I'd prefer this.  It's more consistent with RFC 3748, as well as existing
implementations.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap