Subject: [Technical Errata Reported] RFC4282 (1848)

From: RFC Errata System <[email-masked]>
Date: Tue, 8 Sep 2009 08:35:21 -0700 (PDT)

The following errata report has been submitted for RFC4282,
"The Network Access Identifier".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4282&eid=1848

--------------------------------------
Type: Technical
Reported by: Alan DeKok <[email-masked]>

Section: 2.4

Original Text
-------------
   o  Normalization requirements, as specified in Section 2.2 of
      [RFC4013], are also designed to assist in comparisons.

Corrected Text
--------------
  o Normalization is, in general, a bad idea.

Notes
-----
Much of RFC 4282 is simply wrong.

Normalization can be done only when both the local and character set information is included with the text.  And that information is not included with the username or realm.

In addition, not all systems will treat "User" the same as "user".  The decision about how to
compare user names is site specific.  User name comparisons SHOULD NOT be performed on
any system other than the final one that performs user authentication.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC4282 (draft-ietf-radext-rfc2486bis-06)
--------------------------------------
Title               : The Network Access Identifier
Publication Date    : December 2005
Author(s)           : B. Aboba, M. Beadles, J. Arkko, P. Eronen
Category            : PROPOSED STANDARD
Source              : RADIUS EXTensions
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 9 Sep 2009 10:40:24 +0200

> Much of RFC 4282 is simply wrong. 

If this is the case, I do not believe that an Errata is the right
instrument to fix the situation, but rather the WG working on a document
to obsolete and replace RFC 4282 or simply declare it Historical. 

I would invite other opinions from the WG and especially from the
editors. 

Thanks and Regards,

Dan

> -----Original Message-----
> From: RFC Errata System [mailto:[email-masked]] 
> Sent: Tuesday, September 08, 2009 6:35 PM
> To: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; Romascanu, 
> Dan (Dan); [email-masked]; [email-masked]; 
> [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]
> Subject: [Technical Errata Reported] RFC4282 (1848)
> 
> 
> Normalization can be done only when both the local and 
> character set information is included with the text.  And 
> that information is not included with the username or realm.
> 
> In addition, not all systems will treat "User" the same as 
> "user".  The decision about how to compare user names is site 
> specific.  User name comparisons SHOULD NOT be performed on 
> This errata is currently posted as "Reported". If necessary, 
> please use "Reply All" to discuss whether it should be 
> verified or rejected. When a decision is reached, the 
> verifying party (IESG) can log in to change the status and 
> edit the report, if necessary. 
>

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 9 Sep 2009 11:29:59 +0200

> I would invite other opinions from the WG and especially from the

Not that I want to question (God forbid!) the godlike opinion of Alan DeKok,
but could we have just a smidgeon of justification for that statement before
tossing RFC 4282?

...

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 9 Sep 2009 12:24:15 +0200

Alan T DeKok [mailto:[email-masked]] writes:

> Glen Zorn wrote:
>   Perhaps you would appreciate my comments more if I noted that:
> 
> a) the i18n work in 4282 has been deprecated, found to be faulty, or
>    replaced, by later i18n documents
> 
> b) nearly all of the rest of the recommendations in 4282 have been
>    ignored (and not implemented) by all of the AAA vendors
> 
> c) I was not involved in any of the i18n work that negated the
>    recommendations of 4282
> 
> d) no major AAA vendor has ever asked for my opinion on how to
>    implement 4282 in their product.
> 
> 
>   Don't blame the messenger.
> 
>   If you have a problem with the statement that 4282 is wrong, go fight
> with the i18n people.  Once you've done that, go force all of the AAA
> vendors to implement the other recommendations of 4282.
> 
>   Or, you can attack me for pointing out the problems.  Which is
> easier?

"it's wrong" hardly qualifies as "pointing out the problems".  OTOH, this
message (was it so hard?) may.

