[radext] #143: Review of draft-dekok-radext-nai-02

["radext issue tracker" <[e-mail]>]

#143: Review of draft-dekok-radext-nai-02

 > @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.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:
  [e-mail]          |  [e-mail]
     Type:  defect                   |     Status:  new
 Priority:  major                    |  Milestone:  milestone1
Component:  RFC4282bis               |    Version:  1.0
 Severity:  Candidate WG Document    |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: <https://trac.tools.ietf.org/wg/radext/trac/ticket/143>
radext <http://tools.ietf.org/radext/>