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üller.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/Identityshould 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 problemis 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-sensitiveASCII characters which identifies the
peer's user account name.” Yup. ASCII, *not* UTF-8! This actually can cause
an authentication failurefor a user with an NAI of [EMAIL PROTECTED] 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
normativelanguage. If we created a username and password combination
including UTF-8 non-ASCIIcharacters 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.
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
