RE: Issue 75: Why Not UTF-8 For Realm, Too?

[<Pasi.Eronen@nokia.com>]

This basically proposes changing the realm part from
"IDN-unaware domain name slot" to "IDN-aware domain name slot"
(in RFC 3490 terminology). This might cause problems, since
existing systems don't know that they need to use the ToAscii
operation before e.g. using the realm for DNS lookups.
(But I'm not sure how important those problems would be in
practice...)

However, it seems that the problem described below does not
occur if the client implements 2486bis and RFC 3490 (and
understands the "!" notation). 

In this case, all the places where realms can occur are "IDN-
unware domain name slots", and thus according to RFC 3490, the 
client must use ToAscii for them. Thus, when a NAI looking like 
"<part1>!<part2>@<part3>" reaches a RADIUS proxy, neither part1 
or part3 contain any non-ASCII characters (since they were run 
through ToAscii), and the proxy doesn't have to do any conversions 
when "undecorating" this to "<part2>@<part1>".

Of course, it's probably realistic to assume that many clients
will take shortcuts in implementing support for non-ASCII
characters (such as simply taking whatever the user typed in,
UTF-8 encoding it, and stuffing that to EAP identity response or
something) instead of implementing 2486bis and RFC 3490 to the
letter. Obviously, there's no way to guarantee that these
kind of clients fully comply with everything.

Also, if the client does not understand the "!" notation, then
there's no way to guarantee that part1 will conform to RFC 3490 
(which is not only about UTF-8 vs. Punycode encoding, but other 
things as well).

It thus seems that doing things 100% right in the client is very 
difficult, and IMHO anything we can do won't substantially change
that. We can only give pointers to specs which describe the
right way, and if the implementations ignore that, well, that's
life (but I don't think that, e.g., ignoring some minor details 
of RFC3490 would cause major interoperability problems... so
perhaps this is not a very serious issue).

Best regards,
Pasi

> -----Original Message-----
> From: Bernard Aboba
> Sent: Monday, March 07, 2005 9:17 AM
> To: radiusext@ops.ietf.org
> Subject: Issue 75: Why Not UTF-8 For Realm, Too?
> 
> 
> Issue 75: Why Not UTF-8 For Realm, Too?
> Submitter name: Avi Lior
> Submitter email address: avi@bridgewatersystems.com
> Date first submitted: March 6, 2005
> Reference:
> Document: RFC2486bis
> Comment type: T
> Priority: S
> Section:  Various
> Rationale/Explanation of issue:
> 
> When a RADIUS proxy undecorates the NAI, the current document
> may require translation when a realm name moves between the
> userid portion and the realm portion. For example, when
> intl_name.com!avi@idn_realm.com is redecorated to
> avi@intl_name.com.  In the fomer construction, intl_name.com
> is in UTF-8, and in the later, intl_name.com needs to be
> translated to IDNA.
> 
> Why not just specify the entire NAI in UTF-8? Then, say that
> if a proxy needs to utilize the realm name within DNS, it will
> convert it to an IDN.  Doesn't that make more sense? Existing
> link layers (e.g. EAP Request/Response-Identity messages) can
> carry UTF-8 just fine.


--
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/>