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
