RE: Bang-path routing

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

Alan DeKok said:

"  I've looked at 4282, and I think that the issues are larger than that."

Yes, there are a large number of issues in RFC 4282, particularly Section
2.4:

Here are just a few: 

2.4.  International Character Sets

   This specification allows both international usernames and realms.
   International usernames are based on the use of Unicode characters,
   encoded as UTF-8 and processed with a certain algorithm to ensure a
   canonical representation.  Internationalization of the realm portion
   of the NAI is based on "Internationalizing Domain Names in
   Applications (IDNA)" [RFC3490].

   In order to ensure a canonical representation, characters of the
   username portion in an NAI MUST fulfill the ABNF in this
   specification as well as the requirements specified in [RFC4013].
   These requirements consist of the following:

   o  Mapping requirements, as specified in Section 2.1 of [RFC4013].
      Mapping consists of mapping certain characters to others (such as
      SPACE) in order to increase the likelihood of correctly performed
      comparisons.

[BA] Unfortunately, as pointed out in RFC 4690, these mappings can be
language specific, and so are not easily defined.  In fact, they may
vary by registry.  So it would seem to make more sense to specify that
realms need to conform to IDNAbis and registry requirements and leave
it at that.  

   o  Normalization requirements, as specified in Section 2.2 of
      [RFC4013], are also designed to assist in comparisons.

[BA] This assumes that the NAI is being entered by a user, rather than
being automatically configured, which is often the case.  Why should
normalization be required for an automatically configured NAI? 

   o  Prohibited output.  Certain characters are not permitted in
      correctly formed strings that follow Section 2.3 of [RFC4013].
      Ensuring that NAIs conform to their ABNF is not sufficient; it is
      also necessary to ensure that they do not contain prohibited
      output.

[BA] It seems that the set of prohibited characters should be the same
within IDNAbis as within a realm that is also an FQDN.  However, this
statement ensures that they will be different since RFC 4013 and IDNAbis
are not in sync. Why not just cite IDNAbis?

   o  Bidirectional characters are handled as specified in Section 2.4
      of [RFC4013].

[BA] Given that the bidi rules are being revised in IDNAbis, this would
also appear to be out of date.  Better to cite the IDNAbis bidi document.

   o  Unassigned code points are specified in Section 2.5 of [RFC4013].
      The use of unassigned code points is prohibited.

[BA] Doesn't this effectively prohibit support for new scripts?  The
IDNAbis approach seems more sensible.  

   The mapping, normalization, and bidirectional character processing
   MUST be performed by end systems that take international text as
   input.  In a network access setting, such systems are typically the
   client and the Authentication, Authorization, and Accounting (AAA)
   server.  NAIs are sent over the wire in their canonical form, and
   tasks such as normalization do not typically need to be performed by
   nodes that just pass NAIs around or receive them from the network.
   End systems MUST also perform checking for prohibited output and
   unassigned code points.  Other systems MAY perform such checks, when
   they know that a particular data item is an NAI.

[BA] IDNAbis does not require end systems to do this kind of
checking, because presumably these checks are done when the user name
and realm is created in the first place.  If the user name/realm was
never created on the AAA server, then presumably the name also can't
be used on the client, so periodic compliance checks are unnecessary. 

Can't we just say that the realm is required to be registerable as an 
FQDN, and that registry and IDNAbis restrictions must be obeyed? This
would leave sufficient flexibility for registry-specific restrictions. 

   The realm name is an "IDN-unaware domain name slot" as defined in
   [RFC3490].  That is, it can contain only ASCII characters.  An
   implementation MAY support Internationalized Domain Names (IDNs)
   using the ToASCII operation; see [RFC3490] for more information.

[BA] Given that EAP and RADIUS specifications specifically mandate 
UTF-8 usage, this appears wrong.  

   The responsibility for the conversion of internationalized domain
   names to ASCII is left for the end systems, such as network access
   clients and AAA servers.  Similarly, we expect domain name
   comparisons, matching, resolution, and AAA routing to be performed on
   the ASCII versions of the internationalized domain names.  This
   provides a canonical representation, ensures that intermediate
   systems such as AAA proxies do not need to perform translations, and
   can be expected to work through systems that are unaware of
   international character sets.

[BA] A more sensible approach would be to require conversion of UTF-8
to punycode as specified in IDNAbis.  





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