Stefan Winter wrote: > 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 [EMAIL PROTECTED]
On a related note, there was discussion in Dublin about updating RFC 4282 for internationalized NAI's. This may be relevant. > 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). I suspect so. The supplicant is likely just copying the username from some external source into the EAP packet. My $0.02 is that the supplicant _usually_, at some level, has access to the current locale && character encoding. The locale and character encoding cannot be passed as part of an EAP transaction. Therefore, the supplicant should be responsible for transforming the name into a wire-compatible form: UTF-8. The caveat here is that there are likely lots of deployments where the stored User-Name on the server is just a cut&paste from the logs. If the supplicant doesn't send UTF-8, then the User-name on the server may reflect the supplicant's choice of locale && encoding. Changing the supplicant to use UTF-8 may break authentication. > 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. Yes, unfortunately. > What troubles me even more is that RADIUS (or Diameter, for that matter) > requires UTF-8 encoding in the User-Name attribute, and that 802.1X > authenticators are required to literally copy EAP-Identity into the > User-Name attribute, even if it is not necessarily UTF-8. That would > mark an incompatibility within IEEE 802.1X. It would appear so. > I seriously hope that I overlooked something, or that I have a language > problem and this UTF-8 half-sentence should span over more than the > displayable message in the Request, and would be happy if someone could > clear this up. If the issue stands, it is a bit uneasy... making the > encoding in the response undefined means that the auth traffic can look > different depending on OS, locale, Yes. This is the current situation. > ... . In any case, out of two > supplicants I tried, both did indeed *not* use UTF-8, so I wouldn't be > the only one confused. This makes adding IDN NAIs somewhat difficult. RFC 3748 Section 5.1 allows additional data to be transmitted after the NUL in an Identity Request. This could perhaps be leveraged to send a string such as "UTF-8", which could indicate to the supplicant that the server is requesting UTF-8 encoding. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
