draft-ietf-radext-nai-00.txt   draft-ietf-radext-nai-01.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-00.txt> <draft-ietf-radext-nai-01.txt>
22 December 2012 8 January 2013
The Network Access Identifier The Network Access Identifier
draft-ietf-radext-nai-00 draft-ietf-radext-nai-01
Abstract Abstract
In order to provide roaming services, it is necessary to have a In order to provide inter-domain authentication services, it is
standardized method for identifying users. This document defines the necessary to have a standardized method that domains can use to
syntax for the Network Access Identifier (NAI), the user identity identify each others users. This document defines the syntax for the
submitted by the client during network authentication. "Roaming" may Network Access Identifier (NAI), the user identity submitted by the
be loosely defined as the ability to use any one of multiple Internet client prior to accessing network resources. This document is a
Service Providers (ISPs), while maintaining a formal, customer-vendor revised version of RFC 4282 [RFC4282], which addresses issues with
relationship with only one. Examples of where roaming capabilities international character sets, as well as a number of other
might be required include ISP "confederations" and ISP-provided corrections to the previous document.
corporate network access support. This document is a revised version
of RFC 4282 [RFC4282], which addresses issues with international
character sets, as well as a number of other corrections to the
previous document.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 49 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 February 28, 2013. This Internet-Draft will expire on July 8, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 17 skipping to change at page 3, line 17
Appendix A - Changes from RFC4282 ............................ 3 Appendix A - Changes from RFC4282 ............................ 3
1. Introduction ............................................. 4 1. Introduction ............................................. 4
1.1. Terminology ......................................... 4 1.1. Terminology ......................................... 4
1.2. Requirements Language ............................... 5 1.2. Requirements Language ............................... 5
1.3. Purpose ............................................. 6 1.3. Purpose ............................................. 6
1.4. Motivation .......................................... 6 1.4. Motivation .......................................... 6
2. NAI Definition ........................................... 7 2. NAI Definition ........................................... 7
2.1. UTF-8 Syntax and Normalization ...................... 7 2.1. UTF-8 Syntax and Normalization ...................... 7
2.2. Formal Syntax ....................................... 7 2.2. Formal Syntax ....................................... 7
2.3. NAI Length Considerations ........................... 8 2.3. NAI Length Considerations ........................... 8
2.4. Support for Username Privacy ........................ 8 2.4. Support for Username Privacy ........................ 9
2.5. International Character Sets ........................ 9 2.5. International Character Sets ........................ 9
2.6. The Normalization Process ........................... 10 2.6. The Normalization Process ........................... 10
2.7. Routing inside of AAA Systems ....................... 10 2.7. Use in Other Protocols .............................. 11
2.8. Compatibility with Email Usernames .................. 11 2.8. Routing inside of AAA Systems ....................... 11
2.9. Compatibility with DNS .............................. 11 2.9. Compatibility with Email Usernames .................. 12
2.10. Realm Construction ................................. 12 2.10. Compatibility with DNS ............................. 12
2.10.1. Historical Practices .......................... 13 2.11. Realm Construction ................................. 13
2.11. Examples ........................................... 13 2.11.1. Historical Practices .......................... 14
3. Security Considerations .................................. 14 2.12. Examples ........................................... 15
4. IANA Considerations ...................................... 15 3. Security Considerations .................................. 15
5. References ............................................... 15 4. IANA Considerations ...................................... 16
5.1. Normative References ................................ 15 5. References ............................................... 16
5.2. Informative References .............................. 16 5.1. Normative References ................................ 16
Appendix A - Changes from RFC4282 ............................ 18 5.2. Informative References .............................. 17
Appendix A - Changes from RFC4282 ............................ 19
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 "roaming capability" for network access, the general category of inter-domain authentiction, or "roaming
including dialup Internet users, Virtual Private Network (VPN) usage, capability" for network access, including dialup Internet users,
wireless LAN authentication, and other applications. Interested Virtual Private Network (VPN) usage, wireless LAN authentication, and
parties have included the following: other applications. Interested parties have included the following:
o 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
with those of other regional providers to offer dialup service with those of other regional providers to offer dialup service
over a wider area. over a wider area.
o National ISPs wishing to combine their operations with those of * National ISPs wishing to combine their operations with those of
one or more ISPs in another nation to offer more comprehensive one or more ISPs in another nation to offer more comprehensive
dialup service in a group of countries or on a continent. dialup service in a group of countries or on a continent.
o Wireless LAN hotspots providing service to one or more ISPs. * Wireless LAN hotspots providing service to one or more ISPs.
o Businesses desiring to offer their employees a comprehensive * Businesses desiring to offer their employees a comprehensive
package of dialup services on a global basis. Those services may package of dialup services on a global basis. Those services may
include Internet access as well as secure access to corporate include Internet access as well as secure access to corporate
intranets via a VPN, enabled by tunneling protocols such as the intranets via a VPN, enabled by tunneling protocols such as the
Point-to-Point Tunneling Protocol (PPTP) [RFC2637], the Layer 2 Point-to-Point Tunneling Protocol (PPTP) [RFC2637], the Layer 2
Forwarding (L2F) protocol [RFC2341], the Layer 2 Tunneling Forwarding (L2F) protocol [RFC2341], the Layer 2 Tunneling
Protocol (L2TP) [RFC2661], and the IPsec tunnel mode [RFC4301]. Protocol (L2TP) [RFC2661], and the IPsec tunnel mode [RFC4301].
In order to enhance the interoperability of roaming services, it is * Other protocols which are interested in leveraging the users
credentials in order to take advantage of an existing
authentication framework.
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].
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
Text which is either in non-UTF-8, or in non-normalized form. The
character set, encoding, and locale are (in general) unknown to
Authentication, Authorization, and Accounting (AAA) network
protocols.
Network Access Identifier Network Access Identifier
The Network Access Identifier (NAI) is the user identity submitted The Network Access Identifier (NAI) is the user identity submitted
by the client during network access authentication. In roaming, by the client during network access authentication. The purpose
the purpose of the NAI is to identify the user as well as to of the NAI is to identify the user as well as to assist in the
assist in the routing of the authentication request. Please note routing of the authentication request. Please note that the NAI
that the NAI may not necessarily be the same as the user's email may not necessarily be the same as the user's email address or the
address or the user identity submitted in an application layer user identity submitted in an application layer authentication.
authentication.
Network Access Server Network Access Server
The Network Access Server (NAS) is the device that clients connect The Network Access Server (NAS) is the device that clients connect
to in order to get access to the network. In PPTP terminology, to in order to get access to the network. In PPTP terminology,
this is referred to as the PPTP Access Concentrator (PAC), and in this is referred to as the PPTP Access Concentrator (PAC), and in
L2TP terminology, it is referred to as the L2TP Access L2TP terminology, it is referred to as the L2TP Access
Concentrator (LAC). In IEEE 802.11, it is referred to as an Concentrator (LAC). In IEEE 802.11, it is referred to as an
Access Point. Access Point.
skipping to change at page 6, line 19 skipping to change at page 6, line 19
involved in roaming consortia is increasing rapidly. involved in roaming consortia is increasing rapidly.
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.
Many protocols include authentication capabilities. The
authentication credentials supplied in those protocols can end up
being transported in AAA protocols. It is therefore useful to define
a representation of the user credentials which can be shared across
multiple protocols.
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
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:
o The [RFC4282] ABNF is not aligned with internationalization of DNS.
o The requirement in Section 2.1 that realms are ASCII conflicts o 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 identities.
o Section 2.4 required mappings that are language-specific, o 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.
o Section 2.4 requires normalization of user names, which o Section 2.4 requires normalization of user names, which
skipping to change at page 7, line 35 skipping to change at page 7, 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; implementations of See [RFC5198] for a discussion of normalization; the use of Normal
this specification MUST use the Normal Form Composed (NFC) for NAIs. Form Composed (NFC) is RECOMMENDED.
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 8, line 31 skipping to change at page 8, line 40
label = utf8-rtext *(ldh-str) label = utf8-rtext *(ldh-str)
ldh-str = *( utf8-rtext / "-" ) utf8-rtext ldh-str = *( utf8-rtext / "-" ) utf8-rtext
utf8-rtext = ALPHA / DIGIT / UTF8-xtra-char utf8-rtext = ALPHA / DIGIT / UTF8-xtra-char
2.3. NAI Length Considerations 2.3. NAI Length Considerations
Devices handling NAIs MUST support an NAI length of at least 72 Devices handling NAIs MUST support an NAI length of at least 72
octets. Devices SHOULD support an NAI length of 253 octets. octets. Devices SHOULD support an NAI length of 253 octets.
However, the following implementation issues should be considered: However, the following implementation issues should be considered:
o NAIs are often transported in the User-Name attribute of the * NAI octet length constraints may impose a more severe constraint
on the number of UTF-8 characters.
* NAIs are often transported in the User-Name attribute of the
Remote Authentication Dial-In User Service (RADIUS) protocol. Remote Authentication Dial-In User Service (RADIUS) protocol.
Unfortunately, RFC 2865 [RFC2865], Section 5.1, states that "the Unfortunately, RFC 2865 [RFC2865], Section 5.1, states that "the
ability to handle at least 63 octets is recommended." As a ability to handle at least 63 octets is recommended." As a
result, it may not be possible to transfer NAIs beyond 63 octets result, it may not be possible to transfer NAIs beyond 63 octets
through all devices. In addition, since only a single User-Name through all devices. In addition, since only a single User-Name
attribute may be included in a RADIUS message and the maximum attribute may be included in a RADIUS message and the maximum
attribute length is 253 octets; RADIUS is unable to support NAI attribute length is 253 octets; RADIUS is unable to support NAI
lengths beyond 253 octets. lengths beyond 253 octets.
o NAIs can also be transported in the User-Name attribute of * NAIs can also be transported in the User-Name attribute of
Diameter [RFC3588], which supports content lengths up to 2^24 - 9 Diameter [RFC3588], which supports content lengths up to 2^24 - 9
octets. As a result, NAIs processed only by Diameter nodes can be octets. As a result, NAIs processed only by Diameter nodes can be
very long. However, an NAI transported over Diameter may very long. However, an NAI transported over Diameter may
eventually be translated to RADIUS, in which case the above eventually be translated to RADIUS, in which case the above
limitations will apply. limitations will apply.
* NAIs may be transported in other protocols. Each protocol
can have its own limitations on maximum NAI length.
The above criteria should permit the widest use, and widest possible
inter-operability of the NAI.
2.4. Support for Username Privacy 2.4. Support for Username Privacy
Interpretation of the username part of the NAI depends on the realm Interpretation of the username part of the NAI depends on the realm
in question. Therefore, the utf8-username portion SHOULD be treated in question. Therefore, the utf8-username portion SHOULD be treated
as opaque data when processed by nodes that are not a part of the as opaque data when processed by nodes that are not a part of the
authoritative domain (in the sense of Section 4) for that realm. authoritative domain (in the sense of Section 4) for that realm.
In some situations, NAIs are used together with a separate In some situations, NAIs are used together with a separate
authentication method that can transfer the username part in a more authentication method that can transfer the username part in a more
secure manner to increase privacy. In this case, NAIs MAY be secure manner to increase privacy. In this case, NAIs MAY be
provided in an abbreviated form by omitting the username part. provided in an abbreviated form by omitting the username part.
Omitting the username part is RECOMMENDED over using a fixed username Omitting the username part is RECOMMENDED over using a fixed username
part, such as "anonymous", since it provides an unambiguous way to part, such as "anonymous", since it provides an unambiguous way to
determine whether the username is intended to uniquely identify a determine whether the username is intended to uniquely identify a
single user. single user. However, current practice is to use the username
"anonymous" instead of omitting the username part. This behavior is
also permitted.
For roaming purposes, it is typically necessary to locate the For roaming purposes, it is typically necessary to locate the
appropriate backend authentication server for the given NAI before appropriate backend authentication server for the given NAI before
the authentication conversation can proceed. As a result, the realm the authentication conversation can proceed. As a result, the realm
portion is typically required in order for the authentication portion is typically required in order for the authentication
exchange to be routed to the appropriate server. exchange to be routed to the appropriate server.
2.5. International Character Sets 2.5. International Character Sets
This specification allows both international usernames and realms. This specification allows both international usernames and realms.
International usernames are based on the use of Unicode characters, International usernames are based on the use of Unicode characters,
encoded as UTF-8. Internationalization of the realm portion of the encoded as UTF-8. Internationalization of the realm portion of the
NAI is based on "Internationalized Email Headers" [RFC5335]. NAI is based on "Internationalized Email Headers" [RFC5335].
In order to ensure a canonical representation, characters of the In order to ensure a canonical representation, characters of the
username portion in an NAI MUST match the ABNF in this specification username portion in an NAI MUST match the ABNF in this specification
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:
o Realms MUST be of the form that can be registered as a o Realms MUST be of the form that can be registered as a
Fully Qualified Domain Name (FQDN) within the DNS name system. 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. This document instead suggests (Section 2.10) that the
realm owner provide a canonical form of the realm, and that all realm owner provide a canonical form of the realm, and that all
intermediate nodes use that form without modification. 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.
In general, the above requirement means following the requirements as In general, the above requirement means following the requirements
specified in [RFC5891]. However, that document is in flux at the specified in [RFC5891].
time of this writing, and the issues with [RFC4282] mandate a timely
update to it.
2.6. The Normalization Process 2.6. The Normalization Process
All normalization MUST be performed by end systems that take "local" Conversion to Unicode as well as normalization is expected to be
text as input. That is, text that is in an encoding other than performed by end systems that take "local" text as input. Other AAA
UTF-8, or that has locale-specific variations. In a network access systems such as proxies do not have access to locale and character
setting, such systems are typically the client (e.g. EAP supplicant) set information that is available to end systems. Therefore, they
and the Authentication, Authorization, and Accounting (AAA) server. are typically incapable of converting local input to Unicode.
All other AAA systems (proxies, etc.) MUST NOT perform
normalization. These other systems do not have access to locale and
character set information that is available to end systems.
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 is performed by edge systems, prior to the NAIs
entering the AAA system. Inside of an AAA system, NAIs are sent over entering the AAA system. Inside of an AAA system, NAIs are sent over
the wire in their canonical form, and this canonical form is used for the wire in their canonical form, and this canonical form is used for
all NAI and/or realm comparisons. all NAI and/or realm comparisons.
In contrast to the comments in [RFC4282] Section 2.4, we expect AAA Copying of localized text into fields that can subsequently be placed
systems to perform NAI comparisons, matching, and AAA routing based into the RADIUS User-Name attribute is problematic. This practice
on the NAI as it is received. This specification provides a can result in a AAA proxy encountering non-UTF8 characters within
canonical representation, ensures that intermediate systems such as what it expects to be an NAI. An example of this requirement is
AAA proxies do not need to perform translations, and can be expected [RFC3579] Section 2.1, which states:
to work through systems that are unaware of international character
sets. the NAS MUST copy the contents of the Type-Data field of the
EAP-Response/Identity received from the peer into the User-Name
attribute
As a result, AAA proxies expect the contents of the EAP-
Response/Identity sent by an EAP supplicant to consist of UTF-8
characters, not localized text. Using localized text in AAA username
or identity fields means that realm routing becomes difficult or
impossible.
In contrast to [RFC4282] Section 2.4, we expect AAA systems to
perform NAI comparisons, matching, and AAA routing based on the NAI
as it is received. This specification provides a canonical
representation, ensures that intermediate systems such as AAA proxies
do not need to perform translations, and can be expected to work
through systems that are unaware of international character sets.
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.
EAP supplicants MUST normalize user names that get placed in the EAP- 2.7. Use in Other Protocols
Response/Identity field. They MUST NOT copy localized text into that
field. This normalization SHOULD be performed once, and then cached
for subsequent use.
2.7. Routing inside of AAA Systems As noted earlier, the NAI MAY be used in other, non-AAA protocols.
It is RECOMMENDED that the definition given here be used unchanged.
Using other definitions for user identifiers may hinder
interoperability, along with the users ability to authenticate
successfully. It is RECOMMENDED that protocols requiring the use of
a user identifier reference this specification, and suggest that the
use of an NAI is RECOMMENDED.
Many systems require that the "utf8-realm" portion of the NAI be used We cannot require other protocols to use the NAI for user
to route requests within a AAA proxy network. The semantics of this identifiers. Their needs are unknown, and unknowable. We simply
operation involves a logical AAA routing table, where the suggest that interoperability and inter-domain authentication is
"utf8-realm" portion acts as a key, and the values stored in the useful, and should be encouraged.
table are one or more "next hop" AAA servers.
Where a protocol is not 8-bit clean, it MUST NOT affect the
definition or handling of the NAI. That is, if a protocol escapes
the '.' character as "%2E", then the protocol may have an identifier
transported as "fred@example%2Ecom", whereas the NAI for that user is
"fred@example.com". Any comparison, validation, or use of the NAI
MUST be done on its un-escaped (i.e. utf8-clean) form.
2.8. Routing inside of AAA Systems
Many AAA systems use the "utf8-realm" portion of the NAI to route
requests within a AAA proxy network. The semantics of this operation
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
"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. Comparisons between the
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. The routing table SHOULD be done as a byte-for-byte equality test. The
"utf8-realm" provisioned in the logical AAA routing table SHOULD be "utf8-realm" provisioned in the logical AAA routing table SHOULD be
provisioned prior to the proxy receiving any AAA traffic, and SHOULD provisioned prior to the proxy receiving any AAA traffic, and SHOULD
be supplied by the "next hop" system that also supplies the other be supplied by the "next hop" system that also supplies the other
information about the next hop. information about the next hop.
This "next hop" information may be IP address, port, RADIUS shared This "next hop" information may be any of, or all of, the following
secret, TLS certificates, or a DNS host name. information: IP address; port; RADIUS shared secret; TLS certificate;
DNS host name; or instruction to use dyanmic DNS discovery (i.e. look
up a record in the "utf8-realm" domain).
2.8. Compatibility with Email Usernames It is RECOMMENDED to use the entirety of the "utf8-realm" for the
routing decisions. However, systems MAY use a portion of the
"utf8-realm" portion, so long as that portion is a valid
"utf8-realm", and that portion is handled as above. For example,
routing "fred@example.com" to a "com" destination is forbidden,
because "com" is not a valid "utf8-realm". However, routing
"fred@sales.example.com" to the "example.com" destination is
permissible.
2.9. 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 NAI form "user@realm". Please note that while the user portion of the
is based on the BNF described in [RFC5198], it has been modified for NAI is based on the BNF described in [RFC5198], it has been modified
the purposes of Section 2.2. It does not permit quoted text along for the purposes of Section 2.2. It does not permit quoted text
with "folding" or "non-folding" whitespace that is commonly used in along with "folding" or "non-folding" whitespace that is commonly
email addresses. As such, the NAI is not necessarily equivalent to used in email addresses. As such, the NAI is not necessarily
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
identifiers in AAA systems. The ABNF in Section 2.2 is defined to be identifiers in AAA systems. The ABNF in Section 2.2 is defined to be
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 the comments in [RFC4282] Section 2.5, we state that In contrast to [RFC4282] Section 2.5, we state that the
the internationalization requirements for NAIs and email addresses internationalization requirements for NAIs and email addresses are
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.9. Compatibility with DNS 2.10. Compatibility with DNS
The "realm" portion of the NAI is intended to be compatible with The "utf8-realm" portion of the NAI is intended to be compatible with
domain names used in DNS systems. However, the "realm" portion Internationalized Domain Names [RFC5890]. As defined above, the
within AAA systems is intended to be a UTF-8 string, not an ASCII "utf8-realm" portion as transported within the RADIUS User-Name
string as with the DNS protocol. Therefore, AAA systems transporting attribute is composed of U-labels, not A-labels. There is therefore
NAIs in an AAA protocol MUST NOT encode the "utf8-realm" portion no reason for a NAS to apply the ToAscii function to the "utf8-realm"
using the ToAscii function. That function creates strings that may portion of an NAI, prior to placing the NAI into a RADIUS User-Name
be transported over DNS, and it is not appropriate for use within an attribute.
AAA protocol.
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
lookups within the DNS system, the ToASCII operation defined in resolution, it may be necessary to convert internationalized realm
[RFC5890] MAY be used to convert internationalized realm names to names to ASCII using the ToASCII operation defined in [RFC5890]. As
ASCII. This function is normally handled by a DNS resolver library noted in [RFC6055] Section 2, resolver Application Programming
on the local system. When this function is not handled by a DNS Interfaces (APIs) are not necessarily DNS-specific, so that the
resolver library, the AAA system MAY perform the ToAscii conversion ToASCII operation needs to be applied carefully:
itself, before passing the modified realm name to the DNS resolver
library. Applications which convert an IDN to A-label form before calling (for
example) getaddrinfo() will result in name resolution failures if the
Punycode name is directly used in such protocols. Having libraries
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
servers, which IDNA was intended to avoid.
As a result, applications SHOULD NOT assume that non-ASCII names are
resolved using the public DNS and blindly convert them to A-labels
without knowledge of what protocol will be selected by the name
resolution library.
There is, however, a problem with this approach. A AAA proxy may not There is, however, a problem with this approach. A AAA proxy may not
have sufficient information in order to perform the ToAscii have sufficient information in order to perform the ToAscii
conversion properly. We therefore RECOMMEND that only the owner of conversion properly. We therefore RECOMMEND that only the owner of
the realm perform the ToAscii conversion. We RECOMMEND that the the realm perform the ToAscii conversion. We RECOMMEND that the
owner of the realm pre-provision all proxies with the "utf8-realm" owner of the realm pre-provision all proxies with the "utf8-realm"
portion of the NAI, along with the value returned from passing the portion of the NAI, along with the value returned from passing the
"utf8-realm" to the ToAscii function. This key-value pair can then "utf8-realm" to the ToAscii function. This key-value pair can then
be placed into logical AAA routing table discussed above. Having be placed into the logical AAA routing table discussed above. Having
only one entity run the ToAscii function ensures that the result only one entity perform the ToAscii function ensures that the result
returned by that function are considered as canonical form by all returned by that function are considered as canonical by all other
other participants in a AAA network. participants in a AAA network.
The paragraph above does not negate all of the benefits of using DNS The paragraph above does not negate all of the benefits of using DNS
to automatically discover the location of a "next hop" AAA server. to automatically discover the location of a "next hop" AAA server.
Many AAA proxies require a business or legal relationship prior to Many AAA proxies require a business or legal relationship prior to
routing any traffic. This relationship can be leveraged to bootstrap routing any traffic. This relationship can be leveraged to bootstrap
the DNS information located in the logical AAA routing table. the DNS information located in the logical AAA routing table.
2.10. Realm Construction 2.11. Realm Construction
The home realm usually appears in the realm portion of the NAI, but The home realm usually appears in the "utf8-realm" portion of the
in some cases a different realm can be used. This may be useful, for NAI, but in some cases a different realm can be used. This may be
instance, when the home realm is reachable only via intermediate useful, for instance, when the home realm is reachable only via
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.10.1. Historical Practices 2.11.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:
o 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.
o There is no RADIUS routing protocol, meaning that routing paths * There is no RADIUS routing protocol, meaning that routing paths
have to be communicated "out of band" to all intermediate AAA have to be communicated "out of band" to all intermediate AAA
nodes, and also to all end-user systems (supplicants) expecting to nodes, and also to all end-user systems (supplicants) expecting to
obtain network access. obtain network access.
o Using explicit routing paths requires thousands, if not * Using explicit routing paths requires thousands, if not
millions of end-user systems to be updated with new path millions of end-user systems to be updated with new path
information when a AAA routing path changes. This adds huge information when a AAA routing path changes. This adds huge
expense for updates that would be better done at only a few AAA expense for updates that would be better done at only a few AAA
systems in the network. systems in the network.
o Manual updates to RADIUS paths are expensive, time-consuming, * Manual updates to RADIUS paths are expensive, time-consuming,
and prone to error. and prone to error.
o Re-writing of the User-Name in AAA servers means that it may not * Creating compatible formats for the NAI is difficult
match the EAP-Response/Identity fields. This mismatch may cause
the home AAA server to reject the request as being malformed.
o Creating compatible formats for the NAI is difficult
when locally-defined "prefixes" and "suffixes" conflict with when locally-defined "prefixes" and "suffixes" conflict with
similar practices elsewhere in the network. These conflicts mean similar practices elsewhere in the network. These conflicts mean
that connecting two networks may be impossible in some cases, as that connecting two networks may be impossible in some cases, as
there is no way for packets to be routed properly in a way that there is no way for packets to be routed properly in a way that
meets all requirements at all intermediate proxies. meets all requirements at all intermediate proxies.
o 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.11. Examples 2.12. 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
skipping to change at page 17, line 24 skipping to change at page 18, line 33
Y. Abel, Ed., "Internationalized Email Headers", RFC 5335, Y. Abel, Ed., "Internationalized Email Headers", RFC 5335,
September 2008. September 2008.
[EDUROAM] [EDUROAM]
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]
Thaler, D., et al, "IAB Thoughts on Encodings for Internationalized
Domain Names", RFC 6055, February 2011.
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
This document contains the following updates with respect to the This document contains the following updates with respect to the
previous NAI definition in RFC 4282 [RFC4282]: previous NAI definition in RFC 4282 [RFC4282]:
o The formal syntax in Section 2.1 has been updated to forbid * The formal syntax in Section 2.1 has been updated to forbid
non-UTF8 characters. e.g. characters with the "high bit" set. non-UTF8 characters. e.g. characters with the "high bit" set.
o The formal syntax in Section 2.1 has been updated to allow * The formal syntax in Section 2.1 has been updated to allow
UTF-8 in the "realm" portion of the NAI. UTF-8 in the "realm" portion of the NAI.
o The formal syntax in [RFC4282] Section 2.1 applied to the * The formal syntax in [RFC4282] Section 2.1 applied to the
NAI after it was "internationalized" via the ToAscii function. NAI after it was "internationalized" via the ToAscii function.
The contents of the NAI before it was "internationalized" were The contents of the NAI before it was "internationalized" were
left indeterminate. This document updates the formal syntax to left indeterminate. This document updates the formal syntax to
define an internationalized form of the NAI, and forbids the use define an internationalized form of the NAI, and forbids the use
of the ToAscii function for NAI "internationalization". of the ToAscii function for NAI "internationalization".
o The grammar for the user and realm portion is based on a o The grammar for the user and realm portion is based on a
combination combination
of the "nai" defined in [RFC4282] Section 2.1, and the "utf8-addr- of the "nai" defined in [RFC4282] Section 2.1, and the "utf8-addr-
spec" defined in [RFC5335] Section 4.4. spec" defined in [RFC5335] Section 4.4.
o All use of the ToAscii function has been moved to normal * All use of the ToAscii function has been moved to normal
requirements on DNS implementations when realms are used as the requirements on DNS implementations when realms are used as the
basis for DNS lookups. This involves no changes to the existing basis for DNS lookups. This involves no changes to the existing
DNS infrastructure. DNS infrastructure.
o The discussions on internationalized character sets in Section 2.4 * The discussions on internationalized character sets in Section 2.4
have been updated. The suggestion to use the ToAscii function for have been updated. The suggestion to use the ToAscii function for
realm comparisons has been removed. No AAA system implemented the realm comparisons has been removed. No AAA system implemented the
suggestion, so this change should have no operational impact. suggestion, so this change should have no operational impact.
o The section "Routing inside of AAA Systems" section is new in this o The section "Routing inside of AAA Systems" section is new in this
document. The concept of a "local AAA routing table" is also new, document. The concept of a "local AAA routing table" is also new,
although it accurately describes the functionality of wide-spread although it accurately describes the functionality of wide-spread
implementations. implementations.
o The "Compatibility with EMail Usernames" and "Compatibility * The "Compatibility with EMail Usernames" and "Compatibility
with DNS" sections have been revised and updated. We now note with DNS" sections have been revised and updated. We now note
that the ToAscii function is required to be used only when a realm that the ToAscii function is suggested to be used only when a
name is used for DNS lookups, and even then the function is only realm name is used for DNS lookups, and even then the function is
used by a DNS resolving library on the local system, and even then only used by a resolving API on the local system, and even then we
we recommend that only the home network perform this conversion. recommend that only the home network perform this conversion.
o The "Realm Construction" section has been updated to note * The "Realm Construction" section has been updated to note
that editing of the NAI is NOT RECOMMENDED. that editing of the NAI is NOT RECOMMENDED.
o The "Examples" section has been updated to remove the instance * The "Examples" section has been updated to remove the instance
of the IDN being converted to ASCII. This behavior is now of the IDN being converted to ASCII. This behavior is now
forbidden. forbidden.
Authors' Addresses Authors' Addresses
Alan DeKok Alan DeKok
The FreeRADIUS Server Project The FreeRADIUS Server Project
Email: aland@freeradius.org Email: aland@freeradius.org
 End of changes. 57 change blocks. 
142 lines changed or deleted 214 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/