draft-ietf-radext-nai-12.txt   draft-ietf-radext-nai-13.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-12.txt> <draft-ietf-radext-nai-13.txt>
3 December 2014 4 December 2014
The Network Access Identifier The Network Access Identifier
draft-ietf-radext-nai-12 draft-ietf-radext-nai-13
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 identifier 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
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 June 03, 2015. This Internet-Draft will expire on June 04, 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 30 skipping to change at page 3, line 30
2.6.1. Issues with the Normalization Process .......... 15 2.6.1. Issues with the Normalization Process .......... 15
2.7. Use in Other Protocols .............................. 16 2.7. Use in Other Protocols .............................. 16
2.8. Using the NAI format for other identifiers .......... 17 2.8. Using the NAI format for other identifiers .......... 17
3. Routing inside of AAA Systems ............................ 18 3. Routing inside of AAA Systems ............................ 18
3.1. Compatibility with Email Usernames .................. 19 3.1. Compatibility with Email Usernames .................. 19
3.2. Compatibility with DNS .............................. 19 3.2. Compatibility with DNS .............................. 19
3.3. Realm Construction .................................. 20 3.3. Realm Construction .................................. 20
3.3.1. Historical Practices ........................... 20 3.3.1. Historical Practices ........................... 20
3.4. Examples ............................................ 21 3.4. Examples ............................................ 21
4. Security Considerations .................................. 22 4. Security Considerations .................................. 22
4.1. Correlation of Identities over Time and Protocols ... 22 4.1. Correlation of Identities over Time and Protocols ... 23
4.2. Multiple Identifiers ................................ 23 4.2. Multiple Identifiers ................................ 23
5. Administration of Names .................................. 24 5. Administration of Names .................................. 24
6. IANA Considerations ...................................... 24 6. IANA Considerations ...................................... 24
7. References ............................................... 24 7. References ............................................... 25
7.1. Normative References ................................ 24 7.1. Normative References ................................ 25
7.2. Informative References .............................. 25 7.2. Informative References .............................. 25
Appendix A - Changes from RFC4282 ............................ 28 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. other applications.
skipping to change at page 5, line 16 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. Protocols that re-use the same credential or
so long as privacy issues are dealt with. The alternative is to have the same identifier format can benefit from this management
protocol-specific identifiers, which increases cost to both the user simplicity. The alternative is to have protocol-specific credentials
and the administrator. or identifier formats, which increases cost to both the user and the
administrator.
There are privacy implications to using one identifier across There are privacy implications to using one identifier across
multiple protocols. See Section 2.7 and Section 4 for further multiple protocols. See Section 2.7 and Section 4 for further
discussion of this topic. 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 format. This adoption will
will decrease work required to leverage identification and decrease work required to leverage identification and authentication
authentication in other protocols. It will also decrease the in other protocols. It will also decrease the complexity of non-AAA
complexity of non-AAA systems for end users and administrators. systems for end users and administrators.
We note that this document only suggest that the NAI be used, but We note that this document only suggests that the NAI format be used,
does not require such use. Many protocols already define their own but does not require such use. Many protocols already define their
identifier formats. Some of these are incompatible with the NAI, own identifier formats. Some of these are incompatible with the NAI,
while others allow the NAI in addition to non-NAI identifiers. The while others allow the NAI in addition to non-NAI identifiers. The
definition of the NAI in this document has no requirements on definition of the NAI in this document has no requirements on
protocol specifications, implementations, or deployments. protocol specifications, implementations, or deployments.
However, we suggest that using one standard identifier format is However, this document suggests that using one standard identifier
preferable to using multiple incompatible identifier formats. Where format is preferable to using multiple incompatible identifier
identifiers need to be used in new protocols and/or specifications, formats. Where identifiers need to be used in new protocols and/or
it is RECOMMENDED that the format of the NAI be used. That is, the specifications, it is RECOMMENDED that the format of the NAI be used.
interpretation of the identifier is context-specific, while the That is, the interpretation of the identifier is context-specific,
format of the identifier remains the same. These issues are while the format of the identifier remains the same. These issues
discussed in more detail in Section 2.8, below. are discussed in more detail in Section 2.8, below.
The recommendation for a standard identifier format is not a The recommendation for a standard identifier format is not a
recommendation that each user have one universal identifier. In recommendation that each user have one universal identifier. In
contrast, this document allows for the use of multiple identifiers, contrast, this document allows for the use of multiple identifiers,
and recommends the use of anonymous identifiers where those and recommends the use of anonymous identifiers where those
identifiers are publicly visible. 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.
skipping to change at page 8, line 19 skipping to change at page 8, line 19
Providers are involved in roaming consortia. 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
Many protocols include authentication capabilities, including format. Many protocols include authentication capabilities,
defining their own identifier formats. These identifiers can then including defining their own identifier formats. These identifiers
end up being transported in AAA protocols, so that the originating can then end up being transported in AAA protocols, so that the
protocols can leverage AAA for user authentication. There is originating protocols can leverage AAA for user authentication.
therefore a need for a definition of a user identifier which can be There is therefore a need for a definition of a user identifier which
used in multiple protocols. can be used in multiple protocols.
While we define the NAI here, we recognize that existing protocols While we define the NAI here, we recognize that existing protocols
and deployments do not always use it. AAA systems MUST therefore be and deployments do not always use it. AAA systems MUST therefore be
able to handle user identifiers which are not in the NAI format. The able to handle user identifiers which are not in the NAI format. The
process by which that is done is outside of the scope of this process by which that is done is outside of the scope of this
document. document.
Non-AAA systems MAY accept user identifiers in forms other than the Non-AAA systems can accept user identifiers in forms other than the
NAI. This specification does not forbid that practice. It only NAI. This specification does not forbid that practice. It only
codifies the format and interpretation of the NAI. We cannot expect codifies the format and interpretation of the NAI. We cannot expect
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 format implifies protocols requiring Using a common identifier format implifies protocols requiring
authentication, as they no longer need to specify protocol-specific authentication, as they no longer need to specify protocol-specific
format for user identifiers. It increases security, as it multiple format for user identifiers. It increases security, as it multiple
identifier formats allow attackers to make contradictory claims identifier formats allow attackers to make contradictory claims
without being detected (see Section 4.2 for further discussion of without being detected (see Section 4.2 for further discussion of
this topic). It simplifies deployments, as a user can have one this topic). It simplifies deployments, as a user can have one
identifier in multiple contexts, which allows them to be uniquely identifier in multiple contexts, which allows them to be uniquely
identified, so long as that identifier is itself kept private. identified, so long as that identifier is itself protected against
access.
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 Punycode [RFC3492] encoding form as described in [RFC5891] There
problems with this approach: are a number of 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) conflicts with the Extensible Authentication Protocol (EAP)
defined in [RFC3748], and RADIUS, which are both 8-bit clean, and defined in [RFC3748], and RADIUS, which are both 8-bit clean, and
which both recommend the 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
skipping to change at page 10, line 5 skipping to change at page 10, line 6
scripts. scripts.
* No Authentication, Authorization, and Accounting (AAA) * No Authentication, Authorization, and Accounting (AAA)
client, proxy, or server has implemented any of the requirements client, proxy, or server has implemented any of the requirements
in [RFC4282] Section 2.4, among other sections. in [RFC4282] Section 2.4, among other sections.
With international roaming growing in popularity, it is important for With international roaming growing in popularity, it is important for
these issues to be corrected in order to provide robust and inter- these issues to be corrected in order to provide robust and inter-
operable network services. operable network services.
Furthermore, this document was motivated by a desire to codify
existing practice related to the use of the NAI format and to
encourage widespread use of the format.
2. NAI Definition 2. NAI Definition
2.1. UTF-8 Syntax and Normalization 2.1. UTF-8 Syntax and Normalization
UTF-8 characters can be defined in terms of octets using the UTF-8 characters can be defined in terms of octets using the
following ABNF [RFC5234], taken from [RFC3629]: following ABNF [RFC5234], taken from [RFC3629]:
UTF8-xtra-char = UTF8-2 / UTF8-3 / UTF8-4 UTF8-xtra-char = UTF8-2 / UTF8-3 / UTF8-4
UTF8-2 = %xC2-DF UTF8-tail UTF8-2 = %xC2-DF UTF8-tail
skipping to change at page 10, line 37 skipping to change at page 10, line 42
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] and section 2.6 of this specification for a discussion See [RFC5198] and section 2.6 of this specification for a discussion
of normalization. Strings which are not in Normal Form Composed (NFC) of normalization. Strings which are not in Normal Form Composed (NFC)
are not valid NAIs and SHOULD NOT be treated as such. are not valid NAIs and SHOULD NOT be treated as such.
Implementations which expect to receive a NAI, but which instead Implementations which expect to receive a NAI, but which instead
receive non-normalised (but otherwise valid) UTF-8 strings instead receive non-normalised (but otherwise valid) UTF-8 strings instead
SHOULD attempt to create a local version of the NAI, which is SHOULD attempt to create a local version of the NAI, which is
normalized from the input identifier. This local version can then be normalized from the input identifier. This local version can then be
used for local processing. used for local processing. This local version of the identifier MUST
NOT be used outside of the local context.
Where protocols carry identifiers which are expected to be Where protocols carry identifiers which are expected to be
transported over an AAA protocol, it is RECOMMENDED that the transported over an AAA protocol, it is RECOMMENDED that the
identifiers be in NAI format. Where the identifiers are not in the identifiers be in NAI format. Where the identifiers are not in the
NAI format, it is up to the AAA systems to discover this, and to NAI format, it is up to the AAA systems to discover this, and to
process them. This document does not suggest how that is done. process them. This document does not suggest how that is done.
However, existing practice indicates that it is possible. However, existing practice indicates that it is possible.
We expect that with wider use of internationalized domain names, We expect that with wider use of internationalized domain names,
existing practices will be inadequate. We therefore define the NAI, existing practices will be inadequate. We therefore define the NAI,
which is a user identifier that can correctly deal with which is a user identifier format that can correctly deal with
internationalized identifiers. internationalized identifiers.
2.2. Formal Syntax 2.2. Formal Syntax
The grammar for the NAI is given below, described in Augmented The grammar for the NAI is given below, described in Augmented
Backus-Naur Form (ABNF) as documented in [RFC5234]. Backus-Naur Form (ABNF) as documented in [RFC5234].
nai = utf8-username nai = utf8-username
nai =/ "@" utf8-realm nai =/ "@" utf8-realm
nai =/ utf8-username "@" utf8-realm nai =/ utf8-username "@" utf8-realm
skipping to change at page 12, line 41 skipping to change at page 12, line 46
may be used as "firstname.lastname", or it may be entirely digits, or 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 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 reason) for any other domain to interpret the utf8-username field as
having any meaning whatsoever. 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 including a fixed username part is
determine whether the username is intended to uniquely identify a ambiguous as to whether or not the NAI refers to a single user.
single user. However, current practice is to use the username However, current practice is to use the username "anonymous" instead
"anonymous" instead of omitting the username part. This behavior is 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 The most common use-case of such behavior is with TLS-based EAP
methods such as TTLS [RFC5281]. Those methods allow for an "outer" methods such as TTLS [RFC5281]. Those methods allow for an "outer"
identifier, which is typically an anonymous "@realm". This outer identifier, which is typically an anonymous "@realm". This outer
identifier allows the authentication request to be routed from a identifier allows the authentication request to be routed from a
visited domain to a home domain. At the same time, user privacy is visited domain to a home domain. At the same time, user privacy is
preserved. The protocol provides for an "inner" authentication preserved. The protocol provides for an "inner" authentication
exchange, in which a full identifier is used to authenticate a user. exchange, in which a full identifier is used to authenticate a user.
That scenario offers the best of both worlds. An anonymous NAI can That scenario offers the best of both worlds. An anonymous NAI can
skipping to change at page 13, line 38 skipping to change at page 13, line 42
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 authentication conversation can proceed. As a result,
authentication routing is impossible unless the realm portion is authentication routing is impossible unless the realm portion is
available, and in a well-known format. 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 [RFC5890].
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 realm portion in an NAI MUST match the ABNF in this specification as
as well as the requirements specified in [RFC5891]. In practice, well as the requirements specified in [RFC5891]. In practice, these
these requirements consist of the following item: requirements consist of the following item:
* Realms MUST be of the form that can be registered as a * Realms MUST be of the form that can be registered as a
Fully Qualified Domain Name (FQDN) within the DNS. Fully Qualified Domain Name (FQDN) within the DNS.
This list is significantly shorter and simpler than the list in This list is significantly shorter and simpler than the list in
Section 2.4 of [RFC4282]. The form suggested in [RFC4282] depended Section 2.4 of [RFC4282]. The form suggested in [RFC4282] depended
on intermediate nodes performing canonicalizations based on on intermediate nodes performing canonicalizations based on
insufficient information, which meant that the form was not insufficient information, which meant that the form was not
canonical. canonical.
skipping to change at page 16, line 25 skipping to change at page 16, line 28
realm. If no match is found, the original form of the NAI SHOULD be realm. If no match is found, the original form of the NAI SHOULD be
used in all subsequent processing. used in all subsequent processing.
The AAA server may also convert realms to punycode, and perform all The AAA server may also convert realms to punycode, and perform all
realm comparisons on the resulting punycode strings. This conversion realm comparisons on the resulting punycode strings. This conversion
follows the recommendations above, but may have different operational follows the recommendations above, but may have different operational
effects and failure modes. effects and failure modes.
2.7. Use in Other Protocols 2.7. Use in Other Protocols
As noted earlier, the NAI MAY be used in other, non-AAA protocols. As noted earlier, the NAI format can be used in other, non-AAA
It is RECOMMENDED that the definition given here be used unchanged. protocols. It is RECOMMENDED that the definition given here be used
Using other definitions for user identifiers may hinder unchanged. Using other definitions for user identifiers may hinder
interoperability, along with the users ability to authenticate interoperability, along with the users ability to authenticate
successfully. It is RECOMMENDED that protocols requiring the use of successfully. It is RECOMMENDED that protocols requiring the use of
a user identifier reference this specification, and suggest that the a user identifier use the NAI format.
use of an NAI is RECOMMENDED.
We cannot require other protocols to use the NAI for user We cannot require other protocols to use the NAI format for user
identifiers. Their needs are unknown, and unknowable. We simply identifiers. Their needs are unknown, and at this time unknowable.
suggest that interoperability and inter-domain authentication is This document suggests that interoperability and inter-domain
useful, and should be encouraged. authentication is useful, and should be encouraged.
Where a protocol is 8-bit clean, it can likely transport the NAI as- Where a protocol is 8-bit clean, it can likely transport the NAI as-
is, without further modification. is, without further modification.
Where a protocol is not 8-bit clean, it cannot transport the NAI as- Where a protocol is not 8-bit clean, it cannot transport the NAI as-
is. Instead, we presume that a protocol-specific transport layer is. Instead, we presume that a protocol-specific transport layer
takes care of encoding the NAI on input to the protocol, and decoding takes care of encoding the NAI on input to the protocol, and decoding
it when the NAI exits the protocol. The encoded or escaped version it when the NAI exits the protocol. The encoded or escaped version
of the NAI is not a valid NAI, and MUST NOT be presented to the AAA of the NAI is not a valid NAI, and MUST NOT be presented to the AAA
system. system.
skipping to change at page 17, line 41 skipping to change at page 17, line 43
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.
This format ensures that the identifier is globally unique, as it is This format as defiend by 3GPP ensures that the identifier is
based off of the "3gppnetwork.org" domain. It ensures that the globally unique, as it is based off of the "3gppnetwork.org" domain.
"realm" portion is specific to a particular home network (or It ensures that the "realm" portion is specific to a particular home
organization), via the "ims.mnc015.mcc234" prefix to the realm. network (or organization), via the "ims.mnc015.mcc234" prefix to the
Finally, it ensures that the "username" portion follows a well-known realm. Finally, it ensures that the "username" portion follows a
format. well-known format.
We suggest that the NAI format be used for all new specifications This document suggests that the NAI format be used for all new
and/or protocols where a user identifier is required. It is specifications and/or protocols where a user identifier is required.
RECOMMENDED that methods similar to that described above for 3GPP be
used to derive the identifier. It is RECOMMENDED that methods similar to that described above for
3GPP be used to derive the identifier.
3. Routing inside of AAA Systems 3. Routing inside of AAA Systems
Many AAA systems use the "utf8-realm" portion of the NAI to route Many AAA systems use the "utf8-realm" portion of the NAI to route
requests within a AAA proxy network. The semantics of this operation requests within a AAA proxy network. The semantics of this operation
involves a logical AAA routing table, where the "utf8-realm" portion involves a logical AAA routing table, where the "utf8-realm" portion
acts as a key, and the values stored in the table are one or more acts as a key, and the values stored in the table are one or more
"next hop" AAA servers. "next hop" AAA servers.
Intermediate nodes MUST use the "utf8-realm" portion of the NAI Intermediate nodes MUST use the "utf8-realm" portion of the NAI
skipping to change at page 19, line 25 skipping to change at page 19, line 27
form "user@realm". Please note that while the user portion of the form "user@realm". Please note that while the user portion of the
NAI is based on the BNF described in [RFC5198], it has been modified NAI is based on the BNF described in [RFC5198], it has been modified
for the purposes of Section 2.2. It does not permit quoted text for the purposes of Section 2.2. It does not permit quoted text
along with "folding" or "non-folding" whitespace that is commonly along with "folding" or "non-folding" whitespace that is commonly
used in email addresses. As such, the NAI is not necessarily used in email addresses. As such, the NAI is not necessarily
equivalent to usernames used in e-mail. equivalent to usernames used in e-mail.
However, it is a common practice to use email addresses as user However, it is a common practice to use email addresses as user
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], [RFC5890], and [RFC5891].
In contrast to [RFC4282] Section 2.5, we state that the In contrast to [RFC4282] Section 2.5, we state that the
internationalization requirements for NAIs and email addresses are internationalization requirements for NAIs and email addresses are
substantially similar. The NAI and email identifiers may be the substantially similar. The NAI and email identifiers may be the
same, and both need to be entered by the user and/or the operator same, and both need to be entered by the user and/or the operator
supplying network access to that user. There is therefore good supplying network access to that user. There is therefore good
reason for the internationalization requirements to be similar. reason for the internationalization requirements to be similar.
3.2. Compatibility with DNS 3.2. Compatibility with DNS
The "utf8-realm" portion of the NAI is intended to be compatible with The "utf8-realm" portion of the NAI is intended to be compatible with
Internationalized Domain Names (IDNs) [RFC5890]. As defined above, Internationalized Domain Names (IDNs) [RFC5890]. As defined above,
the "utf8-realm" portion as transported within an 8-bit clean the "utf8-realm" portion as transported within an 8-bit clean
protocol such as RADIUS and EAP can contain any valid UTF8 character. protocol such as RADIUS and EAP can contain any valid UTF8 character.
There is therefore no reason for a NAS to apply the ToAscii function There is therefore no reason for a NAS to convert the "utf8-realm"
to the "utf8-realm" portion of an NAI, prior to placing the NAI into portion of an NAI into Punycode encoding form [RFC3492] prior to
a RADIUS User-Name attribute. placing the NAI into a RADIUS User-Name attribute.
The NAI does not make a distinction between A-labels and U-labels, as The NAI does not make a distinction between A-labels and U-labels, as
those are terms specific to DNS. It is instead an IDNA-valid label, those are terms specific to DNS. It is instead an IDNA-valid label,
as per the first item in Section 2.3.2.1 of [RFC5890]. As noted in as per the first item in Section 2.3.2.1 of [RFC5890]. As noted in
that section, the term "IDNA-valid label" encompases both of the that section, the term "IDNA-valid label" encompases both of the
terms A-label and U-label. terms A-label and U-label.
When the realm portion of the NAI is used as the basis for name When the realm portion of the NAI is used as the basis for name
resolution, it may be necessary to convert internationalized realm resolution, it may be necessary to convert internationalized realm
names to ASCII using the ToASCII operation defined in [RFC5890]. As names to Punycode [RFC3492] encoding form as described in [RFC5891].
noted in [RFC6055] Section 2, resolver Application Programming As noted in [RFC6055] Section 2, resolver Application Programming
Interfaces (APIs) are not necessarily DNS-specific, so that the Interfaces (APIs) are not necessarily DNS-specific, so conversion to
ToASCII operation needs to be applied carefully: Punycode needs to be done carefully:
Applications which convert an IDN to A-label form before calling (for Applications which convert an IDN to A-label form before calling (for
example) getaddrinfo() will result in name resolution failures if the example) getaddrinfo() will result in name resolution failures if the
Punycode name is directly used in such protocols. Having libraries Punycode name is directly used in such protocols. Having libraries
or protocols to convert from A-labels to the encoding scheme defined or protocols to convert from A-labels to the encoding scheme defined
by the protocol (e.g., UTF-8) would require changes to APIs and/or by the protocol (e.g., UTF-8) would require changes to APIs and/or
servers, which IDNA was intended to avoid. servers, which IDNA was intended to avoid.
As a result, applications SHOULD NOT assume that non-ASCII names are As a result, applications SHOULD NOT assume that non-ASCII names are
resolvable using the public DNS and blindly convert them to A-labels resolvable using the public DNS and blindly convert them to A-labels
skipping to change at page 21, line 31 skipping to change at page 21, line 33
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.
* 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 manually managed explicit path routing was
time has come for better methods to be used. once useful, the time has come for better methods to be used.
Notwithstanding the above recommendations, we note that the above
practice is widely used for Diameter routing [RFC5729]. The routes
described there are managed automatically, from both credential
provisioning and routing updates. Those routes also exist within a
particular framework (typically 3G), where membership is controlled
and system behavior is standardized. There are no known issues with
using explicit routing in such an environment.
3.4. Examples 3.4. Examples
Examples of valid Network Access Identifiers include the following: Examples of valid Network Access Identifiers include the following:
bob bob
joe@example.com joe@example.com
fred@foo-9.example.com fred@foo-9.example.com
jack@3rd.depts.example.com jack@3rd.depts.example.com
fred.smith@example.com fred.smith@example.com
skipping to change at page 22, line 20 skipping to change at page 22, line 31
fred@example fred@example
fred@example_9.com fred@example_9.com
fred@example.net@example.net fred@example.net@example.net
fred.@example.net fred.@example.net
eng:nancy@example.net eng:nancy@example.net
eng;nancy@example.net eng;nancy@example.net
(user)@example.net (user)@example.net
<nancy>@example.net <nancy>@example.net
One example given in [RFC4282] is still permitted by the ABNF, but it One example given in [RFC4282] is still permitted by the ABNF, but it
is NOT RECOMMMENDED because of the use of the ToAscii function to is NOT RECOMMMENDED because of the use of the Punycode [RFC3492]
create an ASCII encoding from what is now a valid UTF-8 string. encoding form for what is now a valid UTF-8 string.
alice@xn--tmonesimerkki-bfbb.example.net alice@xn--tmonesimerkki-bfbb.example.net
4. Security Considerations 4. Security Considerations
Since an NAI reveals the home affiliation of a user, it may assist an Since an NAI reveals the home affiliation of a user, it may assist an
attacker in further probing the username space. Typically, this attacker in further probing the username space. Typically, this
problem is of most concern in protocols that transmit the username in problem is of most concern in protocols that transmit the username in
clear-text across the Internet, such as in RADIUS, described in clear-text across the Internet, such as in RADIUS, described in
[RFC2865] and [RFC2866]. In order to prevent snooping of the [RFC2865] and [RFC2866]. In order to prevent snooping of the
skipping to change at page 23, line 36 skipping to change at page 23, line 47
outer identifier, and "user@example.org" as an inner identifier. The outer identifier, and "user@example.org" as an inner identifier. The
authentication request will then be routed to "example.com", which authentication request will then be routed to "example.com", which
will likely be unable to authenticate "user@example.org". will likely be unable to authenticate "user@example.org".
Even worse, a misconfiguration of "example.com" means that it may in Even worse, a misconfiguration of "example.com" means that it may in
turn proxy the inner authentication request to the "example.org" turn proxy the inner authentication request to the "example.org"
domain. Such cross-domain authentication is highly problematic, and domain. Such cross-domain authentication is highly problematic, and
there are few good reasons to allow it. there are few good reasons to allow it.
It is therefore RECOMMENDED that systems which permit anonymous It is therefore RECOMMENDED that systems which permit anonymous
"outer" identifiers require that the both the "outer" and "inner" "outer" identifiers require that the "inner" domain be the same as,
identifiers use the same realm. An authentication request using or a sub-domain of the "outer" domain. An authentication request
different realms is a security violation, and the request SHOULD be using disparate realms is a security violation, and the request
rejected. SHOULD be rejected.
The situation gets worse when multiple protocols are involved. The The situation gets worse when multiple protocols are involved. The
TTLS protocol permits MS-CHAP [RFC2433] to be carried inside of the TTLS protocol permits MS-CHAP [RFC2433] to be carried inside of the
TLS tunnel. MS-CHAP defines its own identifier which is encapsulated TLS tunnel. MS-CHAP defines its own identifier which is encapsulated
inside of the MS-CHAP exchange. That identifier is not required to 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. 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 There is no way in practice to determine which character set was used
for that identifier. for that identifier.
The result is that the "outer" EAP Identity carried by TTLS is likely The result is that the "outer" EAP Identity carried by TTLS is likely
skipping to change at page 25, line 17 skipping to change at page 25, line 29
Interchange", RFC 5198, March 2008 Interchange", RFC 5198, March 2008
[RFC5234] [RFC5234]
Crocker, D. and P. Overell, "Augmented BNF for Syntax Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 5234, January 2008. Specifications: ABNF", RFC 5234, January 2008.
[RFC5890] [RFC5890]
Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing
Domain Names in Applications (IDNA)", RFC 5890, August 2010 Domain Names in Applications (IDNA)", RFC 5890, August 2010
[RFC5891]
Klensin, J., "Internationalized Domain Names in Applications
(IDNA): Protocol", RFC 5891, August 2010
[RFC6365] [RFC6365]
Hoffman, P., and Klensin, J., "Terminology Used in Hoffman, P., and Klensin, J., "Terminology Used in
Internationalization in the IETF", RFC 6365, September 2011 Internationalization in the IETF", RFC 6365, September 2011
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.
skipping to change at page 25, line 51 skipping to change at page 26, line 19
Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August
1999. 1999.
[RFC2865] [RFC2865]
Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2866] [RFC2866]
Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC3492]
Costello, A., "Punycode: A Bootstring encoding of Unicode for
Internationalized Domain Names in Applications (IDNA)", RFC 3492,
March 2003.
[RFC3579] [RFC3579]
Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In
User Service) Support For Extensible Authentication Protocol User Service) Support For Extensible Authentication Protocol
(EAP)", RFC 3579, September 2003. (EAP)", RFC 3579, September 2003.
[RFC3748] [RFC3748]
Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748,
June 2004. June 2004.
[RFC4282] [RFC4282]
Aboba, B. et al., "The Network Access Identifier", RFC 4282, Aboba, B. et al., "The Network Access Identifier", RFC 4282,
December 2005. December 2005.
[RFC4301] [RFC4301]
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]
Y. Abel, Ed., "Internationalized Email Headers", RFC 5335,
September 2008.
[EDUROAM]
http://eduroam.org, "eduroam (EDUcational ROAMing)"
[RFC5281] [RFC5281]
Funk, P., and Blake-Wilson, S., "Extensible Authentication Protocol Funk, P., and Blake-Wilson, S., "Extensible Authentication Protocol
Tunneled Transport Layer Security Authenticated Protocol Version 0 Tunneled Transport Layer Security Authenticated Protocol Version 0
(EAP-TTLSv0)", RFC 5281, August 2008/ (EAP-TTLSv0)", RFC 5281, August 2008/
[RFC5891] [RFC5335]
Klensin, J., "Internationalized Domain Names in Applications Y. Abel, Ed., "Internationalized Email Headers", RFC 5335,
(IDNA): Protocol", RFC 5891, August 2010 September 2008.
[RFC5729]
Korhohen, J. (Ed) et. al., "Clarifications on the Routing of
Diameter Requests Based on the Username and the Realm", RFC 5729,
December 2009
[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]
Sullivan, A., et al, "Principles for Unicode Code Point Inclusion Sullivan, A., et al, "Principles for Unicode Code Point Inclusion
in Labels in the DNS", RFC 6912, April 2013. in Labels in the DNS", RFC 6912, April 2013.
[EDUROAM]
http://eduroam.org, "eduroam (EDUcational ROAMing)"
[3GPP] [3GPP]
3GPP, "TS 23.003 Numbering, addressing, and Identification (Release 3GPP, "TS 23.003 Numbering, addressing, and Identification (Release
12)", July 2014, 12)", July 2014,
ftp://ftp.3gpp.org/Specs/archive/23_series/23.003/. ftp://ftp.3gpp.org/Specs/archive/23_series/23.003/.
Acknowledgments Acknowledgments
The initial text for this document was [RFC4282], which was then The initial text for this document was [RFC4282], which was then
heavily edited. The original authors of [RFC4282] were Bernard heavily edited. The original authors of [RFC4282] were Bernard
Aboba, Mark A. Beadles, Jari Arkko, and Pasi Eronen. Aboba, Mark A. Beadles, Jari Arkko, and Pasi Eronen.
 End of changes. 35 change blocks. 
92 lines changed or deleted 116 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/