draft-ietf-geopriv-radius-lo-07.txt   draft-ietf-geopriv-radius-lo-08.txt 
Geopriv H. Tschofenig Geopriv H. Tschofenig
Internet-Draft Siemens Internet-Draft Siemens
Expires: December 27, 2006 F. Adrangi Intended status: Informational F. Adrangi
Intel Expires: February 13, 2007 Intel
M. Jones M. Jones
A. Lior A. Lior
Bridgewater Bridgewater
June 25, 2006 August 12, 2006
Carrying Location Objects in RADIUS Carrying Location Objects in RADIUS
draft-ietf-geopriv-radius-lo-07.txt draft-ietf-geopriv-radius-lo-08.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 December 27, 2006. This Internet-Draft will expire on February 13, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Delivery Methods for Location Information . . . . . . . . . . 5 3. Delivery Methods for Location Information . . . . . . . . . . 6
3.1. Authentication/Authorization Phase Delivery . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . . . . . 11 Services . . . . . . . . . . . . . . . . . . . . . . . . . 12
5. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Operator-Name Attribute . . . . . . . . . . . . . . . . . 12 5.1. Operator-Name Attribute . . . . . . . . . . . . . . . . . 13
5.2. Location-Information Attribute . . . . . . . . . . . . . . 15 5.2. Location-Information Attribute . . . . . . . . . . . . . . 16
5.3. Location-Info-Civic Attribute . . . . . . . . . . . . . . 17 5.3. Location-Info-Civic Attribute . . . . . . . . . . . . . . 18
5.4. Location-Info-Geo Attribute . . . . . . . . . . . . . . . 18 5.4. Location-Info-Geo Attribute . . . . . . . . . . . . . . . 19
5.5. Basic Policy Rules Attribute . . . . . . . . . . . . . . . 20 5.5. Basic Policy Rules Attribute . . . . . . . . . . . . . . . 21
5.6. Extended Policy Rules Attribute . . . . . . . . . . . . . 23 5.6. Extended Policy Rules Attribute . . . . . . . . . . . . . 25
5.7. Challenge-Capable Attribute . . . . . . . . . . . . . . . 24 5.7. Challenge-Capable Attribute . . . . . . . . . . . . . . . 26
5.8. Requested-Info Attribute . . . . . . . . . . . . . . . . . 25 5.8. Requested-Info Attribute . . . . . . . . . . . . . . . . . 26
6. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 31 6. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 32
7. Diameter RADIUS Interoperability . . . . . . . . . . . . . . . 32 7. Diameter RADIUS Interoperability . . . . . . . . . . . . . . . 33
8. Matching with Geopriv Requirements . . . . . . . . . . . . . . 33 8. Matching with Geopriv Requirements . . . . . . . . . . . . . . 34
8.1. Distribution of Location Information at the User's 8.1. Distribution of Location Information at the User's
Home Network . . . . . . . . . . . . . . . . . . . . . . . 33 Home Network . . . . . . . . . . . . . . . . . . . . . . . 34
8.2. Distribution of Location Information at the Visited 8.2. Distribution of Location Information at the Visited
Network . . . . . . . . . . . . . . . . . . . . . . . . . 34 Network . . . . . . . . . . . . . . . . . . . . . . . . . 35
8.3. Requirements matching . . . . . . . . . . . . . . . . . . 35 8.3. Requirements matching . . . . . . . . . . . . . . . . . . 36
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 41 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 42
9.1. Entity in the visited network . . . . . . . . . . . . . . 41 9.1. Entity in the visited network . . . . . . . . . . . . . . 42
9.2. Entity in the home network . . . . . . . . . . . . . . . . 42 9.2. Entity in the home network . . . . . . . . . . . . . . . . 43
10. Security Considerations . . . . . . . . . . . . . . . . . . . 45 10. Security Considerations . . . . . . . . . . . . . . . . . . . 46
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
11.1. New Registry: Operator Type . . . . . . . . . . . . . . . 48 11.1. New Registry: Operator Type . . . . . . . . . . . . . . . 49
11.2. New Registry: Requested-Info attribute . . . . . . . . . . 49 11.2. New Registry: Requested-Info attribute . . . . . . . . . . 50
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 51
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53
13.1. Normative References . . . . . . . . . . . . . . . . . . . 52 13.1. Normative References . . . . . . . . . . . . . . . . . . . 53
13.2. Informative References . . . . . . . . . . . . . . . . . . 52 13.2. Informative References . . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56
Intellectual Property and Copyright Statements . . . . . . . . . . 56 Intellectual Property and Copyright Statements . . . . . . . . . . 57
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
such a network, information about the location and ownership of this such a network, information about the location and ownership of this
network needs to be conveyed to the user's home network to which the network needs to be conveyed to the user's home network to which the
user has a contractual relationship. The main intent of this user has a contractual relationship. The main intent of this
document is to enable location aware billing (e.g., determine the document is to enable location aware billing (e.g., by determining
appropriate tariff and taxation in dependence of the location of the the appropriate tariff and taxation in dependence of the location of
access network/user), location aware subscriber authentication and the access network and the end host), location aware subscriber
authorization for roaming environments and to enable other location authentication and authorization for roaming environments and to
aware services. enable other location aware services.
This document describes AAA attributes that are used by a AAA client This document describes AAA attributes, which are used by a AAA
or a local AAA server in an access network for conveying location- client or a AAA proxy in an access network, to convey location-
related information to the user's home AAA server. related information to the user's home AAA server.
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. [10] defines access and distribution to preserve the user's privacy. [10] defines
requirements for a protocol-independent model for the access to requirements for a protocol-independent model for the access to
skipping to change at page 4, line 29 skipping to change at page 5, line 29
location information is sent from the AAA client to the AAA server. location information is sent from the AAA client to the AAA server.
The authenticated identity might refer to a user, a device or The authenticated identity might refer to a user, a device or
something else. Although there might often be a user associated with something else. Although there might often be a user associated with
the authentication process (either directly or indirectly; indirectly the authentication process (either directly or indirectly; indirectly
when a binding between a device and a user exists) there is no when a binding between a device and a user exists) there is no
assurance that a particular real-world entity (such as a person) assurance that a particular real-world entity (such as a person)
triggered this process. Since location based authorization is triggered this process. Since location based authorization is
executed based on the network access authentication of a particular executed based on the network access authentication of a particular
"user" it might be reasonable to talk about user's privacy within "user" it might be reasonable to talk about user's privacy within
this document even though scenarios exist where this might not apply this document even though scenarios exist where this might not apply
(and device or network privacy might be the correct term). (and device or network privacy might be the better term).
Furthermore, the authors believe that there is a relationship between Furthermore, the authors believe that there is a relationship between
the NAS (or other nodes in the access network) and the location of the NAS (or other nodes in the access network) and the location of
the entity that triggered the network access authentication, such as the entity that triggered the network access authentication, such as
the user. The NAS might in many cases know the location of the end the user. The NAS might in many cases know the location of the end
host through various techniques (e.g., wire databases, wireless host through various techniques (e.g., wire databases, wireless
triangulation). Knowing the location of a network (where the user or triangulation). Knowing the location of a network (where the user or
end host is attached to) might in many networks also reveal enough end host is attached) might in many networks also reveal enough
information about the location of the user or the end host. A information about the location of the user or the end host. A
similar assumption is also made with regard to the location similar assumption is also made with regard to the location
information obtained via DHCP (see for example [4]). This information obtained via DHCP (see for example [4]). This
information might be used by applications in other protocols (such as information might be used by applications in other protocols (such as
SIP [11] with extensions [12]) to indicate the location of a SIP [11] with extensions [12]) to indicate the location of a
particular user even though the location "only" refers to the particular user even though the location "only" refers to the
location of the network or equipment within the network. This location of the network or equipment within the network. This
assumption might not hold in all scenarios but seems to be reasonable assumption might not hold in all scenarios but seems to be reasonable
and practicable. and practicable.
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.
network access authentication. The term 'user' is used whenever the
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 the visited rules, are transported via the RADIUS protocol from the AAA client to
access network to the home AAA server. To embed a Location Object the AAA server. A few attributes are introduced for this purpose, as
into RADIUS a number of attribute are used, such as Location- listed in Section 5, whereby delivery to the RADIUS server can happen
Information attribute, Basic-Policy-Rules attribute, Extended-Policy- during the authentication/authorization phase (described in
Rules attribute, Operator-Name attribute. These attributes can be Section 3.1), or in the mid-session using the dynamic authorization
delivered to the RADIUS server during the authentication/ protocol framework (described in Section 3.2). This section
authorization phase described in Section 3.1, or in the mid-session describes messages flows for both delivery methods.
using the dynamic authorization protocol framework described in
Section 3.2. This section describes messages flows for both delivery
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 and
procedure. Upon a network authentication request from an access authorization procedure. Upon a network authentication request from
network client, the NAS submits a RADIUS Access-Request message which an access network client, the NAS submits a RADIUS Access-Request
contains location information attributes among other required message that contains location information attributes among other
attributes. The attributes (including location information) are required attributes. These attributes are added based on various
added based on some criteria, such as local policy, business criteria (such as local policy, business relationship with
relationship with subscriber's home network provider and in case of subscriber's home network provider and in case of location
location information also considering privacy policies. information also by considering privacy policies).
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+
| Network | | Network | | AAA | | Network | | Network | | AAA |
| Access | | Access | | Server | | Access | | Access | | Server |
| Client | | Server | | | | Client | | Server | | |
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+
| | | | | |
| Authentication phase | | | Authentication phase | |
| begin | | | begin | |
|---------------------->| | |---------------------->| |
skipping to change at page 6, line 36 skipping to change at page 7, line 36
| | | | | |
| | RADIUS | | | RADIUS |
| | Accounting-Request | | | Accounting-Request |
| | + Location-Information | | | + Location-Information |
| |----------------------------->| | |----------------------------->|
| | | | | |
Figure 1: Location Delivery based on out-of-band Agreements Figure 1: Location Delivery based on out-of-band Agreements
If no location information is provided by the RADIUS client although If no location information is provided by the RADIUS client although
it is required by the RADIUS server to compute an authorization it is needed by the RADIUS server to compute the authorization
decision then the RADIUS server challenges the RADIUS client. This decision then the RADIUS server challenges the RADIUS client. This
exchange is shown in Figure 2. The Access-Challenge thereby provides exchange is shown in Figure 2. The Access-Challenge thereby provides
a hint to the Network Access Server regarding the type of location a hint to the Network Access Server regarding the type of location
information attributes that are desired. In the shown message flow information attributes that are desired. In the shown message flow
these attributes are then provided in the subsequent Access-Request these attributes are then provided in the subsequent Access-Request
message. When receiving this Access-Request message the message. When receiving this Access-Request message the
authorization procedure at the RADIUS server might be based on a authorization procedure at the RADIUS server might be based on a
number of criteria, including the newly defined Location-Information number of criteria, including the newly defined attributes listed in
and Operator-Name attributes. Section 5.
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+
| Network | | Network | | AAA | | Network | | Network | | AAA |
| Access | | Access | | Server | | Access | | Access | | Server |
| Client | | Server | | | | Client | | Server | | |
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+
| | | | | |
| Authentication phase | | | Authentication phase | |
| begin | | | begin | |
|---------------------->| | |---------------------->| |
skipping to change at page 10, line 8 skipping to change at page 11, line 8
RADIUS server responds with either an Access-Accept or an Access- RADIUS server responds with either an Access-Accept or an Access-
Reject message. Reject message.
Since location information can be sent in accounting records Since location information can be sent in accounting records
(including accounting interim records), RFC 3576 [5] is only needed (including accounting interim records), RFC 3576 [5] is only needed
for authorization changes. for authorization changes.
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. Location information may refer to the
(visited) network or to the end host. How the network obtains the (visited) network or to the end host. How the network obtains the
end hosts location information is out of the scope of this document. end hosts location information is out of the scope of this document.
There are two potential consumers of location information: the AAA There are two potential consumers of location information: the AAA
server and location-based services. The privacy implications of server and location-based services. The privacy implications of
these scenarios are described in Section 9. these scenarios are described in Section 9.
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 only. The NAS delivers location information to the home AAA
server. server.
The location of the AAA client and/or the end host is transferred The location of the AAA client and/or the end host is transferred
from the NAS to the RADIUS server (based on a pre-established from the NAS to the RADIUS server (based on a pre-established
agreement or if the RADIUS server asks for it under consideration of agreement or if the RADIUS server asks for it under consideration of
privacy policies). The NAS and intermediaries (if any) are not privacy policies). The NAS and intermediaries (if any) are not
allowed to use that information other than to forward it to the home allowed to use that information other than to forward it to the home
network. network.
The RADIUS server authenticates and authorizes the user requesting The RADIUS server authenticates and authorizes the user requesting
skipping to change at page 10, line 50 skipping to change at page 11, line 50
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 tariffs or tax rates applied based on the location. be different tariffs or tax rates applied based on the location.
Unless otherwise specified by authorization rules, location Unless otherwise specified by authorization rules, location
information in the accounting stream MUST NOT be transmitted to third information in the accounting stream MUST NOT be transmitted to third
parties. parties.
The location information in the accounting stream MUST only be sent Location information in the accounting stream MUST only be sent in
in the proxy chain to the home network (unless specified otherwise). 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.
5. Attributes 5. Attributes
This section defines the Operator-Name, Location-Information, Basic
Policy Rules, Extended Policy Rules, and the Capability attribute.
5.1. Operator-Name Attribute 5.1. Operator-Name Attribute
This attribute contains the operator namespace and the operator name. This attribute contains the operator namespace and the operator name.
The operator name is combined with the Namespace to uniquely identify The operator name is combined with the namespace to uniquely identify
the owner of an access network. The value of the Operator-Name 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.
The attribute value uniquely identifies the operator name within the
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
managing the operator namespace.
GSM (0):
This namespace can be used to indicate operator names based on
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
based on the Home Network Identifier (HNI). The HNI is the
concatenation of the 3-digit Mobile Country Code (MCC) and 3-digit
Mobile Network Code (MNC). The IMSI Oversight Council (IOC) is
the authority responsible for issuing unique Operator-Name values
for operators of this type.
REALM (2):
The REALM operator namespace can be used to indicate operator
names 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).
ITU (3):
The ITU operator namespace can be used to indicate operator names
based on ITU Carrier codes. The Telecommunication Standardization
Bureau (TSB) within the ITU-T is the authority responsible for the
repository. Each national regulatory authority is responsible for
issuing unique Operator-Name values for operators of this type.
The Operator-Name attribute SHOULD be sent in Access-Request, and The Operator-Name attribute SHOULD be sent in Access-Request, and
Accounting-Request records where the Acc-Status-Type is set to Start, Accounting-Request records where the Acc-Status-Type is set to Start,
Interim, or Stop. Interim, or Stop.
A summary of the Operator-Name attribute is shown below. A summary of the Operator-Name attribute is shown below.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 15, line 5 skipping to change at page 14, line 51
Example: 2 for REALM Example: 2 for REALM
Operator-Name: Operator-Name:
The text field of variable length contains an The text field of variable length contains an
Access Network Operator Name. Access Network Operator Name.
This field is a RADIUS base data type of Text. This field is a RADIUS base data type of Text.
Example: anyisp.com Example: anyisp.com
The Namespace field provides information about the operator
namespace. This document defines four values for this attribute that
are listed below. Defining additional namespaces requires IANA
registration and MUST be associated with an organization responsible
for managing this namespace.
TADIG (0):
This namespace can be used to indicate operator names based on
Transferred Account Data Interchange Group (TADIG) codes defined
in [13]. TADIG codes are assigned by the TADIG Working Group
within the GSM Association. The TADIG Code consists of two
fields, with a total length of five ASCII characters consisting of
a three-character country code and a two-character aplhanumeric
operator (or company) ID.
E212 (1):
The E212 namespace can be used to indicate operator names based on
the Mobile Country Code (MCC) and Mobile Network Code (MNC)
defined in [14]. The MCC/MCC values are assigned by the
Telecommunications Standardization Bureau (TSB) within the ITU-T
and designated administrators in different countries. The E212
value consists of three ASCII digits containing the MCC, followed
by two or three ASCII digits containing the MNC.
REALM (2):
The REALM operator namespace can be used to indicate operator
names 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).
ICC (3):
The ICC namespace can be used to indicate operator names based on
ITU Carrier Codes (ICC) defined in [15]. ICC values are assigned
by national regulatory authorities and are coordinated by the
Telecommunication Standardization Bureau (TSB) within the ITU-T.
When using the ICC namespace, the attribute consists of three
uppercase ASCII characters containing a three-letter alphabetic
country code as defined in [16], followed by one to six uppercase
alphanumeric ASCII characters containing the ICC itself.
5.2. Location-Information Attribute 5.2. Location-Information Attribute
Location-Information attribute SHOULD be sent in Access-Request and The Location-Information attribute SHOULD be sent in Access-Request
in Accounting-Request messages. For the Accounting-Request message and in Accounting-Request messages. For the Accounting-Request
the Acc-Status-Type may be set to Start, Interim or Stop. message the Acc-Status-Type may be set to Start, Interim or Stop.
The Location-Information Attribute provides meta-data about the The Location-Information Attribute provides meta-data about the
location information, such as sighting time, time-to-live, mechanism location information, such as sighting time, time-to-live, mechanism
that was used to determine the location information, etc. The format that was used to determine the location information, etc. The format
is shown below. is shown below.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value ... | Type | Length | Value ...
skipping to change at page 17, line 4 skipping to change at page 18, line 4
determined. The values are registered with the 'method' Tokens determined. The values are registered with the 'method' Tokens
registry by RFC 4119. The data type of this registry by RFC 4119. The data type of this
field is a string. field is a string.
The following two fields need some explanation: The following two fields need some explanation:
sighting time: sighting time:
This field indicates when the Location Information was accurate. This field indicates when the Location Information was accurate.
The data type of this field is a string and the format is a 64 bit The data type of this field is a string and the format is a 64 bit
NTP timestamp [13]. NTP timestamp [17].
time-to-live: time-to-live:
This field gives a hint until when location information should be This field gives a hint until when location information should be
considered current. Note that the time-to-live field is different considered current. Note that the time-to-live field is different
than retention-expires, which indicates the time the recipient is than retention-expires. The latter indicates the time the
no longer permitted to possess the location information and its recipient is no longer permitted to possess the location
encapsulating Location Object. The data type of this field is a information. The data type of this field is a string and the
string and the format is a 64 bit NTP timestamp [13]. format is a 64 bit NTP timestamp [17].
The length of the Location-Information Attribute MUST NOT exceed 253 The length of the Location-Information Attribute MUST NOT exceed 253
octets. octets.
5.3. Location-Info-Civic Attribute 5.3. Location-Info-Civic Attribute
Civic location is a popular way to describe the location of an Civic location is a popular way to describe the location of an
entity. For the RADIUS protocol civic location information is an entity. For the RADIUS protocol civic location information is an
opaque object and the RADIUS server parses the location information opaque object and the RADIUS server parses the location information
based on the encoding format defined in [4]. The data format based on the encoding format defined in [4]. The data format
described in Section 3.1 of [4] is used, with the exception that the described in Section 3.1 of [4] is used.
first octet (DHCP option code) is not included.
Location-Info-Civic attribute SHOULD be sent in Access-Request and in Location-Info-Civic attribute SHOULD be sent in Access-Request and in
Accounting-Request messages. For the Accounting-Request message the Accounting-Request messages. For the Accounting-Request message the
Acc-Status-Type may be set to Start, Interim or Stop. Acc-Status-Type may be set to Start, Interim or Stop.
The Location-Information attribute provides information about civic The Location-Information attribute provides information about civic
location information. The format is shown below. location information. The format is shown below.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
skipping to change at page 18, line 44 skipping to change at page 19, line 44
Index (16 bits): Index (16 bits):
The 16-bit unsigned integer value allows to associate The 16-bit unsigned integer value allows to associate
the Location-Info-Civic attribute with the the Location-Info-Civic attribute with the
Location-Information attributes. Location-Information attributes.
Civic Location (variable): Civic Location (variable):
The format of the data is described in Section 3.1 of [4] The format of the data is described in Section 3.1 of [4]
whereby the first 8 bits (i.e., the code for this DHCP option) whereby the first 14 bits (i.e., the code for this DHCP option,
the length of the DHCP option, and the 'what' element)
are not included. are not included.
5.4. Location-Info-Geo Attribute 5.4. Location-Info-Geo Attribute
Geospatial location information is encoded as an opaque object Geospatial location information is encoded as an opaque object
whereby the format is reused from [6]. The RFC 3825 Location whereby the format is reused from [6]. The RFC 3825 Location
Configuration Information (LCI) format defined in Section 2 of [6] Configuration Information (LCI) format defined in Section 2 of [6]
starting with bit 17 (i.e., the code for the DHCP option and the starting with bit 17 (i.e., the code for the DHCP option and the
length field is not included.). length field is not included.).
skipping to change at page 20, line 44 skipping to change at page 21, line 44
Index (16 bits): Index (16 bits):
The 16-bit unsigned integer value allows to associate The 16-bit unsigned integer value allows to associate
the Location-Info-Geo attribute with the the Location-Info-Geo attribute with the
Location-Information attributes. Location-Information attributes.
Geo Location (variable): Geo Location (variable):
The RFC 3825 Location Configuration Information (LCI) format The RFC 3825 Location Configuration Information (LCI) format
defined in Section 2 of RFC 3825 starting with bit 17 (i.e., defined in Section 2 of RFC 3825 starting with starting with
the code for the DHCP option and the length field is not the third octet (i.e., the code for the DHCP option and the
included.). length field is not included).
5.5. Basic Policy Rules Attribute 5.5. Basic Policy Rules Attribute
In some environments it is possible for the user to attach Policy rules control the distribution of location location
information about its privacy preferences available to the network. information. In some environments the the AAA client might know the
These preferences allow the visited network, intermediate RADIUS privacy preferences of the user based on pre-configuration or the
proxies and the home network to authorize the distribution of the user communicated them as part of the network attachment. In many
user's location information. The home network will typically possess other cases the AAA server (or an entity with a relationship to the
the user's authorization policies. AAA server) might possess the user's authorization policies. The
Basic-Policy-Rules attribute SHOULD be sent in an an Access-Request,
Access-Accept, an Access-Challenge, an Access-Reject and an
Accounting-Request message.
Without the user providing authorization information two approaches When the AAA client does not know the user's policy then the
are possible: following procedure is applicable:
o The user hides its identity information from the access network o The AAA client SHOULD NOT attach location information in the
and from intermediate networks using the appropriate network initial Access-Request message but should rather wait for the AAA
access authentication mechanism. Section 9 discusses these issues server to receive a challenge for location information.
in more details.
o The access network attaches default authorization policies which o If a roamig agreement or legal circumstances require the AAA
indicates that intermediate networks and the home network should client to transfer location information in the initial Access-
not distribute the location information to other entities. If the Request message to the AAA server (even though user specific
user is able to provide authorization policies to the NAS then policies are not available to the AAA client) then the access
these policies will be attached. Additionally, the home network network attaches default authorization policies. In this case
might have authorization policies which control distribution of default policies with restrictive privacy settings appropriate for
location information. These policies are sent from the RADIUS the respective environment are attached in this case. The
server to the RADIUS client. Users can dynamically change their 'retransmission-allowed' flag MUST be set to '0' meaning that the
policies using the authroization framework defined in [14] and location must not be shared with other parties (other than
[15]. forarding them to the user's home network). In case the home
network knows the user's privacy policies then these policies
SHOULD be sent from the RADIUS server to the RADIUS client in a
subsequent response message and these policies will be applied to
further location dissemination and in subsequent RADIUS
interactions (e.g., when attaching location information to
Accounting messages).
Note that the authorization framework defined in [18] and [19]
together with XCAP [20] gives users the ability to change their
privacy policies.
With regard to authorization policies this document reuses work done With regard to authorization policies this document reuses work done
in [16] and encodes it in an non-XML format. Two fields ('sighting in [21] and encodes them in a non-XML format. Two fields ('sighting
time' and 'time-to-live') are additionally included in the Location- time' and 'time-to-live') are additionally included in the Location-
Information attribute to conform to the Geopriv Requirements [10], Information attribute to conform to the Geopriv requirements [10],
Section 2.7. Two RADIUS attributes are used for this purpose: Basic- Section 2.7. Two RADIUS attributes are used for this purpose: Basic-
Policy-Rule and Extended-Policy-Rule attribute. The latter is Policy-Rule and Extended-Policy-Rule attribute. The latter is
defined in Section 5.6. The Basic-Policy-Rule attribute contains a defined in Section 5.6. The Basic-Policy-Rule attribute contains a
fixed set of privacy relevant fields whereas the Extended-Policy-Rule fixed set of privacy relevant fields whereas the Extended-Policy-Rule
attribute contains a reference to a more extensive authorization rule attribute contains a reference to a more extensive authorization rule
set. set.
The Basic-Policy-Rules attribute MUST be sent in an Access-Accept, an
Access-Challenge, an Access-Request, an Access-Reject and an
Accounting-Request message if location information is transmitted
with this exchange. If authorization policy rules are available to
the RADIUS client then the Access-Request MUST carry the Basic-
Policy-Rules attribute to to the RADIUS server.
The format of the Basic-Policy-Rules attribute is shown below. The format of the Basic-Policy-Rules attribute is shown below.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value ... | Type | Length | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (cont.) ... | Value (cont.) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 22, line 45 skipping to change at page 23, line 51
Only the first bit (R) is defined and corresponds to the Only the first bit (R) is defined and corresponds to the
retransmission-allowed field. All other bits are reserved retransmission-allowed field. All other bits are reserved
and MUST be zero. and MUST be zero.
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|o o o o o o o o o o o o o o o| |R|o o o o o o o o o o o o o o o|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Reserved Flags The symbol 'o' refers to reserved flags.
Retention Expires (64 bits): Retention Expires (64 bits):
NTP timestamp for the 'retention-expires' field. NTP timestamp for the 'retention-expires' field.
Note Well (variable): Note Well (variable):
This field contains a URI which points to human readable This field contains a URI that points to human readable
privacy instructions. The data type of this field is string. privacy instructions. The data type of this field is string.
This document reuses fields of the 'usage-rules' element, described This document reuses fields of the 'usage-rules' element, described
in [16]. These fields have the following meaning: in [21]. These fields have the following meaning:
retransmission-allowed: retransmission-allowed:
When the value of this element is '0', then the recipient of this When the value of this element is '0', then the recipient of this
Location Object is not permitted to share the enclosed location Location Object is not permitted to share the enclosed location
information, or the object as a whole, with other parties. The information, or the object as a whole, with other parties. The
value of '1' allows to share the location information with other value of '1' allows to share the location information with other
parties by considering the extended policy rules. parties by considering the extended policy rules.
retention-expires: retention-expires:
This field specifies an absolute date at which time the Recipient This field specifies an absolute date at which time the Recipient
is no longer permitted to possess the location information. The is no longer permitted to possess the location information. The
data type of this field is a string and the format is a 64 bit NTP data type of this field is a string and the format is a 64 bit NTP
timestamp [13]. timestamp [17].
note-well: note-well:
This field contains a URI which points to human readable privacy This field contains a URI which points to human readable privacy
instructions. This field is useful when location information is instructions. This field is useful when location information is
distributed to third party entities, which can include humans in a distributed to third party entities, which can include humans in a
location based service. RADIUS entities are not supposed to location based service. RADIUS entities are not supposed to
process this field. process this field.
Whenever a Location Object leaves the AAA system the URI in the Whenever a Location Object leaves the AAA system the URI in the
note-well attribute MUST be expanded to the human readable text. note-well attribute MUST be expanded to the human readable text.
For example, when the Location Object is transferred to a SIP For example, when the Location Object is transferred to a SIP
based environment then the human readable text is placed in the based environment then the human readable text is placed into the
text is put into the 'note-well' attribute inside the 'usage- 'note-well' element of the 'usage-rules' element contained in the
rules' element inside the PIDF-LO document (see [16]). PIDF-LO document (see [21]).
5.6. Extended Policy Rules Attribute 5.6. Extended Policy Rules Attribute
The Extended-Policy-Rules attribute SHOULD be sent in an Access- The Extended-Policy-Rules attribute SHOULD be sent in an Access-
Accept, an Access-Challenge, an Access-Request, an Access-Reject and Request, an Access-Accept, an Access-Challenge, an Access-Reject and
an Accounting-Request message if location information is transmitted in an Accounting-Request message whenever location information is
with this exchange. If authorization policy rules are available to transmitted.
the RADIUS client then the Access-Request MUST carry the Basic-
Policy-Rules attribute to to the RADIUS server.
Ruleset reference field of this attribute is of variable length. It Ruleset reference field of this attribute is of variable length. It
contains a URI that indicates where a richer ruleset is available. contains a URI that indicates where the richer ruleset can be found.
The full ruleset SHOULD be fetched using Transport Layer Security This URI SHOULD use the HTTPS URI scheme. As a deviation from [21]
(TLS). As a deviation from [16] this field only contains a reference this field only contains a reference and does not carry an attached
and does not carry an attached rule set. This modification is extended rule set. This modification is motivated by the size
motivated by the size limitations imposed by RADIUS. limitations imposed by RADIUS.
The format of the Extended-Policy-Rules attribute is shown below. The format of the Extended-Policy-Rules attribute is shown below.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value ... | Type | Length | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (cont.) ... | Value (cont.) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 24, line 39 skipping to change at page 25, line 46
Value: Value:
The Value field is at least two octets in length, and the format The Value field is at least two octets in length, and the format
is shown below. The data type of the Value field is string. is shown below. The data type of the Value field is string.
The fields are transmitted from left to right: The fields are transmitted from left to right:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ruleset reference ... | Ruleset Reference ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ruleset reference: Ruleset Reference:
This field contains a URI that points to policy rules. This field contains a URI that points to policy rules.
5.7. Challenge-Capable Attribute 5.7. Challenge-Capable Attribute
The Challenge-Capable attribute allows a NAS (or client function of a The Challenge-Capable attribute allows a NAS (or client function of a
proxy server) to indicate support for processing general purpose proxy server) to indicate support for processing general purpose
Access-Challenge messages from the RADIUS server, beyond those Access-Challenge messages from the RADIUS server, beyond those
specified for support of the authentication methods of textual specified for support of the authentication methods of textual
challenge-response, CHAP or EAP. This mechanism allows the RADIUS challenge-response, CHAP or EAP. This mechanism allows the RADIUS
server to request additional information from the RADIUS client prior server to request additional information from the RADIUS client prior
to making an authentication and authorization decision. The to making an authentication and authorization decision. The
Challenge-Capable attribute MUST appear in Access-Request Messages, Challenge-Capable attribute MUST appear in Access-Request Messages,
if the NAS supports this feature, as a hint to the RADIUS Server. if the NAS supports this feature, as a hint to the RADIUS server.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value | | Type | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: Type:
To Be Assigned by IANA - Challenge-Capable Attribute To Be Assigned by IANA - Challenge-Capable Attribute
Length: Length:
4 4
Value: Value:
The Value field is four octets. The Value field is two octets long and of type string.
Every bit of the two octets MUST be set to 0. Every bit of the two octets MUST be set to 0.
5.8. Requested-Info Attribute 5.8. Requested-Info Attribute
The Requested-Info attribute allows the RADIUS server to indicate The Requested-Info attribute allows the RADIUS server to indicate
whether it needs civic and/or geospatial location information of the whether it needs civic and/or geospatial location information of the
NAS or the end host (i.e., the entities that are indicated in the NAS or the end host (i.e., the entities that are indicated in the
Entity field of the Location-Information attribute). Entity field of the Location-Information attribute).
If the RADIUS server wants to dynamically decide on a per-request If the RADIUS server wants to dynamically decide on a per-request
basis to ask for location information from the RADIUS client then the basis to ask for location information from the RADIUS client then the
following cases need to be differentiated. If the AAA client and the following cases need to be differentiated. If the AAA client and the
AAA server have agreed out-of-band to mandate the transfer of AAA server have agreed out-of-band to mandate the transfer of
location information for every network access authentication request location information for every network access authentication request
then the issues listed below are not applicable. then the processing listed below is not applicable.
o The RADIUS server requires location information for computing the o The RADIUS server requires location information for computing the
authorization decision. If the RADIUS client does not provide authorization decision. If the RADIUS client does not provide
location information with the Access-Request message then the location information with the Access-Request message then the
Requested-Info attribute is attached to the Access-Challenge to Requested-Info attribute is attached to the Access-Challenge to
indicate what is required. Two cases can be differentiated: indicate what is required. Two cases can be differentiated:
o
1. If the RADIUS client sends the requested information then the 1. If the RADIUS client sends the requested information then the
RADIUS server can process the location-based attributes. RADIUS server can process the location-based attributes.
2. If the RADIUS server does not receive the requested 2. If the RADIUS server does not receive the requested
information in response to the Access-Challenge (including the information in response to the Access-Challenge (including the
Requested-Info attribute) then the RADIUS server responds with Requested-Info attribute) then the RADIUS server responds with
an Access-Reject with an Error-Cause attribute (including the an Access-Reject with an Error-Cause attribute (including the
"Location-Info-Required" error value). Note that an Access- "Location-Info-Required" value). Note that an Access-Reject
Reject message SHOULD only be sent if the RADIUS server MUST message SHOULD only be sent if the RADIUS server MUST use
use location information for returning a positive access location information for returning a positive access control
control decision. decision.
o If the RADIUS server would like location information in the o If the RADIUS server would like location information in the
Accounting-Request message but does not require it for computing Accounting-Request message but does not require it for computing
an authorization decision then an Access-Accept MUST include a an authorization decision then an Access-Accept MUST include a
Required-Info attribute. This is typically the case when location Required-Info attribute. This is typically the case when location
information is used for inclusion to the user's bill only. The information is used for inclusion to the user's bill only. The
RADIUS client SHOULD attach location information to the RADIUS client SHOULD attach location information to the
Accounting-Request (unless authorization policies dictate Accounting-Request (unless authorization policies dictate
something different), if it is available. something different), if it is available.
If the RADIUS server does not send a Requested-Info attribute then If the RADIUS server does not send a Requested-Info attribute then
the RADIUS client MUST NOT attach location information to messages to the RADIUS client MUST NOT attach location information to messages to
the RADIUS server The user's authorization policies MUST be consulted the RADIUS server. The user's authorization policies, if available,
by the RADIUS server before requesting location information delivery MUST be consulted by the RADIUS server before requesting location
from the RADIUS client. information delivery from the RADIUS client.
Figure 11 shows a simple protocol exchange where the RADIUS server Figure 11 shows a simple protocol exchange where the RADIUS server
indicates the desire to obtain location information, namely civic indicates the desire to obtain location information, namely civic
location information of the user, to grant access. Since the location information of the user, to grant access. Since the
Requested-Info attribute is attached to the Access-Challenge the Requested-Info attribute is attached to the Access-Challenge the
RADIUS server indicates that location information is required for RADIUS server indicates that location information is required for
computing an authorization decision. computing an authorization decision.
+---------+ +---------+ +---------+ +---------+
| RADIUS | | RADIUS | | RADIUS | | RADIUS |
skipping to change at page 27, line 36 skipping to change at page 28, line 36
| (civic-location) | | (civic-location) |
|----------------------------->| |----------------------------->|
| | | |
| .... | | .... |
Figure 11: RADIUS server requesting location information Figure 11: RADIUS server requesting location information
The Requested-Info attribute MUST be sent by the RADIUS server if it The Requested-Info attribute MUST be sent by the RADIUS server if it
wants the RADIUS client to return civic and/or geospatial wants the RADIUS client to return civic and/or geospatial
information. This Requested-Info attribute MAY appear in the Access- information. This Requested-Info attribute MAY appear in the Access-
Accept or in the Access-Challenge messages. Accept or in the Access-Challenge message.
A summary of the attribute is shown below. A summary of the attribute is shown below.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value ... | Type | Length | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (cont.) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (cont.) | | Value (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: Type:
To Be Assigned by IANA - Requested-Info Attribute To Be Assigned by IANA - Requested-Info Attribute
Length: Length:
10 10
Value: Value:
The Value field is at least 8 octets in length, and the format The content of the Value field is shown below.
is shown below. The data type of the Value field is string. The data type of the Value field is string.
The fields are transmitted from left to right: The fields are transmitted from left to right:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requested-Info | | Requested-Info |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requested-Info | | Requested-Info |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 30, line 22 skipping to change at page 31, line 31
Numerical Value: Numerical Value:
A numerical value of this attribute is '8'. A numerical value of this attribute is '8'.
If neither the NAS_LOCATION nor the USERS_LOCATION bit is set then If neither the NAS_LOCATION nor the USERS_LOCATION bit is set then
per-default the location of the user's client device MUST be returned per-default the location of the user's client device MUST be returned
(if authorization policies allow it). If both the NAS_LOCATION and (if authorization policies allow it). If both the NAS_LOCATION and
the USERS_LOCATION bits are set then the location information has to the USERS_LOCATION bits are set then the location information has to
be put into separate attributes. If neither the CIVIC_LOCATION nor be put into separate attributes. If neither the CIVIC_LOCATION nor
the GEO_LOCATION bit is set then per-default civic location the GEO_LOCATION bit is set in the Requested-Info attribute then no
information MUST be returned (if authorization policies allow it). location information is returned. If both the CIVIC_LOCATION and the
If both the CIVIC_LOCATION and the GEO_LOCATION bits are set then the GEO_LOCATION bits are set then the location information has to be put
location information has to be put into separate attributes. The into separate attributes. The value of NAS_LOCATION and
value of NAS_LOCATION and USERS_LOCATION refers to the location USERS_LOCATION refers to the location information requested via
requested via CIVIC_LOCATION and/or via GEO_LOCATION. As an example, CIVIC_LOCATION and via GEO_LOCATION. As an example, if the bits for
if the bits for NAS_LOCATION, USERS_LOCATION and GEO_LOCATION are set NAS_LOCATION, USERS_LOCATION and GEO_LOCATION are set then location
then location information of the AAA client and the users' client information of the AAA client and the users' client device are
device are returned in a geospatial location format. returned in a geospatial location format.
6. Table of Attributes 6. Table of Attributes
The following table provides a guide which attributes may be found in The following table provides a guide which attributes may be found in
which RADIUS messages, and in what quantity. which RADIUS messages, and in what quantity.
Request Accept Reject Challenge Accounting # Attribute Request Accept Reject Challenge Accounting # Attribute
Request Request
0-1 0 0 0 0-1 TBD Operator-Name 0-1 0 0 0 0-1 TBD Operator-Name
0+ 0 0 0 0+ TBD Location-Information 0+ 0 0 0 0+ TBD Location-Information
skipping to change at page 31, line 30 skipping to change at page 32, line 30
The Location-Information, the Location-Info-Civic and the Location- The Location-Information, the Location-Info-Civic and the Location-
Info-Geo attribute MAY appear more than once. For example, if the Info-Geo attribute MAY appear more than once. For example, if the
server asks for civic and geospatial location information two server asks for civic and geospatial location information two
Location-Information attributes need to be sent. If multiple Location-Information attributes need to be sent. If multiple
Location-Information attributes are sent then they MUST NOT contain Location-Information attributes are sent then they MUST NOT contain
the same information. the same information.
The next table shows the occurrence of the error-cause attribute. The next table shows the occurrence of the error-cause attribute.
Request Accept Reject Challenge Accounting # Attribute Request Accept Reject Challenge Accounting #
Request Request
0 0 0-1 0 0 TBD Location-Info-Required 0 0 0-1 0 0 TBD Location-Info-Required
0 0 0-1 0 0 101 Error-Cause 0 0 0-1 0 0 101 Error-Cause
7. Diameter RADIUS Interoperability 7. Diameter RADIUS Interoperability
When used in Diameter, the attributes defined in this specification When used in Diameter, the attributes defined in this specification
can be used as Diameter AVPs from the Code space 1-255 (RADIUS can be used as Diameter AVPs from the Code space 1-255 (RADIUS
attribute compatibility space). No additional Diameter Code values attribute compatibility space). No additional Diameter Code values
are therefore allocated. The data types and flag rules for the are therefore allocated. The data types and flag rules for the
attributes are as follows: attributes are as follows:
+---------------------+ +---------------------+
| AVP Flag rules | | AVP Flag rules |
|----+-----+----+-----|----+ |----+-----+----+-----|----+
| | |SHLD| MUST| | | | |SHLD| MUST| |
Attribute Name Value Type |MUST| MAY | NOT| NOT|Encr| Attribute Name Value Type |MUST| MAY | NOT| NOT|Encr|
----------------------------------|----+-----+----+-----|----| ----------------------------------|----+-----+----+-----|----|
Operator-NameID OctetString| M | P | | V | Y | Operator-Name OctetString| | P,M | | V | Y |
Location-Information OctetString| M | P | | V | Y | Location-Information OctetString| M | P | | V | Y |
Location-Info-Civic OctetString| M | P | | V | Y | Location-Info-Civic OctetString| M | P | | V | Y |
Location-Info-Geo OctetString| M | P | | V | Y | Location-Info-Geo OctetString| M | P | | V | Y |
Basic-Policy-Rules OctetString| M | P | | V | Y | Basic-Policy-Rules OctetString| M | P | | V | Y |
Extended-Policy-Rules OctetString| M | P | | V | Y | Extended-Policy-Rules OctetString| M | P | | V | Y |
Requested-Info OctetString| M | P | | V | Y | Requested-Info OctetString| M | P | | V | Y |
Challenge-Capable OctetString| M | P | | V | Y | Challenge-Capable OctetString| | P | | V | Y |
----------------------------------|----+-----+----+-----|----| ----------------------------------|----+-----+----+-----|----|
The attributes in this specification have no special translation The attributes in this specification have no special translation
requirements for Diameter to RADIUS or RADIUS to Diameter gateways; requirements for Diameter to RADIUS or RADIUS to Diameter gateways;
they are copied as is, except for changes relating to headers, they are copied as is, except for changes relating to headers,
alignment, and padding. See also Section 4.1 of [7] and Section 9 of alignment, and padding. See also Section 4.1 of [7] and Section 9 of
[17]. [22].
What this specification says about the applicability of the What this specification says about the applicability of the
attributes for RADIUS Access-Request packets applies in Diameter to attributes for RADIUS Access-Request packets applies in Diameter to
AA-Request [17] or Diameter-EAP-Request [18]. What is said about AA-Request [22] or Diameter-EAP-Request [23]. What is said about
Access-Challenge applies in Diameter to AA-Answer [17] or Diameter- Access-Challenge applies in Diameter to AA-Answer [22] or Diameter-
EAP-Answer [18] with Result-Code AVP set to EAP-Answer [23] with Result-Code AVP set to
DIAMETER_MULTI_ROUND_AUTH. What is said about Access-Accept applies DIAMETER_MULTI_ROUND_AUTH. What is said about Access-Accept applies
in Diameter to AA-Answer or Diameter-EAP-Answer messages that in Diameter to AA-Answer or Diameter-EAP-Answer messages that
indicate success. Similarly, what is said about RADIUS Access-Reject indicate success. Similarly, what is said about RADIUS Access-Reject
packets applies in Diameter to AA- Answer or Diameter-EAP-Answer packets applies in Diameter to AA- Answer or Diameter-EAP-Answer
messages that indicate failure. messages that indicate failure.
What is said about COA-Request applies in Diameter to Re-Auth-Request What is said about COA-Request applies in Diameter to Re-Auth-Request
[17]. [22].
What is said about Accounting-Request applies to Diameter Accounting- What is said about Accounting-Request applies to Diameter Accounting-
Request [17] as well. Request [22] as well.
8. Matching with Geopriv Requirements 8. Matching with Geopriv Requirements
This section compares the Geopriv requirements described in [10] and This section compares the Geopriv requirements described in [10] and
the approach of distributing Location Objects with RADIUS. the approach of distributing Location Objects with RADIUS.
The main usage scenario aimed for Location Object transport in RADIUS In Section 8.1 and Section 8.2 we discuss privacy implications when
assumes that the Location Server and the Location Recipient are co- RADIUS is not used according to these usage scenario. In Section 8.3
located at a single entity with regard to location based network Geopriv requirements are matched against these two scenarios.
access authorization, taxation and billing. In Section 8.1 and
Section 8.2 we discuss privacy implications when RADIUS is not used
according to these usage scenario.
In Section 8.3 Geopriv requirements are matched against these two
scenarios.
8.1. Distribution of Location Information at the User's Home Network 8.1. Distribution of Location Information at the User's Home Network
This section focuses on location information transport from the local This section focuses on location information transport from the local
AAA server (acting as the Location Generator) to the home AAA server AAA server (acting as the Location Generator) to the home AAA server
(acting as the Location Server). To use a more generic scenario we (acting as the Location Server). To use a more generic scenario we
assume that the visited AAA and the home AAA server belong to assume that the visited AAA and the home AAA server belong to
different administrative domains. The Location Recipient obtains different administrative domains. The Location Recipient obtains
location information about a particular Target via protocols location information about a particular Target via protocols
specified outside the scope this document (e.g., SIP, HTTP or an specified outside the scope of this document (e.g., SIP, HTTP or an
API). API).
Please note that the main usage scenario defined in this document Please note that the main usage scenario defined in this document
assumes that the Location Server and the Location Recipient are co- assumes that the Location Server and the Location Recipient are co-
located into a single entity with regard to location based network located into a single entity with regard to location based network
access authorization, taxation and billing. access authorization, taxation and billing.
The subsequent figure shows the interacting entities graphically. The subsequent figure shows the interacting entities graphically.
visited network | home network visited network | home network
skipping to change at page 34, line 24 skipping to change at page 35, line 4
| V | V
+----------+ | +----------+ +----------+ +----------+ | +----------+ +----------+
|Location | publication | Location | notification |Location | |Location | publication | Location | notification |Location |
|Generator |<------------->| Server |<------------->|Recipient | |Generator |<------------->| Server |<------------->|Recipient |
| | interface | | interface | | | | interface | | interface | |
+----------+ | +----------+ +----------+ +----------+ | +----------+ +----------+
| |
Local AAA RADIUS Home AAA SIP/HTTP/API/etc. Local AAA RADIUS Home AAA SIP/HTTP/API/etc.
Server | Server Server | Server
| |
Figure 16: Location Server at the Home Network Figure 16: Location Server at the Home Network
The term 'Rule Holder' in Figure 16 denotes the entity which creates The term 'Rule Holder' in Figure 16 denotes the entity that creates
the authorization ruleset. the authorization ruleset.
8.2. Distribution of Location Information at the Visited Network 8.2. Distribution of Location Information at the Visited Network
This section describes a scenario where Location Information is This section describes a scenario where location information made
distributed by the visited network. available to Location Recipients by some entity in the visited
network.
In order for this scenario to be applicable the following two In order for this scenario to be applicable the following two
assumptions must hold: assumptions must hold:
o The visited network deploys a Location Server and wants to o The visited network deploys a Location Server and wants to
distribute Location Objects of a user distribute Location Objects
o The visited network is able to learn the user's identity o The visited network is able to learn the user's identity.
The visited network provides location information to a Location The visited network provides location information to a Location
Recipient (e.g., via SIP or HTTP). During the network access Recipient (e.g., via SIP or HTTP). During the network access
authentication procedure the visited network is able to retrieve the authentication procedure the visited network is able to retrieve the
user's authorization policies from the home AAA server. This should user's authorization policies from the home AAA server. This should
ensure that the visited network acts according to the user's ensure that the visited network acts according to the user's
policies. policies.
The subsequent figure shows the interacting entities graphically. The subsequent figure shows the interacting entities graphically.
The transport of the Location Object is not shown in this figure
since this aspect is already covered in the previous paragraph.
visited network | home network visited network | home network
| |
+----------+ | +----------+ |
|Location | | |Location | |
|Recipient | | |Recipient | |
| | | | | |
+----------+ | +----------+ |
^ | +----------+ ^ | +----------+
| | | Rule | | | | Rule |
skipping to change at page 35, line 32 skipping to change at page 36, line 32
|Generator |<------------->| Server | |Generator |<------------->| Server |
|& Server | RADIUS | | |& Server | RADIUS | |
+----------+ | +----------+ +----------+ | +----------+
| |
Figure 17: Location Server at the Visited Network Figure 17: Location Server at the Visited Network
8.3. Requirements matching 8.3. Requirements matching
Section 7.1 of [10] details the requirements of a "Location Object". Section 7.1 of [10] details the requirements of a "Location Object".
We discuss these requirements in the subsequent list.
There are:
Req. 1. (Location Object generalities): Req. 1. (Location Object generalities):
* Regarding requirement 1.1, the Location Object has to be * Regarding requirement 1.1, the Location Object has to be
understood by the RADIUS server (and possibly a Diameter server understood by the RADIUS server (and possibly a Diameter server
in case of interworking between the two) as defined in this in case of interworking between the two) as defined in this
document. Due to the encoding of the Location Object it is document. Due to the encoding of the Location Object it is
possible to convert it to the format used in GMLv3 [19]. The possible to convert it to the format used in GMLv3 [24]. This
same civic location information format is used in PIDF-LO [16] document uses the civic and geospatial location information
and this document. format used in [6] and in [4]. The format of [6] and of [4]
can be convered into a PIDF-LO [21].
* Regarding requirement 1.2, a number of fields in the civic * Regarding requirement 1.2, a number of fields in the civic
location information format are optional. location information format are optional.
* Regarding requirement 1.3, the inclusion of type of place item * Regarding requirement 1.3, the inclusion of type of place item
(CAtype 29) gives a further classification of the location. (CAtype 29) used in the DHCP civic format gives a further
This attribute can be seen as an extension. classification of the location. This attribute can be seen as
an extension.
* Regarding requirement 1.4, the location information is not * Regarding requirement 1.4, the location information is not
defined in this document but is extensible. defined in this document.
* Regarding requirement 1.5, the Location Object is useful for * Regarding requirement 1.5, the Location Object is useful for
both receiving and sending location information as described in both receiving and sending location information as described in
this document. this document.
* Regarding requirement 1.6, the Location Object contains both * Regarding requirement 1.6, the Location Object contains both
location information and privacy rules. Location information location information and privacy rules. Location information
is described in Section 5.2, in Section 5.3 and in Section 5.4. is described in Section 5.2, in Section 5.3 and in Section 5.4.
The corresponding privacy rules are detailed in Section 5.5 and The corresponding privacy rules are detailed in Section 5.5 and
in Section 5.6. in Section 5.6.
* Regarding requirement 1.7, the Location Object is usable in a * Regarding requirement 1.7, the Location Object is usable in a
variety of protocols. The format of the object is reused from variety of protocols. The format of the object is reused from
other documents as detailed in the respective sections (see other documents as detailed in Section 5.2, Section 5.3,
Section 5.2, Section 5.3, Section 5.4 Section 5.5 and in Section 5.4 Section 5.5 and in Section 5.6).
Section 5.6).
* Regarding requirement 1.8, the encoding of the Location Object * Regarding requirement 1.8, the encoding of the Location Object
has an emphasis on a lightweight encoding format. As such it has an emphasis on a lightweight encoding format. As such it
is useable on constrained devices. is useable on constrained devices.
Req. 2. (Location Object fields): Req. 2. (Location Object fields):
* Regarding requirement 2.1, the Target Identifier is carried * Regarding requirement 2.1, the Target Identifier is carried
within the network access authentication protocol (e.g., within within the network access authentication protocol (e.g., within
the EAP-Identity Response when EAP is used and/or within the the EAP-Identity Response when EAP is used and/or within the
EAP method itself). As described in Section 9 it has a number EAP method itself). As described in Section 9 it has a number
of advantages if this identifier is not carried in clear text. of advantages if this identifier is not carried in clear. This
This is possible with certain EAP methods whereby the identity is possible with certain EAP methods whereby the identity in
in the EAP-Identity Response only contains information relevant the EAP-Identity Response only contains information relevant
for routing the response to the user's home network. The user for routing the response to the user's home network. The user
identity is protected by the authentication and key exchange identity is protected by the authentication and key exchange
protocol. protocol.
* Regarding requirement 2.2, the Location Recipient is in the * Regarding requirement 2.2, the Location Recipient is in the
main scenario the home AAA server. For a scenario where the main scenario the home AAA server. For a scenario where the
Location Recipient is obtaining Location Information from the Location Recipient is obtaining Location Information from the
Location Server via HTTP or SIP the respective mechanisms Location Server via HTTP or SIP the respective mechanisms
defined in these protocols are used to identify the recipient. defined in these protocols are used to identify the recipient.
The Location Generator cannot, a priori, know the recipients if The Location Generator cannot, a priori, know the recipients if
skipping to change at page 37, line 4 skipping to change at page 37, line 51
main scenario the home AAA server. For a scenario where the main scenario the home AAA server. For a scenario where the
Location Recipient is obtaining Location Information from the Location Recipient is obtaining Location Information from the
Location Server via HTTP or SIP the respective mechanisms Location Server via HTTP or SIP the respective mechanisms
defined in these protocols are used to identify the recipient. defined in these protocols are used to identify the recipient.
The Location Generator cannot, a priori, know the recipients if The Location Generator cannot, a priori, know the recipients if
they are not defined in this protocol. they are not defined in this protocol.
* Regarding requirement 2.3, the credentials of the Location * Regarding requirement 2.3, the credentials of the Location
Recipient are known to the RADIUS entities based on the Recipient are known to the RADIUS entities based on the
security mechanisms defined in the RADIUS protocol itself. security mechanisms defined in the RADIUS protocol itself.
Section 10 describes these security mechanisms offered by the Section 10 describes these security mechanisms offered by the
RADIUS protocol. The same is true for requirement 2.4. RADIUS protocol. The same is true for requirement 2.4.
* Regarding requirement 2.5, Section 5.2, Section 5.3 and * Regarding requirement 2.5, Section 5.2, Section 5.3 and
Section 5.4 describe the content of the Location Field. Since Section 5.4 describe the content of the Location Field. Since
the location format itself is not defined in this document the location format itself is not defined in this document
motion and direction vectors as listed in requirement 2.6 are motion and direction vectors as listed in requirement 2.6 are
not defined. not defined.
* Regarding requirement 2.6, this document only describes one * Regarding requirement 2.6, this document provides the
Location Data Type for civic and for geospatial location capability for the AAA server to indicate what type of location
information, respectively. No negotiation needs to take place. information it would like to see from the AAA client.
* Regarding requirement 2.7, timing information is provided with * Regarding requirement 2.7, timing information is provided with
'sighting time' and 'time-to-live' field defined in 'sighting time' and 'time-to-live' field defined in
Section 5.5. Section 5.2.
* Regarding requirement 2.8, a reference to an external (more * Regarding requirement 2.8, a reference to an external (more
detailed ruleset) is provided with the Section 5.6 attribute. detailed ruleset) is provided with the Section 5.6 attribute.
* Regarding requirement 2.9, security headers and trailers are * Regarding requirement 2.9, security headers and trailers are
provided as part of the RADIUS protocol or even as part of provided as part of the RADIUS protocol or even as part of
IPsec. IPsec.
* Regarding requirement 2.10, a version number in RADIUS is * Regarding requirement 2.10, a version number in RADIUS is
provided with the IANA registration of the attributes. New provided with the IANA registration of the attributes. New
skipping to change at page 37, line 43 skipping to change at page 38, line 41
Req. 3. (Location Data Types): Req. 3. (Location Data Types):
* Regarding requirement 3.1, this document reuses civic and * Regarding requirement 3.1, this document reuses civic and
geospatial location information as described in Section 5.4 and geospatial location information as described in Section 5.4 and
in Section 5.3. in Section 5.3.
* With the support of civic and geospatial location information * With the support of civic and geospatial location information
support requirement 3.2 is fulfilled. support requirement 3.2 is fulfilled.
* Regarding requirement 3.3, the geospatial location information * Regarding requirement 3.3, the geospatial location information
as defined in this document only refers to absolute used by this document only refers to absolute coordinates.
coordinates. However, the granularity of the location However, the granularity of the location information can be
information can be reduced with the help of the AltRes, LoRes, reduced with the help of the AltRes, LoRes, LaRes fields
LaRes fields described in the Location-Information attribute described in [6].
(see Section 5.2).
* Regarding requirement 3.4, further Location Data Types can be * Regarding requirement 3.4, further Location Data Types can be
added via new coordinate reference systems (CRSs) (see Datum added via new coordinate reference systems (CRSs) (see Datum
field in the Location-Information attribute of Section 5.4), field in [6]) and via extensions to [6] and [4].
extensions to existing fields or via additional attributes.
Section 7.2 of [10] details the requirements of a "Using Protocol". Section 7.2 of [10] details the requirements of a "Using Protocol".
These requirements are listed below: These requirements are listed below:
Req. 4.: The using protocol has to obey the privacy and security Req. 4.: The using protocol has to obey the privacy and security
instructions coded in the Location Object and in the corresponding instructions coded in the Location Object regarding the
Rules regarding the transmission and storage of the LO. This transmission and storage of the LO. This document requires that
document requires, that RADIUS entities sending or receiving RADIUS entities sending or receiving location MUST obey such
location MUST obey such instructions. instructions.
Req. 5.: The using protocol will typically facilitate that the keys Req. 5.: The using protocol will typically facilitate that the keys
associated with the credentials are transported to the respective associated with the credentials are transported to the respective
parties, that is, key establishment is the responsibility of the parties, that is, key establishment is the responsibility of the
using protocol. Section 10 specifies how security mechanisms are using protocol. Section 10 specifies how security mechanisms are
used in RADIUS and how they can be reused to provide security used in RADIUS and how they can be reused to provide security
protection for the Location Object. Additionally, the privacy protection for the Location Object. Additionally, the privacy
considerations (see Section 9) are also relevant for this considerations (see Section 9) are also relevant for this
requirement. requirement.
skipping to change at page 38, line 38 skipping to change at page 39, line 36
the inclusion into a single message that even respects the (Path) the inclusion into a single message that even respects the (Path)
MTU size. The concept of a transaction is not immediately MTU size. The concept of a transaction is not immediately
applicable to RADIUS. applicable to RADIUS.
Section 7.3 of [10] details the requirements of a "Rule based Section 7.3 of [10] details the requirements of a "Rule based
Location Data Transfer". These requirements are listed below: Location Data Transfer". These requirements are listed below:
Req. 7. (LS Rules): With the scenario shown in Figure 16 the Req. 7. (LS Rules): With the scenario shown in Figure 16 the
decision of a Location Server to provide a Location Recipient decision of a Location Server to provide a Location Recipient
access to location information is based on Rule Maker-defined access to location information is based on Rule Maker-defined
Privacy Rules which are stored at the home network or are Privacy Rules that are stored at the home network. With regard to
accessible for the home network. With regard to the scenario the scenario shown in Figure 17 the Rule Maker-defined Privacy
shown in Figure 17 the Rule Maker-defined Privacy Rules are sent Rules are sent from the home network to the visited network (see
from the home network to the visited network as part of the Section 5.5, Section 5.6 and Section 9 for more details).
Policy-Information attribute (see Section 5.5, Section 5.6 and
Section 9 for more details).
Req. 8. (LG Rules): For mid-session delivery it is possible to Req. 8. (LG Rules): For mid-session delivery it is possible to
enforce the user's privacy rules for the transfer of the Location enforce the user's privacy rules for the transfer of the Location
Object. For the initial transmission of a Location Object the Object. For the initial transmission of a Location Object the
user would have to use network access authentication methods which user would have to use network access authentication methods which
provide user identity confidentiality which would render the provide user identity confidentiality which would render the
Location Object completely useless for the visited network. For Location Object completely useless for the visited network. For
the scenario shown in Figure 16 the visited network is already in the scenario shown in Figure 16 the visited network is already in
possession of the users location information prior to the possession of the users location information prior to the
authentication and authorization of the user. A correlation authentication and authorization of the user. A correlation
skipping to change at page 39, line 28 skipping to change at page 40, line 20
Req. 9. (Viewer Rules): The Rule Maker might define (via mechanisms Req. 9. (Viewer Rules): The Rule Maker might define (via mechanisms
outside the scope of this document) which policy rules are outside the scope of this document) which policy rules are
disclosed to other entities. disclosed to other entities.
Req. 10. (Full Rule language): Geopriv has defined a rule language Req. 10. (Full Rule language): Geopriv has defined a rule language
capable of expressing a wide range of privacy rules which is capable of expressing a wide range of privacy rules which is
applicable in the area of the distribution of Location Objects. A applicable in the area of the distribution of Location Objects. A
basic ruleset is provided with the Basic-Policy-Rules attribute basic ruleset is provided with the Basic-Policy-Rules attribute
Section 5.5. A reference to the extended ruleset is carried in Section 5.5. A reference to the extended ruleset is carried in
Section 5.6. The format of these rules are described in [14] and Section 5.6. The format of these rules are described in [18] and
[15]. [19].
Req. 11. (Limited Rule language): A limited (or basic) ruleset is Req. 11. (Limited Rule language): A limited (or basic) ruleset is
provided by the Policy-Information attribute Section 5.5 (and as provided by the Policy-Information attribute Section 5.5 (and as
introduced with PIDF-LO [16]). introduced with PIDF-LO [21]).
Section 7.4 of [10] details the requirements of a "Location Object Section 7.4 of [10] details the requirements of a "Location Object
Privacy and Security". These requirements are listed below: Privacy and Security". These requirements are listed below:
Req. 12 (Identity Protection): Support for unlinkable pseudonyms is Req. 12 (Identity Protection): Support for unlinkable pseudonyms is
provided by the usage of a corresponding authentication and key provided by the usage of a corresponding authentication and key
exchange protocol. Such protocols are available, for example, exchange protocol. Such protocols are available, for example,
with the support of EAP as network access authentication methods. with the support of EAP as network access authentication methods.
Some EAP methods support passive user identity confidentiality Some EAP methods support passive user identity confidentiality
whereas others even support active user identity confidentiality. whereas others even support active user identity confidentiality.
This issue is further discussed in Section 10. The importance for This issue is further discussed in Section 10. The importance for
user identity confidentiality and identity protection has already user identity confidentiality and identity protection has already
been recognized (see for example a document on 'EAP Method been recognized as an important property (see for example a
Requirements for Wireless LANs' [20]). document on 'EAP Method Requirements for Wireless LANs' [25]).
Req. 13. (Credential Requirements): As described in Section 10 Req. 13. (Credential Requirements): As described in Section 10
RADIUS signaling messages can be protected with IPsec. This RADIUS signaling messages can be protected with IPsec. This
allows a number of authentication and key exchange protocols to be allows a number of authentication and key exchange protocols to be
used as part of IKE, IKEv2 or KINK. used as part of IKE, IKEv2 or KINK.
Req. 14. (Security Features): Geopriv defines a few security Req. 14. (Security Features): Geopriv defines a few security
requirements for the protection of Location Objects such as mutual requirements for the protection of Location Objects such as mutual
end-point authentication, data object integrity, data object end-point authentication, data object integrity, data object
confidentiality and replay protection. As described in Section 10 confidentiality and replay protection. As described in Section 10
these requirements are fulfilled with the usage of IPsec if the these requirements are fulfilled with the usage of IPsec if mutual
mutual authentication refers to the RADIUS entities (acting as authentication refers to the RADIUS entities (acting as various
various Geopriv entities) which directly communicate with each Geopriv entities) which directly communicate with each other.
other.
Req. 15. (Minimal Crypto): A minimum of security mechanisms are Req. 15. (Minimal Crypto): A minimum of security mechanisms are
mandated by the usage of RADIUS. Communication security for mandated by the usage of RADIUS. Communication security for
Location Objects between AAA infrastructure elements is provided Location Objects between AAA infrastructure elements is provided
by the RADIUS protocol (including IPsec and its dynamic key by the RADIUS protocol (including IPsec and its dynamic key
management framework) rather than on relying on object security management framework) rather than on relying on object security
via S/SIME (which is not available with RADIUS). via S/SIME (which is not available with RADIUS).
9. Privacy Considerations 9. Privacy Considerations
skipping to change at page 42, line 30 skipping to change at page 43, line 30
attribute (such as interim accounting messages). attribute (such as interim accounting messages).
9.2. Entity in the home network 9.2. Entity in the home network
The AAA server in the home network might be an ideal place for The AAA server in the home network might be an ideal place for
storing authorization policies. The user typically has a contractual storing authorization policies. The user typically has a contractual
relationship with his home network and hence the trust relationship relationship with his home network and hence the trust relationship
between them is stronger. Once the infrastructure is deployed and between them is stronger. Once the infrastructure is deployed and
useful applications are available there might be a strong desire to useful applications are available there might be a strong desire to
use location information for other purposes as well (such as location use location information for other purposes as well (such as location
aware applications). Authorization policy rules described in [15] aware applications). Authorization policy rules described in [19]
and in [14] are tailored for this environment. These policies might and in [18] are tailored for this environment. These policies might
be useful for limiting further distribution of the user's location to be useful for limiting further distribution of the user's location to
other location based services. The home AAA server (or a similar other location based services. The home AAA server (or a similar
entity) thereby acts as a location server for access to location entity) thereby acts as a location server for access to location
services. services.
The home network MUST behave according to the following guidelines: The home network MUST behave according to the following guidelines:
o As a default policy the home network MUST NOT distribute the o As a default policy the home network MUST NOT distribute the
user's location information to third party entities. user's location information to third party entities.
skipping to change at page 43, line 41 skipping to change at page 44, line 41
brokers, then it is possible to correlate location information with a brokers, then it is possible to correlate location information with a
particular user. As such, it allows the visited network and brokers particular user. As such, it allows the visited network and brokers
to learn movement patterns of users. to learn movement patterns of users.
The identity of the user can "leak" to the visited network or AAA The identity of the user can "leak" to the visited network or AAA
brokers in a number of ways: brokers in a number of ways:
o The user's device may employ a fixed MAC address, or base its IP o The user's device may employ a fixed MAC address, or base its IP
address on such an address. This enables the correlation of the address on such an address. This enables the correlation of the
particular device to its different locations. Techniques exist to particular device to its different locations. Techniques exist to
avoid the use of an IP address that is based on MAC address [21]. avoid the use of an IP address that is based on MAC address [26].
Some link layers make it possible to avoid MAC addresses or change Some link layers make it possible to avoid MAC addresses or change
them dynamically. them dynamically.
o Network access authentication procedures such as PPP CHAP [22] or o Network access authentication procedures such as PPP CHAP [27] or
EAP [23] may reveal the user's identity as a part of the EAP [28] may reveal the user's identity as a part of the
authentication procedure. Techniques exist to avoid this problem authentication procedure. Techniques exist to avoid this problem
in EAP, for instance by employing private Network Access in EAP, for instance by employing private Network Access
Identifiers (NAIs) in the EAP Identity Response message [24] and Identifiers (NAIs) in the EAP Identity Response message [29] and
by method-specific private identity exchange in the EAP method by method-specific private identity exchange in the EAP method
(e.g., [24], [25], [26]). Support for identity privacy within (e.g., [29], [30], [31]). Support for identity privacy within
CHAP is not available. CHAP is not available.
o AAA protocols may return information from the home network to the o AAA protocols may return information from the home network to the
visited in a manner that makes it possible to either identify the visited in a manner that makes it possible to either identify the
user or at least correlate his session with other sessions, such user or at least correlate his session with other sessions, such
as the use of static data in a Class attribute [2] or in some as the use of static data in a Class attribute [2] or in some
accounting attribute usage scenarios [27]. accounting attribute usage scenarios [32].
o Mobility mechanisms may reveal some permanent identifier (such as o Mobility mechanisms may reveal some permanent identifier (such as
a home address) in cleartext in the packets relating to mobility a home address) in cleartext in the packets relating to mobility
signaling. signaling.
o Application protocols may reveal other permanent identifiers. o Application protocols may reveal other permanent identifiers.
Note that to prevent the correlation of identities with location Note that to prevent the correlation of identities with location
information it is necessary to prevent leakage of identity information it is necessary to prevent leakage of identity
information from all sources, not just one. information from all sources, not just one.
skipping to change at page 45, line 12 skipping to change at page 46, line 12
information along the RADIUS infrastructure. Mechanisms to achieve information along the RADIUS infrastructure. Mechanisms to achieve
this functionality are discussed in Section 10. this functionality are discussed in Section 10.
10. Security Considerations 10. Security Considerations
Requirements for the protection of a Location Object are defined in Requirements for the protection of a Location Object are defined in
[10]: Mutual end-point authentication, data object integrity, data [10]: Mutual end-point authentication, data object integrity, data
object confidentiality and replay protection. The distribution of object confidentiality and replay protection. The distribution of
location information can be restricted with the help of authorization location information can be restricted with the help of authorization
policies. Basic authorization policies are attached to the location policies. Basic authorization policies are attached to the location
information itself, in the same fashion as described in [16]. It is information itself, in the same fashion as described in [21]. It is
possible that the user was already able to transfer some possible that the user was already able to transfer some
authorization policies to the access network to restrict the authorization policies to the access network to restrict the
distribution of location information. This is, however, rather distribution of location information. This is, however, rather
unlikely in case of roaming users. Hence, it will be primarily the unlikely in case of roaming users. Hence, it will be primarily the
NAS creating the Location Object which also sets the authorization NAS creating the Location Object which also sets the authorization
policies. If no authorization information is provided by the user policies. If no authorization information is provided by the user
then the visited network MUST set the authorization policies to only then the visited network MUST set the authorization policies to only
allow the home AAA server to use the provided location information. allow the home AAA server to use the provided location information.
Other entities, such as the visited network and possibly AAA brokers Other entities, such as the visited network and possibly AAA brokers
MUST NOT use the location information for a purpose other than MUST NOT use the location information for a purpose other than
described in this document. More extensible authorization policies described in this document. More extensible authorization policies
can be stored at the user's home network. These policies are useful can be stored at the user's home network. These policies are useful
when location information is distributed to other entities in a when location information is distributed to other entities in a
location-based service. This scenario is, however, outside the scope location-based service. This scenario is, however, outside the scope
of this document. of this document.
It is necessary to use authorization policies to limit the It is necessary to use authorization policies to limit the
unauthorized distribution of location information. The security unauthorized distribution of location information. The security
requirements which are created based on [10] are inline with threats requirements which are created based on [10] are inline with threats
which appear in the relationship with disclosure of location which appear in the relationship with disclosure of location
information as described in [28]. PIDF-LO [16] proposes S/MIME to information as described in [33]. PIDF-LO [21] proposes S/MIME to
protect the Location Object against modifications. S/SIME relies on protect the Location Object against modifications. S/SIME relies on
public key cryptography which raises performance, deployment and size public key cryptography which raises performance, deployment and size
considerations. Encryption would require that the local AAA server considerations. Encryption would require that the local AAA server
or the NAS knows the recipient's public key (e.g., the public key of or the NAS knows the recipient's public key (e.g., the public key of
the home AAA server). Knowing the final recipient of the location the home AAA server). Knowing the final recipient of the location
information is in many cases difficult for RADIUS entities. Some information is in many cases difficult for RADIUS entities. Some
sort of public key infrastructure would be required to obtain the sort of public key infrastructure would be required to obtain the
public key and to verify the digital signature (at the home network). public key and to verify the digital signature (at the home network).
Providing per-object cryptographic protection is, both at the home Providing per-object cryptographic protection is, both at the home
and at the visited network, computationally expensive. and at the visited network, computationally expensive.
If no authentication, integrity and replay protection between the If no authentication, integrity and replay protection between the
participating RADIUS entities is provided then an adversaries can participating RADIUS entities is provided then an adversaries can
spoof and modify transmitted attributes. Two security mechanisms are spoof and modify transmitted attributes. Two security mechanisms are
proposed for RADIUS: proposed for RADIUS:
o [2] proposes the usage of a static key which might raise some o [2] proposes the usage of a static key which might raise some
concerns about the lack dynamic key management. concerns about the lack dynamic key management.
o RADIUS over IPsec [29] allows to run standard key management o RADIUS over IPsec [34] allows to run standard key management
mechanisms, such as KINK, IKE and IKEv2 [30], to establish IPsec mechanisms, such as KINK, IKE and IKEv2 [35], to establish IPsec
security associations. Confidentiality protection MUST be used to security associations. Confidentiality protection MUST be used to
prevent eavesdropper gaining access to location information. prevent eavesdropper gaining access to location information.
Confidentiality protection is not only a property required by this Confidentiality protection is not only a property required by this
document, it is also required for the transport of keying material document, it is also required for the transport of keying material
in the context of EAP authentication and authorization. Hence, in the context of EAP authentication and authorization. Hence,
this requirement is, in many environments, already fulfilled. this requirement is, in many environments, already fulfilled.
Mutual authentication must be provided between the local AAA Mutual authentication must be provided between the local AAA
server and the home AAA server to prevent man-in-the-middle server and the home AAA server to prevent man-in-the-middle
attacks from being successful. This is another requirement raised attacks from being successful. This is another requirement raised
in the area of key transport with RADIUS and does not represent a in the area of key transport with RADIUS and does not represent a
deployment obstacle. The performance advantages superior compared deployment obstacle. The performance advantages superior compared
to the usage of S/MIME and object security since the expensive to the usage of S/MIME and object security since the expensive
authentication and key exchange protocol run needs to be provided authentication and key exchange protocol run needs to be provided
only once (for a long time). Symmetric channel security with only once (for a long time). Symmetric channel security with
IPsec is highly efficient. Since IPsec protection is suggested as IPsec is highly efficient. Since IPsec protection is suggested as
a mechanism to protect RADIUS already no additional considerations a mechanism to protect RADIUS already no additional considerations
need to be addressed beyond those described in [29]. Where an need to be addressed beyond those described in [34]. Where an
untrusted AAA intermediary is present, the Location Object MUST untrusted AAA intermediary is present, the Location Object MUST
NOT be provided to the intermediary. NOT be provided to the intermediary.
In case that IPsec protection is not available for some reason and In case that IPsec protection is not available for some reason and
RADIUS specific security mechanisms have to be used then the RADIUS specific security mechanisms have to be used then the
following considerations apply. The Access-Request message is not following considerations apply. The Access-Request message is not
integrity protected. This would allow an adversary to change the integrity protected. This would allow an adversary to change the
contents of the Location Object or to insert and modify attributes contents of the Location Object or to insert and modify attributes
and fields or to delete attributes. To address these problems the and fields or to delete attributes. To address these problems the
Message-Authenticator (80) can be used to integrity protect the Message-Authenticator (80) can be used to integrity protect the
skipping to change at page 47, line 12 skipping to change at page 48, line 12
RADIUS and Diameter make some assumptions about the trust between RADIUS and Diameter make some assumptions about the trust between
traversed AAA entities in sense that object level security is not traversed AAA entities in sense that object level security is not
provided by neither RADIUS nor Diameter. Hence, some trust has to be provided by neither RADIUS nor Diameter. Hence, some trust has to be
placed on the AAA entities to behave according to the defined rules. placed on the AAA entities to behave according to the defined rules.
Furthermore, the AAA protocols do not involve the user in their Furthermore, the AAA protocols do not involve the user in their
protocol interaction except for tunneling authentication information protocol interaction except for tunneling authentication information
(such as EAP messages) through their infrastructure. RADIUS and (such as EAP messages) through their infrastructure. RADIUS and
Diameter have even become a de-facto protocol for key distribution. Diameter have even become a de-facto protocol for key distribution.
Hence, in the past there were some concerns about the trust placed Hence, in the past there were some concerns about the trust placed
into the infrastructure particularly from the security area when it into the infrastructure particularly from the security area when it
comes to keying. The EAP keying infrastructure is described in [23]. comes to keying. The EAP keying infrastructure is described in [28].
11. IANA Considerations 11. IANA Considerations
The authors request that the Attribute Types, and Attribute Values The authors request that the Attribute Types, and Attribute Values
defined in this document be registered by the Internet Assigned defined in this document be registered by the Internet Assigned
Numbers Authority (IANA) from the RADIUS name spaces as described in Numbers Authority (IANA) from the RADIUS name spaces as described in
the "IANA Considerations" section of RFC 3575 [8], in accordance with the "IANA Considerations" section of RFC 3575 [8], in accordance with
BCP 26 [9]. Additionally, the Attribute Type should be registered in BCP 26 [9]. Additionally, the Attribute Type should be registered in
the Diameter name space. the Diameter name space.
skipping to change at page 48, line 36 skipping to change at page 49, line 36
Error-Cause attribute [5], of "Location-Info-Required" TBA. Error-Cause attribute [5], of "Location-Info-Required" TBA.
Additionally, IANA is requested to create the following new Additionally, IANA is requested to create the following new
registries: registries:
11.1. New Registry: Operator Type 11.1. New Registry: Operator Type
This document also defines an operator namespace registry (used in This document also defines an operator namespace registry (used in
the Namespace field of the Operator-Name attribute). IANA is the Namespace field of the Operator-Name attribute). IANA is
requested to add the following values to this registry using their requested to add the following values to this registry using their
identifier and operator-namespace / associated registry owners for identifier and a token for the operator-namespace / registry owner:
the operator namespace pairs:
+----------+--------------------------------------+ +----------+--------------------------------------+
|Identifier| Operator-Namespace / Registry Owner | |Identifier| Operator-Namespace / Registry Owner |
+----------+--------------------------------------+ +----------+--------------------------------------+
| 0 | GSM - GSM Association/TADIG WG | | 0 | TADIG |
| 1 | CDMA - IMSI Oversight Council | | 1 | E212 |
| 2 | REALM - IANA or delegate | | 2 | REALM |
| 3 | ITU - ITU-T/TSB | | 3 | ICC |
+----------+--------------------------------------+ +----------+--------------------------------------+
Following the policies outline in [9] new values to the Operator- Following the policies outlined in [9] new values to the Operator-
Namespaces will be assigned after Expert Review by the Geopriv Namespaces will be assigned after Expert Review initiated by the O&M
working group or its designated successor. Updates can be provided Area Director in consultation with the RADEXT working group chairs or
based on expert approval only. No mechanism to mark entries as the working group chairs of a designated successor working group.
"deprecated" is envisioned. Based on expert approval it is possible Updates can be provided based on expert approval only. No mechanism
to delete entries from the registry. to mark entries as "deprecated" is envisioned. Based on expert
approval it is possible to delete entries from the registry.
11.2. New Registry: Requested-Info attribute 11.2. New Registry: Requested-Info attribute
This document creates a new IANA registry for the Requested-Info This document creates a new IANA registry for the Requested-Info
attribute. IANA is requested to add the following four values to attribute. IANA is requested to add the following four values to
this registry: this registry:
+----------+----------------------+ +----------+----------------------+
| Value | Capability Token | | Value | Capability Token |
+----------+----------------------+ +----------+----------------------+
| 1 | CIVIC_LOCATION | | 1 | CIVIC_LOCATION |
| 2 | GEO_LOCATION | | 2 | GEO_LOCATION |
| 4 | USERS_LOCATION | | 4 | USERS_LOCATION |
| 8 | NAS_LOCATION | | 8 | NAS_LOCATION |
+----------+----------------------+ +----------+----------------------+
The semantic of these values is defined in Section 5.8. The semantic of these values is defined in Section 5.8.
Following the policies outline in [8] new Value/Capability Tokens Following the policies outline in [8] new Capability Tokens with a
with a description about their sematnic for usage with the Requested- description of their semantic for usage with the Requested-Info
Info attribute will be assigned after Expert Review by the RADEXT attribute will be assigned after Expert Review initiated by the O&M
working group or its designated successor. Updates can be provided Area Directors in consultation with the RADEXT working group chairs
based on expert approval only. A designated expert will be appointed or the working group chairs of a designated successor working group.
by the O&M Area Directors. No mechanism to mark entries as Updates can be provided based on expert approval only. A designated
"deprecated is envisioned. Based on expert approval it is possible expert will be appointed by the O&M Area Directors. No mechanism to
to delete entries from the registry. mark entries as "deprecated" is envisioned. Based on expert approval
it is possible to delete entries from the registry.
Each registration must include: Each registration must include:
Name: Name:
Capability Token (i.e., an identifier of the capability) Capability Token (i.e., an identifier of the capability)
Description: Description:
Brief description indicating the meaning of the info element. Brief description indicating the meaning of the info element.
skipping to change at page 52, line 50 skipping to change at page 53, line 50
13.2. Informative References 13.2. Informative References
[10] Cuellar, J., Morris, J., Mulligan, D., Peterson, D., and D. [10] Cuellar, J., Morris, J., Mulligan, D., Peterson, D., and D.
Polk, "Geopriv Requirements", RFC 3693, February 2004. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[11] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [11] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[12] Polk, J. and B. Rosen, "Session Initiation Protocol Location [12] Polk, J. and B. Rosen, "Session Initiation Protocol Location
Conveyance", draft-ietf-sip-location-conveyance-02 (work in Conveyance", draft-ietf-sip-location-conveyance-03 (work in
progress), March 2006. progress), June 2006.
[13] Mills, D., "Network Time Protocol (Version 3) Specification, [13] "TADIG Naming Conventions, Version 4.1", GSM Association
Official Document TD.13", , June 2006.
[14] "The international identification plan for mobile terminals and
mobile users, ITU-T Recommendation E.212", , May 2004.
[15] "Designations for interconnections among operators' networks,
ITU-T Recommendation M.1400", , January 2004.
[16] "Codes for the representation of names of countries and their
subdivisions - Part 1: Country codes, ISO 3166-1", , 1997.
[17] Mills, D., "Network Time Protocol (Version 3) Specification,
Implementation", RFC 1305, March 1992. Implementation", RFC 1305, March 1992.
[14] Schulzrinne, H., "Common Policy: An XML Document Format for [18] Schulzrinne, H., "Common Policy: A Document Format for
Expressing Privacy Preferences", Expressing Privacy Preferences",
draft-ietf-geopriv-common-policy-10 (work in progress), draft-ietf-geopriv-common-policy-11 (work in progress),
May 2006. August 2006.
[15] Schulzrinne, H., "A Document Format for Expressing Privacy [19] Schulzrinne, H., "A Document Format for Expressing Privacy
Preferences for Location Information", Preferences for Location Information",
draft-ietf-geopriv-policy-08 (work in progress), February 2006. draft-ietf-geopriv-policy-08 (work in progress), February 2006.
[16] Peterson, J., "A Presence-based GEOPRIV Location Object [20] Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)",
draft-ietf-simple-xcap-11 (work in progress), May 2006.
[21] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005. Format", RFC 4119, December 2005.
[17] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter [22] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter
Network Access Server Application", RFC 4005, August 2005. Network Access Server Application", RFC 4005, August 2005.
[18] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible [23] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
Authentication Protocol (EAP) Application", RFC 4072, Authentication Protocol (EAP) Application", RFC 4072,
August 2005. August 2005.
[19] "Open Geography Markup Language (GML) Implementation [24] "Open Geography Markup Language (GML) Implementation
Specification", OGC 02-023r4, Specification", OGC 02-023r4,
http://www.opengis.org/techno/implementation.htm", , http://www.opengis.org/techno/implementation.htm", ,
January 2003. January 2003.
[20] Stanley, D., Walker, J., and B. Aboba, "Extensible [25] Stanley, D., Walker, J., and B. Aboba, "Extensible
Authentication Protocol (EAP) Method Requirements for Wireless Authentication Protocol (EAP) Method Requirements for Wireless
LANs", RFC 4017, March 2005. LANs", RFC 4017, March 2005.
[21] Narten, T. and R. Draves, "Privacy Extensions for Stateless [26] Narten, T. and R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, January 2001. Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[22] Simpson, W., "PPP Challenge Handshake Authentication Protocol [27] Simpson, W., "PPP Challenge Handshake Authentication Protocol
(CHAP)", RFC 1994, August 1996. (CHAP)", RFC 1994, August 1996.
[23] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network [28] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network
Access Identifier", RFC 4282, December 2005. Access Identifier", RFC 4282, December 2005.
[24] Arkko, J. and H. Haverinen, "Extensible Authentication Protocol [29] Arkko, J. and H. Haverinen, "Extensible Authentication Protocol
Method for 3rd Generation Authentication and Key Agreement Method for 3rd Generation Authentication and Key Agreement
(EAP-AKA)", RFC 4187, January 2006. (EAP-AKA)", RFC 4187, January 2006.
[25] Josefsson, S., Palekar, A., Simon, D., and G. Zorn, "Protected [30] Josefsson, S., Palekar, A., Simon, D., and G. Zorn, "Protected
EAP Protocol (PEAP) Version 2", EAP Protocol (PEAP) Version 2",
draft-josefsson-pppext-eap-tls-eap-10 (work in progress), draft-josefsson-pppext-eap-tls-eap-10 (work in progress),
October 2004. October 2004.
[26] Tschofenig, H., "EAP IKEv2 Method", [31] Tschofenig, H., "EAP IKEv2 Method",
draft-tschofenig-eap-ikev2-11 (work in progress), June 2006. draft-tschofenig-eap-ikev2-11 (work in progress), June 2006.
[27] Adrangi, F., Lior, A., Korhonen, J., and J. Loughney, [32] Adrangi, F., Lior, A., Korhonen, J., and J. Loughney,
"Chargeable User Identity", RFC 4372, January 2006. "Chargeable User Identity", RFC 4372, January 2006.
[28] Danley, M., "Threat Analysis of the Geopriv Protocol", [33] Danley, M., "Threat Analysis of the Geopriv Protocol",
RFC 3694, September 2003. RFC 3694, September 2003.
[29] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial [34] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial
In User Service) Support For Extensible Authentication Protocol In User Service) Support For Extensible Authentication Protocol
(EAP)", RFC 3579, September 2003. (EAP)", RFC 3579, September 2003.
[30] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [35] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005. RFC 4306, December 2005.
Authors' Addresses Authors' Addresses
Hannes Tschofenig Hannes Tschofenig
Siemens Siemens
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
Munich, Bavaria 81739 Munich, Bavaria 81739
Germany Germany
Email: Hannes.Tschofenig@siemens.com Email: Hannes.Tschofenig@siemens.com
URI: http://www.tschofenig.com
Farid Adrangi Farid Adrangi
Intel Corporatation Intel Corporatation
2111 N.E. 25th Avenue 2111 N.E. 25th Avenue
Hillsboro OR Hillsboro OR
USA USA
Email: farid.adrangi@intel.com Email: farid.adrangi@intel.com
Mark Jones Mark Jones
skipping to change at page 56, line 5 skipping to change at page 57, line 5
Email: mark.jones@bridgewatersystems.com Email: mark.jones@bridgewatersystems.com
Avi Lior Avi Lior
Bridgewater Systems Corporation Bridgewater Systems Corporation
303 Terry Fox Drive 303 Terry Fox Drive
Ottawa, Ontario K2K 3J1 Ottawa, Ontario K2K 3J1
CANADA CANADA
Email: avi@bridgewatersystems.com Email: avi@bridgewatersystems.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
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 procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 56, line 29 skipping to change at page 57, line 45
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
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
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 provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 130 change blocks. 
357 lines changed or deleted 364 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/