RFC 2486bis issue: "Decorated" NAIs and IDN support

[Bernard Aboba <aboba@internaut.com>]

Patrick, Paul & Ted --

We are having difficulty finishing the RFC 2486bis document, due to
an issue relating to th impact of IDN on Network Access Identifier
"decoration".

The issue is that 3GPP wants to be able to "decorate" NAIs in order
to describe source routes between RADIUS realms.  The format of
decoration is similar to the old format for routing email within
UUCP.  For example,  microsoft.com!bernarda@bt.com would indicate
that authentication is to be proxied to Microsoft via a local
Access Point attaching to the British Telecom network.

The issue arises because many clients enter the entire NAI in
UTF-8, whereas in some AAA protocols (such as Diameter), the
realm name may be used in a DNS query in order to locate the
Diameter server for that realm.

This means that a user could potentially enter an NAI in UTF-8
that might not be convertable to a valid FQDN in the IDN format.

For example, microsoft.com!bernarda@bt.com -> bernarda@microsoft.com
after it is forwarded by the bt.com RADIUS proxy.  In the latter
construction the realm portion (microsoft.com) may need to be
converted from UTF-8 to IDN to enable use of DNS for service
location.

Can you look at the below thread and give us your feedback on how
we should think about this?

Bernard Aboba
Co-Chair, RADEXT WG

"Oh blinding light,
Oh light that blinds,
I cannot see --
Look out for me!"

-- Firesign Theatre


[BA] Am I correct in saying that the recommended approach implies that
RADIUS
proxies don't have to do any character set translations when processing
"decorated" NAIs?  If so, that is a good thing.

[Jari Arkko]
Well, no you are not correct :-( If the realm part is an IDN-unaware
name slot, then transformations from the username part will
have to do conversions.

On the other hand, it seems to me that conversions are
going to be necessary anyway in some circumstance, and
this choice appears to place the conversion burden on a relatively
rare function, and in a place where its known for sure that
you need to do a conversion. So I think we are picking
the lesser of two evils :-)

(If we choose UTF-8 for realm part then one might ask
if the proxies doing routing or policy lookups based on the
realm part would have to normalize realms before comparisons
and lookups; its perfectly reasonable that implementations
or even users send ASCII based versions of international
domain names.)


[BA] If internaut.com contained an international character set (e.g.
UTF-8),
then a conversion should still not be necessary in RADIUS, since DNS
lookups aren't done on the realm portion, right?

[Jari Arkko]
Well, this assumes that DNS lookups are the only reason
for conversion. I suspect that normalization/canonization
is necessary also for other purposes, such as comparisons,
lookup, and matching in proxies and home servers.

[BA] Question: does this have implications for EAP peer implementations
that
just send UTF-8 in the EAP-Response Identity?  I think it doesn't imply
that they should check that the realm part is compatible with the
"IDN-unaware domain name slot" grammar, but I wanted to check.

[Jari Arkko]
Yes. But my understanding is that implementations that
correctly process international names will ALWAYS have
to do something to the user input that they receive, to
normalize and check it in some manner. Section 2.4 of
our draft lists the requirements for the username part
that we have now. It seems that calling routine a or b
does not matter so much for implementations. Of course
there are likely implementations that just pass input bytes
on, but this appears to be something that has be fixed
anyway.

[BA] The implied requirement is that users send domain names in the same
format
that they are included in the RADIUS proxy routing table.  As Alan noted,
this assumption seems to work today.

[Jari Arkko]
Yes. One case where pure reliance on users might still fail is roaming, if
you have one network which has stored the name in UTF-8 and another
one in ASCII...

[Alan DeKok]

  I'm confused.  If it can be represented in 7-bit ASCII, it's UTF-8
compatible.  The only concern, then, is the UTF-8 extensions to ASCII
which may "map" to 8-bit ASCII.  That's the only situation where the
"same" name can have two representations.

  If that happens, then the users won't be able to authenticate, and
the problem will quickly be brought to the attention of the
appropriate admin.

  As a related question, which user-client implementations permit
entry of data in 8-bit ASCII, and which permit UTF-8?  Maybe I can do
<ALT>-<foo> on a Windows box to type in 8-bit characters.  But I'm
sure I can change the locale, and type in glyphs which end up as
UTF-8.

[Jari Arkko] the user wouldn't know what to enter to get his transaction
routed through the network. That's why I believe its still useful
for the RFC to indicate what the correct format is.

[Alan DeKok]
  I don't think the user has a *choice* as to how to enter his name.  The
user-client interface will most likely make that choice for him.

I just don't see this as a problem.

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