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/