|
I think we�ve got a problem here :(
Stefan Winter said:
�I'm currently trying to figure out what would happen if a AAA roaming consortium (802.1X based, using EAP and RADIUS) were to use IDNs in its NAIs, i.e. a user name like lieschen at m�de. I was kind of expecting to see UTF-8 encoded User-Name attributes showing up at the RADIUS server, since RFC2865 defines User-Name to be UTF-8. 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?
Stefan Winter also said:
�It struck me that according to this clause, the supplicant in principle has the option of encoding the EAP-Response/Identity to its liking, since this clause only defines displayable messages in EAP-*Request*/Identity to be UTF-8 encoded.� [BA] Yes, I believe that this is an unfortunate oversight; the EAP-Response/Identity should also be UTF-8 encoded.
Glen Zorn said:
�I suppose that we could also propose new RFC boilerplate saying something
like
"IF YOU ARE A MORON DON'T IMPLEMENT THIS SPECIFICATION." but I don't
think
it would do much good. RFC 4282 already allows UTF-8 for NAIs that
cannot
be represented in ASCII. If a supplicant doesn't use it, it's a bug
in
the supplicant implementation, not in the NAI specification, let alone
EAP
or .1X.�
[BA] RFC 4282 actually proposes that the realm portion of
the NAI be encoded in punycode, not UTF-8.
RFC 2865 talks about the User-Name being encoded in UTF-8,
and RFC 3748 also talks
about UTF-8 (albeit for the EAP-Request/Identity).
With RFC 3759 requiring the EAP-Response/Identity
to be placed into the RADIUS User-Name attribute, it is hard
for me to see how the NAI in EAP or
RADIUS could be encoded in anything other than UTF-8.
Since the EAP Identity Request & Response are 8-bit
clean, and RADIUS explicitly enables carriage of
UTF-8 in the User-Name Attribute, there is no reason for a
conversion to punycode to occur for the
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.
Stefan Winter also said:
�I seriously hope that I overlooked something,� [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: �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 m�at example.com. Section 5 states: The <message> quantity is human-readable text in the appropriate charset and language. Note: no reference to UTF-8. It gets better. RFC 3748 Section 5 says: � 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].� Not only is support for non-ASCII characters in passwords optional, but that stringprep is referred to as a �possible� scheme, without normative language. If we created a username and password combination including UTF-8 non-ASCII characters in both, what do you think the odds of interoperating are? Not good, I�d wager.
[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.
| 
