draft-ietf-radext-nai-02.txt   draft-ietf-radext-nai-03.txt 
Network Working Group DeKok, Alan Network Working Group DeKok, Alan
INTERNET-DRAFT FreeRADIUS INTERNET-DRAFT FreeRADIUS
Obsoletes: 4282 Obsoletes: 4282
Category: Standards Track Category: Standards Track
<draft-ietf-radext-nai-02.txt> <draft-ietf-radext-nai-03.txt>
28 January 2013 23 May 2013
The Network Access Identifier The Network Access Identifier
draft-ietf-radext-nai-02 draft-ietf-radext-nai-03
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 others users. This document defines the syntax for the identify each others 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 client prior to accessing network resources. This document is a
revised version of RFC 4282 [RFC4282], which addresses issues with revised version of RFC 4282 [RFC4282], 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 3, line 15 skipping to change at page 3, line 15
Table of Contents Table of Contents
Appendix A - Changes from RFC4282 ............................ 3 Appendix A - Changes from RFC4282 ............................ 3
1. Introduction ............................................. 4 1. Introduction ............................................. 4
1.1. Terminology ......................................... 5 1.1. Terminology ......................................... 5
1.2. Requirements Language ............................... 6 1.2. Requirements Language ............................... 6
1.3. Purpose ............................................. 7 1.3. Purpose ............................................. 7
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 ....................................... 8 2.2. Formal Syntax ....................................... 9
2.3. NAI Length Considerations ........................... 9 2.3. NAI Length Considerations ........................... 9
2.4. Support for Username Privacy ........................ 10 2.4. Support for Username Privacy ........................ 10
2.5. International Character Sets ........................ 10 2.5. International Character Sets ........................ 11
2.6. The Normalization Process ........................... 11 2.6. The Normalization Process ........................... 11
2.7. Use in Other Protocols .............................. 12 2.7. Use in Other Protocols .............................. 12
2.8. Routing inside of AAA Systems ....................... 12 2.8. Routing inside of AAA Systems ....................... 13
2.9. Compatibility with Email Usernames .................. 13 2.9. Compatibility with Email Usernames .................. 14
2.10. Compatibility with DNS ............................. 14 2.10. Compatibility with DNS ............................. 14
2.11. Realm Construction ................................. 15 2.11. Realm Construction ................................. 15
2.11.1. Historical Practices .......................... 15 2.11.1. Historical Practices .......................... 16
2.12. Examples ........................................... 16 2.12. Examples ........................................... 17
3. Security Considerations .................................. 17 3. Security Considerations .................................. 17
4. IANA Considerations ...................................... 17 4. IANA Considerations ...................................... 18
5. References ............................................... 18 5. References ............................................... 18
5.1. Normative References ................................ 18 5.1. Normative References ................................ 18
5.2. Informative References .............................. 18 5.2. Informative References .............................. 19
Appendix A - Changes from RFC4282 ............................ 21 Appendix A - Changes from RFC4282 ............................ 21
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
skipping to change at page 4, line 41 skipping to change at page 4, line 41
* Other protocols which are interested in leveraging the users * Other protocols which are interested in leveraging the users
credentials in order to take advantage of an existing credentials in order to take advantage of an existing
authentication framework. authentication framework.
In order to enhance the interoperability of these services, it is In order to enhance the interoperability of these services, it is
necessary to have a standardized method for identifying users. This necessary to have a standardized method for identifying users. This
document defines syntax for the Network Access Identifier (NAI). document defines syntax for the Network Access Identifier (NAI).
Examples of implementations that use the NAI, and descriptions of its Examples of implementations that use the NAI, and descriptions of its
semantics, can be found in [RFC2194]. semantics, can be found in [RFC2194].
When the NAI was defined for network access, it had the side effect
of defining an identifier which could be used elsewhere. Some
systems which required the use of an identifier did so by leveraging
the NAI. This process simplified the management of credentials, by
re-using the same credential in multiple situations. We suggest that
this re-use is good practice. The alternative is to have protocol-
specific identifiers, which increases cost to both user and
administrator.
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
does not require it. Many protocols already define their own
identifier formats. Some of these are incompatible with the NAI,
while others allow the NAI in addition to non-NAI identifiers. This
definition of the NAI has no requirements on protocol specifications,
implementations, or deployments. We simply suggest that using a
standard identifier format is preferable to using multiple
incompatible identifier formats.
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 7, line 45 skipping to change at page 7, line 45
English letters, digits, and the hyphen "-" character. The intent English letters, digits, and the hyphen "-" character. The intent
appears to have been to encode, compare, and transport realms with appears to have been to encode, compare, and transport realms with
the ToASCII operation defined in [RFC5890]. There are a number of the ToASCII operation defined in [RFC5890]. There are a number of
problems with this approach: problems with this approach:
* The [RFC4282] ABNF is not aligned with internationalization of DNS. * The [RFC4282] ABNF is not aligned with internationalization of DNS.
* The requirement in Section 2.1 that realms are ASCII conflicts * The requirement in Section 2.1 that realms are ASCII conflicts
with the Extensible Authentication Protocol (EAP) and RADIUS, with the Extensible Authentication Protocol (EAP) and RADIUS,
which are both 8-bit clean, and which both recommend the use of which are both 8-bit clean, and which both recommend the use of
UTF-8 for identities. UTF-8 for identitifiers.
* Section 2.4 required mappings that are language-specific, * Section 2.4 required mappings that are language-specific,
and which are nearly impossible for intermediate nodes to perform and which are nearly impossible for intermediate nodes to perform
correctly without information about that language. correctly without information about that language.
* Section 2.4 requires normalization of user names, which * Section 2.4 requires normalization of user names, which
may conflict with local system or administrative requirements. may conflict with local system or administrative requirements.
* The recommendations in Section 2.4 for treatment of * The recommendations in Section 2.4 for treatment of
bidirectional characters have proven to be unworkable. bidirectional characters have proven to be unworkable.
skipping to change at page 8, line 44 skipping to change at page 8, line 44
UTF8-4 = %xF0 %x90-BF 2( UTF8-tail ) / UTF8-4 = %xF0 %x90-BF 2( UTF8-tail ) /
%xF1-F3 3( UTF8-tail ) / %xF1-F3 3( UTF8-tail ) /
%xF4 %x80-8F 2( UTF8-tail ) %xF4 %x80-8F 2( UTF8-tail )
UTF8-tail = %x80-BF UTF8-tail = %x80-BF
These are normatively defined in [RFC3629], but are repeated in this These are normatively defined in [RFC3629], but are repeated in this
document for reasons of convenience. document for reasons of convenience.
See [RFC5198] for a discussion of normalization; the use of Normal See [RFC5198] and section 2.6 of this specification for a discussion
Form Composed (NFC) is RECOMMENDED. of normalization. Strings which are not in Normal Form Composed (NFC)
are not valid NAIs and SHOULD NOT be treated as such.
Implementations which expect to receive a NAI, but get non-normalised
(but otherwise valid) UTF-8 strings instead SHOULD attempt to create
a local version of the NAI, which is normalized from the input
identifier. This local version can then be used for local
processing.
Systems MAY accept user identifiers in forms other than the NAI.
This specification does not forbid that practice. It only codifies
the format and interpretation of the NAI. Where protocols carry
identifiers which are expected to be transported over an AAA
protocol, it is RECOMMENDED that the identifiers be in NAI format.
2.2. Formal Syntax 2.2. Formal Syntax
The grammar for the NAI is given below, described in Augmented The grammar for the NAI is given below, described in Augmented
Backus-Naur Form (ABNF) as documented in [RFC5234]. Backus-Naur Form (ABNF) as documented in [RFC5234].
nai = utf8-username nai = utf8-username
nai =/ "@" utf8-realm nai =/ "@" utf8-realm
nai =/ utf8-username "@" utf8-realm nai =/ utf8-username "@" utf8-realm
skipping to change at page 13, line 17 skipping to change at page 13, line 28
NAI as given in a AAA packet, and as provisioned in a logical AAA NAI as given in a AAA packet, and as provisioned in a logical AAA
routing table SHOULD be done as a byte-for-byte equality test. As routing table SHOULD be done as a byte-for-byte equality test. As
noted earlier, intermediate nodes may not have access to the same noted earlier, intermediate nodes may not have access to the same
locale information as the system which injected the NAI into the AAA locale information as the system which injected the NAI into the AAA
routing systems. Therefore, almost all "case insensitive" routing systems. Therefore, almost all "case insensitive"
comparisons will be wrong. Where the "utf8-realm" is entirely ASCII, comparisons will be wrong. Where the "utf8-realm" is entirely ASCII,
current systems sometimes perform case-insensitive matching on current systems sometimes perform case-insensitive matching on
realms. This practice MAY be continued, as it has been shown to work realms. This practice MAY be continued, as it has been shown to work
in practice. in practice.
We also note that many existing systems use user identifiers which
are similar in format to the NAI, but which are not compliant with
this specification. For example, they may use non-NFC form, or they
may have multiple "@" characters in the user identifier.
Intermediate nodes MAY normalize non-NFC identifiers to NFC, prior to
looking up the "utf8-realm" in the logical routing table.
Intermediate nodes MUST NOT modify the identifiers that they forward.
The data as entered by the user is inviolate.
The "utf8-realm" provisioned in the logical AAA routing table SHOULD The "utf8-realm" provisioned in the logical AAA routing table SHOULD
be provisioned to the proxy prior to it receiving any AAA traffic. be provisioned to the proxy prior to it receiving any AAA traffic.
The "utf8-realm" SHOULD be supplied by the "next hop" system that The "utf8-realm" SHOULD be supplied by the "next hop" or "home"
also supplies the other information, necessary to reach the next hop. system that also supplies the routing information necessary for
packets to reach the next hop.
This "next hop" information may be any of, or all of, the following This "next hop" information may be any of, or all of, the following
information: IP address; port; RADIUS shared secret; TLS certificate; information: IP address; port; RADIUS shared secret; TLS certificate;
DNS host name; or instruction to use dyanmic DNS discovery (i.e. look DNS host name; or instruction to use dyanmic DNS discovery (i.e. look
up a record in the "utf8-realm" domain). This list is not up a record in the "utf8-realm" domain). This list is not
exhaustive, and my be extended by future specifications. exhaustive, and my be extended by future specifications.
It is RECOMMENDED to use the entirety of the "utf8-realm" for the It is RECOMMENDED to use the entirety of the "utf8-realm" for the
routing decisions. However, systems MAY use a portion of the routing decisions. However, systems MAY use a portion of the
"utf8-realm" portion, so long as that portion is a valid "utf8-realm" portion, so long as that portion is a valid
 End of changes. 14 change blocks. 
16 lines changed or deleted 56 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/