Re: [Emu] EAP, RADIUS, UTF-8, RFC 4282 and SASLPREP: the interop nightmare
Bernard Aboba wrote: [BA] RFC 4282 actually proposes that the realm portion of the NAI be encoded in punycode, not UTF-8. That's just wrong. No AAA client or server does that. At the last IETF, I had proposed in a hallway conversation, to update portions RFC 4282 to describe what implementors actually do. It looks like it's time for that document to get written. ...it is hard for me tosee how the NAI in EAP or RADIUS could be encoded in anything other than UTF-8. I agree. RFC 5335 Section 4.4 defines a utf8-addr-spec, which is: utf8-local-part @ utf8-domain That's probably a good start for this document. realm portion of the NAI.It **is** reasonable to say that if and when the realm is included in a DNS query that it should be converted to punycode (e.g. an A-label) beforehand. Yes. [BA] The more I’ve looked into this, the more likely it seems that this problem is real and potentially wide in scope, affecting not only EAP, RADIUS, Diameter but also EAP methods. For example, RFC 2759 (MS-CHAPv2) Section 4 states: Potentially anywhere a user identifier is used. User-Name, CUI, and other protocols such as Kerberos. [BA] So what do we do about this? ... a. A document on NAI internationalization, updating RFC 4282. This would address the (IMHO incorrect) punycode encoding of the realm portion. I'll start on that. 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'll stay away from that. :( Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] EAP, RADIUS, UTF-8, RFC 4282 and SASLPREP: the interop nightmare
Alan DeKok said: [BA] RFC 4282 actually proposes that the realm portion of the NAI be encoded in punycode, not UTF-8. That's just wrong. [BA] I agree. I don't know of any EAP peers that encode the NAI this way (although, based on Stefan's tests, they may not use UTF-8 either). ...it is hard for me tosee how the NAI in EAP or RADIUS could be encoded in anything other than UTF-8. I agree. RFC 5335 Section 4.4 defines a utf8-addr-spec, which is: utf8-local-part @ utf8-domain That's probably a good start for this document. [BA] Interesting. NAIs and e-mail addresses are similar; one of the reasons that we got in trouble with RFC 4282 was perhaps that we didn't wait until the EAI discussion was further along. At this point, in 8-bit clean situations, my understanding is that EAI utilizes UTF-8 for both the username and realm portion. Since both EAP Identity and RADIUS User-Name are 8-bit clean, the same logic (and probably, much of the ABNF) would seem to apply here. Stefan Winter said: 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. [BA] What version of Windows was this? XP? Vista? Stefan Winter said: 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] I'm trying to understand why the ASCII limitation exists in the first place. Presumably there are security protocols out there that utilize UTF-8 encoded usernames or NAIs (perhaps after some normalization procedure), right? Potentially anywhere a user identifier is used. User-Name, CUI, and other protocols such as Kerberos. RFC 4372 (CUI) Section 2.2 doesn't say anything at all about internationalization: String: The string identifies the CUI of the end-user. This string value is a reference to a particular user. The format and content of the string value are determined by the Home RADIUS server. The binding lifetime of the reference to the user is determined based on business agreements. For example, the lifetime can be set to one billing period. RADIUS entities other than the Home RADIUS server MUST treat the CUI content as an opaque token, and SHOULD NOT perform operations on its content other than a binary equality comparison test, between two instances of CUI. In cases where the attribute is used to indicate the NAS support for the CUI, the string value contains a nul character. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] EAP, RADIUS, UTF-8, RFC 4282 and SASLPREP: the interop nightmare
Bernard Aboba wrote: [BA] I agree. I don't know of any EAP peers that encode the NAI this way (although, based on Stefan's tests, they may not use UTF-8 either). I think the correct term is memcpy. [BA] Interesting. NAIs and e-mail addresses are similar; ... Often the same. Leveraging EAI would be beneficial. Since both EAP Identity and RADIUS User-Name are 8-bit clean, the same logic (and probably, much of the ABNF) would seem to apply here. I would like very much to know if anyone thinks that they *cannot* be applied here. [BA] I'm trying to understand why the ASCII limitation exists in the first place. Presumably there are security protocols out there that utilize UTF-8 encoded usernames or NAIs (perhaps after some normalization procedure), right? Or, it was easier to say ASCII, and to avoid any unknowns that might occur of 8-bit data is used. Given Stefan's test of MS-CHAP ISO-8895-15 encodings, I think the ASCII limitation in the spec is not matched by any similar limitations in the code. Potentially anywhere a user identifier is used. User-Name, CUI, and other protocols such as Kerberos. RFC 4372 (CUI) Section 2.2 doesn't say anything at all about internationalization: The CUI is often created as [EMAIL PROTECTED]. i.e. based off of the User-Name. So it's worth double-checking the effects of changing User-Name on all down-stream uses. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
