draft-ietf-radext-nai-05.txt		draft-ietf-radext-nai-06.txt
	Network 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-05.txt>		<draft-ietf-radext-nai-06.txt>
	6 November 2013		17 June 2014
	The Network Access Identifier		The Network Access Identifier
	draft-ietf-radext-nai-05		draft-ietf-radext-nai-06
	Abstract		Abstract
	In order to provide inter-domain authentication services, it is		In order to provide inter-domain authentication services, it is
	necessary to have a standardized method that domains can use to		necessary to have a standardized method that domains can use to
	identify each others users. This document defines the syntax for the		identify each other's users. This document defines the syntax for
	Network Access Identifier (NAI), the user identity submitted by the		the Network Access Identifier (NAI), the user identity submitted by
	client prior to accessing network resources. This document is a		the client prior to accessing network resources. This document is a
	revised version of RFC 4282 [RFC4282], which addresses issues with		revised version of RFC 4282, which addresses issues with
	international character sets, as well as a number of other		international character sets, as well as a number of other
	corrections to the previous document.		corrections to the previous document.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 45		skipping to change at page 1, line 45
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on May 6, 2014.		This Internet-Draft will expire on January 17, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 3, line 7		skipping to change at page 3, line 7
	modifications of such material outside the IETF Standards Process.		modifications of such material outside the IETF Standards Process.
	Without obtaining an adequate license from the person(s) controlling		Without obtaining an adequate license from the person(s) controlling
	the copyright in such materials, this document may not be modified		the copyright in such materials, this document may not be modified
	outside the IETF Standards Process, and derivative works of it may		outside the IETF Standards Process, and derivative works of it may
	not be created outside the IETF Standards Process, except to format		not be created outside the IETF Standards Process, except to format
	it for publication as an RFC or to translate it into languages other		it for publication as an RFC or to translate it into languages other
	than English.		than English.
	Table of Contents		Table of Contents
	3. ........................................................... 3
	Appendix A - Changes from RFC4282 ............................ 3		Appendix A - Changes from RFC4282 ............................ 3
	1. Introduction ............................................. 4		1. Introduction ............................................. 4
	1.1. Terminology ......................................... 5		1.1. Terminology ......................................... 5
	1.2. Requirements Language ............................... 6		1.2. Requirements Language ............................... 6
	1.3. Purpose ............................................. 7		1.3. Purpose ............................................. 7
	1.4. Motivation .......................................... 7		1.4. Motivation .......................................... 7
	2. NAI Definition ........................................... 8		2. NAI Definition ........................................... 8
	2.1. UTF-8 Syntax and Normalization ...................... 8		2.1. UTF-8 Syntax and Normalization ...................... 8
	2.2. Formal Syntax ....................................... 9		2.2. Formal Syntax ....................................... 9
	2.3. NAI Length Considerations ........................... 10		2.3. NAI Length Considerations ........................... 10
	2.4. Support for Username Privacy ........................ 11		2.4. Support for Username Privacy ........................ 11
	2.5. International Character Sets ........................ 11		2.5. International Character Sets ........................ 11
	2.6. The Normalization Process ........................... 12		2.6. The Normalization Process ........................... 12
	2.6.1. Issues with the Normalization Process .......... 13		2.6.1. Issues with the Normalization Process .......... 13
	2.7. Use in Other Protocols .............................. 14		2.7. Use in Other Protocols .............................. 14
	3. ........................................................... 15		3. Routing inside of AAA Systems ............................ 15
	3.1. Compatibility with Email Usernames .................. 16		3.1. Compatibility with Email Usernames .................. 16
	3.2. Compatibility with DNS .............................. 16		3.2. Compatibility with DNS .............................. 16
	3.3. Realm Construction .................................. 17		3.3. Realm Construction .................................. 17
	3.3.1. Historical Practices ........................... 18		3.3.1. Historical Practices ........................... 18
	3.4. Examples ............................................ 18		3.4. Examples ............................................ 18
	4. Security Considerations .................................. 19		4. Security Considerations .................................. 19
	5. IANA Considerations ...................................... 20		5. Administration of Names .................................. 20
	6. References ............................................... 20		6. IANA Considerations ...................................... 20
	6.1. Normative References ................................ 20		7. References ............................................... 20
	6.2. Informative References .............................. 21		7.1. Normative References ................................ 20
			7.2. Informative References .............................. 21
	Appendix A - Changes from RFC4282 ............................ 23		Appendix A - Changes from RFC4282 ............................ 23
	1. Introduction		1. Introduction
	Considerable interest exists for a set of features that fit within		Considerable interest exists for a set of features that fit within
	the general category of inter-domain authentiction, or "roaming		the general category of inter-domain authentiction, or "roaming
	capability" for network access, including dialup Internet users,		capability" for network access, including dialup Internet users,
	Virtual Private Network (VPN) usage, wireless LAN authentication, and		Virtual Private Network (VPN) usage, wireless LAN authentication, and
	other applications. Interested parties have included the following:		other applications. Interested parties have included the following:
	* Regional Internet Service Providers (ISPs) operating within a		* Regional Internet Service Providers (ISPs) operating within a
	skipping to change at page 6, line 36		skipping to change at page 6, line 36
	Tunneling Service		Tunneling Service
	A tunneling service is any network service enabled by tunneling		A tunneling service is any network service enabled by tunneling
	protocols such as PPTP, L2F, L2TP, and IPsec tunnel mode. One		protocols such as PPTP, L2F, L2TP, and IPsec tunnel mode. One
	example of a tunneling service is secure access to corporate		example of a tunneling service is secure access to corporate
	intranets via a Virtual Private Network (VPN).		intranets via a Virtual Private Network (VPN).
	1.2. Requirements Language		1.2. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	document are to be interpreted as described in [RFC2119].		"OPTIONAL" in this document are to be interpreted as described in
			[RFC2119].
	1.3. Purpose		1.3. Purpose
	As described in [RFC2194], there are a number of providers offering		As described in [RFC2194], there are a number of providers offering
	network access services, and the number of Internet Service Providers		network access services, and the number of Internet Service Providers
	involved in roaming consortia is increasing rapidly.		involved in roaming consortia is increasing rapidly.
	In order to be able to offer roaming capability, one of the		In order to be able to offer roaming capability, one of the
	requirements is to be able to identify the user's home authentication		requirements is to be able to identify the user's home authentication
	server. For use in roaming, this function is accomplished via the		server. For use in roaming, this function is accomplished via the
	skipping to change at page 11, line 4		skipping to change at page 11, line 4
	Remote Authentication Dial-In User Service (RADIUS) protocol.		Remote Authentication Dial-In User Service (RADIUS) protocol.
	Unfortunately, RFC 2865 [RFC2865], Section 5.1, states that "the		Unfortunately, RFC 2865 [RFC2865], Section 5.1, states that "the
	ability to handle at least 63 octets is recommended." As a		ability to handle at least 63 octets is recommended." As a
	result, it may not be possible to transfer NAIs beyond 63 octets		result, it may not be possible to transfer NAIs beyond 63 octets
	through all devices. In addition, since only a single User-Name		through all devices. In addition, since only a single User-Name
	attribute may be included in a RADIUS message and the maximum		attribute may be included in a RADIUS message and the maximum
	attribute length is 253 octets; RADIUS is unable to support NAI		attribute length is 253 octets; RADIUS is unable to support NAI
	lengths beyond 253 octets.		lengths beyond 253 octets.
	* NAIs can also be transported in the User-Name attribute of		* NAIs can also be transported in the User-Name attribute of
	Diameter [RFC3588], which supports content lengths up to 2^24 - 9		Diameter [RFC6733], which supports content lengths up to 2^24 - 9
	octets. As a result, NAIs processed only by Diameter nodes can be		octets. As a result, NAIs processed only by Diameter nodes can be
	very long. However, an NAI transported over Diameter may		very long. However, an NAI transported over Diameter may
	eventually be translated to RADIUS, in which case the above		eventually be translated to RADIUS, in which case the above
	limitations will apply.		limitations will apply.
	* NAIs may be transported in other protocols. Each protocol		* NAIs may be transported in other protocols. Each protocol
	can have its own limitations on maximum NAI length.		can have its own limitations on maximum NAI length.
	The above criteria should permit the widest use, and widest possible		The above criteria should permit the widest use, and widest possible
	inter-operability of the NAI.		inter-operability of the NAI.
	skipping to change at page 12, line 19		skipping to change at page 12, line 19
	insufficient information, which meant that the form was not		insufficient information, which meant that the form was not
	canonical.		canonical.
	Specifying the realm requirement as above means that the requirements		Specifying the realm requirement as above means that the requirements
	depend on specifications that are referenced here, rather than copied		depend on specifications that are referenced here, rather than copied
	here. This allows the realm definition to be updated when the		here. This allows the realm definition to be updated when the
	referenced documents change, without requiring a revision of this		referenced documents change, without requiring a revision of this
	specification.		specification.
	One caveat on the above recommendation is the issues noted in		One caveat on the above recommendation is the issues noted in
	[CODEPOINTS]. That document notes that there are additional		[RFC6912]. That document notes that there are additional
	restrictions around DNS registration which forbid some code points		restrictions around DNS registration which forbid some code points
	from being valid in a DNS U-label. These restrictions cannot be		from being valid in a DNS U-label. These restrictions cannot be
	expressed algorithmically.		expressed algorithmically.
	For this specification, that caveat means the following. Realms not		For this specification, that caveat means the following. Realms not
	matching the above ABNF are not valid NAIs. However, some realms		matching the above ABNF are not valid NAIs. However, some realms
	which do match the ABNF are still invalid NAIs. That is, matching		which do match the ABNF are still invalid NAIs. That is, matching
	the ABNF is a necessary, but not sufficient, requirement for an NAI.		the ABNF is a necessary, but not sufficient, requirement for an NAI.
	In general, the above requirement means following the requirements		In general, the above requirement means following the requirements
	skipping to change at page 15, line 16		skipping to change at page 15, line 16
	For example, HTTP carries user identifiers, but escapes the '.'		For example, HTTP carries user identifiers, but escapes the '.'
	character as "%2E" (among others). When we desire HTTP to transport		character as "%2E" (among others). When we desire HTTP to transport
	the NAI "fred@example.com", the data as transported will be in the		the NAI "fred@example.com", the data as transported will be in the
	form "fred@example%2Ecom". That data exists only within HTTP, and		form "fred@example%2Ecom". That data exists only within HTTP, and
	has no relevance to any AAA system.		has no relevance to any AAA system.
	Any comparison, validation, or use of the NAI MUST be done on its un-		Any comparison, validation, or use of the NAI MUST be done on its un-
	escaped (i.e. utf8-clean) form.		escaped (i.e. utf8-clean) form.
	3.		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
	without modification to perform this lookup. As noted earlier,		without modification to perform this lookup. As noted earlier,
	intermediate nodes may not have access to the same locale information		intermediate nodes may not have access to the same locale information
	skipping to change at page 19, line 45		skipping to change at page 19, line 45
	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
	username, protocols may use confidentiality services provided by		username, protocols may use confidentiality services provided by
	protocols transporting them, such as RADIUS protected by IPsec		protocols transporting them, such as RADIUS protected by IPsec
	[RFC3579] or Diameter protected by TLS [RFC3588].		[RFC3579] or Diameter protected by TLS [RFC6733].
	This specification adds the possibility of hiding the username part		This specification adds the possibility of hiding the username part
	in the NAI, by omitting it. As discussed in Section 2.4, this is		in the NAI, by omitting it. As discussed in Section 2.4, this is
	possible only when NAIs are used together with a separate		possible only when NAIs are used together with a separate
	authentication method that can transfer the username in a secure		authentication method that can transfer the username in a secure
	manner. In some cases, application-specific privacy mechanism have		manner. In some cases, application-specific privacy mechanism have
	also been used with NAIs. For instance, some EAP methods apply		also been used with NAIs. For instance, some EAP methods apply
	method-specific pseudonyms in the username part of the NAI [RFC3748].		method-specific pseudonyms in the username part of the NAI [RFC3748].
	While neither of these approaches can protect the realm part, their		While neither of these approaches can protect the realm part, their
	advantage over transport protection is that privacy of the username		advantage over transport protection is that privacy of the username
	is protected, even through intermediate nodes such as NASes.		is protected, even through intermediate nodes such as NASes.
	5. IANA Considerations		5. Administration of Names
	In order to avoid creating any new administrative procedures,		In order to avoid creating any new administrative procedures,
	administration of the NAI realm namespace piggybacks on the		administration of the NAI realm namespace piggybacks on the
	administration of the DNS namespace.		administration of the DNS namespace.
	NAI realm names are required to be unique, and the rights to use a		NAI realm names are required to be unique, and the rights to use a
	given NAI realm for roaming purposes are obtained coincident with		given NAI realm for roaming purposes are obtained coincident with
	acquiring the rights to use a particular Fully Qualified Domain Name		acquiring the rights to use a particular Fully Qualified Domain Name
	(FQDN). Those wishing to use an NAI realm name should first acquire		(FQDN). Those wishing to use an NAI realm name should first acquire
	the rights to use the corresponding FQDN. Using an NAI realm without		the rights to use the corresponding FQDN. Administrators MUST NOT
	ownership of the corresponding FQDN creates the possibility of		publicly use an NAI realm without first owning the corresponding
	conflict and is therefore discouraged.		FQDN. Private use of unowned NAI realms within an administative
			domain is allowed, though it is RECOMMENDED that example names be
			used, such as "example.com".
	Note that the use of an FQDN as the realm name does not require use		Note that the use of an FQDN as the realm name does not require use
	of the DNS for location of the authentication server. While Diameter		of the DNS for location of the authentication server. While Diameter
	[RFC3588] supports the use of DNS for location of authentication		[RFC6733] supports the use of DNS for location of authentication
	servers, existing RADIUS implementations typically use proxy		servers, existing RADIUS implementations typically use proxy
	configuration files in order to locate authentication servers within		configuration files in order to locate authentication servers within
	a domain and perform authentication routing. The implementations		a domain and perform authentication routing. The implementations
	described in [RFC2194] did not use DNS for location of the		described in [RFC2194] did not use DNS for location of the
	authentication server within a domain. Similarly, existing		authentication server within a domain. Similarly, existing
	implementations have not found a need for dynamic routing protocols		implementations have not found a need for dynamic routing protocols
	or propagation of global routing information. Note also that there		or propagation of global routing information. Note also that there
	is no requirement that the NAI represent a valid email address.		is no requirement that the NAI represent a valid email address.
	6. References		6. IANA Considerations
	6.1. Normative References		This document has no actions for IANA.
			7. References
			7.1. Normative References
	[RFC2119]		[RFC2119]
	Bradner, S., "Key words for use in RFCs to Indicate Requirement		Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", RFC 2119, March, 1997.		Levels", RFC 2119, March, 1997.
	[RFC3629]		[RFC3629]
	Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63,		Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63,
	RFC 3629, November 2003.		RFC 3629, November 2003.
	[RFC5198]		[RFC5198]
	skipping to change at page 21, line 17		skipping to change at page 21, line 21
	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
	[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
	6.2. Informative References		7.2. Informative References
	[RFC2194]		[RFC2194]
	Aboba, B., Lu, J., Alsop, J., Ding, J., and W. Wang, "Review of		Aboba, B., Lu, J., Alsop, J., Ding, J., and W. Wang, "Review of
	Roaming Implementations", RFC 2194, September 1997.		Roaming Implementations", RFC 2194, September 1997.
	[RFC2341]		[RFC2341]
	Valencia, A., Littlewood, M., and T. Kolar, "Cisco Layer Two		Valencia, A., Littlewood, M., and T. Kolar, "Cisco Layer Two
	Forwarding (Protocol) "L2F"", RFC 2341, May 1998.		Forwarding (Protocol) "L2F"", RFC 2341, May 1998.
	[RFC2637]		[RFC2637]
	skipping to change at page 21, line 48		skipping to change at page 22, line 5
	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.
	[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.
	[RFC3588]
	Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
	"Diameter Base Protocol", RFC 3588, 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]
	skipping to change at page 22, line 33		skipping to change at page 22, line 33
	http://eduroam.org, "eduroam (EDUcational ROAMing)"		http://eduroam.org, "eduroam (EDUcational ROAMing)"
	[RFC5891]		[RFC5891]
	Klensin, J., "Internationalized Domain Names in Applications		Klensin, J., "Internationalized Domain Names in Applications
	(IDNA): Protocol", RFC 5891		(IDNA): Protocol", RFC 5891
	[RFC6055]		[RFC6055]
	Thaler, D., et al, "IAB Thoughts on Encodings for Internationalized		Thaler, D., et al, "IAB Thoughts on Encodings for Internationalized
	Domain Names", RFC 6055, February 2011.		Domain Names", RFC 6055, February 2011.
	[CODEPOINTS]		[RFC6733]
			V. Fajardo, Ed., et al, "Diameter Base Protocol", RFC 6733, October
			2012.
			[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", draft-iab-dns-zone-codepoint-pples, work in		in Labels in the DNS", RFC 6912, April 2013.
	progress.
	Acknowledgments		Acknowledgments
	The initial text for this document was [RFC4282], which was then		The initial text for this document was [RFC4282], which was then
	heavily edited. The original authors of [RFC4282] were Bernard		heavily edited. The original authors of [RFC4282] were Bernard
	Aboba, Mark A. Beadles, Jari Arkko, and Pasi Eronen.		Aboba, Mark A. Beadles, Jari Arkko, and Pasi Eronen.
	The ABNF validator at http://www.apps.ietf.org/abnf.html was used to		The ABNF validator at http://www.apps.ietf.org/abnf.html was used to
	verify the syntactic correctness of the ABNF in Section 2.		verify the syntactic correctness of the ABNF in Section 2.
End of changes. 23 change blocks.
	38 lines changed or deleted		43 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/