Hi Bernard, thanks for providing more insight. What a mess.
> I got an encoding of ü ::= 0xfc, which hinted that the supplicant was > not using UTF-8 but some locale (I expect it to be either ISO-8859-15 or > Windows-1252, not that this matters).” > > > [BA] Can you provide more details on the EAP implementation/operating > system on which the test was conducted? > I tried: Intel supplicant --------------------- * User-Name in GUI: @müller.de * encoded on wire: ü ::= 0xFC (ISO-8859-15/Windows-1252 of ü) * User-Name in GUI: tried cyrillic letters - couldn't even enter them in the dialog box in spite of Uzbek (Cyrillic) IME Windows built-in supplicant --------------------------------------- * User-Name in GUI: @müller.de * encoded on wire: ü ::= 0xFC (ISO-8859-15/Windows-1252 of ü) * User-Name in GUI: some cyrillic letters * encoded on wire: all transcribed to the same symbol "?" in ISO-8859-15 or similar encoding (which is not very helpful!) To get to the cyrillic letters, I installed multi-language support and complex IMEs, i.e. everything I could find in System Settings, thinking that it may help the system to move to UTF-8 encodings. The transscript to "?" now makes at least a little bit of sense to me, after your statement: > EAP methods. For example, RFC 2759 (MS-CHAPv2) Section 4 states: > > “The Name field is a string of 0 to (theoretically) 256 case-sensitive > ASCII characters which identifies the peer's user account name.” > > Yup. ASCII, **not** UTF-8! This actually can cause an authentication failure > for a user with an NAI of [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>. So... if for MS-CHAPv2, the behaviour for non-ASCII is unspecified, then it's alright for it to transscribe unexpected input to whatever character it likes. So not the supplicant is to blame, but rather the fact of life that MS-CHAPv2 lives in an ASCII world. Hmmm... is an update to 2759 in any way feasible? Considering its deployed base that appears difficult at best. > [BA] So what do we do about this? > > > > Some of the following may be needed to fix the problem: > > > > a. A document on NAI internationalization, updating RFC 4282. > This would address the (IMHO incorrect) punycode encoding of the > realm portion. > > b. A document on EAP internationalization, updating RFC 3748. > This would cover the EAP-Response/Identity as well as potentially > giving advice on issues such as password internationalization and > internationalization of the EAP Peer-Id and Server-Ids. > I didn't notice so far that 4282 allows both UTF-8 characters AND demands punycode conversion on the realm part. That adds another bit to the confusion indeed. I also think the punycode translation is wrong at this place. It should rather be done by an application if it needs to look up the realm in DNS by the time it is looked up in DNS, not before that on the wire. Especially since 4282 does allow UTF-8 encoding to be transported literally. NAIs can also be used outside of EAP (right?), so the issue of fixing punycode in NAI is independent of fixing the character encoding in EAP. Fixing EAP character encoding for proper internationalisation is also needed IMHO, for all the reasons outlined in the thread before. So, in short, both a) and b) seem necessary to me. UTF-8 endcoded "Grüße", Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
