draft-ietf-radext-nai-06.txt   draft-ietf-radext-nai-07.txt 
RADEXT Working Group DeKok, Alan RADEXT Working Group DeKok, Alan
INTERNET-DRAFT FreeRADIUS INTERNET-DRAFT FreeRADIUS
Obsoletes: 4282 Obsoletes: 4282
Category: Standards Track Category: Standards Track
<draft-ietf-radext-nai-06.txt> <draft-ietf-radext-nai-07.txt>
17 June 2014 23 September 2014
The Network Access Identifier The Network Access Identifier
draft-ietf-radext-nai-06 draft-ietf-radext-nai-07
Abstract Abstract
In order to provide inter-domain authentication services, it is In order to provide inter-domain authentication services, it is
necessary to have a standardized method that domains can use to necessary to have a standardized method that domains can use to
identify each other's users. This document defines the syntax for identify each other's users. This document defines the syntax for
the Network Access Identifier (NAI), the user identity submitted by the Network Access Identifier (NAI), the user identity submitted by
the client prior to accessing network resources. This document is a the client prior to accessing network resources. This document is a
revised version of RFC 4282, which addresses issues with revised version of RFC 4282, which addresses issues with
international character sets, as well as a number of other international character sets, as well as a number of other
skipping to change at page 1, line 45 skipping to change at page 1, line 45
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 17, 2015. This Internet-Draft will expire on June 23, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 22 skipping to change at page 3, line 22
1.4. Motivation .......................................... 7 1.4. Motivation .......................................... 7
2. NAI Definition ........................................... 8 2. NAI Definition ........................................... 8
2.1. UTF-8 Syntax and Normalization ...................... 8 2.1. UTF-8 Syntax and Normalization ...................... 8
2.2. Formal Syntax ....................................... 9 2.2. Formal Syntax ....................................... 9
2.3. NAI Length Considerations ........................... 10 2.3. NAI Length Considerations ........................... 10
2.4. Support for Username Privacy ........................ 11 2.4. Support for Username Privacy ........................ 11
2.5. International Character Sets ........................ 11 2.5. International Character Sets ........................ 11
2.6. The Normalization Process ........................... 12 2.6. The Normalization Process ........................... 12
2.6.1. Issues with the Normalization Process .......... 13 2.6.1. Issues with the Normalization Process .......... 13
2.7. Use in Other Protocols .............................. 14 2.7. Use in Other Protocols .............................. 14
3. Routing inside of AAA Systems ............................ 15 2.8. Using the NAI format for other identifiers .......... 15
3.1. Compatibility with Email Usernames .................. 16 3. Routing inside of AAA Systems ............................ 16
3.2. Compatibility with DNS .............................. 16 3.1. Compatibility with Email Usernames .................. 17
3.3. Realm Construction .................................. 17 3.2. Compatibility with DNS .............................. 17
3.3. Realm Construction .................................. 18
3.3.1. Historical Practices ........................... 18 3.3.1. Historical Practices ........................... 18
3.4. Examples ............................................ 18 3.4. Examples ............................................ 19
4. Security Considerations .................................. 19 4. Security Considerations .................................. 20
5. Administration of Names .................................. 20 5. Administration of Names .................................. 21
6. IANA Considerations ...................................... 20 6. IANA Considerations ...................................... 21
7. References ............................................... 20 7. References ............................................... 21
7.1. Normative References ................................ 20 7.1. Normative References ................................ 21
7.2. Informative References .............................. 21 7.2. Informative References .............................. 22
Appendix A - Changes from RFC4282 ............................ 23 Appendix A - Changes from RFC4282 ............................ 24
1. Introduction 1. Introduction
Considerable interest exists for a set of features that fit within Considerable interest exists for a set of features that fit within
the general category of inter-domain authentiction, or "roaming the general category of inter-domain authentiction, or "roaming
capability" for network access, including dialup Internet users, capability" for network access, including dialup Internet users,
Virtual Private Network (VPN) usage, wireless LAN authentication, and Virtual Private Network (VPN) usage, wireless LAN authentication, and
other applications. Interested parties have included the following: other applications. Interested parties have included the following:
* Regional Internet Service Providers (ISPs) operating within a * Regional Internet Service Providers (ISPs) operating within a
particular state or province, looking to combine their efforts particular state or province, looking to combine their efforts
skipping to change at page 5, line 12 skipping to change at page 5, line 12
The goal of this document is to define the format of an identifier The goal of this document is to define the format of an identifier
which can be used in many protocols. A protocol may transport an which can be used in many protocols. A protocol may transport an
encoded version of the NAI (e.g. '.' as %2E). However, the encoded version of the NAI (e.g. '.' as %2E). However, the
definition of the NAI is protocol independent. We hope to encourage definition of the NAI is protocol independent. We hope to encourage
the wide-spread adoption of the NAI as an identifier. This adoption the wide-spread adoption of the NAI as an identifier. This adoption
will decrease work required to leverage identification and will decrease work required to leverage identification and
authentication in other protocols. It will also decrease the authentication in other protocols. It will also decrease the
complexity of systems for end users and administrators. complexity of systems for end users and administrators.
We note that this document only suggest that the NAI be used, but We note that this document only suggest that the NAI be used, but
does not require it. Many protocols already define their own does not require such use. Many protocols already define their own
identifier formats. Some of these are incompatible with the NAI, identifier formats. Some of these are incompatible with the NAI,
while others allow the NAI in addition to non-NAI identifiers. This while others allow the NAI in addition to non-NAI identifiers. The
definition of the NAI has no requirements on protocol specifications, definition of the NAI in this document has no requirements on
implementations, or deployments. We suggest that using a standard protocol specifications, implementations, or deployments.
identifier format is preferable to using multiple incompatible
identifier formats. However, we suggest that using one standard identifier format is
preferable to using multiple incompatible identifier formats. Where
identifiers need to be used in new protocols and/or specifications,
it is RECOMMENDED that the format of the NAI be used. That is, the
interpretation of the identifier is context-specific, while the
format of the identifier remains the same. These issues are
discussed in more detail in Section 2.8, below.
This document is a revised version of [RFC4282], which originally This document is a revised version of [RFC4282], which originally
defined internationalized NAIs. Differences and enhancements defined internationalized NAIs. Differences and enhancements
compared to that document are listed in Appendix A. compared to that document are listed in Appendix A.
1.1. Terminology 1.1. Terminology
This document frequently uses the following terms: This document frequently uses the following terms:
"Local" or "localized" text "Local" or "localized" text
skipping to change at page 15, line 16 skipping to change at page 15, line 16
For example, HTTP carries user identifiers, but escapes the '.' For example, HTTP carries user identifiers, but escapes the '.'
character as "%2E" (among others). When we desire HTTP to transport character as "%2E" (among others). When we desire HTTP to transport
the NAI "fred@example.com", the data as transported will be in the the NAI "fred@example.com", the data as transported will be in the
form "fred@example%2Ecom". That data exists only within HTTP, and form "fred@example%2Ecom". That data exists only within HTTP, and
has no relevance to any AAA system. has no relevance to any AAA system.
Any comparison, validation, or use of the NAI MUST be done on its un- Any comparison, validation, or use of the NAI MUST be done on its un-
escaped (i.e. utf8-clean) form. escaped (i.e. utf8-clean) form.
2.8. Using the NAI format for other identifiers
As discussed in Section 1, above, is RECOMMENDED that the NAI format
be used as the standard format for user identifiers. This section
discusses that use in more detail.
It is often useful to create new identifiers for use in specific
contexts. These identifiers may have a number of different
properties, most of which are unimportant to this document. For our
purposes, we are interested in identifiers which need to be in a
well-known format, and to have namespaces. The NAI format fits these
requirements.
One example of such use is the "private user identity", which is
defined by the 3rd-Generation Partnership Project (3GPP). That
identity is used to uniquely identify the user to the network. The
identity is used for authorization, authentication, accounting,
administation, etc. The private user identity is globally unique,
and is defined by the home network operator. The format of the
identity is explicitly the NAI, as stated by Section 13.3 of [3GPP]:
The private user identity shall take the form of an NAI, and shall
have the form username@realm as specified in clause 2.1 of IETF
RFC 4282
For 3GPP, the "username" portion is a unique identifier which is
derived from device-specific information. The "realm" portion is
composed of information about the home network, followed by the base
string "3gppnetwork.org". e.g.
234150999999999@ims.mnc015.mcc234.3gppnetwork.org.
This format ensures that the identifier is globally unique, as it is
based off of the "3gppnetwork.org" domain. It ensures that the
"realm" portion is specific to a particular home network (or
organization), via the "ims.mnc015.mcc234" prefix to the realm.
Finally, it ensures that the "username" portion follows a well-known
format.
We suggest that the NAI format be used for all new specifications
and/or protocols where a user identifier is required. It is
RECOMMENDED that methods similar to that described above for 3GPP be
used to derive the identifier.
3. Routing inside of AAA Systems 3. Routing inside of AAA Systems
Many AAA systems use the "utf8-realm" portion of the NAI to route Many AAA systems use the "utf8-realm" portion of the NAI to route
requests within a AAA proxy network. The semantics of this operation requests within a AAA proxy network. The semantics of this operation
involves a logical AAA routing table, where the "utf8-realm" portion involves a logical AAA routing table, where the "utf8-realm" portion
acts as a key, and the values stored in the table are one or more acts as a key, and the values stored in the table are one or more
"next hop" AAA servers. "next hop" AAA servers.
Intermediate nodes MUST use the "utf8-realm" portion of the NAI Intermediate nodes MUST use the "utf8-realm" portion of the NAI
without modification to perform this lookup. As noted earlier, without modification to perform this lookup. As noted earlier,
skipping to change at page 22, line 41 skipping to change at page 23, line 36
Domain Names", RFC 6055, February 2011. Domain Names", RFC 6055, February 2011.
[RFC6733] [RFC6733]
V. Fajardo, Ed., et al, "Diameter Base Protocol", RFC 6733, October V. Fajardo, Ed., et al, "Diameter Base Protocol", RFC 6733, October
2012. 2012.
[RFC6912] [RFC6912]
Sullivan, A., et al, "Principles for Unicode Code Point Inclusion Sullivan, A., et al, "Principles for Unicode Code Point Inclusion
in Labels in the DNS", RFC 6912, April 2013. in Labels in the DNS", RFC 6912, April 2013.
[3GPP]
3GPP, "TS 23.003 Numbering, addressing, and Identification (Release
12)", July 2014,
ftp://ftp.3gpp.org/Specs/archive/23_series/23.003/.
Acknowledgments Acknowledgments
The initial text for this document was [RFC4282], which was then The initial text for this document was [RFC4282], which was then
heavily edited. The original authors of [RFC4282] were Bernard heavily edited. The original authors of [RFC4282] were Bernard
Aboba, Mark A. Beadles, Jari Arkko, and Pasi Eronen. Aboba, Mark A. Beadles, Jari Arkko, and Pasi Eronen.
The ABNF validator at http://www.apps.ietf.org/abnf.html was used to The ABNF validator at http://www.apps.ietf.org/abnf.html was used to
verify the syntactic correctness of the ABNF in Section 2. verify the syntactic correctness of the ABNF in Section 2.
Appendix A - Changes from RFC4282 Appendix A - Changes from RFC4282
 End of changes. 9 change blocks. 
22 lines changed or deleted 77 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/