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

[Alan DeKok <[e-mail]>]

Jouni Korhonen wrote:
> 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.

  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.