> 
> 
>   This subject was discussed last year on the on RADEXT list.  See
> message subjects with 4282 in them.  I don't see you having any
> comments
> at that time.  I also see a number of comments from other people who
> also claim to see problems with 4282.
> 
> 
>   At a minimum:
> 
> - the mapping requirements are likely wrong.  Intermediate nodes
>   should not be doing comparisons on the username portion of an NAI.
> 
> - the bidirectional rules are superseded by later BIDI documents
> 
> - the suggestion to reject NAIs with unassigned code points
>   means that those code points can never be assigned, as conformant
>   implementations that have not yet been updated will reject those
> NAIs.
> 
> - the suggestion to encode NAIs as punycode is implemented by no one.
> 
> - the suggest for intermediate nodes to normalize the NAI is
>   unnecessary, can cause inter-operability requirements, and is
>   implemented by no one.
> 
> 
>   Again, these are not *my* points.  I'm just repeating comments from
> *other* people on the RADEXT mailing list.
> 
>   Alan DeKok.

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 9 Sep 2009 14:54:18 +0200

Alan T DeKok [mailto:[email-masked]] writes:

>   The errata I filed had explanations as to what was wrong, why it was
> wrong, and suggested replacement text.
> 
>   You picked *one* sentence out of 20, ignored the rest, ignored the
> previous mailing list discussion, and then claimed (essentially) that I
> had no justification for seeing problems with 4282.
> 
>   Could you please read my messages before attacking me?

Terribly unfair of me.  To redress this wrong, I have reproduced the erratum
in question in full below:

Errata ID: 1848

Status: Reported
Type: Technical

Reported By: Alan DeKok
Date Reported: 2009-09-08

Section 2.4 says: 

It should say:

Notes:

Normalization can be done only when both the local and character set
information is included with the text. And that information is not included
with the username or realm.

In addition, not all systems will treat "User" the same as "user". The
decision about how to
compare user names is site specific. User name comparisons SHOULD NOT be
performed on
any system other than the final one that performs user authentication. 

I count 8 sentences (including the one reproduced from the RFC), not 20.
One of those sentences appears to be irrelevant hyperbole ("Much of RFC 4282
is simply wrong.") & another is incomprehensible (what does "Normalization
can be done only when both the local and character set information is
included with the text." mean?  Did you mean "locale"?  Why should we have
to guess?).  Based upon this evidence, I have no choice but to conclude that
you are absolutely right: RFC 4282 should be trashed immediately (apparently
the same conclusion reached by the IESG, based upon the same evidence).

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 9 Sep 2009 14:59:57 +0200

Jari Arkko [mailto:[email-masked]] writes:

> Alan,
> 
> >   It would be good to note at least that the document should be
> largely
> > ignored.  Errata may be a good way to do this.
> >
> 
> I do not believe errata is the right way to do this. 

Why not?  My understanding is that accepted technical errata are generally
saved up & incorporated in a new RFC.  Is that incorrect?  If not, why isn't
that the way to deal with this particular case?

> Furthermore, 4282
> contains more updates than the i18n parts.
> 
> >   There was some discussion last year about working on an update to
> > 4282.  There didn't seem to be much interest, unfortunately.  Maybe
> if
> > we can get the 4-5 pending RADEXT documents out of the way, there may
> be
> > interest in working on updates to 4282.
> >
> 
> That is the best way, IMO. 

Since 4282 wasn't the product of either the radext or radius WGs, what makes
radext the right place to do it?  I'd suggest a new WG, with Alan DeKok as a
Chair.

> We also need to analyze the problem and
> possible solutions in detail. I confess that I have not looked at the
> issues, so I can offer no comment on them yet.
> 
> Jari

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 9 Sep 2009 15:22:56 +0200

Alan T DeKok [mailto:[email-masked]] writes:

>   Please check your inbox.  There were other errata filed at the same
> time, with additional explanatory text.

I didn't respond to those.  How are they relevant?

>   As I said, please check the RADEXT archives for longer discussions
> about this issue.  That discussion includes comments from other people
> explaining what is wrong with 4282.

Alan, you filed an Errata with the RFC Editor.  Do you expect them to search
the radext archives?

> 
>   Maybe one of those people can talk to you without you claiming that
> they have a god complex.  I know I can't.

For DeKok's sake, quit your whining! ;-)

---

From: Jari Arkko <[email-masked]>
Date: Wed, 09 Sep 2009 16:25:40 +0300

Glen,

> that the way to deal with this particular case?

Erratas are for correcting small problems. If you have to rewrite large 
parts, that requires significant effort, review, and a proper new document.

