Subject: [precis] FYI on i18n in the real world.

From: Alan DeKok <[email-masked]>
Date: Fri, 24 Aug 2012 22:11:06 +0200

One nice effect of i18n issues is the ability to play different
protocols off against each other.  In my area (RADIUS), there are
multiple layers of protocols.  Each layer has the ability to choose
different encodings for the "same" data.

  For 802.1X, this means there's a RADIUS "name", another copy of the
name in EAP, and another copy of the name in MS-CHAP.  For security,
we've required that they're all the same.  The alternative is to allow
conflicting claims for identity.

  Well, that bit me today.  I got the following message from a customer.

---
  The supplicant makes a request the way User-Name and MSCHAP name are
encoded differently. For User-Name it uses UTF-8, while MSCHAP name is
sent in internationalized encoding (e.g. CP-1251 for Russian).  The
strings are clearly different, so the names are rejected as being different.
---

  RFC 2865 (RADIUS) says that the User-Name is UTF-8.  RFC 3748 (EAP)
says that the identity should be UTF-8.  RFC 2433 (MS-CHAP) is silent on
the encoding of the name field.  The given example is (of course) ASCII.
 RFC 2759 (MSCHAPv2) says explicitly that the name is ASCII.

  I find it worrying that different encodings are used by the same
software.  This kind of thing makes it nearly impossible for the other
side of the protocol to do *anything* sane with the data.

  The kicker (of course) is that the MS-CHAP name is sent as CP-1251.
Different countries will use different encodings, all of which are
incompatible.  And there's no provision in MS-CHAP for telling the other
end which encoding is being used.

  Does anyone have a good suggestion for what to do here?

  Alan DeKok.