draft-ietf-geopriv-radius-lo-04.txt		draft-ietf-geopriv-radius-lo-06.txt
	Geopriv H. Tschofenig		Geopriv H. Tschofenig
	Internet-Draft Siemens		Internet-Draft Siemens
	Expires: January 17, 2006 F. Adrangi		Expires: September 7, 2006 F. Adrangi
	Intel		Intel
	M. Jones		M. Jones
	A. Lior		A. Lior
	Bridgewater		Bridgewater
	July 16, 2005		March 6, 2006
	Carrying Location Objects in RADIUS		Carrying Location Objects in RADIUS
	draft-ietf-geopriv-radius-lo-04.txt		draft-ietf-geopriv-radius-lo-06.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		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 becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of 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 38		skipping to change at page 1, line 38
	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 January 17, 2006.		This Internet-Draft will expire on September 7, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	This document describes RADIUS attributes for conveying access		This document describes RADIUS attributes for conveying access
	network ownership and location information based on a civic and		network ownership and location information based on a civic and
	geospatial location format.		geospatial location format.
	The distribution of location information is a privacy sensitive task.		The distribution of location information is a privacy sensitive task.
	Dealing with mechanisms to preserve the user's privacy is important		Dealing with mechanisms to preserve the user's privacy is important
	and addressed in this document.		and addressed in this document.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Delivery Methods for Location Information . . . . . . . . . . 7		3. Delivery Methods for Location Information . . . . . . . . . . 6
	3.1 Authentication/Authorization Phase Delivery . . . . . . . 7		3.1. Authentication/Authorization Phase Delivery . . . . . . . 6
	3.2 Mid-session Authorization . . . . . . . . . . . . . . . . 8		3.2. Mid-session Authorization . . . . . . . . . . . . . . . . 9
	4. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 10		4. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	4.1 Scenario 1 - Use of Location Information in AAA . . . . . 10		4.1. Scenario 1 - Use of Location Information in AAA . . . . . 11
	4.2 Scenario 2 - Use of Location Information for Other		4.2. Scenario 2 - Use of Location Information for Other
	Services . . . . . . . . . . . . . . . . . . . . . . . . . 10		Services . . . . . . . . . . . . . . . . . . . . . . . . . 12
	5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 12		5. Description of Attributes . . . . . . . . . . . . . . . . . . 13
	5.1 Operator-Namespace Attribute . . . . . . . . . . . . . . . 12		5.1. Operator-Name Attribute . . . . . . . . . . . . . . . . . 13
	5.2 Operator-Name Attribute . . . . . . . . . . . . . . . . . 12		5.2. Location-Information Attribute . . . . . . . . . . . . . . 14
	5.3 Location-Information Attribute . . . . . . . . . . . . . . 13		5.2.1. Civic Location Information . . . . . . . . . . . . . . 14
	5.3.1 Civic Location Information . . . . . . . . . . . . . . 13		5.2.2. Geospatial Location Information . . . . . . . . . . . 16
	5.3.2 Geospatial Location Information . . . . . . . . . . . 15		6. Basic- and Extended-Policy-Rule Attributes . . . . . . . . . . 17
	6. Basic- and Extended-Policy-Rule Attributes . . . . . . . . . . 16		7. Requested-Info Attribute . . . . . . . . . . . . . . . . . . . 18
	7. Location-Type Attribute . . . . . . . . . . . . . . . . . . . 17		8. Diameter RADIUS Interoperability . . . . . . . . . . . . . . . 20
	8. Capability Attribute . . . . . . . . . . . . . . . . . . . . . 18		9. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 21
	9. Diameter RADIUS Interoperability . . . . . . . . . . . . . . . 20		9.1. Operator-Name Attribute . . . . . . . . . . . . . . . . . 21
	10. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . 21		9.2. Location-Information Attribute . . . . . . . . . . . . . . 21
	10.1 Operator-Namespace Attribute . . . . . . . . . . . . . . . 21		9.3. Basic Policy Rules Attribute . . . . . . . . . . . . . . . 26
	10.2 Operator-Name Attribute . . . . . . . . . . . . . . . . . 21		9.4. Extended Policy Rules Attribute . . . . . . . . . . . . . 27
	10.3 Location-Information Attribute . . . . . . . . . . . . . . 22		9.5. Challenge-Capable Attribute . . . . . . . . . . . . . . . 28
	10.4 Basic Policy Rules Attribute . . . . . . . . . . . . . . . 26		9.6. Requested-Info Attribute . . . . . . . . . . . . . . . . . 28
	10.5 Extended Policy Rules Attribute . . . . . . . . . . . . . 27		10. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 32
	10.6 Location-Type Attribute . . . . . . . . . . . . . . . . . 28		11. Matching with Geopriv Requirements . . . . . . . . . . . . . . 33
	10.7 Capability Attribute . . . . . . . . . . . . . . . . . . . 28		11.1. Distribution of Location Information at the User's
	11. Table of Attributes . . . . . . . . . . . . . . . . . . . . 31		Home Network . . . . . . . . . . . . . . . . . . . . . . . 33
	12. Matching with Geopriv Requirements . . . . . . . . . . . . . 32		11.2. Distribution of Location Information at the Visited
	12.1 Distribution of Location Information at the User's		Network . . . . . . . . . . . . . . . . . . . . . . . . . 34
	Home Network . . . . . . . . . . . . . . . . . . . . . . . 32		11.3. Requirements matching . . . . . . . . . . . . . . . . . . 35
	12.2 Distribution of Location Information at the Visited		12. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
	Network . . . . . . . . . . . . . . . . . . . . . . . . . 33		13. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 43
	12.3 Requirements matching . . . . . . . . . . . . . . . . . . 34		13.1. Entity in the visited network . . . . . . . . . . . . . . 43
	13. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 40		13.2. Entity in the home network . . . . . . . . . . . . . . . . 44
	14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 42		14. Security Considerations . . . . . . . . . . . . . . . . . . . 47
	14.1 Entity in the visited network . . . . . . . . . . . . . . 42		15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50
	14.2 Entity in the home network . . . . . . . . . . . . . . . . 43		15.1. New Registry: Operator Type . . . . . . . . . . . . . . . 50
	15. Security Considerations . . . . . . . . . . . . . . . . . . 46		15.2. New Registry: Requested-Info attribute . . . . . . . . . . 51
	16. IANA Considerations . . . . . . . . . . . . . . . . . . . . 49		16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52
	16.1 New Registry: Operator Type . . . . . . . . . . . . . . . 49		17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54
	16.2 New Registry: Capabilities . . . . . . . . . . . . . . . . 49		17.1. Normative References . . . . . . . . . . . . . . . . . . . 54
	17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 51		17.2. Informative References . . . . . . . . . . . . . . . . . . 54
	18. References . . . . . . . . . . . . . . . . . . . . . . . . . 52		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 57
	18.1 Normative References . . . . . . . . . . . . . . . . . . . 52		Intellectual Property and Copyright Statements . . . . . . . . . . 58
	18.2 Informative References . . . . . . . . . . . . . . . . . . 52
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 55
	Intellectual Property and Copyright Statements . . . . . . . . 56
	1. Introduction		1. Introduction
	Wireless LAN (WLAN) access networks are being deployed in public		Wireless LAN (WLAN) access networks are being deployed in public
	places such as airports, hotels, shopping malls, and coffee shops by		places such as airports, hotels, shopping malls, and coffee shops by
	a diverse set of operators such as cellular network operators (GSM		a diverse set of operators such as cellular network operators (GSM
	and CDMA), Wireless Internet Service Providers (WISPs), and fixed		and CDMA), Wireless Internet Service Providers (WISPs), and fixed
	broadband operators.		broadband operators.
	When a user executes the network access authentication procedure to		When a user executes the network access authentication procedure to
	skipping to change at page 5, line 35		skipping to change at page 4, line 35
	related information to the user's home AAA server. This document		related information to the user's home AAA server. This document
	defines attributes for RADIUS [1].		defines attributes for RADIUS [1].
	Although the proposed attributes in this draft are intended for		Although the proposed attributes in this draft are intended for
	wireless LAN deployments, they can also be used in other types of		wireless LAN deployments, they can also be used in other types of
	wireless and wired networks whenever location information is		wireless and wired networks whenever location information is
	required.		required.
	Location information needs to be protected against unauthorized		Location information needs to be protected against unauthorized
	access and distribution to preserve the user's privacy with regard to		access and distribution to preserve the user's privacy with regard to
	location information. [11] defines requirements for a protocol-		location information. [12] defines requirements for a protocol-
	independent model for the access to geographic location information.		independent model for the access to geographic location information.
	The model includes a Location Generator (LG) that creates location		The model includes a Location Generator (LG) that creates location
	information, a Location Server (LS) that authorizes access to		information, a Location Server (LS) that authorizes access to
	location information, a Location Recipient (LR) that requests and		location information, a Location Recipient (LR) that requests and
	receives information, and a Rule Maker (RM) that provides		receives information, and a Rule Maker (RM) that provides
	authorization policies to the LS which enforces access control		authorization policies to the LS which enforces access control
	policies on requests to location information.		policies on requests to location information.
	Althougth this document focuses on the use cases of location based
	authorization, charging, billing and taxation for network access
	RADIUS might also be used for location-based authorization for
	application layer services as well. The extensions defined in this
	document are therefore not only applicable to a network access
	scenario. A further description of these scenarios is outside the
	scope of this document.
	2. Terminology		2. Terminology
	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", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [2].		document are to be interpreted as described in [2].
	RADIUS specific terminology is borrowed from [1] and [3].		RADIUS specific terminology is borrowed from [1] and [3].
	Terminology related to privacy issues, location information and		Terminology related to privacy issues, location information and
	authorization policy rules is taken from [11].		authorization policy rules is taken from [12].
	Based on today's protocols we assume that the location information is		Based on today's protocols we assume that the location information is
	provided by the access network where the end host is attached. As		provided by the access network where the end host is attached. As
	part of the network attachment, which includes the execution of an		part of the network attachment authentication to the home network is
	authentication and authorization protocol exchange, authentication is		provided. The authenticated identity might refer to a user, a device
	accomplished. The authenticated identity can refer to a user, a		or something else. Although there might often be a user associated
	device or something else. Although there might often be a user		with the authentication process (either directly or indirectly;
	associated with the authentication process (either directly or		indirectly when a binding between a device and a user exists) there
	indirectly; indirectly when a binding between a device and a user		is no assurance that a particular real-world entity (such as a
	exists) there is no assurance that a particular real-world entity		person) triggered this process. Since location based authorization
	(such as a person) triggered this process. Since location based		is executed based on the network access authentication of a
	authorization is executed based on the network access authentication		particular "user" it might be reasonable to talk about user's privacy
	of a particular "user" it might be reasonable to talk about user's		within this document even though scenarios exist where this might not
	privacy within this document even though scenarios exist where this		apply (and device or network privacy might be the correct term).
	might not apply (and device or network privacy might be the correct		Furthermore, the authors believe that there is a relationship between
	term). Furthermore, the authors believe that there is a relationship		the NAS (or other nodes in the access network) and the location of
	between the location of the network and the location of the entity		the entity that triggered the network access authentication, such as
	that triggered the network access authentication. Knowing the		the user. Knowing the location of a network (where the user or end
	location of a network (where the user or end host is attached to)		host is attached to) might in many networks also reveal the location
	might in many networks also reveal the location of the user or end		of the user or end host. In some networks it is even possible to
	host. In some networks it is even possible to provide a accurate		provide accurate location of the user or end host. A similar
	location of the user or end host. A similar assumption is also made		assumption is also made with regard to the location information
	with regard to the location information obtained via DHCP (see for		obtained via DHCP (see for example [4]). This information might be
	example [4]). This information might be used by applications in		used by applications in other protocols (such as SIP [13] with
	other protocols (such as SIP [12] with extensions [13]) to indicate		extensions [14]) to indicate the location of a particular user even
	the location of a particular user even though the location "only"		though the location "only" refers to the location of the network or
	refers to the location of the network or equipment within the		equipment within the network. This assumption might not hold in all
	network. The assumption here is also that the location of the		scenarios but seems to be reasonable and practicable.
	network has some relationship to the location of the end host (and
	subsequently to a user). This assumption might not hold in all
	scenarios. Nevertheless, it seems to be reasonable.
	Please note that the authors use the terms end host and user		Please note that the authors use the terms end host and user
	interchangably with respect to the used identities as part of the		interchangably with respect to the used identities as part of the
	network access authentication. The term 'user' is used whenever the		network access authentication. The term 'user' is used whenever the
	privacy of the user could potentially be compromised.		privacy of the user could potentially be compromised.
	3. Delivery Methods for Location Information		3. Delivery Methods for Location Information
	Location Objects, which consist of location information and privacy		Location Objects, which consist of location information and privacy
	rules, are transported over the RADIUS protocol from visited access		rules, are transported over the RADIUS protocol from the visited
	network to the home AAA server. To embed a Location Object into		access network to the home AAA server. To embed a Location Object
	RADIUS a number of AVPs are used, such as Location-Information AVP,		into RADIUS a number of attribute are used, such as Location-
	Basic-Policy-Rules AVP, Extended-Policy-Rules AVP, Location-Type AVP,		Information attribute, Basic-Policy-Rules attribute, Extended-Policy-
	Operator-Namespace AVP and Operator-Name AVP. These AVPs can be		Rules attribute, Operator-Name attribute. These attributes can be
	delivered to the RADIUS server during the authentication/		delivered to the RADIUS server during the authentication/
	authorization phase described in Section 3.1, or in the mid-session		authorization phase described in Section 3.1, or in the mid-session
	using the dynamic authorization protocol framework described in		using the dynamic authorization protocol framework described in
	Section 3.2. This section describes messages flow for both delivery		Section 3.2. This section describes messages flows for both delivery
	methods.		methods.
	3.1 Authentication/Authorization Phase Delivery		3.1. Authentication/Authorization Phase Delivery
	Figure 1 shows an example message flow for delivering location		Figure 1 shows an example message flow for delivering location
	information during the network access authentication/authorization		information during the network access authentication/authorization
	procedure. Upon a network authentication request from an access		procedure. Upon a network authentication request from an access
	network client, the NAS submits a RADIUS Access-Request message which		network client, the NAS submits a RADIUS Access-Request message which
	contains location information attributes among other required		contains location information attributes among other required
	attributes. The attributes (including location information) are		attributes. The attributes (including location information) are
	added based on some criteria, such as local policy and business		added based on some criteria, such as local policy and business
	relationship with subscriber's home network provider. If no location		relationship with subscriber's home network provider.
	information is attached although required by the aaa server an error
	message is returned.
	The authentication and/or authorization procedure is completed based		+---------+ +---------+ +---------+
	on a number of criteria, including the newly defined Location-		| Network | | Network | | AAA |
	Information, Operator-Namespace, Operator-Name, Location-Type,		| Access | | Access | | Server |
	Policy-Information attributes. A RADIUS Accounting Request message		| Client | | Server | | |
	may also carry location specific attributes.		+---------+ +---------+ +---------+
			| | |
			| Authentication phase | |
			| begin | |
			|---------------------->| |
			| | |
			| | RADIUS |
			| | Access-Request |
			| | + Location-Information |
			| |----------------------------->|
			| | |
			| | RADIUS |
			| | Access-Accept |
			| |<-----------------------------|
			| Authentication | |
			| Success | |
			|<----------------------| |
			| | |
			| | RADIUS |
			| | Accounting-Request |
			| | + Location-Information |
			| |----------------------------->|
			| | |
			Figure 1: Location Delivery based on out-of-band Agreements
			If no location information is provided by the RADIUS client although
			it is required by the RADIUS server to compute an authorization
			decision then the RADIUS server challenges the RADIUS client. This
			exchange is shown in Figure 2. The Access-Challenge thereby provides
			a hint to Network Access Server regarding the type of location
			information attributes that are desired. In the shown message flow
			these attributes are then provided in the subsequent Access-Request
			message. When receiving this Access-Request message the
			authorization procedure at the RADIUS server might be based on a
			number of criteria, including the newly defined Location-Information
			and Operator-Name attributes.
	+---------+ +---------+ +---------+		+---------+ +---------+ +---------+
	| Network | | Network | | AAA |		| Network | | Network | | AAA |
	| Access | | Access | | Server |		| Access | | Access | | Server |
	| Client | | Server | | |		| Client | | Server | | |
	+---------+ +---------+ +---------+		+---------+ +---------+ +---------+
	| | |		| | |
	| Authentication phase | |		| Authentication phase | |
	| begin | |		| begin | |
	|---------------------->| |		|---------------------->| |
	| | |		| | |
			| | RADIUS |
			| | Access-Request |
			| | + Challenge-Capable |
			| |----------------------------->|
			| | |
			| | RADIUS |
			| | Access-Challenge |
			| | + Rule set Information |
			| | + Requested-Info |
			| |<-----------------------------|
	| | |		| | |
	| | RADIUS |		| | RADIUS |
	| | Access-Request |		| | Access-Request |
	| | + Location-Information |		| | + Location-Information |
	| | attributes |
	| |----------------------------->|		| |----------------------------->|
	| | |		| | |
	: : :		: : :
	: Multiple Protocol Exchanges to perform :		: Multiple Protocol Exchanges to perform :
	: Authentication, Key Exchange and Authorization :		: Authentication, Key Exchange and Authorization :
	: ...continued... :		: ...continued... :
	: : :		: : :
			| | |
	| | RADIUS |		| | RADIUS |
	| | Access-Accept |		| | Access-Accept |
	| | + Rule set Information |		| | + Requested-Info |
	| |<-----------------------------|		| |<-----------------------------|
	| Authentication | |		| Authentication | |
	| Accept | |		| Success | |
	|<----------------------| |		|<----------------------| |
	| | |		| | |
	| | RADIUS |		| | RADIUS |
	| | Accounting Request |		| | Accounting-Request |
	| | + Location-Information |		| | + Location-Information |
	| | attributes |
	| |----------------------------->|		| |----------------------------->|
	| | |		| | |
	Figure 1: Message Flow: Authentication/Authorization Phase Delivery		Figure 2: Location Delivery based on dynamic Request
			If the AAA server needs to obtain location information also in
			accounting messages then it needs to include a Requested-Info
			attribute to the Access-Accept to express that is desired. The
			Network Access Server SHOULD then include location information to the
			RADIUS accounting messages.
	3.2 Mid-session Authorization		3.2. Mid-session Authorization
	The mid-session delivery method uses the Change of Authorization		The mid-session delivery method uses the Change of Authorization
	(COA) message as defined in [5]. At anytime during the session the		(COA) message as defined in [5]. At anytime during the session the
	AAA server MAY send a COA message containing session identification		RADIUS server MAY send a COA message containing session
	attributes to the access network. The COA message may instruct the		identification attributes to the access network. The COA message MAY
	access network to generate an Authorize-Only Access-Request (Access-		instruct the RADIUS client to generate an Authorize-Only Access-
	Request with Service-Type set to "Authorize-Only") in which case the		Request (Access-Request with Service-Type set to "Authorize-Only") in
	NAS MUST include the location infromation in this Access-Request.		which case the RADIUS client MUST include location information in
			this Access-Request if it included location information is previous
			Access-Request messages.
	Figure 2 shows the approach graphically.		Figure 3 shows the approach graphically.
	+---------+ +---------+		+---------+ +---------+
	| AAA | | AAA |		| AAA | | AAA |
	| Client | | Server |		| Client | | Server |
	| (NAS) | | |		| (NAS) | | |
	+---------+ +---------+		+---------+ +---------+
	| |		| |
	| COA + Service-Type "Authorize Only" |		| COA + Service-Type "Authorize Only" |
	|<----------------------------------------------|		|<----------------------------------------------|
	| |		| |
	| COA NAK + Service-Type "Authorize Only" |		| COA NAK + Service-Type "Authorize Only" |
	| + Error-Cause "Request Initiated" |		| + Error-Cause "Request Initiated" |
	|---------------------------------------------->|		|---------------------------------------------->|
	| |		| |
	| Access-Request + Service-Type "Authorize Only"|		| Access-Request + Service-Type "Authorize Only"|
	| + Location Information attributes |		| + Location-Information |
	| + Location Information policy |		| + Policy-Rules |
	|---------------------------------------------->|		|---------------------------------------------->|
	| |		| |
	| Access-Accept |		| Access-Accept |
	|<----------------------------------------------|		|<----------------------------------------------|
	| |		| |
	Figure 2: Message Flow: Mid-session Authorization		Figure 3: Mid-session Authorization
	Upon receiving the Authorize-Only message from the access network,		Upon receiving the Access-Request message containing the Service-Type
	the AAA server MUST respond with either an Access-Accept message or		hint attribute with a value of Authorize-Only from the NAS, the
	an Access-Reject message.		RADIUS server MUST respond with either an Access-Accept or an Access-
			Reject message.
	4. Scenarios		4. Scenarios
	In the following subsections we describe two scenarios for use of		In the following subsections we describe two scenarios for use of
	location information. The location information may refer to the		location information. The location information may refer to the
	(visited) network or to the user. How the network obtains the user's		(visited) network or to the user. How the network obtains the user's
	location information is out of the scope of this document. There are		location information is out of the scope of this document. There are
	two consumers of location information: the AAA server and location-		two potential consumers of location information: the AAA server and
	based services. The privacy implications of these scenarios are		location-based services. The privacy implications of these scenarios
	described in Section 14.		are described in Section 13.
	4.1 Scenario 1 - Use of Location Information in AAA		4.1. Scenario 1 - Use of Location Information in AAA
	The home network operator requires location information for		The home network operator requires location information for
	authorization and billing purposes. The operator may deny service if		authorization and billing purposes. The operator may deny service if
	location information is not available, or it may offer limited		location information is not available, or it may offer limited
	service. The NAS delivers location information to the home AAA		service. The NAS delivers location information to the home AAA
	server.		server.
	The user's location is transferred from the NAS to the RADIUS server.		The location of the AAA client and/or the end host is transferred
	The NAS and intermediaries (if any) are not allowed to use that		from the NAS to the RADIUS server (based on a pre-established
	information other than to forward it to the home network.		agreement or if the RADIUS server asks for it). The NAS and
			intermediaries (if any) are not allowed to use that information other
			than to forward it to the home network.
	The RADIUS server authenticates and authorizes the user requesting		The RADIUS server authenticates and authorizes the user requesting
	access to the network. If the user's location policies are available		access to the network. If the user's location policies are available
	to the RADIUS server, the RADIUS server must deliver those policies		to the RADIUS server, the RADIUS server MUST deliver those policies
	in an Access Accept to the RADIUS client. This information may be		in an Access Accept to the RADIUS client. This information MAY be
	needed if intermediaries or other elements want to act as Location		needed if intermediaries or other elements want to act as Location
	Servers (see Section 4.2). If intermediaries do not receive these		Servers (see Section 4.2). If the NAS or intermediaries do not
	policies then they MUST NOT make any use of the location information		receive policies from the RADIUS server (or the end host itself) then
	other than forwarding it to the home network.		they MUST NOT make any use of the location information other than
			forwarding it to the user's home network.
	Location Information may also be reported in accounting messages.		Location Information may also be reported in accounting messages.
	Accounting messages are generated when the session starts, stops and		Accounting messages are generated when the session starts, stops and
	periodically. Accounting messages may also be generated when the		periodically. Accounting messages may also be generated when the
	user roams during handoff. This information may be needed by the		user roams during handoff. This information may be needed by the
	billing system to calculate the user's bill. For example, there may		billing system to calculate the user's bill. For example, there may
	be different rates applied based on the location and there may be		be different rates applied based on the location and there may be
	different tax rates applied based on the location. Unless otherwise		different tax rates applied based on the location. Unless otherwise
	specified by authorization rules, location information in the		specified by authorization rules, location information in the
	accounting stream MUST NOT be transmitted to third parties.		accounting stream MUST NOT be transmitted to third parties.
	The location information in the accounting stream MUST only be sent		The location information in the accounting stream MUST only be sent
	in the proxy chain to the home network (unless specified otherwise).		in the proxy chain to the home network (unless specified otherwise).
	4.2 Scenario 2 - Use of Location Information for Other Services		4.2. Scenario 2 - Use of Location Information for Other Services
	Location Servers are entities that receive the user's location		Location Servers are entities that receive the user's location
	information and transmit it to other entities. In this second		information and transmit it to other entities. In this second
	scenario, Location Servers comprise also the NAS and the RADIUS		scenario, Location Servers comprise also the NAS and the RADIUS
	server. The RADIUS servers are in the home network, in the visited		server. The RADIUS servers are in the home network, in the visited
	network, or in broker networks.		network, or in broker networks.
	Unless explicitly authorized by the user's location policy, location		Unless explicitly authorized by the user's location policy, location
	information MUST NOT be transmitted to other parties outside the		information MUST NOT be transmitted to other parties outside the
	proxy chain between the NAS and the Home RADIUS server.		proxy chain between the NAS and the Home RADIUS server.
	Upon authentication and authorization, the home RADIUS server must		Upon authentication and authorization, the home RADIUS server MUST
	transmit the ruleset (if available) in an Access-Accept. The RADIUS		transmit the ruleset (if available) in an Access-Accept. The RADIUS
	client, intermediate proxies are allowed to share location		client, intermediate proxies are allowed to share location
	information if they received ruleset indicates that it is allowed.		information if they received ruleset indicates that it is allowed.
	Note that the NAS is the source of all location information that is		5. Description of Attributes
	disseminated by RADIUS. The NAS tags the location information with
	the policy rules or a reference to the policy rules received in an
	Access-Accept. All location information in the accounting stream
	will also be tagged.
	5. Overview
	Location information and ownership of the access network is conveyed		Location information and ownership of the access network is conveyed
	in the following RADIUS attributes: Operator-Namespace, Operator-		in the following RADIUS attributes: Operator-Name and Location-
	Name, Location-Information and Location-Type. Furthermore, the		Information. Furthermore, the Basic-Policy-Rules and the Extended-
	Basic-Policy-Rules and the Extended-Policy-Rules attributes are		Policy-Rules attributes are added to RADIUS message containing the
	attached to the Location-Information attribute turning location		Location-Information attribute turning location information into a
	information into a Location Object as defined in [11].		Location Object as defined in [12].
	5.1 Operator-Namespace Attribute		5.1. Operator-Name Attribute
	This attribute contains the description of an operator namespace		This attribute contains the operator namespace and the operator name.
	which combined with the Operator-Name attribute serves to uniquely		The operator name is combined with the Namespace to uniquely identify
	identify the owner of an access network. The attribute value is a		the owner of an access network. The value of the Operator-Name is a
	non-NULL terminated string whose Length MUST NOT exceed 253 bytes.		non-NULL terminated string whose length MUST NOT exceed 253 bytes.
	This document defines three values for this attribute: GSM, CDMA, and		The attribute value uniquely identifies the operator name within the
	REALM. Additional namespaces require IANA registration and MUST be		scope of the operator namespace
			This Namespace field within the Operator-Name attribute provides
			information about the operator namespace.
			This document defines four values for this attribute: GSM, CDMA,
			REALM and ITU.
			Additional namespaces require IANA registration and MUST be
	associated with an organization responsible for assigning and		associated with an organization responsible for assigning and
	managing the operator namespace.		managing the operator namespace.
	The GSM operator namespace can be used to indicate operator names		GSM (0):
	based on GSMA TADIG codes. The TADIG Working Group within the GSM
	Association is the authority responsible for issuing unique Operator-		This namespace can be used to indicate operator names based on
	Name values for operators of this type.		GSMA TADIG codes. The TADIG Working Group within the GSM
			Association is the authority responsible for issuing unique
			Operator-Name values of this type.
			CDMA (1):
	The CDMA operator namespace can be used to indicate operator names		The CDMA operator namespace can be used to indicate operator names
	based on the Home Network Identifier (HNI). The HNI is the		based on the Home Network Identifier (HNI). The HNI is the
	concatenation of the 3-digit Mobile Country Code (MCC) and 3-digit		concatenation of the 3-digit Mobile Country Code (MCC) and 3-digit
	Mobile Network Code (MNC). The IMSI Oversight Council (IOC) is the		Mobile Network Code (MNC). The IMSI Oversight Council (IOC) is
	authority responsible for issuing unique Operator-Name values for		the authority responsible for issuing unique Operator-Name values
	operators of this type.		for operators of this type.
	The REALM operator namespace can be used to indicate operator names		REALM (2):
	based on any registered domain name. Such names are required to be
	unique and the rights to use a given realm name are obtained
	coincident with acquiring the rights to use a particular Fully
	Qualified Domain Name (FQDN).
	5.2 Operator-Name Attribute		The REALM operator namespace can be used to indicate operator
			names based on any registered domain name. Such names are