Subject: [radext] #19: i18n Issues with RFC 4282

From: "radext issue tracker" <[email-masked]>
Date: Fri, 14 May 2010 02:07:11 -0000

#19: i18n Issues with RFC 4282
---------------------------------------+------------------------------------
 Reporter:  aland@…                    |       Owner:  aland@…                  
     Type:  defect                     |      Status:  new                      
 Priority:  blocker                    |   Milestone:  milestone1               
Component:  RFC4282bis                 |     Version:  1.0                      
 Severity:  Candidate WG Document      |    Keywords:                           
---------------------------------------+------------------------------------
 Date first submitted:  October 31, 2008
 Reference:  http://ops.ietf.org/lists/radiusext/2008/msg00704.html
 Section:   2.1, 2.4

   In summary: RFC 4282 has some problematic text surrounding i18n.  Some
 of the suggestions are unworkable, some are incorrect.  No AAA vendor
 has implemented the problematic suggestions, which is good.

   There is a push to issue an update to RFC 4282 that would address
 these issues.  The updated document would match current practice, and
 would remove the problematic suggestions in 4282.  Based on the
 discussions so far in RADEXT, it looks like AAA implementations will not
 need to change in order to be compliant with the updated draft.

   Some software will have to change, but this may be limited to EAP
 supplicants that put "local" characters into the EAP-Response/Identity
 field, rather than using UTF-8.

 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.

 [BA]

 I've gotten some additional test data on the behavior of Windows EAP
 supplicants with respect to NAI internationalization.
 If the Windows version is XP-SP2 or below the NAI is sent in ANSI.  This
 is what Stefan was observing.
 If the Windows version is XP-SP3 or Vista SP1, the NAI is encoded in UTF-8
 for the WLAN EAP supplicant, but remains ANSI for the PPP EAP supplicant
 (includes dialup as well as VPN (PPTP/L2TP/SSTP)).  This is because the
 WLAN EAP supplicant is a newer code base (EAPHOST), and the PPP EAP
 supplicant utilizes an older code base (Windows 2000 EAP supplicant).
 Going forward, the NAI will be sent in UTF-8 for all EAP supplicants,
 since all supplicants will be based on EAPHOST.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/19>
radext <http://tools.ietf.org/radext/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>