< draft-adrangi-eap-network-discovery-00.txt		draft-adrangi-eap-network-discovery-01.txt >
	Extensible Authentication Protocol F. Adrangi		Extensible Authentication Protocol F. Adrangi
	Working Group V. Lortz		Working Group V. Lortz
	Internet-Draft Intel Corporation		Internet-Draft Intel Corporation
	Expires: October 24, 2004 F. Bari		Expires: December 16, 2004 F. Bari
	AT&T Wireless		AT&T Wireless
	P. Eronen		P. Eronen
	Nokia		Nokia Research Center
	M. Watson		M. Watson
	Nortel		Nortel
	April 25, 2004		June 17, 2004
	Mediating Network Discovery in the Extensible Authentication Protocol		Mediating Network Discovery in the Extensible Authentication Protocol
	(EAP)		(EAP)
	draft-adrangi-eap-network-discovery-00		draft-adrangi-eap-network-discovery-01
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, I certify that any applicable		By submitting this Internet-Draft, I certify that any applicable
	patent or other IPR claims of which I am aware have been disclosed,		patent or other IPR claims of which I am aware have been disclosed,
	and any of which I become aware will be disclosed, in accordance with		and any of which I become aware will be disclosed, in accordance with
	RFC 3668.		RFC 3668.
	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 other		Task Force (IETF), its areas, and its working groups. Note that
	groups may also distribute working documents as Internet-Drafts.		other groups may also distribute working documents as
			Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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 http://		The list of current Internet-Drafts can be accessed at
	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 October 24, 2004.		This Internet-Draft will expire on December 16, 2004.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
	Abstract		Abstract
	This document defines a mechanism to enable a wireless client to		This document defines a mechanism to enable a wireless client to
	discover roaming partners of an access network over EAP. The purpose		discover roaming partners of an access network over EAP. The purpose
	is to help a wireless client select the most appropriate roaming		is to help a wireless client select the most appropriate roaming
	partner as a next hop for routing of AAA packets. This solution is		partner as a next hop for routing of AAA packets. This solution is
	especially useful in roaming scenarios where the access network does		especially useful in roaming scenarios where the access network does
	not have a direct relationship with the wireless client's home		not have a direct relationship with the wireless client's home
	network - i.e., when AAA packets can not be directly routed from		network - i.e., when AAA packets can not be directly routed from
	access network to the home network.		access network to the home network.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1 Applicability . . . . . . . . . . . . . . . . . . . . . . 4		1.1 Applicability . . . . . . . . . . . . . . . . . . . . . . 4
	1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 5		1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
	2. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Delivery Mechanism . . . . . . . . . . . . . . . . . . . . . . 6		3. Delivery Mechanism . . . . . . . . . . . . . . . . . . . . . . 6
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 8		4. Implementation Considerations . . . . . . . . . . . . . . . . 6
	5. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9		6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	6.1 Normative References . . . . . . . . . . . . . . . . . . . . 9		7. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	6.2 Informative References . . . . . . . . . . . . . . . . . . . 9		8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	Intellectual Property and Copyright Statements . . . . . . . . 16		9.1 Normative References . . . . . . . . . . . . . . . . . . . . 13
			9.2 Informative References . . . . . . . . . . . . . . . . . . . 13
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
			Intellectual Property and Copyright Statements . . . . . . . . 15
	1. Introduction		1. Introduction
	In wireless network access, the high level network topology is		In wireless network access, the high level network topology is
	comprised of access networks, mediating networks, and home networks		comprised of access networks, mediating networks, and home networks
	as depicted in Figure 1. RADIUS [2] protocol has been assumed for AAA		as depicted in Figure 1. RADIUS [2] protocol has been assumed for
	mediation between the access network and the home network although		AAA mediation between the access network and the home network
	Diameter [3] could also be used instead of RADIUS without introducing		although Diameter [3] could also be used instead of RADIUS without
	significant architectural differences.		introducing significant architectural differences.
	Access Network Mediating Network 1		Access Network Mediating Network 1
	+-------------------+ +-----------+ Home		+-------------------+ +-----------+ Home
	| | | | Network A		| | | | Network A
	| +------+ | |AAA server;| +---------------+		| +------+ | |AAA server;| +---------------+
	| +-----+ |Access| | | Other |=====|Home AAA server|		| +-----+ |Access| | | Other |=====|Home AAA server|
	| |APs | |Router| | ||====|Components | | |		| |APs | |Router| | ||====|Components | | |
	| |1..n | +------+ | || +------------ | ,And |		| |1..n | +------+ | || +------------ | and |
	| +-----+ | || | Other |		| +-----+ | || | Other |
	| +------+ | || Mediating Network 2 | Components |		| +------+ | || Mediating Network 2 | Components |
	| +-----+ |local | | || +------------+ | |		| +-----+ |local | | || +------------+ | |
	| |Users| |AAA | | || |AAA Server; |====| |		| |Users| |AAA | | || |AAA Server; |====| |
	| |1..n | |Server|============| Other | +---------------+		| |1..n | |Server|============| Other | +---------------+
	| +-----+ +------+ | || | Components |		| +-----+ +------+ | || | Components |
	| | || +------------+		| | || +------------+
	+-------------------+ ||		+-------------------+ ||
	|| Mediating Network 3		|| Mediating Network 3
	|| +------------+ Home		|| +------------+ Home
	|| | | Network B		|| | | Network B
	|| |AAA Server; | +---------------+		|| |AAA Server; | +---------------+
	||====| Other |===|Home AAA Server|		||====| Other |===|Home AAA Server|
	|| | Components | | |		|| | Components | | |
	|| +------------+ | ,And |		|| +------------+ | and |
	|| | Other |		|| | Other |
	|| | Components |		|| | Components |
	||=====================| |		||=====================| |
	| |		| |
	+---------------+		+---------------+
	Figure 1. Network Access Arrangement.		Figure 1. Network Access Arrangement.
	In roaming situations, EAP authentication exchanges [6] will be		In roaming situations, EAP authentication exchanges [5] will be
	carried out between the wireless client in the access network and an		carried out between the wireless client in the access network and an
	AAA server in the home network directly when the two networks have a		AAA server in the home network directly when the two networks have a
	direct roaming relationship. However when a wireless client roams to		direct roaming relationship. However when a wireless client roams to
	an access network that it does not recognize and which does not have		an access network that it does not recognize and which does not have
	a direct roaming relationship with its home network, the AAA packets		a direct roaming relationship with its home network, the AAA packets
	have to be routed through a mediating AAA network to the home		have to be routed through a mediating AAA network to the home
	network. For inter operator settlement reasons, it is necessary to		network. For inter operator settlement reasons, it is necessary to
	select the best mediating network. For instance, in Figure 2, access		select the best mediating network. For instance, in Figure 2, access
	through the Mediating Network 1 may be cheaper for isp1 user, than if		through the Mediating Network 1 may be cheaper for isp1 user, than if
	Mediating Network 2 is used. However this decision can not be made by		Mediating Network 2 is used. However this decision can not be made
	the access network as it would be unaware of the roaming agreements		by the access network as it would be unaware of the roaming
	of mediating networks 1 and 2 with the isp1. For this reason, it is		agreements of mediating networks 1 and 2 with the isp1. For this
	desirable for the wireless client to know which mediating networks		reason, it is desirable for the wireless client to know which
	are available through an access network, and influence the decision		mediating networks are available through an access network, and
	of using the desired mediating network.		influence the decision of using the desired mediating network.
	+---------+		+---------+
	| |---------> "isp1.com"		| |---------> "isp1.com"
	| Roaming |		| Roaming |
	+---------+ | Group 1 |		+---------+ | Group 1 |
	| |-------->| |---------> "isp2.com"		| |-------->| |---------> "isp2.com"
	User "joe | Access | +---------+		User "joe | Access | +---------+
	@isp1.com"--->| Network |		@isp1.com"--->| Network |
	| | +---------+		| | +---------+
	| |-------->| |---------> "isp1.com"		| |-------->| |---------> "isp1.com"
	+---------+ | Roaming |		+---------+ | Roaming |
	| Group 2 |		| Group 2 |
	| |---------> "isp3.com"		| |---------> "isp3.com"
	+---------+		+---------+
	Figure 3: Ambiguous AAA routing		Figure 2: Ambiguous AAA routing
	Influencing the mediating network selection problem can be divided		Influencing the mediating network selection problem can be divided
	into three sub-problems as follows:		into three sub-problems as follows:
	1. A general data model and syntax by which network information is		1. A syntax by which mediating network information can be
	structured for unambiguous interpretation by the wireless client.		represented.
	2. A delivery mechanism by which network information is conveyed to		2. A delivery mechanism by which mediating network information is
	a wireless client.		conveyed to a wireless client.
	3. A general mechanism by which a wireless client's selection can be		3. A general mechanism by which a wireless client's selection can be
	conveyed to the access network.		conveyed to the access network.
	Section 2.7 of [7] discusses the conditions upon which NAIs can be		Section 2.7 of [6] discusses the conditions upon which NAIs can be
	used to affect AAA routing, i.e., problem 3 above. Problems 1 and 2		used to affect AAA routing, i.e., problem 3 above. Problems 1 and 2
	are discussed in this document.		are discussed in this document.
	1.1 Applicability		1.1 Applicability
	Although the proposed solution here is discussed in the context of		Although the proposed solution here is discussed in the context of
	public 802.11 access network deployment, it is applicable to other		public 802.11 access network deployment, it is applicable to other
	public wireless access networks where the wireless clients use the		public wireless access networks where the wireless clients use the
	EAP specification framework [6] for authentication, and they present		EAP specification framework [5] for authentication, and they present
	their identity to the network in NAI [7] format.		their identity to the network in NAI [6] format.
	1.2 Terminology		1.2 Terminology
	Network Access Identifier (NAI)		Network Access Identifier (NAI)
	An identifier that represents a wireless client or user		An identifier that represents a wireless client or user
	identity. The basic structure of a NAI is user@realm, where		identity. The basic structure of a NAI is user@realm, where
	the realm part of the NAI indicates the domain responsible		the realm part of the NAI indicates the domain responsible
	for interpretation and resolution of the user name. Please		for interpretation and resolution of the user name. Please
	See [7] for more details on NAI format.		See [6] for more details on NAI format.
	Access Point (AP)		Access Point (AP)
	A station that provides access to the distribution services		A station that provides access to the distribution services
	via the wireless medium for associated Stations.		via the wireless medium for associated Stations.
	RADIUS server		RADIUS server
	This is a server which provides for authentication/		This is a server which provides for authentication/
	authorization via the protocol described in [2], and for		authorization via the protocol described in [2].
	accounting as described in [5].
	2. Data Model		2. Data Model
	Network Information needs to be structured in a general format and		Mediating network information needs to be structured in a general
	syntax so that the EAP client software can interpret it and behave		format and syntax so that the EAP client software can interpret it
	accordingly. The syntax should have minimum overhead because the		and behave accordingly. The syntax should have minimum overhead
	proposed delivery mechanism (i.e., EAP-Identity Request) doesn't		because the proposed delivery mechanism (i.e., EAP-Identity Request)
	support fragmentation and therefore size of the data is limited by		doesn't support fragmentation and therefore size of the data is
	the link layer MTU.		limited by the link layer MTU.
	Network Information is placed after the displayable string and NULL		Mediating network information is placed after the displayable string
	in the EAP-Identity Request. It is structured as a set of		and NULL in the EAP-Identity Request. It is structured as a set of
	comma-separated attribute names and values according to the following		comma-separated attribute names and values according to the following
	ABNF [1]:		ABNF [1]:
	identity-request-data = displayable-string [ %d0 network-info ]		identity-request-data = displayable-string [ %d0 network-info ]
	displayable-string = *CHAR		displayable-string = *CHAR
	network-info = item ["," item ]		network-info = attribute "=" value
	item = attribute "=" value
	attribute = 1*( ALPHA / "-" / "_" / DIGIT)		attribute = 1*( ALPHA / "-" / "_" / DIGIT)
	value = 1*( 0x01-2B / 0x2D-FF ) ; any non-null UTF-8 char except ","		value = 1*( %x01-2B / %x2D-FF ) ; any non-null UTF-8 char except ","
	Only one attribute is defined here, the NAIRealms attribute. The use		The CHAR, DIGIT, ALPHA terminals are defined in [1].
			Only one attribute is defined here, the NAIRealms attribute. The use
	of this facility for other purposes is discouraged due to the limited		of this facility for other purposes is discouraged due to the limited
	amount of space available in EAP packets.		amount of space available in EAP packets.
	The content of the attribute (i.e., the value part) MUST NOT contain		The format and semantics of the NAIRealms attribute value are as
	a comma (","). The format and semantics of the NAIRealms attribute		follows:
	value are as follows:
	value = Realm [ ";" Realm ]		value = Realm [ ";" Realm ]
	Realm = *( domainlabel "." ) toplabel		Where the Realm is defined in [6].
	domainlabel = alphanum *( alphanum / "-" )
	toplabel = ALPHA *alphanum
	An example "NAIRealms" attribute is shown below:		An example "NAIRealms" attribute is shown below:
	NAIRealms=ipass.com;mnc123.mcc334.3gppnetwork.org		NAIRealms=anyisp.com;mnc123.mcc334.3gppnetwork.org
	3. Delivery Mechanism		3. Delivery Mechanism
	There are three possible options of delivering Network Information to		There are three possible options of delivering mediating network
	a wireless client by using an EAP-Identity Request. These options		information to a wireless client by using an EAP-Identity Request.
	are:		These options are:
	Option 1		Option 1 - Use the Initial EAP-Identity Request issued by the access
			network NAS
	Use a subsequent EAP-Identity Request issued by the access network		Mediating network information is pushed to a wireless client in
	RADIUS server.		the initial EAP-Identity Request issued by the AP.
	Option 2		Option 2 - Use the initial EAP-Identity Request issued by the access
			network RADIUS server
	Use the initial EAP-Identity Request issued by the access network		This is similar to Option 1, but the initial EAP-Identity Request
	RADIUS server.		is issued by the access network RADIUS Server instead. Once a
			wireless client associates with an access network AP using native
			IEEE 802.11 procedures, the AP sends an EAP-Start message [4]
			within a RADIUS Access-Request to trigger an EAP conversation
			initiated by the access network RADIUS server.
	Option 3		Option 3 - Use a subsequent EAP-Identity Request issued by the access
			network RADIUS server
	Use the Initial EAP-Identity Request issued by the access network		Mediating network information is delivered to a wireless client in
	NAS.		a subsequent EAP-Identity request, after the initial EAP-Identity
			Request/Response exchange, issued by by the access network RADIUS
			server.
	In general, an option that requires changes only to a central AAA		4. Implementation Considerations
			- In general, an option that requires changes only to a central AAA
	server is much preferred than a one that impacts a distributed set of		server is much preferred than a one that impacts a distributed set of
	APs. The reasons for this preference include ease of operation and		APs. The reasons for this preference include ease of operation and
	deployment, update costs, backwards compatibility and possible impact		deployment, update costs, backwards compatibility and possible impact
	on current standards. Option 1 is therefore preferred as it does not		on current standards. Option 3 is therefore preferred as it does not
	require any changes to the AP. Option 2 is also equally desirable if		require any changes to the AP. Option 2 is also equally desirable if
	the AP supports the EAP-Start message.		the AP supports the EAP-Start message [4].
	If the home network RADIUS server uses an updated User-Name
	attribute, for example, in RADIUS Access-Challenge and Access-Accept
	packets, then this SHOULD be used in subsequent RADIUS message flows
	between AP and Home RADIUS server.
	In order for a wireless client software implementation to work with		- In order for a wireless client software implementation to work with
	all options transparently, the implementation MUST not require the		all options transparently, the implementation MUST not require the
	arrival of network information on a particular EAP-Identity Request		arrival of mediating network information on a particular EAP-Identity
	(i.e., the initial or a subsequent Request). Access network		Request (i.e., the initial or a subsequent Request). Access network
	operators therefore MAY choose to deploy any of the above delivery		operators therefore MAY choose to deploy any of the above delivery
	mechanism options in their network without losing interoperability.		mechanism options in their network without losing interoperability.
	However, delivery mechanism options 1 and 2 are recommended as they		However, delivery mechanism options 2 and 3 are recommended as they
	are backward-compatible with the currently-deployed APs.		are backward-compatible with the currently-deployed APs.
	The following describes the three options with pros and cons of each.		- When Option 3 is used, upon receipt of a RADIUS Access-Request
			packet containing the initial EAP-Identity Response, the access
	Option 1		network RADIUS proxy/server MAY send an EAP-Identity Request
			containing mediating network information to the wireless client if it
	Network information is delivered to a wireless client in a		cannot route the RADIUS packet to the next AAA hop based on the realm
	subsequent EAP-Identity request after the initial		portion (i.e., string after the @ sign) of the NAI in the RADIUS
	EAP-Identity Request/Response exchange.		User-Name attribute. When a RADIUS Access-Request containing a
			subsequent EAP-Identity Response is received, if the RADIUS proxy/
	Upon receipt of a RADIUS Access-Request packet containing the		server still cannot route the RADIUS packet to the next AAA hop based
	initial EAP-Identity Response, the access network RADIUS		on the realm portion of the NAI, then it MUST discard the packet.
	proxy/server MAY send an EAP-Identity Request containing
	network information to the wireless client if it cannot route
	the RADIUS packet to the next AAA hop based on the realm
	portion (i.e., string after the @ sign) of the NAI in the
	RADIUS User-Name attribute.
	When a RADIUS Access-Request containing a subsequent
	EAP-Identity Response is received, if the RADIUS proxy/server
	still cannot route the RADIUS packet to the next AAA hop
	based on the realm portion of the NAI, then it MAY route the
	packet based on its local routing policy, or it MAY discard
	the packet.
	This option does not require any modifications to existing
	APs, and it uses a dedicated EAP-Identity Request for
	delivering network information and hence no contention
	problem for using the space in the Type-Data field. However,
	it introduces an extra EAP-Identity Request/Response pair and
	requires software upgrade on access network RADIUS server for
	administering and delivering network information in the
	EAP-Identity Request.
	Option 2
	This is similar to Option 1, but the initial EAP-Identity
	Request is issued by the access network RADIUS Server
	instead. Once a wireless client associates with an access
	network AP using native IEEE 802.11 procedures, the AP sends
	an EAP-Start message within a RADIUS Access-Request as
	defined in [4] to trigger an EAP conversation initiated by
	the access network RADIUS server.
	This option does not require any modifications to existing
	APs. However, it may not be backwards compatible if
	currently-deployed APs in access networks do not support
	EAP-Start. Besides, it may introduce a contention problem if
	the Type-Data field has already been used for other purposes.
	It also requires software upgrade on access network RADIUS
	server for administering and delivering network information
	in the EAP-Identity Request.
	Option 3		- The use of the mechanism described in this document SHOULD be
			reserved for situations where the WLAN client can not identify a
			direct route to its home network based on the available SSIDs in the
			hotspot.
	Network information is pushed to a wireless client in the		5. IANA Considerations
	initial EAP-Identity Request issued by the AP.
	This option requires modifications to APs, since most		This document does not define a new name space, therefore, there are
	currently-deployed APs do not include support for		no considerations for IANA.
	administering and delivering network information in the
	EAP-Identity Request. Furthermore, it may introduce a
	contention problem if the Type-Data field has already been
	used for other purposes.
	4. Security Considerations		6. Security Considerations
	Network Information delivered inside an EAP-Identity Request is		Mediating network information delivered inside an EAP-Identity
	considered as a hint in guiding the wireless client to select the		Request before the user authenticates to the network. Therefore, it
	desired MN. It SHOULD be treated similarly to the SSID in beacon		is considered as a hint in guiding the wireless client to select the
	broadcast: subject to modification and spoofing.		desired mediating network through which the AAA packets should be
			routed.
	It should also be noted that at least with some EAP methods, there is		It should also be noted that at least with some EAP methods, there is
	no way for the HSN RADIUS server to verify that the MN used was		no way for the home network RADIUS server to verify that the
	actually the same one that the wireless client had requested.		mediating network used was actually the same one that the wireless
			client had requested.
	5. Acknowledgement		7. Appendix
	The authors would specially like to thank Jari Arkko (of Ericsson)		The railroad diagrams below illustrate conversations between a
	for his help in scoping the problem, for reviewing the draft work in		wireless client, AP, Access Network (AN) RADIUS proxy/server,
	progress and for suggesting improvements to it.		Mediating Network (MN) RADIUS proxy/server, and Home Network (HN)
			RADIUS server for the three options described above.
	The authors would also like to acknowledge and thank Jari Arkko (of		Option 1 - Use the Initial EAP-Identity Request issued by the access
	Ericson), Bernard Aboba (of Microsoft), Adrian Buckley (of RIM),		network AP
	Blair Bullock (of iPass) , Jose Puthenkulam (of Intel), Johanna Wild
	(of Motorola), Joe Salowey (of Cisco), Marco Spini (of Telecom
	Italia), and Mark Grayson (of Cisco)for their support, feedback and
	guidance during the various stages of this work. This draft would not
	have been possible without their valuable input.
	6. References		Wireless AP AN RADIUS MN RADIUS HN RADIUS
			Client server server Server
			| (1) | | | |
			| EAP Id. Req. | | | |
			|(Network Info) | | | |
			|< -------------| | | |
			| | | | |
			| (2a) | | | |
			| EAP Id. Resp. | | | |
			|(Decorated NAI)| | | |
			| *OR* | | | |
			| (2b) | | | |
			| EAP Id. Resp. | | | |
			|(normal NAI) | | | |
			|------------- >| (3) | | |
			| |Access Request | | |
			| |(EAP Id. Resp.)| | |
			| |------------- >| (4) | |
			| | |Access Request | |
			| | |(EAP Id. Resp.)| |
			| | |------------- >| |
			| | | | |
			| | | |Access Request |
			| | | |(EAP Id. Resp.)|
			| | | (5) |------------- >|
			| ... | ... | ... | ... |
			| < EAP Authentication Methods > |
			| ... | | ... | ... |
			| | | | |
			| | | | |
			| EAP Success | | | |
			|< ------------ | | | |
			| | | | |
	6.1 Normative References		The following describes each message flow in details.
	[1] Crocker, D. and P. Overell, "Augmented BNF for Syntax		1. The AP sends the initial EAP-Identity Request containing
	Specifications: ABNF", RFC 2234, November 1997.		mediating network information to the wireless client.
	[2] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote		2. The wireless client sends an EAP-Identity Response containing a
	Authentication Dial In User Service (RADIUS)", RFC 2865, June		Decorated NAI indicating the selected MN to the AP. OR,
	2000.
	[3] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko,		3. The wireless client sends an EAP-Identity Response containing a
	"Diameter Base Protocol", RFC 3588, September 2003.		normal NAI (i.e., non-decorated)to the AP.
	[4] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In		4. The AP sends a RADIUS Access Request packet containing the
	User Service) Support For Extensible Authentication Protocol		EAP-Identity Response to the access network RADIUS proxy/server
	(EAP)", RFC 3579, September 2003.		as described in [4]. Please note that NAI in the EAP-Identity
			Response is copied to the RADIUS User-Name attribute in the
			Access-Request packet as per [4].
	[5] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.		5. The access network RADIUS proxy/server forwards the received
			Access-Request packet to the next AAA hop based on the realm
			portion of the NAI in the RADIUS User-Name attribute.
	[6] Blunk, L., "Extensible Authentication Protocol (EAP)",		6. The MN RADIUS proxy/server forwards the received Access-Request
	draft-ietf-eap-rfc2284bis-09 (work in progress), February 2004.		packet based on the NAI in the RADIUS User-Name attribute to the
			next AAA hop (i.e., HN RADIUS Server).
	[7] Aboba, B., "The Network Access Identifier",		7. The EAP Authentication continues as described in [4].
	draft-arkko-roamops-rfc2486bis-00 (work in progress), February
	2004.
	6.2 Informative References		Option 2 - Use the initial EAP-Identity Request issued by the access
			network RADIUS server.
	Authors' Addresses		Wireless AP AN RADIUS MN RADIUS HN RADIUS
			Client server server Server
	Farid Adrangi		| (1) | | | |
	Intel Corporation		| Association | | | |
			|------------ >| (2) | | |
			| |Access Request | | |
			| |(EAP-Start) | | |
			| |-------------- >| | |
			| | | | |
			| | (3) | | |
			| |Access Challenge| | |
			| |(EAP Id. Req. + | | |
			| | (Network Info) | | |
			| (4) |< --------------| | |
			| EAP Id. Req. | | | |
			|(Network Info)| | | |
			|< ------------| | | |
			| | | | |
			| (5a) | | | |
			|EAP Id. Resp. | | | |
			| | | | |
			| (5b) | | | |
			|EAP Id. Resp. | | | |
			|------------ >| (6) | | |
			| |Access Request | | |
			| |(EAP Id. Resp.) | | |
			| |-------------- >| (7) | |
			| | |Access Req. ( | |
			| | |EAP Id. Resp.)| |
			| | |------------ >| |
			| | | |Access Request |
			| | | |(EAP Id. Resp.)|
			| | | |------------- >|
			| ... | ... |.. | ... |
			| < EAP Authentication Methods > |
			| ... | |... | ... |
			| | | | |
			| EAP Success | | | |
			|< ------------| | | |
	EMail: farid.adrangi@intel.com		The following describes each message flow in details.
	Victor Lortz		1. The wireless client associates with the AP.
	Intel Corporation
	EMail: victor.lortz@intel.com		2. An EAP-Start message encapsulated within a RADIUS Access-Request
	Farooq Bari		sent to the access network RADIUS server.
	AT&T Wireless
	EMail: Farooq.bari@attws.com		3. The access network RADIUS server processes the received
			Access-Request message and initiates an EAP conversation by
			sending an EAP-Identity Request containing mediating network
			information encapsulated within a RADIUS Access-Challenge.
	Pasi Eronen		4. The AP extracts the EAP-Identity Request from the received
	Nokia		Access-Challenge and sends it to the wireless client.
	EMail: pasi.eronen@nokia.com		5. The wireless client sends an EAP-Identity Response containing its
			decorated NAI indicating the selected MN to the AP. OR,
	Mark Watson		6. The wireless client sends an EAP-Identity Response containing a
	Nortel		normal NAI (i.e., non-decorated) to the AP.
	EMail: mwatson@nortel.com		7. The AP sends a RADIUS Access-Request packet containing the
			EAP-Identity Response to the access network RADIUS server as
			described in [4]. Please note that NAI in the EAP-Identity
			Response is copied to the RADIUS User-Name attribute in the
			Access-Request packet as per [4].
	Appendix - Protocol Message Flow		8. The access network RADIUS proxy/server forwards the received
			Access-Request packet to the next AAA hop based on the realm
			portion of the NAI in the RADIUS User-Name attribute.
	The railroad diagrams below illustrate conversations between a		9. The MN RADIUS proxy/server forwards the received Access-Request
	wireless client, AP, Access Network (AN) RADIUS proxy/server,		packet based on the NAI in the RADIUS User-Name attribute to
	Mediating Network (MN) RADIUS proxy/server, and Home Network (HN)		the next AAA hop (i.e., HN RADIUS Server).
	RADIUS server for the three options described above.
	Option 1 - Use a subsequent EAP-Identity Request issued by the access		10. The EAP Authentication continues as described in [4].
			Option 3 - Use a subsequent EAP-Identity Request issued by the access
	network RADIUS server		network RADIUS server
	Wireless AP AN RADIUS MN RADIUS HN RADIUS		Wireless AP AN RADIUS MN RADIUS HN RADIUS
	Client server server Server		Client server server Server
	| (1) | | | |		| (1) | | | |
	| EAP Id. Req. | | | |		| EAP Id. Req. | | | |
	|< ------------| | | |		|< ------------| | | |
	| | | | |		| | | | |
	| (2) | | | |		| (2) | | | |
	| EAP Id. Resp.| | | |		| EAP Id. Resp.| | | |
	skipping to change at page 11, line 32 ¶		skipping to change at page 12, line 17 ¶
	| EAP Success | | | |		| EAP Success | | | |
	|< ------------| | | |		|< ------------| | | |
	The following describes each message flow in details.		The following describes each message flow in details.
	1. The access network AP issues an EAP-Identity Request to a		1. The access network AP issues an EAP-Identity Request to a
	wireless client		wireless client
	2. The wireless client replies with an EAP-Identity Response		2. The wireless client replies with an EAP-Identity Response
	containing a normal NAI (i.e., non-decorated), or perhaps a		containing a normal NAI (i.e., non-decorated), or perhaps a
	Decorated NAI [7] based on the network information cached from		Decorated NAI [6] based on the mediating network information
	the most recent authentication session to the access network.		cached from the most recent authentication session to the access
			network.
	3. The AP creates a RADIUS Access-Request packet encapsulating the		3. The AP creates a RADIUS Access-Request packet encapsulating the
	EAP-Identity Response and sends it to the access network RADIUS		EAP-Identity Response and sends it to the access network RADIUS
	server.		server.
	4. The access network RADIUS proxy/server sends a RADIUS		4. The access network RADIUS proxy/server sends a RADIUS
	Access-Challenge packet encapsulating an EAP-Identity Request		Access-Challenge packet encapsulating an EAP-Identity Request
	containing Network Information. Or, the step 8 is executed if		containing mediating network information. Or, the step 8 is
	the access network proxy/server can route the packet based on the		executed if the access network proxy/server can route the packet
	realm portion of the NAI in the RADIUS User-Name attribute to the		based on the realm portion of the NAI in the RADIUS User-Name
	next AAA hop.		attribute to the next AAA hop.
	5. The access network AP forwards the EAP-Identity Request		5. The access network AP forwards the EAP-Identity Request
	containing the network information to the wireless client.		containing the mediating network information to the wireless
			client.
	6. The wireless client replies with an EAP-Identity Response		6. The wireless client replies with an EAP-Identity Response
	containing a Decorated NAI indicating the preferred MN. It should		containing a Decorated NAI indicating the preferred MN. Wireless
	be noted that the wireless client may also decide not to connect		client can still send an undecorated NAI to the RADIUS proxy/
	to the access network in the absence of the desired Mediating		server, if it is a legacy client. It should also be noted that
	Network in the received network information in step (4).		the wireless client may also decide not to connect to the access
			network in the absence of the desired MN in the received MN
			information in step (4).
	7. The access network AP forwards the EAP-Identity Response to the		7. The access network AP forwards the EAP-Identity Response to the
	access network RADIUS server over RADIUS protocol.		access network RADIUS server over RADIUS protocol.
	8. The access network RADIUS proxy/server forwards the received		8. The access network RADIUS proxy/server forwards the received
	Access Request to the appropriate MN RADIUS server based on the		Access Request to the appropriate MN RADIUS server based on the
	realm portion of the NAI in the RADIUS User-Name attribute.		realm portion of the NAI in the RADIUS User-Name attribute.
	9. The MN RADIUS proxy/server forwards the received Access-Request		9. The MN RADIUS proxy/server forwards the received Access-Request
	packet based on the NAI in the RADIUS User-Name attribute to the		packet based on the NAI in the RADIUS User-Name attribute to the
	next AAA hop (i.e., HN RADIUS Server). The EAP Authentication		next AAA hop (i.e., HN RADIUS Server). The EAP Authentication
	continues as described in [4].		continues as described in [4].
	Option 2 - Use the initial EAP-Identity Request issued by the access		8. Acknowledgement
	network RADIUS server.
	Wireless AP AN RADIUS MN RADIUS HN RADIUS
	Client server server Server
	| (1) | | | |
	| Association | | | |
	|------------ >| (2) | | |
	| |Access Request | | |
	| |(EAP-Start) | | |
	| |-------------- >| | |
	| | | | |
	| | (3) | | |
	| |Access Challenge| | |
	| |(EAP Id. Req. + | | |
	| | (Network Info) | | |
	| (4) |< --------------| | |
	| EAP Id. Req. | | | |
	|(Network Info)| | | |
	|< ------------| | | |
	| | | | |
	| (5a) | | | |
	|EAP Id. Resp. | | | |
	| | | | |
	| (5b) | | | |
	|EAP Id. Resp. | | | |
	|------------ >| (6) | | |
	| |Access Request | | |
	| |(EAP Id. Resp.) | | |
	| |-------------- >| (7) | |
	| | |Access Req. ( | |
	| | |EAP Id. Resp.)| |
	| | |------------ >| |
	| | | |Access Request |
	| | | |(EAP Id. Resp.)|
	| | | |------------- >|
	| ... | ... |.. | ... |
	| < EAP Authentication Methods > |
	| ... | |... | ... |
	| | | | |
	| EAP Success | | | |
	|< ------------| | | |
	The following describes each message flow in details.		The authors would specially like to thank Jari Arkko (of Ericsson)
			for his help in scoping the problem, for reviewing the draft work in
			progress and for suggesting improvements to it.
	1. The wireless client associates with the AP.		The authors would also like to acknowledge and thank Jari Arkko (of
			Ericson), Bernard Aboba (of Microsoft), Adrian Buckley (of RIM),
			Blair Bullock (of iPass) , Jose Puthenkulam (of Intel), Johanna Wild
			(of Motorola), Joe Salowey (of Cisco), Marco Spini (of Telecom
			Italia), Simone Ruffino (of Telecom Italia) and Mark Grayson (of
			Cisco)for their support, feedback and guidance during the various
			stages of this work.
	2. An EAP-Start message encapsulated within a RADIUS Access-Request		9. References
	sent to the access network RADIUS server.
	3. The access network RADIUS server processes the received		9.1 Normative References
	Access-Request message and initiates an EAP conversation by
	sending an EAP-Identity Request containing Network Information
	encapsulated within a RADIUS Access-Challenge.
	4. The AP extracts the EAP-Identity Request from the received		[1] Crocker, D. and P. Overell, "Augmented BNF for Syntax
	Access-Challenge and sends it to the wireless client.		Specifications: ABNF", RFC 2234, November 1997.
	5. The wireless client sends an EAP-Identity Response containing		[2] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
	its decorated NAI indicating the selected MN to the AP. OR,		Authentication Dial In User Service (RADIUS)", RFC 2865, June
			2000.
	6. The wireless client sends an EAP-Identity Response containing a		[3] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko,
	normal NAI (i.e., non-decorated) to the AP.		"Diameter Base Protocol", RFC 3588, September 2003.
	7. The AP sends a RADIUS Access-Request packet containing the		[4] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In
	EAP-Identity Response to the access network RADIUS server as		User Service) Support For Extensible Authentication Protocol
	described in [4]. Please note that NAI in the EAP-Identity		(EAP)", RFC 3579, September 2003.
	Response is copied to the RADIUS User-Name attribute in the
	Access-Request packet as per [4].
	8. The access network RADIUS proxy/server forwards the received		[5] Blunk, L., "Extensible Authentication Protocol (EAP)",
	Access-Request packet to the next AAA hop based on the realm		draft-ietf-eap-rfc2284bis-09 (work in progress), February 2004.
	portion of the NAI in the RADIUS User-Name attribute.
	9. The MN RADIUS proxy/server forwards the received Access-Request		[6] Aboba, B., "The Network Access Identifier",
	packet based on the NAI in the RADIUS User-Name attribute to		draft-arkko-roamops-rfc2486bis-00 (work in progress), February
	the next AAA hop (i.e., HSN RADIUS Server).		2004.
	10. The EAP Authentication continues as described in [4].		9.2 Informative References
			Authors' Addresses
	[Option 3] Use the Initial EAP-Identity Request issued by the access		Farid Adrangi
	network AP		Intel Corporation
			2111 N.E. 25th Avenue
			Hillsboro OR
			USA
	Wireless AP AN RADIUS MN RADIUS HN RADIUS		Phone: +1 503-712-1791
	Client server server Server		EMail: farid.adrangi@intel.com
	| (1) | | | |
	| EAP Id. Req. | | | |
	|(Network Info) | | | |
	|< -------------| | | |
	| | | | |
	| (2a) | | | |
	| EAP Id. Resp. | | | |
	|(Decorated NAI)| | | |
	| *OR* | | | |
	| (2b) | | | |
	| EAP Id. Resp. | | | |
	|(normal NAI) | | | |
	|------------- >| (3) | | |
	| |Access Request | | |
	| |(EAP Id. Resp.)| | |
	| |------------- >| (4) | |
	| | |Access Request | |
	| | |(EAP Id. Resp.)| |
	| | |------------- >| |
	| | | | |
	| | | |Access Request |
	| | | |(EAP Id. Resp.)|
	| | | (5) |------------- >|
	| ... | ... | ... | ... |
	| < EAP Authentication Methods > |
	| ... | | ... | ... |
	| | | | |
	| | | | |
	| EAP Success | | | |
	|< ------------ | | | |
	| | | | |
	The following describes each message flow in details.		Victor Lortz
			Intel Corporation
			2111 N.E. 25th Avenue
			Hillsboro OR
			USA
	1. The AP sends the initial EAP-Identity Request containing Network		Phone: +1 503-264-3253
	Information to the wireless client.		EMail: victor.lortz@intel.com
	2. The wireless client sends an EAP-Identity Response containing a		Farooq Bari
	Decorated NAI indicating the selected MN to the AP. OR,		AT&T Wireless
			7277 164th Avenue N.E.
			Redmond WA
			USA
	3. The wireless client sends an EAP-Identity Response containing a		Phone: +1 425-580-5526
	normal NAI (i.e., non-decorated)to the AP.		EMail: Farooq.bari@attws.com
	4. The AP sends a RADIUS Access Request packet containing the		Pasi Eronen
	EAP-Identity Response to the access network RADIUS proxy/server		Nokia Research Center
	as described in [4]. Please note that NAI in the EAP-Identity		P.O. Box 407
	Response is copied to the RADIUS User-Name attribute in the		FIN-0005 Nokia Group
	Access-Request packet as per [4].		Finland
	5. The access network RADIUS proxy/server forwards the received		EMail: pasi.eronen@nokia.com
	Access-Request packet to the next AAA hop based on the realm
	portion of the NAI in the RADIUS User-Name attribute.
	6. The MN RADIUS proxy/server forwards the received Access-Request		Mark Watson
	packet based on the NAI in the RADIUS User-Name attribute to the		Nortel
	next AAA hop (i.e., HSN RADIUS Server).		2221, Lakeside Blvd
			Richardson TX
			USA
	7. The EAP Authentication continues as described in [4].		EMail: mwatson@nortel.com
	Intellectual Property Statement		Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the IETF's procedures with respect to rights in IETF Documents can		on the procedures with respect to rights in RFC documents can be
	be found in BCP 78 and BCP 79.		found in BCP 78 and BCP 79.
	Copies of IPR disclosures made to the IETF Secretariat and any		Copies of IPR disclosures made to the IETF Secretariat and any
	assurances of licenses to be made available, or the result of an		assurances of licenses to be made available, or the result of an
	attempt made to obtain a general license or permission for the use of		attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.		ietf-ipr@ietf.org.
	Disclaimer of Validity		Disclaimer of Validity
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Copyright Statement		Copyright Statement
	Copyright (C) The Internet Society (2004). This document is subject		Copyright (C) The Internet Society (2004). This document is subject
	to the rights, licenses and restrictions contained in BCP 78, and		to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.		except as set forth therein, the authors retain all their rights.
	Acknowledgment		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the
	Internet Society.		Internet Society.
End of changes. 115 change blocks.
	356 lines changed or deleted		343 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/