|
It has occurred to me that the most fundamental mistake of RFC 4282 is the assertion that there is a single NAI encoding for every protocol. In reality, the protocol in which the NAI is encoded makes the decision about the encoding. Where the protocol is 8-bit clean and requires UTF-8 (both EAP and RADIUS fall in this category), the encoding described in RFC 4282 does not apply. EAP and RADIUS implementations can and do carry UTF-8 natively. The only time a conversion from a U label to an A label would be required would be for a DNS lookup such as what is envisaged in the Dynamic Discovery document. That said, issues of internationalization could come up within specific EAP methods. However, not all methods utilize the same internationalization mechanisms. For example, none of the authentication methods defined in RFC 3748 specify the use of SASLPREP, and as far as I am aware, no implementations of those methods (e.g. EAP-MD5) use it. There is substantial variety in EAP methods defined elsewhere (compare say, EAP-EKE with EAP-TLS and EAP-MS-CHAP, for example). Given this, the following sentence in RFC 3748 Section 5 (quoted by PRECIS) is not just inappropriate (the choice should be left to the method spec), but actually misleading because the methods defined in RFC 3748 do not in fact use SASLPREP. EAP methods MAY support authentication based on shared secrets. If the shared secret is a passphrase entered by the user, implementations MAY support entering passphrases with non-ASCII characters. In this case, the input should be processed using an appropriate stringprep [RFC3454] profile, and encoded in octets using UTF-8 encoding [RFC2279]. A preliminary version of a possible stringprep profile is described in [SASLPREP]. Alan DeKok said: As discussed at the last IETF, RFC 4282 has some problems. My draft (expired) describes the issues, and proposes a way to address them. The Precis working group is looking at i18n issues across a wide variety of protocols. The framework document applies to RADIUS and to EAP, though neither is explicitly mentioned: http://tools.ietf.org/id/draft-blanchet-precis-framework-02.txt I'd recommend reading Section 3, which defines stringprep "classes" for names and secrets. Section 10 deals with "confusable" strings, and says that applications need to find a way to deal with them. It looks like the work in Precis will allow RADIUS and EAP to continue with their current way of dealing with names and passwords. Since neither RADIUS nor EAP show strings to users, "confusable" strings can be avoided in the protocol transport. Alan DeKok. |