draft-ietf-radext-nai-03.txt   draft-ietf-radext-nai-04.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-03.txt> <draft-ietf-radext-nai-04.txt>
23 May 2013 17 October 2013
The Network Access Identifier The Network Access Identifier
draft-ietf-radext-nai-03 draft-ietf-radext-nai-04
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 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 July 8, 2013. This Internet-Draft will expire on April 16, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 7 skipping to change at page 3, line 7
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
3. ........................................................... 3
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 ....................................... 9 2.2. Formal Syntax ....................................... 9
2.3. NAI Length Considerations ........................... 9 2.3. NAI Length Considerations ........................... 10
2.4. Support for Username Privacy ........................ 10 2.4. Support for Username Privacy ........................ 11
2.5. International Character Sets ........................ 11 2.5. International Character Sets ........................ 11
2.6. The Normalization Process ........................... 11 2.6. The Normalization Process ........................... 12
2.7. Use in Other Protocols .............................. 12 2.6.1. Issues with the Normalization Process .......... 13
2.8. Routing inside of AAA Systems ....................... 13 2.7. Use in Other Protocols .............................. 14
2.9. Compatibility with Email Usernames .................. 14 3. ........................................................... 14
2.10. Compatibility with DNS ............................. 14 3.1. Compatibility with Email Usernames .................. 16
2.11. Realm Construction ................................. 15 3.2. Compatibility with DNS .............................. 16
2.11.1. Historical Practices .......................... 16 3.3. Realm Construction .................................. 17
2.12. Examples ........................................... 17 3.3.1. Historical Practices ........................... 17
3. Security Considerations .................................. 17 3.4. Examples ............................................ 18
4. IANA Considerations ...................................... 18 4. Security Considerations .................................. 19
5. References ............................................... 18 5. IANA Considerations ...................................... 19
5.1. Normative References ................................ 18 6. References ............................................... 20
5.2. Informative References .............................. 19 6.1. Normative References ................................ 20
Appendix A - Changes from RFC4282 ............................ 21 6.2. Informative References .............................. 20
Appendix A - Changes from RFC4282 ............................ 23
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 4, line 42 skipping to change at page 4, line 42
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 When the NAI was defined for network access, it had the side effect
of defining an identifier which could be used elsewhere. Some of defining an identifier which could be used in non-AAA systems.
systems which required the use of an identifier did so by leveraging Some systems defined identifiers which were compatible with the NAI,
the NAI. This process simplified the management of credentials, by and deployments used the NAI. This process simplified the management
re-using the same credential in multiple situations. We suggest that of credentials, by re-using the same credential in multiple
this re-use is good practice. The alternative is to have protocol- situations. We suggest that this re-use is good practice. The
specific identifiers, which increases cost to both user and alternative is to have protocol-specific identifiers, which increases
administrator. 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 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 it. 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. This
definition of the NAI has no requirements on protocol specifications, definition of the NAI has no requirements on protocol specifications,
implementations, or deployments. We simply suggest that using a implementations, or deployments. We suggest that using a standard
standard identifier format is preferable to using multiple identifier format is preferable to using multiple incompatible
incompatible identifier formats. 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 6, line 16 skipping to change at page 6, line 16
Roaming Capability Roaming Capability
Roaming capability can be loosely defined as the ability to use Roaming capability can be loosely defined as the ability to use
any one of multiple Internet Service Providers (ISPs), while any one of multiple Internet Service Providers (ISPs), while
maintaining a formal, customer-vendor relationship with only one. maintaining a formal, customer-vendor relationship with only one.
Examples of cases where roaming capability might be required Examples of cases where roaming capability might be required
include ISP "confederations" and ISP-provided corporate network include ISP "confederations" and ISP-provided corporate network
access support. access support.
Normalization Canonicalization
These terms are defined in [RFC6365] Section 4. We incorporate
the definitions here by reference.
Locale
This term is defined in [RFC6365] Section 8. We incorporate the
definition here by reference.
Tunneling Service Tunneling Service
A tunneling service is any network service enabled by tunneling A tunneling service is any network service enabled by tunneling
protocols such as PPTP, L2F, L2TP, and IPsec tunnel mode. One protocols such as PPTP, L2F, L2TP, and IPsec tunnel mode. One
example of a tunneling service is secure access to corporate example of a tunneling service is secure access to corporate
intranets via a Virtual Private Network (VPN). intranets via a Virtual Private Network (VPN).
1.2. Requirements Language 1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 7, line 20 skipping to change at page 7, line 20
In order to be able to offer roaming capability, one of the In order to be able to offer roaming capability, one of the
requirements is to be able to identify the user's home authentication requirements is to be able to identify the user's home authentication
server. For use in roaming, this function is accomplished via the server. For use in roaming, this function is accomplished via the
Network Access Identifier (NAI) submitted by the user to the NAS in Network Access Identifier (NAI) submitted by the user to the NAS in
the initial network authentication. It is also expected that NASes the initial network authentication. It is also expected that NASes
will use the NAI as part of the process of opening a new tunnel, in will use the NAI as part of the process of opening a new tunnel, in
order to determine the tunnel endpoint. order to determine the tunnel endpoint.
We also hope that other protocols can take advantage of the NAI. We also hope that other protocols can take advantage of the NAI.
Many protocols include authentication capabilities. The Many protocols include authentication capabilities, including
authentication credentials supplied in those protocols can end up defining their own identifier formats. These identifiers can then
being transported in AAA protocols. It is therefore useful to define end up being transported in AAA protocols, when those systems want to
a representation of the user credentials which can be shared across leverage AAA for user authentication. There is therefore a need for
multiple protocols. a definition of a user identifier which can be used in multiple
protocols.
While we define the NAI here, we recognize that existing protocols
and deployments do not always use it. AAA systems MUST therefore be
able to handle user identifiers which are not in the NAI format. The
process by which that is done is outside of the scope of this
document.
We note that this document does not make any protocol-specific
definitions for an identifier format, and it does not make changes to
any existing protocol. Instead, it defines a protocol-independent
form for the NAI. It is hoped that the NAI is a user identifier
which can be used in multiple protocols.
Using a common identifier simplifies deployments, as there is no need
to maintain multiple identifiers for one user. It simplifies
protocols requiring authentication, as they no longer need to specify
protocol-specific format for user identifiers. It increases
security, as it multiple identifiers allow attackers to make
contradictory claims without being detected.
In short, having a standard is better than having no standard at all.
1.4. Motivation 1.4. Motivation
The changes from [RFC4282] are listed in detail in Appendix A. The changes from [RFC4282] are listed in detail in Appendix A.
However, some additional discussion is appropriate to motivate those However, some additional discussion is appropriate to motivate those
changes. changes.
The motivation to revise [RFC4282] began with internationalization The motivation to revise [RFC4282] began with internationalization
concerns raised in the context of [EDUROAM]. Section 2.1 of concerns raised in the context of [EDUROAM]. Section 2.1 of
[RFC4282] defines ABNF for realms which limits the realm grammar to [RFC4282] defines ABNF for realms which limits the realm grammar to
skipping to change at page 9, line 7 skipping to change at page 9, line 29
of normalization. Strings which are not in Normal Form Composed (NFC) of normalization. Strings which are not in Normal Form Composed (NFC)
are not valid NAIs and SHOULD NOT be treated as such. are not valid NAIs and SHOULD NOT be treated as such.
Implementations which expect to receive a NAI, but get non-normalised Implementations which expect to receive a NAI, but get non-normalised
(but otherwise valid) UTF-8 strings instead SHOULD attempt to create (but otherwise valid) UTF-8 strings instead SHOULD attempt to create
a local version of the NAI, which is normalized from the input a local version of the NAI, which is normalized from the input
identifier. This local version can then be used for local identifier. This local version can then be used for local
processing. processing.
Systems MAY accept user identifiers in forms other than the NAI. Systems MAY accept user identifiers in forms other than the NAI.
This specification does not forbid that practice. It only codifies This specification does not forbid that practice. It only codifies
the format and interpretation of the NAI. Where protocols carry the format and interpretation of the NAI. We cannot expect to change
identifiers which are expected to be transported over an AAA existing protocols or practices. We can, however, suggest that using
protocol, it is RECOMMENDED that the identifiers be in NAI format. a consistent form for a user identifier is of a benefit to the
community.
Where protocols carry identifiers which are expected to be
transported over an AAA protocol, it is RECOMMENDED that the
identifiers be in NAI format. Where the identifiers are not in the
NAI format, it is up to the AAA systems to discover this, and to
process them. This document does not suggest how that is done.
However, existing practice indicates that it is possible.
We expect that with wider use of internationalized domain names,
existing practices will be inadequate. We therefore define the NAI,
which is a user identifier that can correctly deal with
internationalized identifiers.
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 11, line 24 skipping to change at page 12, line 10
as well as the requirements specified in [RFC5891]. In practice, as well as the requirements specified in [RFC5891]. In practice,
these requirements consist of the following item: these requirements consist of the following item:
* Realms MUST be of the form that can be registered as a * Realms MUST be of the form that can be registered as a
Fully Qualified Domain Name (FQDN) within the DNS. Fully Qualified Domain Name (FQDN) within the DNS.
This list is significantly shorter and simpler than the list in This list is significantly shorter and simpler than the list in
Section 2.4 of [RFC4282]. The form suggested in [RFC4282] depended Section 2.4 of [RFC4282]. The form suggested in [RFC4282] depended
on intermediate nodes performing canonicalizations based on on intermediate nodes performing canonicalizations based on
insufficient information, which meant that the form was not insufficient information, which meant that the form was not
canonical. This document instead suggests (Section 2.10) that the canonical.
realm owner provide a canonical form of the realm, and that all
intermediate nodes use that form without modification.
Specifying the realm requirement as above means that the requirements Specifying the realm requirement as above means that the requirements
depend on specifications that are referenced here, rather than copied depend on specifications that are referenced here, rather than copied
here. This allows the realm definition to be updated when the here. This allows the realm definition to be updated when the
referenced documents change, without requiring a revision of this referenced documents change, without requiring a revision of this
specification. specification.
One caveat on the above recommendation is the issues noted in
[CODEPOINTS]. That document notes that there are additional
restrictions around DNS registration which forbid some code points
from being valid in a DNS U-label. These restrictions cannot be
expressed algorithmically.
For this specification, that caveat means the following. Realms not
matching the above ABNF are not valid NAIs. However, some realms
which do match the ABNF are still invalid NAIs. That is, matching
the ABNF is a necessary, but not sufficient, requirement for an NAI.
In general, the above requirement means following the requirements In general, the above requirement means following the requirements
specified in [RFC5891]. specified in [RFC5891].
2.6. The Normalization Process 2.6. The Normalization Process
Conversion to Unicode as well as normalization is expected to be Conversion to Unicode as well as normalization is expected to be
performed by end systems that take "local" text as input. Other AAA performed by end systems that take "local" text as input. Other AAA
systems such as proxies do not have access to locale and character systems such as proxies do not have access to locale and character
set information that is available to end systems. Therefore, they set information that is available to end systems. Therefore, they
are typically incapable of converting local input to Unicode. are typically incapable of converting local input to Unicode.
That is, all processing of NAIs from "local" character sets and That is, all processing of NAIs from "local" character sets and
locales to UTF-8 is performed by edge systems, prior to the NAIs locales to UTF-8 SHOULD BE performed by edge systems, prior to the
entering the AAA system. Inside of an AAA system, NAIs are sent over NAIs entering the AAA system. Inside of an AAA system, NAIs are sent
the wire in their canonical form, and this canonical form is used for over the wire in their canonical form, and this canonical form is
all NAI and/or realm comparisons. used for all NAI and/or realm comparisons.
Copying of localized text into fields that can subsequently be placed Copying of localized text into fields that can subsequently be placed
into the RADIUS User-Name attribute is problematic. This practice into the RADIUS User-Name attribute is problematic. This practice
can result in a AAA proxy encountering non-UTF8 characters within can result in a AAA proxy encountering non-UTF8 characters within
what it expects to be an NAI. An example of this requirement is what it expects to be an NAI. An example of this requirement is
[RFC3579] Section 2.1, which states: [RFC3579] Section 2.1, which states:
the NAS MUST copy the contents of the Type-Data field of the the NAS MUST copy the contents of the Type-Data field of the
EAP-Response/Identity received from the peer into the User-Name EAP-Response/Identity received from the peer into the User-Name
attribute attribute
skipping to change at page 12, line 25 skipping to change at page 13, line 22
or identity fields means that realm routing becomes difficult or or identity fields means that realm routing becomes difficult or
impossible. impossible.
In contrast to [RFC4282] Section 2.4, we expect AAA systems to In contrast to [RFC4282] Section 2.4, we expect AAA systems to
perform NAI comparisons, matching, and AAA routing based on the NAI perform NAI comparisons, matching, and AAA routing based on the NAI
as it is received. This specification provides a canonical as it is received. This specification provides a canonical
representation, ensures that intermediate systems such as AAA proxies representation, ensures that intermediate systems such as AAA proxies
do not need to perform translations, and can be expected to work do not need to perform translations, and can be expected to work
through systems that are unaware of international character sets. through systems that are unaware of international character sets.
In short,
* End systems using "localized" text SHOULD normalize the NAI
prior to it being used as an identifier in an authentication
protocol.
* AAA systems SHOULD NOT normalize the NAI, as they may not have
sufficient information to perform the normalization.
For example, much of the common realm routing can be done on the For example, much of the common realm routing can be done on the
"utf8-realm" portion of NAI, through simple checks for equality. "utf8-realm" portion of NAI, through simple checks for equality.
This routing can be done even if the AAA proxy is unaware of This routing can be done even if the AAA proxy is unaware of
internalized domain names. All that is required is for the AAA proxy internalized domain names. All that is required is for the AAA proxy
to be able to enter, store, and compare 8-bit data. to be able to enter, store, and compare 8-bit data.
2.6.1. Issues with the Normalization Process
We recognize that the requirements in the preceding section are not
implemented today. For example, most EAP implementations use a user
identifier which is passed to them from some other local system.
This identifier is treated as an opaque blob, and is placed as-is
into the EAP Identity field. Any subsequent system which receives
that identifier is assumed to be able to understand and process it.
This opaque blob unfortunately contains localized text, which means
that the AAA systems have to process that text.
These limitations have the following theoretical and practical
implications.
* "local" systems used today generally do not normalize the NAI
* Therefore AAA systems SHOUD attempt to normalize the NAI
Where the user identifier can be normalized, or determined to be in
normal form, the normal form MUST be used as the NAI. In all other
circumstances, the user identifier MUST NOT be treated as an NAI.
That data is still, however, a user identifier. AAA systems MUST NOT
fail authentication simply because the user identifier is not an NAI.
2.7. Use in Other Protocols 2.7. Use in Other Protocols
As noted earlier, the NAI MAY be used in other, non-AAA protocols. As noted earlier, the NAI MAY be used in other, non-AAA protocols.
It is RECOMMENDED that the definition given here be used unchanged. It is RECOMMENDED that the definition given here be used unchanged.
Using other definitions for user identifiers may hinder Using other definitions for user identifiers may hinder
interoperability, along with the users ability to authenticate interoperability, along with the users ability to authenticate
successfully. It is RECOMMENDED that protocols requiring the use of successfully. It is RECOMMENDED that protocols requiring the use of
a user identifier reference this specification, and suggest that the a user identifier reference this specification, and suggest that the
use of an NAI is RECOMMENDED. use of an NAI is RECOMMENDED.
We cannot require other protocols to use the NAI for user We cannot require other protocols to use the NAI for user
identifiers. Their needs are unknown, and unknowable. We simply identifiers. Their needs are unknown, and unknowable. We simply
suggest that interoperability and inter-domain authentication is suggest that interoperability and inter-domain authentication is
useful, and should be encouraged. useful, and should be encouraged.
Where a protocol is 8-bit clean, it can likely transport the NAI as- Where a protocol is 8-bit clean, it can likely transport the NAI as-
is, without further modification. is, without further modification.
Where a protocol is not 8-bit clean, it MUST NOT affect the Where a protocol is not 8-bit clean, it cannot transport the NAI as-
definition or handling of the NAI. That is, if a protocol escapes is. Instead, we presume that a protocol-specific transport layer
the '.' character as "%2E", then the protocol may have an identifier takes care of encoding the NAI on input to the protocol, and decoding
transported as "fred@example%2Ecom", whereas the NAI for that user is it when the NAI exits the protocol. The encoded or escaped version
"fred@example.com". Any comparison, validation, or use of the NAI of the NAI is not a valid NAI, and MUST NOT be presented to the AAA
MUST be done on its un-escaped (i.e. utf8-clean) form. system.
2.8. Routing inside of AAA Systems For example, HTTP carries user identifiers, but escapes the '.'
character as "%2E" (among others). When we desire HTTP to transport
the NAI "fred@example.com", the data as transported will be in the
form "fred@example%2Ecom". That data exists only within HTTP, and
has no relevance to any AAA system.
Any comparison, validation, or use of the NAI MUST be done on its un-
escaped (i.e. utf8-clean) form.
3.
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. Comparisons between the without modification to perform this lookup. As noted earlier,
NAI as given in a AAA packet, and as provisioned in a logical AAA intermediate nodes may not have access to the same locale information
routing table SHOULD be done as a byte-for-byte equality test. As as the system which injected the NAI into the AAA routing systems.
noted earlier, intermediate nodes may not have access to the same Therefore, almost all "case insensitive" comparisons will be wrong.
locale information as the system which injected the NAI into the AAA Where the "utf8-realm" is entirely ASCII, current systems sometimes
routing systems. Therefore, almost all "case insensitive" perform case-insensitive matching on realms. This practice MAY be
comparisons will be wrong. Where the "utf8-realm" is entirely ASCII, continued, as it has been shown to work in practice.
current systems sometimes perform case-insensitive matching on
realms. This practice MAY be continued, as it has been shown to work
in practice.
We also note that many existing systems use user identifiers which We also note that many existing systems have user identifiers which
are similar in format to the NAI, but which are not compliant with 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 this specification. For example, they may use non-NFC form, or they
may have multiple "@" characters in the user identifier. may have multiple "@" characters in the user identifier.
Intermediate nodes MAY normalize non-NFC identifiers to NFC, prior to Intermediate nodes SHOULD normalize non-NFC identifiers to NFC, prior
looking up the "utf8-realm" in the logical routing table. to looking up the "utf8-realm" in the logical routing table.
Intermediate nodes MUST NOT modify the identifiers that they forward. Intermediate nodes MUST NOT modify the identifiers that they forward.
The data as entered by the user is inviolate. 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" or "home" The "utf8-realm" SHOULD be supplied by the "next hop" or "home"
system that also supplies the routing information necessary for system that also supplies the routing information necessary for
packets to reach the next hop. 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
skipping to change at page 14, line 18 skipping to change at page 16, line 5
permissible. permissible.
Another reason to forbid the use of a single label (e.g. Another reason to forbid the use of a single label (e.g.
"fred@sales") is that many systems treat a single label as being a "fred@sales") is that many systems treat a single label as being a
local identifier within their realm. That is, a user logging in as local identifier within their realm. That is, a user logging in as
"fred@sales" to a domain "example.com", would be treated as if the "fred@sales" to a domain "example.com", would be treated as if the
NAI was instead "fred@sales.example.com". Permitting the use of a NAI was instead "fred@sales.example.com". Permitting the use of a
single label would mean changing the interpretation and meaning of a single label would mean changing the interpretation and meaning of a
single label, which cannot be done. single label, which cannot be done.
2.9. Compatibility with Email Usernames 3.1. Compatibility with Email Usernames
As proposed in this document, the Network Access Identifier is of the As proposed in this document, the Network Access Identifier is of the
form "user@realm". Please note that while the user portion of the form "user@realm". Please note that while the user portion of the
NAI is based on the BNF described in [RFC5198], it has been modified NAI is based on the BNF described in [RFC5198], it has been modified
for the purposes of Section 2.2. It does not permit quoted text for the purposes of Section 2.2. It does not permit quoted text
along with "folding" or "non-folding" whitespace that is commonly along with "folding" or "non-folding" whitespace that is commonly
used in email addresses. As such, the NAI is not necessarily used in email addresses. As such, the NAI is not necessarily
equivalent to usernames used in e-mail. equivalent to usernames used in e-mail.
However, it is a common practice to use email addresses as user However, it is a common practice to use email addresses as user
skipping to change at page 14, line 40 skipping to change at page 16, line 27
close to the "utf8-addr-spec" portion of [RFC5335], while still being close to the "utf8-addr-spec" portion of [RFC5335], while still being
compatible with [RFC4282]. compatible with [RFC4282].
In contrast to [RFC4282] Section 2.5, we state that the In contrast to [RFC4282] Section 2.5, we state that the
internationalization requirements for NAIs and email addresses are internationalization requirements for NAIs and email addresses are
substantially similar. The NAI and email identifiers may be the substantially similar. The NAI and email identifiers may be the
same, and both need to be entered by the user and/or the operator same, and both need to be entered by the user and/or the operator
supplying network access to that user. There is therefore good supplying network access to that user. There is therefore good
reason for the internationalization requirements to be similar. reason for the internationalization requirements to be similar.
2.10. Compatibility with DNS 3.2. Compatibility with DNS
The "utf8-realm" portion of the NAI is intended to be compatible with The "utf8-realm" portion of the NAI is intended to be compatible with
Internationalized Domain Names (IDNs) [RFC5890]. As defined above, Internationalized Domain Names (IDNs) [RFC5890]. As defined above,
the "utf8-realm" portion as transported within an 8-bit clean the "utf8-realm" portion as transported within an 8-bit clean
protocol such as RADIUS and EAP can contain any valid UTF8 character. protocol such as RADIUS and EAP can contain any valid UTF8 character.
There is therefore no reason for a NAS to apply the ToAscii function There is therefore no reason for a NAS to apply the ToAscii function
to the "utf8-realm" portion of an NAI, prior to placing the NAI into to the "utf8-realm" portion of an NAI, prior to placing the NAI into
a RADIUS User-Name attribute. Unlike DNS, the NAI does not make a a RADIUS User-Name attribute.
distinction between A-labels and U-labels. Is instead an IDNA-valid
label, as per Section 2.3.2.1 of [RFC5890]. The NAI does not make a distinction between A-labels and U-labels, as
those are terms specific to DNS. It is instead an IDNA-valid label,
as per the first item in Section 2.3.2.1 of [RFC5890]. As noted in
that section, the term "IDNA-valid label" encompases both of the
terms A-label and U-label.
When the realm portion of the NAI is used as the basis for name When the realm portion of the NAI is used as the basis for name
resolution, it may be necessary to convert internationalized realm resolution, it may be necessary to convert internationalized realm
names to ASCII using the ToASCII operation defined in [RFC5890]. As names to ASCII using the ToASCII operation defined in [RFC5890]. As
noted in [RFC6055] Section 2, resolver Application Programming noted in [RFC6055] Section 2, resolver Application Programming
Interfaces (APIs) are not necessarily DNS-specific, so that the Interfaces (APIs) are not necessarily DNS-specific, so that the
ToASCII operation needs to be applied carefully: ToASCII operation needs to be applied carefully:
Applications which convert an IDN to A-label form before calling (for Applications which convert an IDN to A-label form before calling (for
example) getaddrinfo() will result in name resolution failures if the example) getaddrinfo() will result in name resolution failures if the
Punycode name is directly used in such protocols. Having libraries Punycode name is directly used in such protocols. Having libraries
or protocols to convert from A-labels to the encoding scheme defined or protocols to convert from A-labels to the encoding scheme defined
by the protocol (e.g., UTF-8) would require changes to APIs and/or by the protocol (e.g., UTF-8) would require changes to APIs and/or
servers, which IDNA was intended to avoid. servers, which IDNA was intended to avoid.
As a result, applications SHOULD NOT assume that non-ASCII names are As a result, applications SHOULD NOT assume that non-ASCII names are
resolved using the public DNS and blindly convert them to A-labels resolvable using the public DNS and blindly convert them to A-labels
without knowledge of what protocol will be selected by the name without knowledge of what protocol will be selected by the name
resolution library. resolution library.
There is, however, a problem with this approach. A AAA proxy may not 3.3. Realm Construction
have sufficient information in order to perform the ToAscii
conversion properly. We therefore RECOMMEND that only the owner of
the realm perform the ToAscii conversion. We RECOMMEND that the
owner of the realm pre-provision all proxies with the "utf8-realm"
portion of the NAI, along with the value returned from passing the
"utf8-realm" to the ToAscii function. This key-value pair can then
be placed into the logical AAA routing table discussed above. Having
only one entity perform the ToAscii function ensures that the result
returned by that function are considered as canonical by all other
participants in a AAA network.
The paragraph above does not negate all of the benefits of using DNS
to automatically discover the location of a "next hop" AAA server.
Many AAA proxies require a business or legal relationship prior to
routing any traffic. This relationship can be leveraged to bootstrap
the DNS information located in the logical AAA routing table.
2.11. Realm Construction
The home realm usually appears in the "utf8-realm" portion of the The home realm usually appears in the "utf8-realm" portion of the
NAI, but in some cases a different realm can be used. This may be NAI, but in some cases a different realm can be used. This may be
useful, for instance, when the home realm is reachable only via useful, for instance, when the home realm is reachable only via
intermediate proxies. intermediate proxies.
Such usage may prevent interoperability unless the parties involved Such usage may prevent interoperability unless the parties involved
have a mutual agreement that the usage is allowed. In particular, have a mutual agreement that the usage is allowed. In particular,
NAIs MUST NOT use a different realm than the home realm unless the NAIs MUST NOT use a different realm than the home realm unless the
sender has explicit knowledge that (a) the specified other realm is sender has explicit knowledge that (a) the specified other realm is
available and (b) the other realm supports such usage. The sender available and (b) the other realm supports such usage. The sender
may determine the fulfillment of these conditions through a database, may determine the fulfillment of these conditions through a database,
dynamic discovery, or other means not specified here. Note that the dynamic discovery, or other means not specified here. Note that the
first condition is affected by roaming, as the availability of the first condition is affected by roaming, as the availability of the
other realm may depend on the user's location or the desired other realm may depend on the user's location or the desired
application. application.
The use of the home realm MUST be the default unless otherwise The use of the home realm MUST be the default unless otherwise
configured. configured.
2.11.1. Historical Practices 3.3.1. Historical Practices
Some systems have historically used NAI modifications with multiple Some systems have historically used NAI modifications with multiple
"prefix" and "suffix" decorations to perform explicit routing through "prefix" and "suffix" decorations to perform explicit routing through
multiple proxies inside of a AAA network. This practice is NOT multiple proxies inside of a AAA network. This practice is NOT
RECOMMENDED for the following reasons: RECOMMENDED for the following reasons:
* Using explicit routing paths is fragile, and is unresponsive to * Using explicit routing paths is fragile, and is unresponsive to
changes in the network due to servers going up or down, or to changes in the network due to servers going up or down, or to
changing business relationships. changing business relationships.
skipping to change at page 17, line 6 skipping to change at page 18, line 26
meets all requirements at all intermediate proxies. meets all requirements at all intermediate proxies.
* Leveraging the DNS name system for realm names establishes * Leveraging the DNS name system for realm names establishes
a globally unique name space for realms. a globally unique name space for realms.
In summary, network practices and capabilities have changed In summary, network practices and capabilities have changed
significantly since NAIs were first overloaded to define AAA routes significantly since NAIs were first overloaded to define AAA routes
through a network. While explicit path routing was once useful, the through a network. While explicit path routing was once useful, the
time has come for better methods to be used. time has come for better methods to be used.
2.12. Examples 3.4. Examples
Examples of valid Network Access Identifiers include the following: Examples of valid Network Access Identifiers include the following:
bob bob
joe@example.com joe@example.com
fred@foo-9.example.com fred@foo-9.example.com
jack@3rd.depts.example.com jack@3rd.depts.example.com
fred.smith@example.com fred.smith@example.com
fred_smith@example.com fred_smith@example.com
fred$@example.com fred$@example.com
fred=?#$&*+-/^smith@example.com fred=?#$&*+-/^smith@example.com
nancy@eng.example.net nancy@eng.example.net
eng.example.net!nancy@example.net eng.example.net!nancy@example.net
eng%nancy@example.net eng%nancy@example.net
@privatecorp.example.net @privatecorp.example.net
\(user\)@example.net \(user\)@example.net
An additional valid NAI is the following, given as a hex string, as
this document can only contain ASCII characters.
626f 6240 ceb4 cebf ceba ceb9 cebc ceae 2e63 6f6d
Examples of invalid Network Access Identifiers include the following: Examples of invalid Network Access Identifiers include the following:
fred@example fred@example
fred@example_9.com fred@example_9.com
fred@example.net@example.net fred@example.net@example.net
fred.@example.net fred.@example.net
eng:nancy@example.net eng:nancy@example.net
eng;nancy@example.net eng;nancy@example.net
(user)@example.net (user)@example.net
<nancy>@example.net <nancy>@example.net
One example given in [RFC4282] is still permitted by the ABNF, but it One example given in [RFC4282] is still permitted by the ABNF, but it
is NOT RECOMMMENDED because of the use of the ToAscii function to is NOT RECOMMMENDED because of the use of the ToAscii function to
create an ASCII encoding from what is now a valid UTF-8 string. create an ASCII encoding from what is now a valid UTF-8 string.
alice@xn--tmonesimerkki-bfbb.example.net alice@xn--tmonesimerkki-bfbb.example.net
3. Security Considerations 4. Security Considerations
Since an NAI reveals the home affiliation of a user, it may assist an Since an NAI reveals the home affiliation of a user, it may assist an
attacker in further probing the username space. Typically, this attacker in further probing the username space. Typically, this
problem is of most concern in protocols that transmit the username in problem is of most concern in protocols that transmit the username in
clear-text across the Internet, such as in RADIUS, described in clear-text across the Internet, such as in RADIUS, described in
[RFC2865] and [RFC2866]. In order to prevent snooping of the [RFC2865] and [RFC2866]. In order to prevent snooping of the
username, protocols may use confidentiality services provided by username, protocols may use confidentiality services provided by
protocols transporting them, such as RADIUS protected by IPsec protocols transporting them, such as RADIUS protected by IPsec
[RFC3579] or Diameter protected by TLS [RFC3588]. [RFC3579] or Diameter protected by TLS [RFC3588].
skipping to change at page 18, line 16 skipping to change at page 19, line 40
in the NAI, by omitting it. As discussed in Section 2.4, this is in the NAI, by omitting it. As discussed in Section 2.4, this is
possible only when NAIs are used together with a separate possible only when NAIs are used together with a separate
authentication method that can transfer the username in a secure authentication method that can transfer the username in a secure
manner. In some cases, application-specific privacy mechanism have manner. In some cases, application-specific privacy mechanism have
also been used with NAIs. For instance, some EAP methods apply also been used with NAIs. For instance, some EAP methods apply
method-specific pseudonyms in the username part of the NAI [RFC3748]. method-specific pseudonyms in the username part of the NAI [RFC3748].
While neither of these approaches can protect the realm part, their While neither of these approaches can protect the realm part, their
advantage over transport protection is that privacy of the username advantage over transport protection is that privacy of the username
is protected, even through intermediate nodes such as NASes. is protected, even through intermediate nodes such as NASes.
4. IANA Considerations 5. IANA Considerations
In order to avoid creating any new administrative procedures, In order to avoid creating any new administrative procedures,
administration of the NAI realm namespace piggybacks on the administration of the NAI realm namespace piggybacks on the
administration of the DNS namespace. administration of the DNS namespace.
NAI realm names are required to be unique, and the rights to use a NAI realm names are required to be unique, and the rights to use a
given NAI realm for roaming purposes are obtained coincident with given NAI realm for roaming purposes are obtained coincident with
acquiring the rights to use a particular Fully Qualified Domain Name acquiring the rights to use a particular Fully Qualified Domain Name
(FQDN). Those wishing to use an NAI realm name should first acquire (FQDN). Those wishing to use an NAI realm name should first acquire
the rights to use the corresponding FQDN. Using an NAI realm without the rights to use the corresponding FQDN. Using an NAI realm without
skipping to change at page 18, line 42 skipping to change at page 20, line 18
[RFC3588] supports the use of DNS for location of authentication [RFC3588] supports the use of DNS for location of authentication
servers, existing RADIUS implementations typically use proxy servers, existing RADIUS implementations typically use proxy
configuration files in order to locate authentication servers within configuration files in order to locate authentication servers within
a domain and perform authentication routing. The implementations a domain and perform authentication routing. The implementations
described in [RFC2194] did not use DNS for location of the described in [RFC2194] did not use DNS for location of the
authentication server within a domain. Similarly, existing authentication server within a domain. Similarly, existing
implementations have not found a need for dynamic routing protocols implementations have not found a need for dynamic routing protocols
or propagation of global routing information. Note also that there or propagation of global routing information. Note also that there
is no requirement that the NAI represent a valid email address. is no requirement that the NAI represent a valid email address.
5. References 6. References
5.1. Normative References 6.1. Normative References
[RFC2119] [RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March, 1997. Levels", RFC 2119, March, 1997.
[RFC3629] [RFC3629]
Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63,
RFC 3629, November 2003. RFC 3629, November 2003.
[RFC5198] [RFC5198]
Klensin J., and Padlipsky M., "Unicode Format for Network Klensin J., and Padlipsky M., "Unicode Format for Network
Interchange", RFC 5198, March 2008 Interchange", RFC 5198, March 2008
[RFC5234] [RFC5234]
Crocker, D. and P. Overell, "Augmented BNF for Syntax Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 5234, January 2008. Specifications: ABNF", RFC 5234, January 2008.
[RFC5890] [RFC5890]
Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing
Domain Names in Applications (IDNA)", RFC 5890 Domain Names in Applications (IDNA)", RFC 5890, August 2010
5.2. Informative References [RFC6365]
Hoffman, P., and Klensin, J., "Terminology Used in
Internationalization in the IETF", RFC 6365, September 2011
6.2. Informative References
[RFC2194] [RFC2194]
Aboba, B., Lu, J., Alsop, J., Ding, J., and W. Wang, "Review of Aboba, B., Lu, J., Alsop, J., Ding, J., and W. Wang, "Review of
Roaming Implementations", RFC 2194, September 1997. Roaming Implementations", RFC 2194, September 1997.
[RFC2341] [RFC2341]
Valencia, A., Littlewood, M., and T. Kolar, "Cisco Layer Two Valencia, A., Littlewood, M., and T. Kolar, "Cisco Layer Two
Forwarding (Protocol) "L2F"", RFC 2341, May 1998. Forwarding (Protocol) "L2F"", RFC 2341, May 1998.
[RFC2637] [RFC2637]
skipping to change at page 20, line 33 skipping to change at page 22, line 13
http://eduroam.org, "eduroam (EDUcational ROAMing)" http://eduroam.org, "eduroam (EDUcational ROAMing)"
[RFC5891] [RFC5891]
Klensin, J., "Internationalized Domain Names in Applications Klensin, J., "Internationalized Domain Names in Applications
(IDNA): Protocol", RFC 5891 (IDNA): Protocol", RFC 5891
[RFC6055] [RFC6055]
Thaler, D., et al, "IAB Thoughts on Encodings for Internationalized Thaler, D., et al, "IAB Thoughts on Encodings for Internationalized
Domain Names", RFC 6055, February 2011. Domain Names", RFC 6055, February 2011.
[CODEPOINTS]
Sullivan, A., et al, "Principles for Unicode Code Point Inclusion
in Labels in the DNS", draft-iab-dns-zone-codepoint-pples, work in
progress.
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. 36 change blocks. 
98 lines changed or deleted 193 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/