draft-ietf-radext-nai-11.txt   draft-ietf-radext-nai-12.txt 
RADEXT Working Group DeKok, Alan RADEXT Working Group DeKok, Alan
INTERNET-DRAFT FreeRADIUS INTERNET-DRAFT FreeRADIUS
Obsoletes: 4282 Obsoletes: 4282
Category: Standards Track Category: Standards Track
<draft-ietf-radext-nai-11.txt> <draft-ietf-radext-nai-12.txt>
26 November 2014 3 December 2014
The Network Access Identifier The Network Access Identifier
draft-ietf-radext-nai-11 draft-ietf-radext-nai-12
Abstract Abstract
In order to provide inter-domain authentication services, it is In order to provide inter-domain authentication services, it is
necessary to have a standardized method that domains can use to necessary to have a standardized method that domains can use to
identify each other's users. This document defines the syntax for identify each other's users. This document defines the syntax for
the Network Access Identifier (NAI), the user identity submitted by the Network Access Identifier (NAI), the user identifier submitted by
the client prior to accessing resources. This document is a revised the client prior to accessing resources. This document is a revised
version of RFC 4282, which addresses issues with international version of RFC 4282, which addresses issues with international
character sets, as well as a number of other corrections to the character sets, as well as a number of other corrections to the
previous document. 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.
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 May 29, 2015. This Internet-Draft will expire on June 03, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 9 skipping to change at page 3, line 9
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
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 ......................................... 6
1.2. Requirements Language ............................... 6 1.2. Requirements Language ............................... 7
1.3. Purpose ............................................. 7 1.3. Purpose ............................................. 8
1.4. Motivation .......................................... 8 1.4. Motivation .......................................... 9
2. NAI Definition ........................................... 9 2. NAI Definition ........................................... 10
2.1. UTF-8 Syntax and Normalization ...................... 9 2.1. UTF-8 Syntax and Normalization ...................... 10
2.2. Formal Syntax ....................................... 10 2.2. Formal Syntax ....................................... 11
2.3. NAI Length Considerations ........................... 10 2.3. NAI Length Considerations ........................... 11
2.4. Support for Username Privacy ........................ 11 2.4. Support for Username Privacy ........................ 12
2.5. International Character Sets ........................ 11 2.5. International Character Sets ........................ 13
2.6. The Normalization Process ........................... 12 2.6. The Normalization Process ........................... 14
2.6.1. Issues with the Normalization Process .......... 13 2.6.1. Issues with the Normalization Process .......... 15
2.7. Use in Other Protocols .............................. 14 2.7. Use in Other Protocols .............................. 16
2.8. Using the NAI format for other identifiers .......... 15 2.8. Using the NAI format for other identifiers .......... 17
3. Routing inside of AAA Systems ............................ 16 3. Routing inside of AAA Systems ............................ 18
3.1. Compatibility with Email Usernames .................. 17 3.1. Compatibility with Email Usernames .................. 19
3.2. Compatibility with DNS .............................. 17 3.2. Compatibility with DNS .............................. 19
3.3. Realm Construction .................................. 18 3.3. Realm Construction .................................. 20
3.3.1. Historical Practices ........................... 19 3.3.1. Historical Practices ........................... 20
3.4. Examples ............................................ 19 3.4. Examples ............................................ 21
4. Security Considerations .................................. 20 4. Security Considerations .................................. 22
5. Administration of Names .................................. 21 4.1. Correlation of Identities over Time and Protocols ... 22
6. IANA Considerations ...................................... 21 4.2. Multiple Identifiers ................................ 23
7. References ............................................... 21 5. Administration of Names .................................. 24
7.1. Normative References ................................ 21 6. IANA Considerations ...................................... 24
7.2. Informative References .............................. 22 7. References ............................................... 24
Appendix A - Changes from RFC4282 ............................ 25 7.1. Normative References ................................ 24
7.2. Informative References .............................. 25
Appendix A - Changes from RFC4282 ............................ 28
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 authentication, or "roaming the general category of inter-domain authentication, 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.
By "inter-domain authentication", we mean situations where a user has
authentication credentials at one "home" domain, but is able to
present them at a second "visited" domain to access certain services
at the visited domain. The two domains generally have a pre-existing
relationship, so that the credentials can be passed from the visited
domain to the home domain for verification. The home domain
typically responds with a permit / deny response, which may also
include authorization parameters which the visited domain is expected
to enforce on the user.
That is, the "roaming" scenario involves a user visiting, or
"roaming" to a non-home domain, and requesting the use of services at
that visted domain.
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
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.
* National ISPs wishing to combine their operations with those of * Telecommunications companies who wish to combine their
one or more ISPs in another nation to offer more comprehensive operations with those of one or more companies in another areas or
dialup service in a group of countries or on a continent. nations, in order to offer more comprehensive network access
service in areas where there is no native service. e.g. In
another country.
* Wireless LAN hotspots providing service to one or more ISPs. * Wireless LAN hotspots providing service to one or more ISPs.
* 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].
skipping to change at page 4, line 46 skipping to change at page 5, line 16
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 in non-AAA systems. of defining an identifier which could be used in non-AAA systems.
Some non-AAA systems defined identifiers which were compatible with Some non-AAA systems defined identifiers which were compatible with
the NAI, and deployments used the NAI. This process simplified the the NAI, and deployments used the NAI. This process simplified the
management of credentials, by re-using the same credential in management of credentials, by re-using the same credential in
multiple situations. We suggest that this re-use is good practice. multiple situations. We suggest that this re-use is good practice,
The alternative is to have protocol-specific identifiers, which so long as privacy issues are dealt with. The alternative is to have
increases cost to both user and administrator. protocol-specific identifiers, which increases cost to both the user
and the administrator.
There are privacy implications to using one identifier across
multiple protocols. See Section 2.7 and Section 4 for further
discussion of this topic.
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 non-AAA systems for end users and administrators. complexity of non-AAA systems for end users and administrators.
skipping to change at page 5, line 26 skipping to change at page 5, line 49
protocol specifications, implementations, or deployments. protocol specifications, implementations, or deployments.
However, we suggest that using one standard identifier format is However, we suggest that using one standard identifier format is
preferable to using multiple incompatible identifier formats. Where preferable to using multiple incompatible identifier formats. Where
identifiers need to be used in new protocols and/or specifications, identifiers need to be used in new protocols and/or specifications,
it is RECOMMENDED that the format of the NAI be used. That is, the it is RECOMMENDED that the format of the NAI be used. That is, the
interpretation of the identifier is context-specific, while the interpretation of the identifier is context-specific, while the
format of the identifier remains the same. These issues are format of the identifier remains the same. These issues are
discussed in more detail in Section 2.8, below. discussed in more detail in Section 2.8, below.
The recommendation for a standard identifier format is not a
recommendation that each user have one universal identifier. In
contrast, this document allows for the use of multiple identifiers,
and recommends the use of anonymous identifiers where those
identifiers are publicly visible.
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
Text which is either in non-UTF-8, or in non-normalized form. The Text which is either in non-UTF-8, or in non-normalized form. The
character set, encoding, and locale are (in general) unknown to character set, encoding, and locale are (in general) unknown to
Authentication, Authorization, and Accounting (AAA) network Authentication, Authorization, and Accounting (AAA) network
protocols. The client which "knows" the locale may have a protocols. The client which "knows" the locale may have a
different concept of this text than other AAA entities, which do different concept of this text than other AAA entities, which do
not know the same locale. not know the same locale.
Network Access Identifier Network Access Identifier
The Network Access Identifier (NAI) is the user identity submitted The Network Access Identifier (NAI) is a common format for user
by a client during authentication. The purpose of the NAI is to identifiers submitted by a client during authentication. The
identify the user as well as to assist in the routing of the purpose of the NAI is to allow a user to be associated with an
authentication request. Please note that the NAI may not account name, as well as to assist in the routing of the
necessarily be the same as the user's email address or the user authentication request across multiple domains. Please note that
identity submitted in an application layer authentication. the NAI may not necessarily be the same as the user's email
address or the user identifier submitted in an application layer
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 7, line 8 skipping to change at page 8, line 8
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",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
1.3. Purpose 1.3. Purpose
As described in [RFC2194], there are a number of providers offering As described in [RFC2194], there are a number of providers offering
network access services, and the number of Internet Service Providers network access services, and essentially all Internet Service
involved in roaming consortia is increasing rapidly. Providers are involved in roaming consortia.
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.
skipping to change at page 7, line 46 skipping to change at page 8, line 46
to change existing protocols or practices. We can, however, suggest to change existing protocols or practices. We can, however, suggest
that using a consistent form for a user identifier is of a benefit to that using a consistent form for a user identifier is of a benefit to
the community. the community.
We note that this document does not make any protocol-specific We note that this document does not make any protocol-specific
definitions for an identifier format, and it does not make changes to definitions for an identifier format, and it does not make changes to
any existing protocol. Instead, it defines a protocol-independent any existing protocol. Instead, it defines a protocol-independent
form for the NAI. It is hoped that the NAI is a user identifier form for the NAI. It is hoped that the NAI is a user identifier
which can be used in multiple protocols. which can be used in multiple protocols.
Using a common identifier simplifies deployments, as there is no need Using a common identifier format implifies protocols requiring
to maintain multiple identifiers for one user. It simplifies authentication, as they no longer need to specify protocol-specific
protocols requiring authentication, as they no longer need to specify format for user identifiers. It increases security, as it multiple
protocol-specific format for user identifiers. It increases identifier formats allow attackers to make contradictory claims
security, as it multiple identifiers allow attackers to make without being detected (see Section 4.2 for further discussion of
contradictory claims without being detected. this topic). It simplifies deployments, as a user can have one
identifier in multiple contexts, which allows them to be uniquely
identified, so long as that identifier is itself kept private.
In short, having a standard is better than having no standard at all. 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
English letters, digits, and the hyphen "-" character. The intent English letters, digits, and the hyphen "-" character. The intent
appears to have been to encode, compare, and transport realms with appears to have been to encode, compare, and transport realms with
the ToASCII operation defined in [RFC5890]. There are a number of the ToASCII operation defined in [RFC5890]. There are a number of
problems with this approach: problems with this approach:
* The [RFC4282] ABNF is not aligned with internationalization of DNS. * The [RFC4282] ABNF is not aligned with internationalization of DNS.
* The requirement in [RFC4282] Section 2.1 that realms are ASCII * The requirement in [RFC4282] Section 2.1 that realms are ASCII
conflicts with the Extensible Authentication Protocol (EAP) and conflicts with the Extensible Authentication Protocol (EAP)
RADIUS, which are both 8-bit clean, and which both recommend the defined in [RFC3748], and RADIUS, which are both 8-bit clean, and
use of UTF-8 for identitifiers. which both recommend the use of UTF-8 for identitifiers.
* [RFC4282] Section 2.4 required mappings that are * [RFC4282] Section 2.4 required mappings that are
language-specific, and which are nearly impossible for language-specific, and which are nearly impossible for
intermediate nodes to perform correctly without information about intermediate nodes to perform correctly without information about
that language. that language.
* [RFC4282] Section 2.4 requires normalization of user names, * [RFC4282] Section 2.4 requires normalization of user names,
which may conflict with local system or administrative which may conflict with local system or administrative
requirements. requirements.
skipping to change at page 10, line 15 skipping to change at page 11, line 15
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
utf8-username = dot-string utf8-username = dot-string
dot-string = string
dot-string =/ dot-string "." string dot-string = string *("." string)
string = utf8-atext string = 1*utf8-atext
string =/ string utf8-atext
utf8-atext = ALPHA / DIGIT / utf8-atext = ALPHA / DIGIT /
"!" / "#" / "!" / "#" /
"$" / "%" / "$" / "%" /
"&" / "'" / "&" / "'" /
"*" / "+" / "*" / "+" /
"-" / "/" / "-" / "/" /
"=" / "?" / "=" / "?" /
"^" / "_" / "^" / "_" /
"`" / "{" / "`" / "{" /
skipping to change at page 11, line 6 skipping to change at page 12, line 5
* NAI octet length constraints may impose a more severe constraint * NAI octet length constraints may impose a more severe constraint
on the number of UTF-8 characters. on the number of UTF-8 characters.
* NAIs are often transported in the User-Name attribute of the * 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.
* NAIs can also be transported in the User-Name attribute of * NAIs can also be transported in the User-Name attribute of
Diameter [RFC6733], which supports content lengths up to 2^24 - 9 Diameter [RFC6733], 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 * NAIs may be transported in other protocols. Each protocol
can have its own limitations on maximum NAI length. can have its own limitations on maximum NAI length.
The above criteria should permit the widest use, and widest possible The above criteria should permit the widest use, and widest possible
inter-operability of the NAI. 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. home domain for that realm.
That is, the only domain which is capable of interpreting the meaning
of the utf8-username portion of the NAI is the home domain. Any
third-party domains cannot form any conclusions about the
utf8-username, and cannot decode it into sub-fields. For example, it
may be used as "firstname.lastname", or it may be entirely digits, or
it may be a random hex identifier. There is simply no way (and no
reason) for any other domain to interpret the utf8-username field as
having any meaning whatsoever.
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. However, current practice is to use the username single user. However, current practice is to use the username
"anonymous" instead of omitting the username part. This behavior is "anonymous" instead of omitting the username part. This behavior is
also permitted. also permitted.
The most common use-case of such behavior is with TLS-based EAP
methods such as TTLS [RFC5281]. Those methods allow for an "outer"
identifier, which is typically an anonymous "@realm". This outer
identifier allows the authentication request to be routed from a
visited domain to a home domain. At the same time, user privacy is
preserved. The protocol provides for an "inner" authentication
exchange, in which a full identifier is used to authenticate a user.
That scenario offers the best of both worlds. An anonymous NAI can
be used to route authentication to the home domain, and the home
domain has sufficient information to identify and authenticate users.
However, some protocols do not support authenticate methods which
allow for "inner" and "outer" exchanges. Those protocols are limited
to using an identifier which is publicly visible. It is therefore
RECOMMENDED that such protocols use ephemeral identifiers. We
recognize that this practice is not currently used, and will likely
be difficult to implement.
Similarly to the anonymous user, there may be situations where
portions of the realm are sensitive. For those situations, it is
RECOMMENDED that the sensitive portion of the realm also be omitted.
e.g. To use "@example.com" instead of "@sensitive.example.com", or
"anonymous@sensitive.example.com". The home domain is authoritative
for users in all subdomains, and can (if necessary) route the
authentication request to the appropriate subsystem within the home
domain.
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,
portion is typically required in order for the authentication authentication routing is impossible unless the realm portion is
exchange to be routed to the appropriate server. available, and in a well-known format.
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
skipping to change at page 15, line 34 skipping to change at page 17, line 22
be used as the standard format for user identifiers. This section be used as the standard format for user identifiers. This section
discusses that use in more detail. discusses that use in more detail.
It is often useful to create new identifiers for use in specific It is often useful to create new identifiers for use in specific
contexts. These identifiers may have a number of different contexts. These identifiers may have a number of different
properties, most of which are unimportant to this document. For our properties, most of which are unimportant to this document. For our
purposes, we are interested in identifiers which need to be in a purposes, we are interested in identifiers which need to be in a
well-known format, and to have namespaces. The NAI format fits these well-known format, and to have namespaces. The NAI format fits these
requirements. requirements.
One example of such use is the "private user identity", which is One example of such use is the "private user identity", which is an
defined by the 3rd-Generation Partnership Project (3GPP). That identifier defined by the 3rd-Generation Partnership Project (3GPP).
identity is used to uniquely identify the user to the network. The That identifier is used to uniquely identify the user to the network.
identity is used for authorization, authentication, accounting, The identifier is used for authorization, authentication, accounting,
administation, etc. The private user identity is globally unique, administation, etc. The "private user identity" is globally unique,
and is defined by the home network operator. The format of the and is defined by the home network operator. The format of the
identity is explicitly the NAI, as stated by Section 13.3 of [3GPP]: identifier is explicitly the NAI, as stated by Section 13.3 of
[3GPP]:
The private user identity shall take the form of an NAI, and shall The private user identity shall take the form of an NAI, and shall
have the form username@realm as specified in clause 2.1 of IETF have the form username@realm as specified in clause 2.1 of IETF
RFC 4282 RFC 4282
For 3GPP, the "username" portion is a unique identifier which is For 3GPP, the "username" portion is a unique identifier which is
derived from device-specific information. The "realm" portion is derived from device-specific information. The "realm" portion is
composed of information about the home network, followed by the base composed of information about the home network, followed by the base
string "3gppnetwork.org". e.g. string "3gppnetwork.org". e.g.
234150999999999@ims.mnc015.mcc234.3gppnetwork.org. 234150999999999@ims.mnc015.mcc234.3gppnetwork.org.
skipping to change at page 16, line 29 skipping to change at page 18, line 19
involves a logical AAA routing table, where the "utf8-realm" portion involves a logical AAA routing table, where the "utf8-realm" portion
acts as a key, and the values stored in the table are one or more acts as a key, and the values stored in the table are one or more
"next hop" AAA servers. "next hop" AAA servers.
Intermediate nodes MUST use the "utf8-realm" portion of the NAI Intermediate nodes MUST use the "utf8-realm" portion of the NAI
without modification to perform this lookup. As noted earlier, without modification to perform this lookup. As noted earlier,
intermediate nodes may not have access to the same locale information intermediate nodes may not have access to the same locale information
as the system which injected the NAI into the AAA routing systems. as the system which injected the NAI into the AAA routing systems.
Therefore, almost all "case insensitive" comparisons can be wrong. Therefore, almost all "case insensitive" comparisons can be wrong.
Where the "utf8-realm" is entirely ASCII, current AAA systems Where the "utf8-realm" is entirely ASCII, current AAA systems
sometimes perform case-insensitive matching on realms. This practice sometimes perform case-insensitive matching on realms. This method
MAY be continued, as it has been shown to work in practice. MAY be continued, as it has been shown to work in practice.
We also note that many existing non-AAA systems have user identifiers We also note that many existing non-AAA systems have user identifiers
which are similar in format to the NAI, but which are not compliant which are similar in format to the NAI, but which are not compliant
with this specification. For example, they may use non-NFC form, or with this specification. For example, they may use non-NFC form, or
they may have multiple "@" characters in the user identifier. they may have multiple "@" characters in the user identifier.
Intermediate nodes SHOULD normalize non-NFC identifiers to NFC, prior Intermediate nodes SHOULD normalize non-NFC identifiers to NFC, prior
to 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.
skipping to change at page 21, line 10 skipping to change at page 22, line 47
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.1. Correlation of Identities over Time and Protocols
The recommendations in Section 2.7 and Section 2.8 for using the NAI
in other protocols has implications for privacy. Any attacker who is
capable of observing traffic containing the NAI can track the user,
and correlate his activity across time and across multiple protocols.
The authentication credentials therefore SHOULD be transported over
channels which permit private communications, or multiple identifiers
SHOULD be used, so that user tracking is impossible.
It is RECOMMENDED that user privacy be enhanced by configuring
multiple identifiers for one user. These identifiers can be changed
over time, in order to make user tracking more difficult for a
malicous observer. However, we recognise that provisioning and
management of the identifiers may be difficult in to do in practice,
which is likely why multiple identifiers are rarely used today.
4.2. Multiple Identifiers
Section 1.3 states that multiple identifier formats allow attackers
to make contradictory claims without being detected. This statement
deserves further discussion.
Section 2.4 discussed "inner" and "outer" identifiers in the context
of TTLS [RFC5281]. A close reading of that specification shows there
is no requirement that the inner and outer identifiers be in any way
related. That is, it is perfectly valid to use "@example.com" for an
outer identifier, and "user@example.org" as an inner identifier. The
authentication request will then be routed to "example.com", which
will likely be unable to authenticate "user@example.org".
Even worse, a misconfiguration of "example.com" means that it may in
turn proxy the inner authentication request to the "example.org"
domain. Such cross-domain authentication is highly problematic, and
there are few good reasons to allow it.
It is therefore RECOMMENDED that systems which permit anonymous
"outer" identifiers require that the both the "outer" and "inner"
identifiers use the same realm. An authentication request using
different realms is a security violation, and the request SHOULD be
rejected.
The situation gets worse when multiple protocols are involved. The
TTLS protocol permits MS-CHAP [RFC2433] to be carried inside of the
TLS tunnel. MS-CHAP defines its own identifier which is encapsulated
inside of the MS-CHAP exchange. That identifier is not required to
be UTF-8, and in practice, can be one of many unknown character sets.
There is no way in practice to determine which character set was used
for that identifier.
The result is that the "outer" EAP Identity carried by TTLS is likely
to not even share the same character set as the "inner" identifier
used by MS-CHAP. The two identifiers are entirely independent, and
fundamentally incomparable.
Such protocol design is NOT RECOMMENDED.
5. Administration of Names 5. Administration of Names
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
skipping to change at page 22, line 32 skipping to change at page 25, line 31
7.2. Informative References 7.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.
[RFC2433]
Zorn G., and Cobb, S. "Microsoft PPP CHAP Extensions", RFC 2433,
October 1998.
[RFC2637] [RFC2637]
Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W., and G. Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W., and G.
Zorn, "Point-to-Point Tunneling Protocol", RFC 2637, July 1999. Zorn, "Point-to-Point Tunneling Protocol", RFC 2637, July 1999.
[RFC2661] [RFC2661]
Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B.
Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August
1999. 1999.
[RFC2865] [RFC2865]
skipping to change at page 23, line 25 skipping to change at page 26, line 27
Kent, S. and S. Keo, "Security Architecture for the Internet Kent, S. and S. Keo, "Security Architecture for the Internet
Protocol", RFC 4301, December 2005. Protocol", RFC 4301, December 2005.
[RFC5335] [RFC5335]
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)"
[RFC5281]
Funk, P., and Blake-Wilson, S., "Extensible Authentication Protocol
Tunneled Transport Layer Security Authenticated Protocol Version 0
(EAP-TTLSv0)", RFC 5281, August 2008/
[RFC5891] [RFC5891]
Klensin, J., "Internationalized Domain Names in Applications Klensin, J., "Internationalized Domain Names in Applications
(IDNA): Protocol", RFC 5891 (IDNA): Protocol", RFC 5891, August 2010
[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.
[RFC6733] [RFC6733]
V. Fajardo, Ed., et al, "Diameter Base Protocol", RFC 6733, October V. Fajardo, Ed., et al, "Diameter Base Protocol", RFC 6733, October
2012. 2012.
[RFC6912] [RFC6912]
 End of changes. 25 change blocks. 
73 lines changed or deleted 211 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/