Re: [radext] Call for WG Adoption for draft-dekok-radext-nai-02; The Network Access Identifier

[Bernard Aboba <[e-mail]>]

> @Alan: resubmit the current document as a draft-ietf-* as soon as
> possible.
> 
> We will continue pursuing the one document approach (based on the
> current charter). Of course WG is now free to decide anything on
> the content as long as there is consensus and it fits to the 
> charter.

[BA]  When re-submitting the document as draft-ietf-*, please utilize the pre-5378 boilerplate, since the document contains text from RFC 4282 and RFC 2486.

Also, some notes:

Section 1.4
   The motivation to revise [RFC4282] began with internationalization
   concerns raised in the context of [EDUROAM].  Section 2.1 of
   [RFC4282] defines ABNF for realms which limits the realm grammar to
   English letters, digits, and the hyphen "-" character.  The intent
   appears to have been to encode, compare, and transport realms with
   the ToASCII operation defined in [RFC5890].  There are a number of
   problems with this approach:
[BA] One big problem with the RFC 4282 ABNF, is that it is not aligned 
with internationalization of the DNS.  You might note this in the first
bullet since it is referred to elsewhere. 

Section 2.1

   See [RFC5198] for a discussion of normalization; implementations of
   this specification MUST use the Normal Form Composed (NFC) for NAIs.

[BA] I would recommend carrying over the text from RFC 5335:

   See [RFC5198] for a discussion of normalization; the use of
   normalization form NFC is RECOMMENDED.

Section 2.3 

   Devices handling NAIs MUST support an NAI length of at least 72
   octets.  Devices SHOULD support an NAI length of 253 octets.
   However, the following implementation issues should be considered:

[BA] It should be pointed out that when using UTF-8 that the NAI
octet length constraint may result in a more severe constraint on the
number of UTF-8 characters.

Section 2.4

   Omitting the username part is RECOMMENDED over using a fixed username
   part, such as "anonymous", since it provides an unambiguous way to
   determine whether the username is intended to uniquely identify a
   single user.  

[BA] I might consider changing (or deleting) this sentence, since in
practice, I believe that use of a fixed username part is more popular
than omitting the username part.  

Section 2.5

   o  Realms MUST be of the form that can be registered as a
      Fully Qualified Domain Name (FQDN) within the DNS name system.

[BA] Delete "name system". 

Section 2.6 

   All normalization MUST be performed by end systems that take "local"
   text as input.  That is, text that is in an encoding other than
   UTF-8, or that has locale-specific variations.  In a network access
   setting, such systems are typically the client (e.g. EAP supplicant)
   and the Authentication, Authorization, and Accounting (AAA) server.

[BA] As used in this section, "normalization" appears to go beyond the 
conversion of Unicode characters to canonical form.  I might rewrite
this to say "Conversion to Unicode as well as normalization 
is expected to be performed by end systems that take "local" text
as input." 

   All other AAA systems (proxies, etc.)  MUST NOT perform
   normalization.  These other systems do not have access to locale and
   character set information that is available to end systems.

[BA] Suggest rewriting to say "Since AAA proxies do not have access to 
locale and character set information that is available to end systems, 
they are typically incapable of converting local input to Unicode." 

   EAP supplicants MUST normalize user names that get placed in the EAP-
   Response/Identity field.  They MUST NOT copy localized text into that
   field.  This normalization SHOULD be performed once, and then cached
   for subsequent use.

[BA] Since RFC 4282 was published, RADIUS has been extended to cover application protocols such as in
RFC 5090 (SIP and HTTP) and ABFAB.  As a result, the advice needs to be generalized. 

Suggest rewriting to "Copying of localized text into fields that can subsequently be placed into
the RADIUS User-Name attribute is problematic since this can result in a AAA proxy encountering non-UTF8
characters within what it expects to be an NAI, resulting in potential difficulties in realm routing.  
As an example, RFC 3579 Section 2.1 states:

   the NAS MUST copy the contents of the Type-Data field of the EAP-Response/Identity received
   from the peer into the User-Name attribute

As a result, AAA proxies expect the contents of the EAP-Response/Identity sent by an EAP supplicant to consist
of UTF-8 characters, not localized text."

Section 2.9

   The "realm" portion of the NAI is intended to be compatible with
   domain names used in DNS systems.  However, the "realm" portion
   within AAA systems is intended to be a UTF-8 string, not an ASCII
   string as with the DNS protocol.  Therefore, AAA systems transporting
   NAIs in an AAA protocol MUST NOT encode the "utf8-realm" portion
   using the ToAscii function.  That function creates strings that may
   be transported over DNS, and it is not appropriate for use within an
   AAA protocol.

[BA] Since the DNS protocol is 8-bit clean, I suggest the above text be modified as follows:

 
   'The "realm" portion of the NAI is intended to be compatible with
   Internationalized Domain Names [RFC5890]. Since the "realm" portion
   as transported within the RADIUS User-Name attribute is composed of 
   U-labels, not A-labels, there is no reason for a NAS to apply the
   ToAscii function to the "realm" portion of an NAI prior to placing
   the NAI into a RADIUS User-Name attribute.'





   When the realm portion of the NAI is used as the basis for name
   lookups within the DNS system, the ToASCII operation defined in
   [RFC5890] MAY be used to convert internationalized realm names to
   ASCII.  This function is normally handled by a DNS resolver library
   on the local system.  When this function is not handled by a DNS
   resolver library, the AAA system MAY perform the ToAscii conversion
   itself, before passing the modified realm name to the DNS resolver
   library.

[BA] As noted in RFC 6055, resolver APIs are not DNS-specific. 
So I would use the term "resolver API" rather than DNS resolver
library. Recommend the following text:


   When the realm portion of the NAI is used as the basis for name
   resolution, it may be necessary to convert internationalized
   realm names to ASCII using the ToASCII operation defined in
   [RFC5890].  As noted in [RFC6055] Section 2, resolver APIs are not necessarily
   DNS-specific, so that the ToASCII operation needs to be applied
   carefully:

     Applications that convert an IDN to A-label form before calling
     getaddrinfo() will result in name resolution failures if the Punycode
     name is directly used in such protocols.  Having libraries or
     protocols to convert from A-labels to the encoding scheme defined by
     the protocol (e.g., UTF-8) would require changes to APIs and/or
     servers, which IDNA was intended to avoid.

     As a result, applications that assume that non-ASCII names are
     resolved using the public DNS and blindly convert them to A-labels
     without knowledge of what protocol will be selected by the name
     resolution library, have problems.  

Section 2.10.1

   o  Re-writing of the User-Name in AAA servers means that it may not
      match the EAP-Response/Identity fields.  This mismatch may cause
       the home AAA server to reject the request as being malformed.

[BA[ AAA servers should not be comparing the RADIUS User-Name attribute
to the EAP-Response/Identity field, so I would suggest that this bullet
be deleted.