RE: [Emu] EAP, RADIUS, UTF-8, RFC 4282 and SASLPREP: the interop nightmare

["Bernard Aboba" <Bernard_Aboba@hotmail.com>]

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.


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>