Subject: [radext] Updated NAI document

From: Alan DeKok <[email-masked]>
Date: Tue, 08 Jan 2013 08:43:19 -0500

I've just posted the updated NAI document.  It addresses all concerns
raised here, and in the issues tracker.

  If there are no further issues with it, we should be able to last-call it.

  Alan DeKok.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 8 Jan 2013 05:57:48 -0800

Looking at the revision, it appears that many of the issues remain open. Can you post what the proposed resolutions?

> Date: Tue, 8 Jan 2013 08:43:19 -0500
> From: [email-masked]
> To: [email-masked]
> Subject: [radext] Updated NAI document
> 
> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext

---

From: Alan DeKok <[email-masked]>
Date: Tue, 08 Jan 2013 09:17:29 -0500

Bernard Aboba wrote:
> Looking at the revision, it appears that many of the issues remain open.

  Hm... I don't see that.  The diff is here:

http://tools.ietf.org/rfcdiff?url2=draft-ietf-radext-nai-01.txt

  There were a number of changes to the docuemnt.

> Can you post what the proposed resolutions?

  I posted all of the proposed text to the list.  Here again for summary:

* "roaming / NAI" in abstract and introduction

  ** changed text to use "inter-domain authentication"
  ** removed text around "ISPs" etc. in abstract:

  Abstract:
   In order to provide inter-domain authentication services, it is
   necessary to have a standardized method that domains can use to
   identify each others users.  This document defines the syntax for the
   Network Access Identifier (NAI), the user identity submitted by the
   client prior to accessing network resources. This document is a
   revised version of RFC 4282 [RFC4282], which addresses issues with
   international character sets, as well as a number of other
   corrections to the previous document.

* for SIP / HTTP, etc. added text in the introduction on "interested
parties":

   * Other protocols which are interested in leveraging the users
      credentials in order to take advantage of an existing
      authentication framework.

* definitions of "local" text in Terminology section:

   "local" or "localized" text

      Text which is either in non-UTF-8, or in non-normalized form.  The
      character set, encoding, and locale are (in general) unknown to
      Authentication, Authorization, and Accounting (AAA) network
      protocols.

* for other protocols, added text in Purpose section:

   We also hope that other protocols can take advantage of the NAI.
   Many protocols include authentication capabilities.  The
   authentication credentials supplied in those protocols can end up
   being transported in AAA protocols.  It is therefore useful to define
   a representation of the user credentials which can be shared across
   multiple protocols.

* in "Motivation", added note:

  o The [RFC4282] ABNF is not aligned with internationalization of DNS.

* updated terminology when recommending NFC:

   See [RFC5198] for a discussion of normalization; the use of Normal
   Form Composed (NFC) is RECOMMENDED.

* Noted difference between octet and character counts in NAI length:

   * NAI octet length constraints may impose a more severe constraint
      on the number of UTF-8 characters.

* noted protocol-specific limitations on NAI length:

   * NAIs may be transported in other protocols.  Each protocol
      can have its own limitations on maximum NAI length.

* permitted use of "anonymous@realm":

   ...
   single user.  However, current practice is to use the username
   "anonymous" instead of omitting the username part.  This behavior is
   also permitted.

* Updated Section 2.6 (Normalization process) with suggested text on EAP
&& proxies, as posted to the list

* Added Section 2.7, "Use in Other Protocols", which discusses the use
of the NAI in other protocols.  It addresses the concerns raised here,
and makes suggestions for best practices

* Clarified suggested data for "next hop" routing information.  It can
be any / all of (IP, port, host name, certificate, etc.)

* noted that routing on portions of the NAI is explicitly permitted, so
long as that portion of the NAI is a valid realm.  Example of routing
[email-masked] to "com" is not allowed, but routing to
"example.com" is allowed

* Changes to Section 2.10 (compatibility with DNS), using text as posted
to the list.  (refer to API, not library, etc.)

* removed text suggesting that differences between EAP Identity and
User-Name are problematic

* moved various RFCs to normative reference, as per Benoit's suggestion

---

From: Alan DeKok <[email-masked]>
Date: Tue, 08 Jan 2013 09:32:52 -0500

>   Hm... I don't see that.  The diff is here:

  Reviewing the issues tracker, there are two remaining issues:

145 - realms allowed by the ABNF can not always be registered in DNS

  This is already covered in Section 2.5:

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

  This point could be made clearer, but I think the issue is covered by
the existing text.  Perhaps re-stating that requirement in the
introduction, so people don't miss it?

146 - reference RFC 6365, re: "locale", "normalization", "canonicalization".

  Possibly.  The document references 5198 re: normalization.

  The document uses "canonicalization" once, and references a
"canonical" form multiple times.  This canonical form is taken as the
"known good" realm data supplied to the interested parties, by the realm
owner.  So this document does not require that anyone perform
"canonicalization" of the realm.

  The updated Terminology section defines "locale" which seems to agree
with RFC 6265, and is good enough for the purposes of this document.

  I'm open to more upates, of course.  I'm not sure I see them as
critical at this time.

  Alan DeKok.