The Network Access Identifier
draft-ietf-radext-nai-15

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: RFC Editor <rfc-editor@rfc-editor.org>,
    radext mailing list <radext@ietf.org>,
    radext chair <radext-chairs@tools.ietf.org>
Subject: Protocol Action: 'The Network Access Identifier' to Proposed Standard (draft-ietf-radext-nai-15.txt)

The IESG has approved the following document:
- 'The Network Access Identifier'
  (draft-ietf-radext-nai-15.txt) as Proposed Standard

This document is the product of the RADIUS EXTensions Working Group.

The IESG contact persons are Benoit Claise and Joel Jaeggli.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-radext-nai/


Technical Summary

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

Working Group Summary

  The preceding RFC4282 was primarily written for the concrete use 
  case of network access. Over time however, many services made use 
   of the concept defined therein; see Citation information at 
   http://www.arkko.com/tools/allstats/citations-rfc4282.html for a complete 
   list of IETF work; other standardization bodies or other documents not counted.
   draft-ietf-radext-nai thus had to make modest modifications in order not to 
   create incompatibilities with these existing uses. It also took care to define 
   the NAI in a protocol-agnostic manner to encourage such re-use.

   One particular issue which was discussed at length was the question: 
   which entity should (be allowed to) normalise or re-encode the realm portions 
   of NAIs; and what to do if such a re-encoding is needed, but not possible. 
   In the core scenario of network access, i.e use with RADIUS and Diameter, 
   character encoding and normalisation information may not be available to any 
   RADIUS/Diameter endpoint at all (the encoding information may get lost at a 
   preceding stage, before the NAI reaches the RADIUS client). In other scenarios,
   the encoding information may be available at all points in the conversation. The 
   working group finally converged on the text in section 2.6, which puts a bias on 
   endpoints doing all conversions, and intermediate entities doing conversions only
   inside their local state; not modifying the NAI on the wire.

   Another aspect that was discussed is that the notion of User-Name in AAA protocols
   and the term NAI are not an exact match; while User-Name often is used to transmit 
   a NAI, it can also be used to transmit arbitrary strings which do not follow the NAI 
   conventions of either RFC4282 or draft-ietf-radext-nai. The working group concluded 
   that this is a fact of life that can't be changed, and that implementations which inspect 
   a User-Name can't blindly assume to get a NAI; they need to care about their own 
   fallback/failure handling. Such handling is outside the scope of draft-ietf-radext-nai.

Document Quality

  The concept of NAIs is not new, and the definitions of draft-ietf-radext-nai are compatible 
  with implementations of NAIs in the "ASCII" subset. Field evidence suggests that RFC4282's 
  provisions for dealing with characters from outside ASCII were with an overwhelming 
  majority not implemented at all or even violated RFC4282 and did what draft-ietf-radext-nai 
  is now suggesting anyway; so existing implementations do not conflict with the new encoding
  rules parts that are introduced with draft-ietf-radext-nai. It's thus a reasonable assumption that
  NAIs as defined in draft-ietf-radext-nai are as widely implemented as the NAIs of RFC4282.

  The encoding and normalisation questions triggered an i18n review; the person doing that 
  review was Pete Resnick <presnick@qti.qualcomm.com>. The review comments were one 
  of the inputs to the discussion and were taken into account in the latest revision of the draft.

Personnel

  The document shepherd is Stefan Winter
  The responsible area directors of the Operations and Management area are Benoit Claise and Joel Jaeggli