> radext the right place to do it?  I'd suggest a new WG, with Alan DeKok as a
4282 was a product of the RADEXT WG.

In any case, I would suggest we stop talking about process or other non 
essential stuff. If the 4282 i18n text is not correct, is there some 
other text that would work, Alan?

Jari

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 9 Sep 2009 15:51:26 +0200

> 4282 was a product of the RADEXT WG.

You're absolutely right; I was thinking of RFC 2486, which it obsolete.  The
point remains the same, however: changes to 4282 don't just effect RADIUS,
but Diameter, possibly EAP and a number of standards published by other
SDOs.

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 9 Sep 2009 17:01:30 +0300

> but Diameter, possibly EAP and 

+ Mobile IP family of protocols....

> a number of standards published by other
> SDOs.

Indeed.

What is the take on backward compatibility?

Alper

---

From: Jari Arkko <[email-masked]>
Date: Wed, 09 Sep 2009 19:18:44 +0300

Excellent -- I will review this. For the benefit of others, here's a diff:

http://tools.ietf.org/rfcdiff?url1=rfc4282.txt&url2=draft-dekok-radext-nai-00.txt

(and to the original RFC: 
http://tools.ietf.org/rfcdiff?url1=rfc2486.txt&url2=draft-dekok-radext-nai-00.txt)

Jari

---

From: Jari Arkko <[email-masked]>
Date: Wed, 09 Sep 2009 20:01:53 +0300

Thanks again for writing this up.

Some initial comments:

Overall I liked it, but there are of course of number of things to 
discuss...

Section 1.2 boilerplate is not according to RFC 2119.

grammer => grammar

> o Section 2.1 did not contain ABNF for the UTF-8 form of the   
>             realm. This makes it impossible to create an 
> inter-operable   
>             internationalized version of the realm

But the realm was not specified to carry UTF-8. As the RFC said later:

   The realm name is an "IDN-unaware domain name slot" as defined in
   [RFC3490].  That is, it can contain only ASCII characters.  An
   implementation MAY support Internationalized Domain Names (IDNs)
   using the ToASCII operation; see [RFC3490] for more information.

I realize that there may be other reasons -- such as compatibility with 
EAP RFCs that demands plain UTF-8 should be used. However, the argument 
above does not seem correct.

> o Section 2.5 required mappings that are language-specific,   
>             and which are nearly impossible to perform correctly 
> without   
>             information about that language.

I guess this means Section 2.4 of RFC 4282, right?

Also, the mappings required in that section are to be done by the end 
systems where the user types in the strings. Such end systems can be 
aware of what character set and language the user employs. I agree that 
none of the intermediate systems could have any idea about that, but 
AFAICT that was not required by the RFC.

>  normalization form NFC for NAIs is REQUIRED.
Expand NFC

> The grammar for   
>     the username is based on [RFC0821], and the grammar for the realm 
> is        the user and realm portion is based on a combination of the 
> "nai"   
>     an updated version of [RFC1035].        defined in [RFC4282] 
> Section 2.1, and the "utf8-addr-spec" defined in   
>             [RFC5335] Section 4.4.
I was confused by this statement. Do you mean that you normatively refer 
4282 for these definitions or that this is how you arrived at the ABNF? 
I think you should just say "this is the ABNF" and if there's any 
rationale that needs to be said, add it to Section 1.4.

> .fi

Nroff problem...

> in question. Therefore, the username portion SHOULD be treated as

Since you changed the ABNF names, this probably should now be 
utf8-username to be exact what you mean by the username portion.

> In order to ensure a canonical representation

I would like to understand this better. 4282 provided canonicalization 
in order to make sure that when you look up a username db lookups and 
routing table comparisons work. Does the bis have the same property, and 
how so?

>    In contrast to the comments in [RFC4282] Section 2.4, we expect AAA
>    systems to perform NAI comparisons, matching, and AAA routing based
>    on the NAI as it is received.  This requirement provides a canonical
>    representation, ensures that intermediate systems such as AAA proxies
>    do not need to perform translations, and can be expected to work
>    through systems that are unaware of international character sets.

I though that this was the case already with RFC 4282, but maybe I'm 
missing something.

> For example, much of the common realm routing can be done on the   
>             "utf8-realm" portion of NAI, through simple checks for 
> equality.

I thought that suffix match was also a possibility in some systems.

> 2.7. Routing inside of AAA Systems
Good stuff.

> There are, however, a number of problems with this approach. A AAA   
>             proxy may not have sufficient information in order to 
> perform the   
>             ToAscii conversion properly. We therefore RECOMMEND that 
> only the   
>             owner of the realm perform the ToAscii conversion. We 
> RECOMMEND that   
>             the owner of the realm pre-provision to all proxies the 
> "utf8-realm"   
>             portion of the NAI, along with the canonical form returned 
> by the   
>             ToAscii function. This canonical form can then be used in 
> the   
>             logical AAA routing table discussed above, in order to 
> perform DNS   
>             lookups

And here's the tradeoff for using UTF-8 as opposed to IDN unaware name 
slots. I was trying to think about situations where the DNS lookups are 
needed and whether they'd form a problem. Can you name a few of the 
situations where DNS name lookups from NAIs are actually used today?

> 2.10.1. Historical Practices
I'm personally not very fond of the decoration practices, but they do 
exist. I think we need a discussion before those can be removed from the 
RFC.

Jari

---

From: Alan DeKok <[email-masked]>
Date: Thu, 10 Sep 2009 16:15:38 +0200

> Section 1.2 boilerplate is not according to RFC 2119.

  Fixed.

> grammer => grammar

  Fixed.

>> inter-operable               internationalized version of the realm
> 
...
> above does not seem correct.

  The later text discusses this, and could be merged:

o The requirement in Section 2.1 that realms are ASCII conflicts
  with the Extensible Authentication Protocol (EAP) and RADIUS, which
  are both 8-bit clean, and which both recommend the use of UTF-8 for
  identities.

>> without               information about that language.
> 

  Yes.

> AFAICT that was not required by the RFC.

  The suggestion was for proxies to perform normalized comparisons,
which requires the mappings.

  The update suggests (essentially) using "strcmp" for comparisons.

  That could say instead:

o Section 2.4 required mappings that are language-specific,
  and which are nearly impossible for intermediate nodes to perform
  correctly without information about that language.

>>  normalization form NFC for NAIs is REQUIRED.

  Done.

>> The grammar for       the username is based on [RFC0821], and the
>> grammar for the realm is        the user and realm portion is based on
>> a combination of the "nai"       an updated version of
>> [RFC1035].        defined in [RFC4282] Section 2.1, and the
>> "utf8-addr-spec" defined in               [RFC5335] Section 4.4.

  It means how I arrived at the ABNF.

> rationale that needs to be said, add it to Section 1.4.

  Ok.  It looked awkward to add it to 1.4, so I added it to the appendix.

> Nroff problem...

  Fixed.

> utf8-username to be exact what you mean by the username portion.

  Fixed.

> routing table comparisons work. Does the bis have the same property, and

  We can say:

The form suggested in [RFC4282] depended on
intermediate nodes performing canonicalizations based on insufficient
information, which meant that the form was not canonical.  This
document instead suggests (Section 2.10) that the realm owner provide
a canonical form of the realm, and that all intermediate nodes use
that form without modification.

  This means that there is only one canonical form: that supplied by the
realm owner.

> I though that this was the case already with RFC 4282, but maybe I'm

  See the above comment.  The *intent* in 4282 was to provide a
canonical representation.  Unfortunately, it cannot be used to provide that.

> I thought that suffix match was also a possibility in some systems.

  A *partial* suffix match?  (e.g. foo.example.com matches example.com)

  That's possible, but fairly rare.

>> perform the               ToAscii conversion properly. ...

> situations where DNS name lookups from NAIs are actually used today?

  Diameter.  RadSec (RADIUS over SSL over TCP), which is being
standardized right now.

  It's pretty rare, which means we should get it right before we have
wide-spread deployments.

  I'm not aware of any scenario where AAA servers would use arbitrary
strings supplied by the user to do DNS lookups, or why anyone would
think that this is a good idea.

  It would be MUCH better to have a AAA routing protocol, where "home"
servers could propagate realm / punycode data to proxies.

  Alan DeKok.