draft-ietf-radext-rfc2486bis-01.txt		naibis.txt
	Network Working Group B. Aboba		Network Working Group B. Aboba
	Internet-Draft Microsoft		Internet-Draft Microsoft
	Expires: April 19, 2005 M. Beadles		Expires: May 5, 2005 M. Beadles
	SmartPipes		SmartPipes
	J. Arkko		J. Arkko
	Ericsson		Ericsson
	P. Eronen		P. Eronen
	Nokia		Nokia
	October 19, 2004		November 4, 2004
	The Network Access Identifier		The Network Access Identifier
	draft-ietf-radext-rfc2486bis-01		draft-ietf-radext-rfc2486bis-02
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is subject to all provisions		This document is an Internet-Draft and is subject to all provisions
	of section 3 of RFC 3667. By submitting this Internet-Draft, each		of section 3 of RFC 3667. By submitting this Internet-Draft, each
	author represents that any applicable patent or other IPR claims of		author represents that any applicable patent or other IPR claims of
	which he or she is aware have been or will be disclosed, and any of		which he or she is aware have been or will be disclosed, and any of
	which he or she become aware will be disclosed, in accordance with		which he or she become aware will be disclosed, in accordance with
	RFC 3668.		RFC 3668.
	skipping to change at page 1, line 40		skipping to change at page 1, line 40
	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 April 19, 2005.		This Internet-Draft will expire on May 5, 2005.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004).		Copyright (C) The Internet Society (2004).
	Abstract		Abstract
	In order to provide roaming services, it is necessary to have a		In order to provide roaming services, it is necessary to have a
	standardized method for identifying users. This document defines the		standardized method for identifying users. This document defines the
	syntax for the Network Access Identifier (NAI), the user identity		syntax for the Network Access Identifier (NAI), the user identity
	skipping to change at page 2, line 17		skipping to change at page 2, line 17
	relationship with only one. Examples of where roaming capabilities		relationship with only one. Examples of where roaming capabilities
	might be required include ISP "confederations" and ISP-provided		might be required include ISP "confederations" and ISP-provided
	corporate network access support. This document is a revised version		corporate network access support. This document is a revised version
	of RFC 2486 which originally defined NAIs. Enhancements include		of RFC 2486 which originally defined NAIs. Enhancements include
	international character set and privacy support, as well as a number		international character set and privacy support, as well as a number
	of corrections to the original RFC.		of corrections to the original RFC.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1 Terminology . . . . . . . . . . . . . . . . . . . . . 3		1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	1.2 Requirements language . . . . . . . . . . . . . . . . 4		1.2 Requirements language . . . . . . . . . . . . . . . . . . 4
	1.3 Purpose . . . . . . . . . . . . . . . . . . . . . . . 4		1.3 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. NAI Definition . . . . . . . . . . . . . . . . . . . . . . . . 5		2. NAI Definition . . . . . . . . . . . . . . . . . . . . . . . . 5
	2.1 Formal Syntax . . . . . . . . . . . . . . . . . . . . 5		2.1 Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 5
	2.2 NAI Length Considerations . . . . . . . . . . . . . . 6		2.2 NAI Length Considerations . . . . . . . . . . . . . . . . 6
	2.3 Support for Username Privacy . . . . . . . . . . . . . 6		2.3 Support for Username Privacy . . . . . . . . . . . . . . . 7
	2.4 International Character Sets . . . . . . . . . . . . . 7		2.4 International Character Sets . . . . . . . . . . . . . . . 7
	2.5 Compatibility with E-Mail Usernames . . . . . . . . . 7		2.5 Compatibility with E-Mail Usernames . . . . . . . . . . . 7
	2.6 Compatibility with DNS . . . . . . . . . . . . . . . . 7		2.6 Compatibility with DNS . . . . . . . . . . . . . . . . . . 8
	2.7 Realm Construction . . . . . . . . . . . . . . . . . . 8		2.7 Realm Construction . . . . . . . . . . . . . . . . . . . . 8
	2.8 Examples . . . . . . . . . . . . . . . . . . . . . . . 9		2.8 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 9
	3. Security Considerations . . . . . . . . . . . . . . . . . . . 10		3. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12		5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	5.1 Normative References . . . . . . . . . . . . . . . . . . 12		5.1 Normative References . . . . . . . . . . . . . . . . . . . . 11
	5.2 Informative References . . . . . . . . . . . . . . . . . 12		5.2 Informative References . . . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
	A. Changes from RFC 2486 . . . . . . . . . . . . . . . . . . . . 14		A. Changes from RFC 2486 . . . . . . . . . . . . . . . . . . . . 12
	B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15		B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
	Intellectual Property and Copyright Statements . . . . . . . . 16		Intellectual Property and Copyright Statements . . . . . . . . 15
	1. Introduction		1. Introduction
	Considerable interest exists for a set of features that fit within		Considerable interest exists for a set of features that fit within
	the general category of "roaming capability" for network access,		the general category of "roaming capability" for network access,
	including dialup Internet users, VPN usage, wireless LAN		including dialup Internet users, VPN usage, wireless LAN
	authentication, and other applications. Interested parties have		authentication, and other applications. Interested parties have
	included:		included:
	o Regional Internet Service Providers (ISPs) operating within a		o Regional Internet Service Providers (ISPs) operating within a
	particular state or province, looking to combine their efforts		particular state or province, looking to combine their efforts
	with those of other regional providers to offer dialup service		with those of other regional providers to offer dialup service
	over a wider area.		over a wider area.
	o National ISPs wishing to combine their operations with those of		o National ISPs wishing to combine their operations with those of
	one or more ISPs in another nation to offer more comprehensive		one or more ISPs in another nation to offer more comprehensive
	dialup service in a group of countries or on a continent.		dialup service in a group of countries or on a continent.
	o Wireless LAN hotspots providing service to one or more ISPs.		o Wireless LAN hotspots providing service to one or more ISPs.
	o Businesses desiring to offer their employees a comprehensive		o Businesses desiring to offer their employees a comprehensive
	package of dialup services on a global basis. Those services may		package of dialup services on a global basis. Those services may
	include Internet access as well as secure access to corporate		include Internet access as well as secure access to corporate
	intranets via a Virtual Private Network (VPN), enabled by		intranets via a Virtual Private Network (VPN), enabled by
	tunneling protocols such as PPTP, L2F, L2TP, and IPsec tunnel		tunneling protocols such as PPTP, L2F, L2TP, and IPsec tunnel
	mode.		mode.
	In order to enhance the interoperability of roaming services, it is		In order to enhance the interoperability of roaming services, it is
	necessary to have a standardized method for identifying users. This		necessary to have a standardized method for identifying users. This
	document defines syntax for the Network Access Identifier (NAI).		document defines syntax for the Network Access Identifier (NAI).
	skipping to change at page 3, line 30		skipping to change at page 3, line 34
	package of dialup services on a global basis. Those services may		package of dialup services on a global basis. Those services may
	include Internet access as well as secure access to corporate		include Internet access as well as secure access to corporate
	intranets via a Virtual Private Network (VPN), enabled by		intranets via a Virtual Private Network (VPN), enabled by
	tunneling protocols such as PPTP, L2F, L2TP, and IPsec tunnel		tunneling protocols such as PPTP, L2F, L2TP, and IPsec tunnel
	mode.		mode.
	In order to enhance the interoperability of roaming services, it is		In order to enhance the interoperability of roaming services, it is
	necessary to have a standardized method for identifying users. This		necessary to have a standardized method for identifying users. This
	document defines syntax for the Network Access Identifier (NAI).		document defines syntax for the Network Access Identifier (NAI).
	Examples of implementations that use the NAI, and descriptions of its		Examples of implementations that use the NAI, and descriptions of its
	semantics, can be found in [7].		semantics, can be found in [RFC2194].
	This document is a revised version of RFC 2486 which originally		This document is a revised version of RFC 2486 [RFC2486] which
	defined NAIs. Differences and enhancements compared to RFC 2486 are		originally defined NAIs. Differences and enhancements compared to
	listed in Appendix A.		RFC 2486 are listed in Appendix A.
	1.1 Terminology		1.1 Terminology
	This document frequently uses the following terms:		This document frequently uses the following terms:
	Network Access Identifier		Network Access Identifier
	The Network Access Identifier (NAI) is the user identity submitted		The Network Access Identifier (NAI) is the user identity submitted
	by the client during network access authentication. In roaming,		by the client during network access authentication. In roaming,
	the purpose of the NAI is to identify the user as well as to		the purpose of the NAI is to identify the user as well as to
	assist in the routing of the authentication request. Please note		assist in the routing of the authentication request. Please note
	that the NAI may not necessarily be the same as the user's e-mail		that the NAI may not necessarily be the same as the user's e-mail
	address or the user identity submitted in an application layer		address or the user identity submitted in an application layer
	authentication.		authentication.
	Network Access Server		Network Access Server
	The Network Access Server (NAS) is the device that clients connect		The Network Access Server (NAS) is the device that clients connect
	to in order to get access to the network. In PPTP terminology		to in order to get access to the network. In PPTP terminology
	this is referred to as the PPTP Access Concentrator (PAC), and in		this is referred to as the PPTP Access Concentrator (PAC), and in
	L2TP terminology, it is referred to as the L2TP Access		L2TP terminology, it is referred to as the L2TP Access
	Concentrator (LAC). In IEEE 802.11, it is referred to as an		Concentrator (LAC). In IEEE 802.11, it is referred to as an
	Access Point.		Access Point.
	Roaming Capability		Roaming Capability
	Roaming capability can be loosely defined as the ability to use		Roaming capability can be loosely defined as the ability to use
	any one of multiple Internet service providers (ISPs), while		any one of multiple Internet service providers (ISPs), while
	maintaining a formal, customer-vendor relationship with only one.		maintaining a formal, customer-vendor relationship with only one.
	Examples of cases where roaming capability might be required		Examples of cases where roaming capability might be required
	include ISP "confederations" and ISP- provided corporate network		include ISP "confederations" and ISP- provided corporate network
	access support.		access support.
	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
	In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL",		In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL",
	skipping to change at page 4, line 26		skipping to change at page 4, line 39
	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
	In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL",		In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL",
	"RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as		"RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as
	described in [2].		described in [RFC2119].
	1.3 Purpose		1.3 Purpose
	As described in [7], there are a number of providers offering network		As described in [RFC2194], there are a number of providers offering
	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
	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.
	2. NAI Definition		2. NAI Definition
	2.1 Formal Syntax		2.1 Formal Syntax
	The grammar for the NAI is given below, described in ABNF as		The grammar for the NAI is given below, described in ABNF as
	documented in [3]. The grammar for the username is based on [6], and		documented in [RFC2234]. The grammar for the username is based on
	the grammar for the realm is an updated version of [1].		[RFC0821], and the grammar for the realm is an updated version of
			[RFC1035].
	nai = username		nai = username
	nai =/ "@" realm		nai =/ "@" realm
	nai =/ username "@" realm		nai =/ username "@" realm
	username = dot-string		username = dot-string
	dot-string = string		dot-string = string
	dot-string =/ dot-string "." string		dot-string =/ dot-string "." string
	string = char		string = char
	string =/ string char		string =/ string char
	skipping to change at page 6, line 26		skipping to change at page 6, line 35
	let-dig = alpha / digit		let-dig = alpha / digit
	alpha = %x41-5A ; 'A'-'Z'		alpha = %x41-5A ; 'A'-'Z'
	alpha =/ %x61-7A ; 'a'-'z'		alpha =/ %x61-7A ; 'a'-'z'
	digit = %x30-39 ; '0'-'9'		digit = %x30-39 ; '0'-'9'
	2.2 NAI Length Considerations		2.2 NAI Length Considerations
	Devices handling NAIs MUST support an NAI length of at least 72		Devices handling NAIs MUST support an NAI length of at least 72
	octets. Support for an NAI length of 253 octets is RECOMMENDED.		octets. Support for an NAI length of 253 octets is RECOMMENDED.
	However, the following implementation issues should be considered:		However, the following implementation issues should be considered:
	o NAIs are often transported in the User-Name attribute of RADIUS.		o NAIs are often transported in the User-Name attribute of RADIUS.
	Unfortunately, RFC 2865 [9] Section 5.1 states that "the ability		Unfortunately, RFC 2865 [RFC2865] Section 5.1 states that "the
	to handle at least 63 octets is recommended." As a result, it may		ability to handle at least 63 octets is recommended." As a result,
	not be possible to transfer NAIs beyond 63 octets through all		it may not be possible to transfer NAIs beyond 63 octets through
	devices. In addition, since only a single User-Name attribute may		all devices. In addition, since only a single User-Name attribute
	be included in a RADIUS message and the maximum attribute length		may be included in a RADIUS message and the maximum attribute
	is 253 octets, RADIUS is unable to support NAI lengths beyond 253		length is 253 octets, RADIUS is unable to support NAI lengths
	octets.		beyond 253 octets.
	o NAIs can also be transported in the User-Name attribute of		o NAIs can also be transported in the User-Name attribute of
	Diameter [12], which supports content lengths up to 2^24 - 9		Diameter [RFC3588], which supports content lengths up to 2^24 - 9
	octets. As a result, NAIs processed only by Diameter nodes can be		octets. As a result, NAIs processed only by Diameter nodes can be
	very long. Unfortunately, an NAI transported over Diameter may		very long. Unfortunately, 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 apply.		limitations apply.
	2.3 Support for Username Privacy		2.3 Support for Username Privacy
	Interpretation of the "username" part of the NAI depends on the realm		Interpretation of the "username" part of the NAI depends on the realm
	in question. Therefore, the "username" part SHOULD be treated as		in question. Therefore, the "username" part SHOULD be treated as
	opaque data when processed by nodes that are not a part of the		opaque data when processed by nodes that are not a part of the
	skipping to change at page 7, line 19		skipping to change at page 7, line 32
	the authentication conversation can proceed. As a result, the realm		the authentication conversation can proceed. As a result, the realm
	portion is typically required in order for the authentication		portion is typically required in order for the authentication
	exchange to be routed to the appropriate server.		exchange to be routed to the appropriate server.
	2.4 International Character Sets		2.4 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 and processed with a certain algorithm to ensure a		encoded as UTF-8 and processed with a certain algorithm to ensure a
	canonical representation. The realm part internationalization is		canonical representation. The realm part internationalization is
	based on International Domain Name (IDN) [4].		based on International Domain Name (IDN) [RFC3490].
	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 fulfill the requirements specified in		username portion in an NAI MUST fulfill the requirements specified in
	[5]. In addition, the use of certain special characters (see grammar		[I-D.ietf-sasl-saslprep]. In addition, the use of certain special
	rule c) are prohibited as well in order to retain compatibility with		characters (see grammar rule c) are prohibited as well in order to
	the previous version of this RFC.		retain compatibility with the previous version of this RFC.
	The realm name is an "IDN-unaware domain name slot" as defined in		The realm name is an "IDN-unaware domain name slot" as defined in
	[4]. That is, it can contain only ASCII characters. An		[RFC3490]. That is, it can contain only ASCII characters. An
	implementation MAY support internationalized domain names (IDNs)		implementation MAY support internationalized domain names (IDNs)
	using the ToASCII operation; see [4] for more information.		using the ToASCII operation; see [RFC3490] for more information.
	2.5 Compatibility with E-Mail Usernames		2.5 Compatibility with E-Mail Usernames
	As proposed in this document, the Network Access Identifier is of the		As proposed in this document, the Network Access Identifier is of the
	form user@realm. Please note that while the user portion of the NAI		form user@realm. Please note that while the user portion of the NAI
	is based on the BNF described in [6], it has been extended for		is based on the BNF described in [RFC0821], it has been extended for
	internationalization support as well as for purposes of Section 2.7,		internationalization support as well as for purposes of Section 2.7,
	and is not necessarily compatible with the usernames used in e-mail.		and is not necessarily compatible with the usernames used in e-mail.
	Note also that the internationalization requirements for NAIs and		Note also that the internationalization requirements for NAIs and
	e-mail addresses are different, since the former need to be typed in		e-mail addresses are different, since the former need to be typed in
	only by the user himself and his own operator, not by others.		only by the user himself and his own operator, not by others.
	2.6 Compatibility with DNS		2.6 Compatibility with DNS
	The BNF of the realm portion allows the realm to begin with a digit,		The BNF of the realm portion allows the realm to begin with a digit,
	which is not permitted by the BNF described in [1]. This change was		which is not permitted by the BNF described in [RFC1035]. This
	made to reflect current practice; although not permitted by the BNF		change was made to reflect current practice; although not permitted
	described in [1], FQDNs such as 3com.com are commonly used, and		by the BNF described in [RFC1035], FQDNs such as 3com.com are
	accepted by current software.		commonly used, and accepted by current software.
	2.7 Realm Construction		2.7 Realm Construction
	NAIs are used, among other purposes, for routing AAA transactions to		NAIs are used, among other purposes, for routing AAA transactions to
	the user's home realm. Usually, the home realm appears in the realm		the user's home realm. Usually, the home realm appears in the realm
	portion of the NAI, but in some cases a different realm can be used.		portion of the NAI, but in some cases a different realm can be used.
	This may be useful, for instance, when the home realm is only		This may be useful, for instance, when the home realm is only
	reachable via another mediating realm.		reachable via another mediating realm.
	Such usage may prevent interoperability unless the parties involved		Such usage may prevent interoperability unless the parties involved
	skipping to change at page 9, line 13		skipping to change at page 9, line 27
	user@homerealm.example.net		user@homerealm.example.net
	2.8 Examples		2.8 Examples
	Examples of valid Network Access Identifiers include:		Examples of valid Network Access Identifiers include:
	bob		bob
	joe@example.com		joe@example.com
	fred@foo-9.example.com		fred@foo-9.example.com
	jack@3rd.depts.example.com		jack@3rd.depts.example.com
			fred.smith@example.com
	fred_smith@example.com		fred_smith@example.com
			fred$@example.com
	fred=?#$&*+-/^smith@example.com		fred=?#$&*+-/^smith@example.com
	nancy@eng.example.net		nancy@eng.example.net
	eng.example.net!nancy@example.net		eng.example.net!nancy@example.net
	eng%nancy@example.net		eng%nancy@example.net
	@privatecorp.example.net		@privatecorp.example.net
	alice@xn--tmonesimerkki-bfbb.example.net		alice@xn--tmonesimerkki-bfbb.example.net
			\(user\)@example.net
	The last example uses an IDN converted into an ASCII representation.		The last example uses an IDN converted into an ASCII representation.
	Examples of invalid Network Access Identifiers include:		Examples of invalid Network Access Identifiers include:
	fred@foo		fred@example
	fred@foo_9.com		fred@example_9.com
	fred@bigco.com@example.net		fred@example.net@example.net
			fred.@example.net
	eng:nancy@example.net		eng:nancy@example.net
	eng;nancy@example.net		eng;nancy@example.net
			(user)@example.net
	<nancy>@example.net		<nancy>@example.net
	3. Security Considerations		3. 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 which transmit the user name		problem is of most concern in protocols which transmit the user name
	in clear-text across the Internet, such as in RADIUS, described in		in clear-text across the Internet, such as in RADIUS, described in
	[9] and [10]. In order to prevent snooping of the user name,		[RFC2865] and [RFC2866]. In order to prevent snooping of the user
	protocols may use confidentiality services provided by protocols		name, protocols may use confidentiality services provided by
	transporting them, such RADIUS protected by IPsec [11] or Diameter		protocols transporting them, such RADIUS protected by IPsec [RFC3579]
	protected by TLS [12].		or Diameter protected by TLS [RFC3588].
	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.3, this is		in the NAI, by omitting it. As discussed in Section 2.3, 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 a		also been used with NAIs. For instance, some EAP methods apply a
	method-specific pseudonyms in the username part of the NAI. While		method-specific pseudonyms in the username part of the NAI. While
	neither of these approaches can protect the realm part, their		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
	skipping to change at page 11, line 20		skipping to change at page 10, line 42
	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. Using an NAI realm without
	ownership of the corresponding FQDN creates the possibility of		ownership of the corresponding FQDN creates the possibility of
	conflict and therefore is to be discouraged.		conflict and therefore is to be discouraged.
	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
	[12] supports the use of DNS for location of authentication servers,		[RFC3588] supports the use of DNS for location of authentication
	existing RADIUS implementations typically use proxy configuration		servers, existing RADIUS implementations typically use proxy
	files in order to locate authentication servers within a domain and		configuration files in order to locate authentication servers within
	perform authentication routing. The implementations described in [7]		a domain and perform authentication routing. The implementations
	did not use DNS for location of the authentication server within a		described in [RFC2194] did not use DNS for location of the
	domain. Similarly, existing implementations have not found a need		authentication server within a domain. Similarly, existing
	for dynamic routing protocols, or propagation of global routing		implementations have not found a need for dynamic routing protocols,
	information. Note also that there is no requirement that that the		or propagation of global routing information. Note also that there
	NAI represent a valid email address.		is no requirement that that the NAI represent a valid email address.
	5. References		5. References
	5.1 Normative References		5.1 Normative References
	[1] Mockapetris, P., "Domain names - implementation and		[RFC1035] Mockapetris, P., "Domain names - implementation and
	specification", STD 13, RFC 1035, November 1987.		specification", STD 13, RFC 1035, November 1987.
	[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[3] Crocker, D. and P. Overell, "Augmented BNF for Syntax		[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", RFC 2234, November 1997.		Specifications: ABNF", RFC 2234, November 1997.
	[4] Faltstrom, P., Hoffman, P. and A. Costello, "Internationalizing		[RFC3490] Faltstrom, P., Hoffman, P. and A. Costello,
	Domain Names in Applications (IDNA)", RFC 3490, March 2003.		"Internationalizing Domain Names in Applications (IDNA)",
			RFC 3490, March 2003.
	[5] Zeilenga, K., "SASLprep: Stringprep profile for user names and		[I-D.ietf-sasl-saslprep]
	passwords", draft-ietf-sasl-saslprep-04 (work in progress),		Zeilenga, K., "SASLprep: Stringprep profile for user names
	October 2003.		and passwords", draft-ietf-sasl-saslprep-10 (work in
			progress), July 2004.
	5.2 Informative References		5.2 Informative References
	[6] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,		[RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
	August 1982.		821, August 1982.
	[7] Aboba, B., Lu, J., Alsop, J., Ding, J. and W. Wang, "Review of		[RFC2194] Aboba, B., Lu, J., Alsop, J., Ding, J. and W. Wang,
	Roaming Implementations", RFC 2194, September 1997.		"Review of Roaming Implementations", RFC 2194, September
			1997.
	[8] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC		[RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier",
	2486, January 1999.		RFC 2486, January 1999.
	[9] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote		[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson,
	Authentication Dial In User Service (RADIUS)", RFC 2865, June		"Remote Authentication Dial In User Service (RADIUS)", RFC
	2000.		2865, June 2000.
	[10] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.		[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
	[11] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial		[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
	In User Service) Support For Extensible Authentication Protocol		Dial In User Service) Support For Extensible
	(EAP)", RFC 3579, September 2003.		Authentication Protocol (EAP)", RFC 3579, September 2003.
	[12] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko,		[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J.
	"Diameter Base Protocol", RFC 3588, September 2003.		Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
	[13] Arkko, J. and B. Aboba, "Network Discovery and Selection within		[I-D.ietf-eap-netsel-problem]
	the EAP Framework", draft-ietf-eap-netsel-problem-00 (work in		Arkko, J. and B. Aboba, "Network Discovery and Selection
	progress), January 2004.		within the EAP Framework",
			draft-ietf-eap-netsel-problem-02 (work in progress),
			October 2004.
	Authors' Addresses		Authors' Addresses
	Bernard Aboba		Bernard Aboba
	Microsoft		Microsoft
	One Microsoft Way		One Microsoft Way
	Redmond, WA 98052		Redmond, WA 98052
	USA		USA
	EMail: bernarda@microsoft.com		EMail: bernarda@microsoft.com
	skipping to change at page 14, line 7		skipping to change at page 12, line 44
	Nokia Research Center		Nokia Research Center
	P.O. Box 407		P.O. Box 407
	FIN-00045 Nokia Group		FIN-00045 Nokia Group
	Finland		Finland
	EMail: pasi.eronen@nokia.com		EMail: pasi.eronen@nokia.com
	Appendix A. Changes from RFC 2486		Appendix A. Changes from RFC 2486
	This draft contains the following updates with respect to the		This draft contains the following updates with respect to the
	original NAI definition in RFC 2486:		original NAI definition in RFC 2486 [RFC2486]:
	o International character set support has been added for both		o International character set support has been added for both
	usernames and realms. Note that this implies character codes 128		usernames and realms. Note that this implies character codes 128
	- 255 may be used in the username portion, which may be		- 255 may be used in the username portion, which may be
	unacceptable to nodes that only support RFC 2486. Many devices		unacceptable to nodes that only support RFC 2486. Many devices
	already allow this behaviour, however.		already allow this behaviour, however.
	o Username privacy support has been added. Note that NAIs without a		o Username privacy support has been added. Note that NAIs without a
	username (for privacy) may not be acceptable to RFC 2486 compliant		username (for privacy) may not be acceptable to RFC 2486 compliant
	nodes. Many devices already allow this behaviour, however.		nodes. Many devices already allow this behaviour, however.
	o A recommendation to support NAI length of at least 253 octets has		o A recommendation to support NAI length of at least 253 octets has
	been added, and compatibility considerations among NAI lengths in		been added, and compatibility considerations among NAI lengths in
	this specification and various AAA protocols are discussed. Note		this specification and various AAA protocols are discussed. Note
	that long NAIs may not be acceptable to RFC 2486 compliant nodes.		that long NAIs may not be acceptable to RFC 2486 compliant nodes.
	o The mediating network syntax and its implications have been fully		o The mediating network syntax and its implications have been fully
	described and not given only as an example. Note that this syntax		described and not given only as an example. Note that this syntax
	is not intended to be a full solution to network discovery and		is not intended to be a full solution to network discovery and
	selection needs as defined in [13]. Rather, it is intended as a		selection needs as defined in [I-D.ietf-eap-netsel-problem].
	clarification of RFC 2486.		Rather, it is intended as a clarification of RFC 2486.
	However, as discussed in Section 2.7, this specification requires		However, as discussed in Section 2.7, this specification requires
	that this syntax be applied only when there is explicit knowledge		that this syntax be applied only when there is explicit knowledge
	that the peer system supports such syntax.		that the peer system supports such syntax.
	o The realm BNF entry definition has been changed to avoid an error		o The realm BNF entry definition has been changed to avoid an error
	(infinite recursion) in the original specification.		(infinite recursion) in the original specification.
	o Several clarifications and improvements have been incorporated to		o Several clarifications and improvements have been incorporated to
	the ABNF specification for NAIs.		the ABNF specification for NAIs.
	Appendix B. Acknowledgements		Appendix B. Acknowledgements
	Thanks to Glen Zorn for many useful discussions of this problem		Thanks to Glen Zorn for many useful discussions of this problem
	space, and for Farid Adrangi and others for suggesting mediating		space, and for Farid Adrangi and others for suggesting mediating
	network representation in NAIs. Jonathan Rosenberg reported the BNF		network representation in NAIs. Jonathan Rosenberg reported the BNF
	error. Dale Worley suggested clarifications of the x and special BNF		error. Dale Worley suggested clarifications of the x and special BNF
	entries. Arne Norefors reported the length differences between RFC		entries. Arne Norefors reported the length differences between RFC
End of changes.
This html diff was produced by rfcdiff v1.06, available from http://www.levkowetz.com/ietf/tools/rfcdiff/