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. _______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
