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