Subject: [radext] WGLC #1 for draft-ietf-radext-nai-03

From: Jouni Korhonen <[email-masked]>
Date: Tue, 4 Jun 2013 07:42:45 +0300

Folks,

This email starts a two week WGLC for draft-ietf-radext-nai-03. The WGLC end
18th June 2013 EOB (EEST). We require minimum three reasonable reviews. Post
your comments and concerns to the mailing list and also enter your issues you
want to be _addressed/resolved_ into the issue tracker.

- Jouni & Mauricio

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 19 Jun 2013 09:21:51 +0300

Folks,

The WGLC#1 has ended. There are now five open tickets in the issue tracker
(#162, #145, #146, #164 and #167). I encourage the I-D author(s) and the WG
to sort out the remaining tickets as soon as possible.

- Jouni & Mauricio

---

From: Alan DeKok <[email-masked]>
Date: Wed, 19 Jun 2013 10:02:41 -0400

> to sort out the remaining tickets as soon as possible.

  I should have an updated draft on Friday.

  Who does normalization is a big issue.  I think it should be done at
the edge, for a number of reasons.  For one, it follows the general
Internet philosophy of having smart edges and a dumb core.

  For another, it's really the only workable approach.  Let's look at an
example.

  Proxy P has been deployed, and is running quite happily for years.

  End user device E wants to get network access.  The user just bought
it, and it's fully of shiny new unicode goodness.  Including code points
which are unknown to proxy P.

  The end point account "belongs" to home server H.  It may, or may not,
have the same unicode information as the endpoint E.  It may, or may
not, have the same unicode information as proxy P.

  It has been suggested that the proxy P do normalization.  Partly
because end points don't do it now, and because there are fewer proxies
than end points.

  However, according to the scenario above (which WILL happen), proxy P
has insufficient information to normalize the realm used by E.  So the
*only* thing that P can do is to treat it as an opaque string.

  However, home server H has supplied P with a "canonical" version of
the realm, as canonicalized by H.  This realm is sadly not the same byte
string as supplied by E.

  Therefore, E can't authenticate.  H has to either supply P with *all*
possible versions of it's realm, or has to give up, and not use i18n at all.

  All this comes about because E is pretty much guaranteed to be newer
than P or H.  It is therefore the *only* entity in the network who is
capable of normalizing the realm.  No one else has the correct information.

  See this page for a recent example of how normalization issues can
cause security holes:
http://labs.spotify.com/2013/06/18/creative-usernames/

  My $0.02 is the following:

- proxies should try to normalize realms, knowing that many endpoints
won't do that.  If the realm can't be normalized, treat it as an opaque
byte string.

- end points MUST normalize realms.  Yes, they don't do this now.  Too
bad.  We've been riding the ASCII wave for 50 years, and it's about to
crash hard on the shoals of i18n.

  I'd like counter-examples showing that end points shouldn't do
normalization.

  Alan DeKok.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 19 Jun 2013 07:28:38 -0700

> *only* thing that P can do is to treat it as an opaque string.
[BA] Assuming that the realm is encoded in UTF-8 (which I believe the draft can require), I don't see why proxy P would have insufficient information.  The "opaque string" comparison doesn't even work for realms which contain no international characters.  For example, "exAMPLE.com" and "example.com" would not be recognized as equivalent.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 19 Jun 2013 11:35:33 -0400

Bernard Aboba wrote:
> [BA] Assuming that the realm is encoded in UTF-8 (which I believe the
> draft can require), I don't see why proxy P would have insufficient
> information.

  From the Unicode docs:

http://unicode.org/reports/tr15/#Versioning

...To see what difference the composition version makes, suppose that a
future version of Unicode were to add the composite Q-caron. For an
implementation that uses that future version of Unicode, strings in
Normalization Form C or KC would continue to contain the sequence Q +
caron, and not the new character Q-caron, because a canonical
composition for Q-caron was not defined in the composition version. See
Section 5, Composition Exclusion Table, for more information.
...

  And later:

...
If an implementation normalizes a string that contains characters that
are not assigned in the version of Unicode that it supports, that string
might not be in normalized form according to a future version of
Unicode. For example, suppose that a Unicode 5.0 program normalizes a
string that contains new Unicode 5.1 characters. That string might not
be normalized according to Unicode 5.1.
...

  i.e. End points and proxies will necessarily have different versions
of Unicode.  Endpoints (by definition) know about the Unicode version
that they have installed.  Therefore, they can normalize the realm.

  Proxies will very often have older versions of unicode than endpoints.
 Therefore, by the Unicode docs above, they will be unable to create a
NFC form when the endpoint sends them non-normalized strings.

  Therefore, proxies will receive multiple representations of the "same"
name, and will be unable to determine that they are the same.  The only
action that proxies can take is two treat two different strings as being
different.  Even though updated unicode specs say that they are
normalized to the "same" string.

>  The "opaque string" comparison doesn't even work for
> realms which contain no international characters.  For example,
> "exAMPLE.com" and "example.com" would not be recognized as equivalent. 

  Well, yes.  I ignored ASCII-only names in my example.  I was trying to
focus on i18n names.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 19 Jun 2013 20:53:23 -0400

Bernard and I had a long talk today about the NAI document.  There are
some clear points, but there is still one point which is unclear.

  It's not clear if the process of normalizing a realm name is
independent of Unicode version.  If it is, then proxies can happily
normalize what they get, and we don't care what endpoints produce.

  If it's dependent on Unicode version, then the only system capable of
normalizing the NAI is the endpoint which produces it.  And they don't
normalize NAIs now.

  We're trying to track down a definitive answer.

  Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 20 Jun 2013 05:53:36 -0400

>>>>> "Alan" == Alan DeKok <[email-masked]> writes:

    Alan>   Bernard and I had a long talk today about the NAI document.
    Alan> There are some clear points, but there is still one point
    Alan> which is unclear.

    Alan>   It's not clear if the process of normalizing a realm name is
    Alan> independent of Unicode version.  If it is, then proxies can
    Alan> happily normalize what they get, and we don't care what
    Alan> endpoints produce.

    Alan>   If it's dependent on Unicode version, then the only system
    Alan> capable of normalizing the NAI is the endpoint which produces
    Alan> it.  And they don't normalize NAIs now.

I think this thinking is bogus.
We're trying to create interoperability.
If we improve the fraction of the time things work, we've made forward
progress even if there are corner cases where it doesn't work.

Endpoints MUST (BUT WE KNOW yOU WON't) normalize because there are some
cases where it's unicode version dependent and a proxy with an older
version has no hope of succeeding.

However, in practice, proxies can do a lot, and so they should.
First, the proxy may not have things stored in Unicode.
Or it may have its routing tables stored in a database that has its own
approach to I18N (say LDAP or some SQL database).
In practice, people will sometimes let that database do the
normalization, and if it increases the chance that you'll route to the
realm then you should encourage that.

It seems bogus to me to assume you need a perfect solution, to assume
normalization can happen in one place or to ignore the long picture as
we migrate things 10-15 years from now.

--Sam

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 20 Jun 2013 10:56:38 -0700

> However, in practice, proxies can do a lot, and so they should.
[BA] That summarizes my perspective.  The challenge is to come up with implementable guidelines for what proxies should do, and demonstrate that they work with running code.  For example, assuming that existing EAP implementations will change to support normalization seems silly to me. 
> we migrate things 10-15 years from now.

[BA] Personally, I would be satisfied with a proxy-based solution that will work with commonly encountered cases.  For example, I wouldn't necessarily declare a potential solution as a "failure" if it couldn't support Sanskrit, assuming that it could work with popular character sets.