draft-ietf-geopriv-radius-lo-11.txt   draft-ietf-geopriv-radius-lo-12.txt 
GEOPRIV H. Tschofenig GEOPRIV H. Tschofenig
Internet-Draft Nokia Siemens Networks Internet-Draft Nokia Siemens Networks
Intended status: Standards Track F. Adrangi Intended status: Standards Track F. Adrangi
Expires: December 11, 2007 Intel Expires: December 20, 2007 Intel
M. Jones M. Jones
A. Lior A. Lior
Bridgewater Bridgewater
June 9, 2007 June 18, 2007
Carrying Location Objects in the Remote Authentication Dial In User Carrying Location Objects in RADIUS and Diameter
Service (RADIUS) Protocol draft-ietf-geopriv-radius-lo-12.txt
draft-ietf-geopriv-radius-lo-11.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 39 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 11, 2007. This Internet-Draft will expire on December 20, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document describes Remote Authentication Dial In User Service This document describes procedures for conveying access network
(RADIUS) attributes for conveying access network ownership and ownership and location information based on a civic and geospatial
location information based on a civic and geospatial location format. location format in Remote Authentication Dial In User Service
(RADIUS) and Diameter.
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Delivery Methods for Location Information . . . . . . . . . . 6 3. Delivery Methods for Location Information . . . . . . . . . . 6
skipping to change at page 3, line 22 skipping to change at page 3, line 22
3.3. Location Delivery based on Mid-Session Request . . . . . . 9 3.3. Location Delivery based on Mid-Session Request . . . . . . 9
3.4. Location Delivery in Accounting Messages . . . . . . . . . 10 3.4. Location Delivery in Accounting Messages . . . . . . . . . 10
4. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Operator-Name Attribute . . . . . . . . . . . . . . . . . 12 4.1. Operator-Name Attribute . . . . . . . . . . . . . . . . . 12
4.2. Location-Information Attribute . . . . . . . . . . . . . . 15 4.2. Location-Information Attribute . . . . . . . . . . . . . . 15
4.3. Location Data Attribute . . . . . . . . . . . . . . . . . 17 4.3. Location Data Attribute . . . . . . . . . . . . . . . . . 17
4.3.1. Civic Location Profile . . . . . . . . . . . . . . . . 18 4.3.1. Civic Location Profile . . . . . . . . . . . . . . . . 18
4.3.2. Geospatial Location Profile . . . . . . . . . . . . . 19 4.3.2. Geospatial Location Profile . . . . . . . . . . . . . 19
4.4. Basic Policy Rules Attribute . . . . . . . . . . . . . . . 19 4.4. Basic Policy Rules Attribute . . . . . . . . . . . . . . . 19
4.5. Extended Policy Rules Attribute . . . . . . . . . . . . . 22 4.5. Extended Policy Rules Attribute . . . . . . . . . . . . . 22
4.6. Challenge-Capable Attribute . . . . . . . . . . . . . . . 23 4.6. Location-Capable Attribute . . . . . . . . . . . . . . . . 23
4.7. Requested-Info Attribute . . . . . . . . . . . . . . . . . 24 4.7. Requested-Info Attribute . . . . . . . . . . . . . . . . . 24
5. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 30 5. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 31
6. Diameter RADIUS Interoperability . . . . . . . . . . . . . . . 31 6. Diameter RADIUS Interoperability . . . . . . . . . . . . . . . 32
7. Security Considerations . . . . . . . . . . . . . . . . . . . 32 7. Security Considerations . . . . . . . . . . . . . . . . . . . 33
7.1. Communication Security . . . . . . . . . . . . . . . . . . 32 7.1. Communication Security . . . . . . . . . . . . . . . . . . 33
7.2. Privacy Considerations . . . . . . . . . . . . . . . . . . 33 7.2. Privacy Considerations . . . . . . . . . . . . . . . . . . 34
7.2.1. RADIUS Client . . . . . . . . . . . . . . . . . . . . 34 7.2.1. RADIUS Client . . . . . . . . . . . . . . . . . . . . 35
7.2.2. RADIUS Server . . . . . . . . . . . . . . . . . . . . 35 7.2.2. RADIUS Server . . . . . . . . . . . . . . . . . . . . 35
7.2.3. RADIUS Broker . . . . . . . . . . . . . . . . . . . . 35 7.2.3. RADIUS Proxy . . . . . . . . . . . . . . . . . . . . . 36
7.3. Identity Information and Location Information . . . . . . 36 7.3. Identity Information and Location Information . . . . . . 36
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
8.1. New Registry: Operator Namespace Identifier . . . . . . . 38 8.1. New Registry: Operator Namespace Identifier . . . . . . . 38
8.2. New Registry: Location Profiles . . . . . . . . . . . . . 39 8.2. New Registry: Location Profiles . . . . . . . . . . . . . 39
8.3. New Registry: Challenge Capable Attribute . . . . . . . . 40 8.3. New Registry: Challenge Capable Attribute . . . . . . . . 40
8.4. New Registry: Entity Types . . . . . . . . . . . . . . . . 40 8.4. New Registry: Entity Types . . . . . . . . . . . . . . . . 40
8.5. New Registry: Privacy Flags . . . . . . . . . . . . . . . 41 8.5. New Registry: Privacy Flags . . . . . . . . . . . . . . . 41
8.6. New Registry: Requested-Info Attribute . . . . . . . . . . 41 8.6. New Registry: Requested-Info Attribute . . . . . . . . . . 41
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 43 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 43
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44
skipping to change at page 4, line 29 skipping to change at page 4, line 29
visited network needs to be conveyed to the user's home network. The visited network needs to be conveyed to the user's home network. The
main intent of this document is to enable location aware billing main intent of this document is to enable location aware billing
(e.g., by determining the appropriate tariff and taxation in (e.g., by determining the appropriate tariff and taxation in
dependence of the location of the access network and the end host), dependence of the location of the access network and the end host),
location aware subscriber authentication and authorization for location aware subscriber authentication and authorization for
roaming environments and to enable other location aware services. roaming environments and to enable other location aware services.
This document describes RADIUS attributes, which are added by a This document describes RADIUS attributes, which are added by a
RADIUS client or a RADIUS proxy, to convey location-related RADIUS client or a RADIUS proxy, to convey location-related
information to the RADIUS server in Access-Request packets, or information to the RADIUS server in Access-Request packets, or
additionally, within Accounting-Request packets. additionally, within Accounting-Request packets. The description is
also applicable for usage with Diameter.
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. [9] defines access and distribution to preserve the user's privacy. [9] defines
requirements for a protocol-independent model for the access to requirements for a protocol-independent model for the access to
geographic location information. The model includes a Location geographic location information. The model includes a Location
Generator (LG) that creates location information, a Location Server Generator (LG) that creates location information, a Location Server
(LS) that authorizes access to location information, a Location (LS) that authorizes access to location information, a Location
Recipient (LR) that requests and receives information, and a Rule Recipient (LR) that requests and receives information, and a Rule
Maker (RM) that provides authorization policies to the LS which Maker (RM) that provides authorization policies to the LS which
enforces access control policies on requests to location information. enforces access control policies on requests to location information.
skipping to change at page 7, line 39 skipping to change at page 7, line 39
| | | | | |
Figure 1: Location Delivery based on out-of-band Agreements Figure 1: Location Delivery based on out-of-band Agreements
3.2. Location Delivery based on Initial Request 3.2. Location Delivery based on Initial Request
If no location information is provided by the RADIUS client although If no location information is provided by the RADIUS client although
it is needed by the RADIUS server to compute the 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. In the initial Access-Request message exchange is shown in Figure 2. In the initial Access-Request message
from the NAS to the RADIUS server the Challenge-Capable attribute is from the NAS to the RADIUS server the Location-Capable attribute is
attached to indicate that the NAS understands the Access-Challenge attached to indicate that the NAS understands the Access-Challenge
message. The subsequent Access-Challenge message sent from the message. The subsequent Access-Challenge message sent from the
RADIUS server to the NAS provides a hint regarding the type of RADIUS server to the NAS provides a hint regarding the type of
desired location information attributes. In the shown message flow desired location information attributes. 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 attributes listed in number of criteria, including the newly defined attributes listed in
Section 4. Section 4.
skipping to change at page 8, line 17 skipping to change at page 8, line 17
| User | | Access | | Server | | User | | Access | | Server |
| | | Server | | | | | | Server | | |
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+
| | | | | |
| Authentication phase | | | Authentication phase | |
| begin | | | begin | |
|---------------------->| | |---------------------->| |
| | | | | |
| | RADIUS | | | RADIUS |
| | Access-Request | | | Access-Request |
| | + Challenge-Capable | | | + Location-Capable |
| |----------------------------->| | |----------------------------->|
| | | | | |
| | RADIUS | | | RADIUS |
| | Access-Challenge | | | Access-Challenge |
| | + Basic-Policy-Rules | | | + Basic-Policy-Rules |
| | + Extended-Policy-Rules | | | + Extended-Policy-Rules |
| | + Requested-Info | | | + Requested-Info |
| |<-----------------------------| | |<-----------------------------|
| | | | | |
| | RADIUS | | | RADIUS |
skipping to change at page 9, line 11 skipping to change at page 9, line 11
| | | | | |
Figure 2: Location Delivery based on Initial Request Figure 2: Location Delivery based on Initial Request
3.3. Location Delivery based on Mid-Session Request 3.3. Location Delivery based on Mid-Session Request
The demand mid-session location delivery method utilizes the Change The demand mid-session location delivery method utilizes the Change
of Authorization (COA) message, as defined in [3]. At anytime during of Authorization (COA) message, as defined in [3]. At anytime during
the session the RADIUS server MAY send a COA message containing the session the RADIUS server MAY send a COA message containing
session identification attributes to the RADIUS client. The COA session identification attributes to the RADIUS client. The COA
message MAY instruct the RADIUS client to generate an Authorize-Only message may instruct the RADIUS client to generate an Authorize-Only
Access-Request (Access-Request with Service-Type set to "Authorize- Access-Request (Access-Request with Service-Type set to "Authorize-
Only") in which case the RADIUS client MUST include location Only") in which case the RADIUS client MUST include location
information in this Access-Request if it did so on a previous Access- information in this Access-Request if this functionality was
Request so that the RADIUS server can authorize based on location previously set in the Requested-Info attribute.
information.
Figure 3 shows the approach graphically. Figure 3 shows the approach graphically.
+---------+ +---------+ +---------+ +---------+
| Network | | RADIUS | | Network | | RADIUS |
| Access | | Server | | Access | | Server |
| Server | | | | Server | | |
+---------+ +---------+ +---------+ +---------+
| | | |
| COA + Service-Type "Authorize Only" | | COA + Service-Type "Authorize Only" |
skipping to change at page 13, line 8 skipping to change at page 13, line 8
The Operator-Name attribute SHOULD be sent in Access-Request, and The Operator-Name attribute SHOULD be sent in Access-Request, and
Accounting-Request messages where the Acc-Status-Type is set to Accounting-Request messages where the Acc-Status-Type is set to
Start, Interim, or Stop. Start, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value ... | Type | Length | Text ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (cont.) ... | Text (cont.) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: Type:
To Be Assigned by IANA - Operator-Name To Be Assigned by IANA - Operator-Name
Length: Length:
>= 5 >= 5
Value: Text:
The Value field is at least two octets in length, and the format This 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 this field is text.
All fields are transmitted from left to right: All 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Namespace ID | Operator-Name ... | Namespace ID | Operator-Name ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operator-Name ... | Operator-Name ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 15, line 11 skipping to change at page 15, line 11
a three-letter alphabetic country code as defined in [14], a three-letter alphabetic country code as defined in [14],
followed by one to six uppercase alphanumeric ASCII characters followed by one to six uppercase alphanumeric ASCII characters
containing the ICC itself. containing the ICC itself.
4.2. Location-Information Attribute 4.2. Location-Information Attribute
The Location-Information attribute MAY be sent in Access-Request and The Location-Information attribute MAY be sent in Access-Request and
in Accounting-Request messages. For the Accounting-Request message in Accounting-Request messages. For the Accounting-Request message
the Acc-Status-Type may be set to Start, Interim or Stop. 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, location location information, such as sighting time, time-to-live, location
determination method, etc. Note that this attribute is largely determination method, etc. Note that this attribute is largely
treated as an opaque blob, like the Location-Data attribute to which treated as an opaque blob, like the Location-Data attribute to which
it refers. it refers.
The format is shown below. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value ... | Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (cont.) ... | String (cont.) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: Type:
To Be Assigned by IANA - Location-Information To Be Assigned by IANA - Location-Information
Length: Length:
>= 21 >= 21
Value: String:
The Value field is at least two octets in length, and the format This 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 this 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index | Code | Entity | | Index | Code | Entity |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sighting Time ~ | Sighting Time ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sighting Time | | Sighting Time |
skipping to change at page 18, line 8 skipping to change at page 18, line 8
The Location-Data attribute MAY be sent in Access-Request and in The Location-Data attribute MAY 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 format is shown below. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value ... | Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (cont.) ... | String (cont.) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: Type:
To Be Assigned by IANA - Location-Data To Be Assigned by IANA - Location-Data
Length: Length:
>= 21 >= 21
Value: String:
The Value field is at least two octets in length, and the format Thhis 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 this field is string.
All fields are transmitted from left to right: All 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index | Location ... | Index | Location ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Location ... | Location ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 20, line 24 skipping to change at page 20, line 24
in [19] and encodes them in a non-XML format. Two fields ('sighting in [19] 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 [9], Information attribute to conform to the GEOPRIV requirements [9],
Section 2.7. Section 2.7.
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 | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (cont.) ... | String (cont.) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: Type:
To Be Assigned by IANA - Basic-Policy-Rules To Be Assigned by IANA - Basic-Policy-Rules
Length: Length:
>= 12 >= 12
Value: String:
The Value field is at least 8 octets in length, and the format This field is at least 8 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 this field is string.
All fields are transmitted from left to right: All 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Retention Expires ... | Flags | Retention Expires ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retention Expires ... | Retention Expires ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retention Expires | Note Well ... | Retention Expires | Note Well ...
skipping to change at page 23, line 8 skipping to change at page 23, line 8
found. This URI SHOULD use the HTTPS URI scheme. As a deviation found. This URI SHOULD use the HTTPS URI scheme. As a deviation
from [19] this field only contains a reference and does not carry an from [19] this field only contains a reference and does not carry an
attached extended rule set. This modification is motivated by the attached extended rule set. This modification is motivated by the
size limitations imposed by RADIUS. size 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 | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (cont.) ... | String (cont.) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: Type:
To Be Assigned by IANA - Extended-Policy-Rules To Be Assigned by IANA - Extended-Policy-Rules
Length: Length:
>= 4 >= 4
Value: String:
The Value field is at least two octets in length, and the format This 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 this 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 the policy rules. This field contains a URI that points to the policy rules.
4.6. Challenge-Capable Attribute 4.6. Location-Capable Attribute
The Challenge-Capable attribute allows a NAS (or client function of a The Location-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 the functionality specified in
Access-Challenge messages from the RADIUS server, beyond those this document. The Location-Capable attribute with the L-flag set
specified for support of the authentication methods of textual MUST appear in Access-Request Messages, if the NAS supports the
challenge-response, PPP Challenge Handshake Authentication Protocol functionality described in this document.
(CHAP) or the Extensible Authentication Protocol (EAP). This
mechanism allows the RADIUS server to request additional information
from the RADIUS client prior to making an authentication and
authorization decision. The Challenge-Capable attribute with the
C-flag set MUST appear in Access-Request Messages, 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 | String |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| String (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: Type:
To Be Assigned by IANA - Challenge-Capable Attribute To Be Assigned by IANA - Location-Capable Attribute
Length: Length:
4 4
Value: Value:
The Value field is at least two octets in length, and the format This field is four 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 this field is string.
All fields are transmitted from left to right: All fields are transmitted from left to right:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|o o o o o o o o o o o o o o o| |L|o o o o o o o o o o o o o o o|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The symbol 'o' refers to reserved flags. The symbol 'o' refers to reserved flags available for
assignment via IANA.
This document defines a single bit only: C - Challenge Capable. This document defines a single bit only: L - Location Capable.
4.7. Requested-Info Attribute 4.7. Requested-Info Attribute
The Requested-Info attribute allows the RADIUS server to indicate The Requested-Info attribute allows the RADIUS server to indicate
what location information about which entity it wants to receive. what location information about which entity it wants to receive.
The latter aspect refers to the entities that are indicated in the The latter aspect refers to 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
skipping to change at page 26, line 13 skipping to change at page 26, line 13
computing an authorization decision. computing an authorization decision.
+---------+ +---------+ +---------+ +---------+
| RADIUS | | RADIUS | | RADIUS | | RADIUS |
| Client | | Server | | Client | | Server |
+---------+ +---------+ +---------+ +---------+
| | | |
| | | |
| RADIUS | | RADIUS |
| Access-Request | | Access-Request |
| + Challenge-Capable | | + Location-Capable |
|----------------------------->| |----------------------------->|
| | | |
| RADIUS | | RADIUS |
| Access-Challenge | | Access-Challenge |
| + Requested-Info | | + Requested-Info |
| ('CIVIC_LOCATION', | | ('CIVIC_LOCATION', |
| 'USERS_LOCATION') | | 'USERS_LOCATION') |
| + Basic-Policy-Rules | | + Basic-Policy-Rules |
| + Extended-Policy-Rules | | + Extended-Policy-Rules |
|<-----------------------------| |<-----------------------------|
skipping to change at page 29, line 28 skipping to change at page 29, line 28
the value of one (1). Hence, there is a one-to-one relationship the value of one (1). Hence, there is a one-to-one relationship
between NAS_LOCATION token and the value of one (1) of the Entity between NAS_LOCATION token and the value of one (1) of the Entity
attribute inside the Location-Information attribute. A value of attribute inside the Location-Information attribute. A value of
one indicates that the location information in the Location- one indicates that the location information in the Location-
Information attribute refers to the RADIUS client. Information attribute refers to the RADIUS client.
Numerical Value: Numerical Value:
A numerical value of this attribute is '8'. A numerical value of this attribute is '8'.
Name:
FUTURE_REQUESTS
Description:
The numerical value representing FUTURE_REQUESTS indicates that
the RADIUS client MUST provide future Access-Requests with the
same information as returned in the initial Access-Request
message.
Numerical Value:
A numerical value of this attribute is '16'.
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 is returned (if per-default the location of the user's client device is returned (if
authorization policies allow it). If both the NAS_LOCATION and the authorization policies allow it). If both the NAS_LOCATION and the
USERS_LOCATION bits are set then the returned location information USERS_LOCATION bits are set then the returned location information
has to be put into separate attributes. If neither the has to be put into separate attributes. If neither the
CIVIC_LOCATION nor the GEO_LOCATION bit is set in the Requested-Info CIVIC_LOCATION nor the GEO_LOCATION bit is set in the Requested-Info
attribute then no location information is returned. If both the attribute then no location information is returned. If both the
CIVIC_LOCATION and the GEO_LOCATION bits are set then the location CIVIC_LOCATION and the GEO_LOCATION bits are set then the location
information has to be put into separate attributes. The value of information has to be put into separate attributes. The value of
NAS_LOCATION and USERS_LOCATION refers to the location information NAS_LOCATION and USERS_LOCATION refers to the location information
skipping to change at page 30, line 18 skipping to change at page 31, line 18
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
0+ 0 0 0 0+ TBD Location-Data 0+ 0 0 0 0+ TBD Location-Data
0-1 0-1 0-1 0-1 0-1 TBD Basic-Policy-Rules 0-1 0-1 0-1 0-1 0-1 TBD Basic-Policy-Rules
0-1 0-1 0-1 0-1 0-1 TBD Extended-Policy-Rules 0-1 0-1 0-1 0-1 0-1 TBD Extended-Policy-Rules
0 0-1 0 0-1 0 TBD Requested-Info 0 0-1 0 0-1 0 TBD Requested-Info
0-1 0 0 0 0 TBD Challenge-Capable 0-1 0 0 0 0 TBD Location-Capable
0 0 0-1 0 0 101 Error-Cause [note1]
[note1] The Error-Cause attribute contains the value for the
'Location-Info-Required' error.
The following table defines the meaning of the above table entries.
0 This attribute MUST NOT be present.
0+ Zero or more instances of this attribute MAY be present.
0-1 Zero or one instance of this attribute MAY be present.
1 Exactly one instance of this attribute MUST be present.
1+ One or more of these attributes MUST be present.
Figure 13: Table of Attributes
The Error-Cause attribute is defined in [3].
The Location-Information and the Location-Data attribute MAY appear The Location-Information and the Location-Data attribute MAY appear
more than once. For example, if the server asks for civic and more than once. For example, if the server asks for civic and
geospatial location information two Location-Information attributes geospatial location information two Location-Information attributes
need to be sent. need to be sent.
The next table shows the occurrence of the error-cause attribute. The attributes defined in this document are not used in any messages
other than the onces listed in Figure 13.
Request Accept Reject Challenge Accounting # This document requests IANA to allocate a new value from the Error-
Request Cause registry with the semantic of 'Location-Info-Required'.
0 0 0-1 0 0 101 Error-Cause
6. Diameter RADIUS Interoperability 6. 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:
+---------------------+ +---------------------+
skipping to change at page 31, line 25 skipping to change at page 32, line 25
|----+-----+----+-----|----+ |----+-----+----+-----|----+
| | |SHLD| MUST| | | | |SHLD| MUST| |
Attribute Name Value Type |MUST| MAY | NOT| NOT|Encr| Attribute Name Value Type |MUST| MAY | NOT| NOT|Encr|
----------------------------------|----+-----+----+-----|----| ----------------------------------|----+-----+----+-----|----|
Operator-Name OctetString| | P,M | | V | Y | Operator-Name OctetString| | P,M | | V | Y |
Location-Information OctetString| M | P | | V | Y | Location-Information OctetString| M | P | | V | Y |
Location-Data OctetString| M | P | | V | Y | Location-Data 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| | P,M | | V | Y | Location-Capable OctetString| | P,M | | 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 [6] and Section 9 of alignment, and padding. See also Section 4.1 of [6] and Section 9 of
[20]. [20].
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
skipping to change at page 33, line 34 skipping to change at page 34, line 34
infrastructure. RADIUS and Diameter have even become a de-facto infrastructure. RADIUS and Diameter have even become a de-facto
protocol for key distribution for network access authentication protocol for key distribution for network access authentication
applications. Hence, in the past there were some concerns about the applications. Hence, in the past there were some concerns about the
trust placed into the infrastructure particularly from the security trust placed into the infrastructure particularly from the security
area when it comes to keying. The EAP keying infrastructure is area when it comes to keying. The EAP keying infrastructure is
described in [24]. described in [24].
7.2. Privacy Considerations 7.2. Privacy Considerations
This section discusses privacy implications for the distribution of This section discusses privacy implications for the distribution of
location information within RADIUS. location information within RADIUS. Note also that it is possible
for the RADIUS server to obtain some amount of location information
In many cases the location information of the network also reveals from the NAS identifier. This document, however, describes
the current location of the user with a certain degree of precision procedures to convey more accurate location information about the end
depending on the mechanism used, the positioning system, update host and/or the network. In a number of deployment environments
frequency, where the location was generated, size of the network and location information about the network also reveals the current
other mechanisms (such as movement traces or interpolation). location of the user with a certain degree of precision depending on
the location determination mechanism used, update frequency, the size
of the network and other factors, such as movement traces.
Three types of use cases have to be differentiated: Three types of use cases have to be differentiated:
o RADIUS server does not want to receive location information from o RADIUS server does not want to receive location information from
the RADIUS client. The RADIUS client does not send location the RADIUS client.
information to the RADIUS server.
o In case there is an out-of-band agreement between the entity o In case there is an out-of-band agreement between the entity
responsible for the NAS and the entity operating the RADIUS server responsible for the NAS and the entity operating the RADIUS server
then location information may be sent without an explicit request then location information may be sent without an explicit request
from the RADIUS server. from the RADIUS server.
o The RADIUS server dynamically requests location information from o The RADIUS server dynamically requests location information from
the NAS. the NAS.
7.2.1. RADIUS Client 7.2.1. RADIUS Client
The RADIUS client MUST behave according to the following guidelines: The RADIUS client MUST behave according to the following guidelines:
o If neither an out-of-band agreement exists nor location o If neither an out-of-band agreement exists nor location
information is requested by the RADIUS server then location information is requested by the RADIUS server then location
information is not disclosed by the RADIUS client. information is not disclosed by the RADIUS client.
o If the RADIUS server provides the Basic-Policy-Rules attribute o The RADIUS client MUST pass location information to other entities
either as part of the Access-Accept, the Access-Reject or the (e.g., when information is written to a local database or to the
Access-Challenge message then the RADIUS client MUST follow the log files) only together with the policy rules. The entity
guidance given with these rules. receiving the location information (together with the policies)
MUST follow the guidance given with these rules.
o If the RADIUS server provides the Extended-Policy-Rules attributes
either as part of the Access-Accept, the Access-Reject or the
Access-Challenge message then the RADIUS client MUST fetch the
full ruleset at the indicated URL and MUST follow the guidance
given by these rules.
o If the RADIUS client in the visited network learns the basic rule
set or a reference to the extended rule set by means outside the
RADIUS protocol (e.g., provided by the end host) then it MUST
include the Basic-Policy-Rules and the Extended-Policy-Rules
attribute in the Access-Request message towards the home RADIUS
server. Furthermore, the visited network MUST evaluate these
rules prior to the transmission of location information either to
the home network or a third party. The visited network MUST
follow the guidance given with these rules.
o If the RADIUS client receives the Basic-Policy-Rules attribute o A RADIUS client MUST include any rules available towards the
with Access-Accept or the Access-Challenge message then the Basic- RADIUS server.
Policy-Rules MUST be attached in subsequent RADIUS messages that
contains the Location-Information attribute (such as in interim
accounting messages).
o If the RADIUS client in the visited network receives the Extended- o If the RADIUS client receives the Basic-Policy-Rules and the
Policy-Rules attribute with Access-Accept or the Access-Challenge Extended-Policy-Rules attribute with an Access-Accept or an
message then the Basic-Policy-Rules attribute MUST be attached in Access-Challenge message then these attributes MUST be attached in
subsequent RADIUS messages that contains the Location-Information subsequent RADIUS messages that contain the Location-Information
attribute (such as in interim accounting messages). attribute (such as accounting messages).
7.2.2. RADIUS Server 7.2.2. RADIUS Server
The RADIUS server is a natural place for storing authorization The RADIUS server is a natural place for storing authorization
policies since the user has some sort of trust relationship with the policies since the user typically has some sort of trust relationship
entity operating the RADIUS server. Once the infrastructure is with the entity operating the RADIUS server. Once the infrastructure
deployed and useful applications are available there might be a is deployed and location aware applications are available then there
strong desire to use location information for other purposes as well might be a strong desire to use location information for other
(such as location aware applications). Authorization policy rules purposes as well. The Common Policy framework [16] that was extended
described in [17] and in [16] are tailored for this purpose. These for geolocation privacy [17] are tailored for this purpose. These
policies might be useful for limiting further distribution of the policies might be useful for limiting further distribution of the
user's location to other location based services. The home RADIUS user's location to other location based services. The home RADIUS
server (or a similar entity) thereby acts as a location server for server (or a similar entity) thereby acts as a location server for
access to location services. access to location 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 The RADIUS server MUST pass location information to other entities
user's location information to third party entities. only together with the policy rules. The entity receiving the
location information (together with the policies) MUST follow the
o If a user provides basic authorization policies then the RADIUS guidance given with these rules. This includes the distribution
server MUST return these rules to the RADIUS client in the Access- of location information via local storage and for further
Accept, the Access-Reject or the Access-Challenge message. distribution. The entity receiving the location information
(together with the policies) MUST follow the guidance given with
o If a user provides extended authorization policies then the RADIUS these rules. The RADIUS server has to ensure that the user's
server MUST return these rules to the RADIUS client using a preferences are taken care of within the given boundaries (such as
reference to this rule set. The Extended-Policy-Rules attribute legal regulations or operational considerations). For example, a
MUST include the reference and they MUST be sent to the RADIUS user might not want the home network to store information about
client in the Access-Accept, the Access-Reject or the Access- its location information beyond a indicated time frame. However,
Challenge message. a user might on the other hand want to ensure that disputes
concerning the billed amount can be resolved. Location
information might help to resolve the dispute. The user might,
for example, be able to show that he has never been at the
indicated place.
o The RADIUS server MUST follow the user provided rule set for both o The RADIUS server MUST attach available rules to the Access-
local storage and for further distribution. With regard to the Accept, the Access-Reject or the Access-Challenge message when the
usage of these rules the entity operating the RADIUS server MUST RADIUS client is supposed to provide location information.
ensure that the user's preferences are taken care of within the
given boundaries (such as legal regulations or operational
considerations). For example, a user might not want the home
network to store information about its location information beyond
a indicated time frame. However, a user might on the other hand
want to ensure that disputes concerning the billed amount can be
resolved. Location information might help to resolve the dispute.
The user might, for example, be able to show that he has never
been at the indicated place.
7.2.3. RADIUS Broker 7.2.3. RADIUS Proxy
When the RADIUS messages traverses one or more RADIUS broker then the A RADIUS proxy, behaving as a combined RADIUS client and RADIUS
RADIUS broker has to follow the privacy policy before utilizing server, MUST follow the rules described in Section 7.2.1 and
location information for a purpose other than then forwarding RADIUS Section 7.2.2.
messages between the RADIUS client and the RADIUS server, and vice
versa.
7.3. Identity Information and Location Information 7.3. Identity Information and Location Information
For the envisioned usage scenarios, the identity of the user and his For the envisioned usage scenarios, the identity of the user and his
device is tightly coupled to the transfer of location information. device is tightly coupled to the transfer of location information.
If the identity can be determined by the visited network or RADIUS If the identity can be determined by the visited network or RADIUS
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.
skipping to change at page 36, line 47 skipping to change at page 37, line 18
at least correlate his session with other sessions, such as the at least correlate his session with other sessions, such as the
use of static data in a Class attribute [2] or in some accounting use of static data in a Class attribute [2] or in some accounting
attribute usage scenarios [31]. attribute usage scenarios [31].
o Mobility protocols may reveal some long-term identifier, such as a o Mobility protocols may reveal some long-term identifier, such as a
home address. home address.
o Application layer protocols may reveal other permanent o Application layer protocols may reveal other permanent
identifiers. identifiers.
Note that to prevent the correlation of identities with location To prevent the correlation of identities with location information it
information it is necessary to prevent leakage of identity is necessary to prevent leakage of identity information from all
information from all sources, not just one. sources, not just one.
Unfortunately, most users are not educated about the importance of Unfortunately, most users are not educated about the importance of
identity confidentiality and some protocols lack support for identity identity confidentiality and some protocols lack support for identity
privacy mechanisms. This problem is made worse by the fact that privacy mechanisms. This problem is made worse by the fact that
users may be unable to choose particular protocols, as the choice is users may be unable to choose particular protocols, as the choice is
often dictated by the type of network operator they use, by the type often dictated by the type of network operator they use, by the type
of network they wish to access, the kind of equipment they have, or of network they wish to access, the kind of equipment they have, or
the type of authentication method they are using. the type of authentication method they are using.
A scenario where the user is attached to the home network is, from a A scenario where the user is attached to the home network is, from a
skipping to change at page 38, line 23 skipping to change at page 38, line 23
created by this document IANA is requested to place them at created by this document IANA is requested to place them at
http://www.iana.org/assignments/radius-types. http://www.iana.org/assignments/radius-types.
This document defines the following attributes: This document defines the following attributes:
Operator-Name Operator-Name
Location-Information Location-Information
Location-Data Location-Data
Basic-Policy-Rules Basic-Policy-Rules
Extended-Policy-Rules Extended-Policy-Rules
Challenge-Capable Location-Capable
Requested-Info Requested-Info
Please refer to Section 5 for the registered list of numbers. Please refer to Section 5 for the registered list of numbers.
This document also instructs IANA to assign a new value for the This document also instructs IANA to assign a new value for the
Error-Cause attribute [3], of "Location-Info-Required" TBA. Error-Cause attribute [3], of "Location-Info-Required" TBA.
Additionally, IANA is requested to create the following new Additionally, IANA is requested to create the following new
registries listed in the subsections below. registries listed in the subsections below.
skipping to change at page 39, line 9 skipping to change at page 39, line 9
IANA is requested to add the following values to the operator IANA is requested to add the following values to the operator
namespace identifier registry using a numerical identifier (allocated namespace identifier registry using a numerical identifier (allocated
in sequence), a token for the operator namespace and a contact person in sequence), a token for the operator namespace and a contact person
for the registry. for the registry.
+----------+--------------------+------------------------------------+ +----------+--------------------+------------------------------------+
|Identifier| Operator Namespace | Contact Person | |Identifier| Operator Namespace | Contact Person |
| | Token | | | | Token | |
+----------+--------------------+------------------------------------+ +----------+--------------------+------------------------------------+
| 0 | TADIG | TD.13 Coordinator | | 48 | TADIG | TD.13 Coordinator |
| | | (td13@gsm.org) | | | | (td13@gsm.org) |
| 1 | REALM | IETF O&M Area Directors | | 49 | REALM | IETF O&M Area Directors |
| | | (ops-chairs@ietf.org) | | | | (ops-chairs@ietf.org) |
| 2 | E212 | ITU Director | | 50 | E212 | ITU Director |
| | | (tsbdir@itu.int) | | | | (tsbdir@itu.int) |
| 3 | ICC | ITU Director | | 51 | ICC | ITU Director |
| | | (tsbdir@itu.int) | | | | (tsbdir@itu.int) |
+----------+--------------------+------------------------------------+ +----------+--------------------+------------------------------------+
Note that the above identifier values represent the ASCII value '0'
(decimal 48), '1' (decimal 49), '2' (decimal 50) and '3' (decimal
51). This encoding was chosen to simplify parsing.
Requests to IANA for a new value for a Namespace ID will be approved Requests to IANA for a new value for a Namespace ID will be approved
by Expert Review. The Designated Expert Reviewer team for these by Expert Review. The Designated Expert Reviewer team for these
requests is the current Operations Area Director and the RADEXT requests is the current Operations Area Director and the RADEXT
working group chairs or the working group chairs of a designated working group chairs or the working group chairs of a designated
successor working group. successor working group.
The Expert Reviewer should ensure that a new entry is indeed required The Expert Reviewer should ensure that a new entry is indeed required
or could fit within an existing database, e.g., whether there is a or could fit within an existing database, e.g., whether there is a
real requirement to provide a token for an Namespace ID because one real requirement to provide a token for an Namespace ID because one
is already up and running, or whether the REALM identifier plus the is already up and running, or whether the REALM identifier plus the
skipping to change at page 40, line 12 skipping to change at page 40, line 16
approval only. A designated expert will be appointed by the O&M Area approval only. A designated expert will be appointed by the O&M Area
Directors. No mechanism to mark entries as "deprecated" is Directors. No mechanism to mark entries as "deprecated" is
envisioned. Based on expert approval it is possible to delete envisioned. Based on expert approval it is possible to delete
entries from the registry. entries from the registry.
Each registration must include the value and the corresponding Each registration must include the value and the corresponding
semantic of the defined location profile. semantic of the defined location profile.
8.3. New Registry: Challenge Capable Attribute 8.3. New Registry: Challenge Capable Attribute
Section 4.6 defines the Challenge-Capable attribute that contains a Section 4.6 defines the Location-Capable attribute that contains a
bit map. 16 bits are available whereby a single bit, bit (0), bit map. 16 bits are available whereby a single bit, bit (0),
indicating 'Challenge Capable' is defined by this document. Bits indicating 'Location Capable' is defined by this document. Bits 1-15
1-15 are reserved for future use. are reserved for future use.
Following the policies outline in [7] the available bits with a Following the policies outline in [7] the available bits with a
description of their semantic will be assigned after Expert Review description of their semantic will be assigned after Expert Review
initiated by the O&M Area Directors in consultation with the RADEXT initiated by the O&M Area Directors in consultation with the RADEXT
working group chairs or the working group chairs of a designated working group chairs or the working group chairs of a designated
successor working group. Updates can be provided based on expert successor working group. Updates can be provided based on expert
approval only. A designated expert will be appointed by the O&M Area approval only. A designated expert will be appointed by the O&M Area
Directors. No mechanism to mark entries as "deprecated" is Directors. No mechanism to mark entries as "deprecated" is
envisioned. Based on expert approval it is possible to delete envisioned. Based on expert approval it is possible to delete
entries from the registry. entries from the registry.
skipping to change at page 41, line 41 skipping to change at page 41, line 44
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 |
| 16 | FUTURE_REQUESTS |
+----------+----------------------+ +----------+----------------------+
The semantic of these values is defined in Section 4.7. The semantic of these values is defined in Section 4.7.
Following the policies outline in [7] new Capability Tokens with a Following the policies outline in [7] new Capability Tokens with a
description of their semantic for usage with the Requested-Info description of their semantic for usage with the Requested-Info
attribute will be assigned after Expert Review initiated by the O&M attribute will be assigned after Expert Review initiated by the O&M
Area Directors in consultation with the RADEXT working group chairs Area Directors in consultation with the RADEXT working group chairs
or the working group chairs of a designated successor working group. or the working group chairs of a designated successor working group.
Updates can be provided based on expert approval only. A designated Updates can be provided based on expert approval only. A designated
skipping to change at page 48, line 25 skipping to change at page 48, line 25
+----------+ | +----------+ +----------+ +----------+ | +----------+ +----------+
|Location | publication | Location | notification |Location | |Location | publication | Location | notification |Location |
|Generator |<------------->| Server |<------------->|Recipient | |Generator |<------------->| Server |<------------->|Recipient |
| | interface | | interface | | | | interface | | interface | |
+----------+ | +----------+ +----------+ +----------+ | +----------+ +----------+
| |
Local RADIUS RADIUS Home RADIUS SIP/HTTP/API/etc. Local RADIUS RADIUS Home RADIUS SIP/HTTP/API/etc.
Server | Server Server | Server
| |
Figure 19: Location Server at the Home Network Figure 18: Location Server at the Home Network
The term 'Rule Holder' in Figure 19 denotes the entity that creates The term 'Rule Holder' in Figure 18 denotes the entity that creates
the authorization rule set. the authorization rule set.
A.2. Distribution of Location Information at the Visited Network A.2. Distribution of Location Information at the Visited Network
This section describes a scenario where location information made This section describes a scenario where location information made
available to Location Recipients by some entity in the visited available to Location Recipients by some entity in the visited
network. 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:
skipping to change at page 49, line 27 skipping to change at page 49, line 27
| | | | | |
| | rule|interface | | rule|interface
v | V v | V
+----------+ | +----------+ +----------+ | +----------+
|Location | Rule Transport| Home | |Location | Rule Transport| Home |
|Generator |<------------->| RADIUS | |Generator |<------------->| RADIUS |
|& Server | RADIUS | Server | |& Server | RADIUS | Server |
+----------+ | +----------+ +----------+ | +----------+
| |
Figure 20: Location Server at the Visited Network Figure 19: Location Server at the Visited Network
A.3. Requirements matching A.3. Requirements matching
Section 7.1 of [9] details the requirements of a "Location Object". Section 7.1 of [9] details the requirements of a "Location Object".
We discuss these requirements in the subsequent list. We discuss these requirements in the subsequent list.
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 as defined in this document. understood by the RADIUS server as defined in this document.
skipping to change at page 52, line 34 skipping to change at page 52, line 34
small target devices, the design should allow a single message/ small target devices, the design should allow a single message/
packet transmission of location as a complete transaction. The packet transmission of location as a complete transaction. The
encoding of the Location Object is specifically tailored towards encoding of the Location Object is specifically tailored towards
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 [9] details the requirements of a "Rule based Location Section 7.3 of [9] details the requirements of a "Rule based Location
Data Transfer". These requirements are listed below: Data Transfer". These requirements are listed below:
Req. 7. (LS Rules): With the scenario shown in Figure 19 the Req. 7. (LS Rules): With the scenario shown in Figure 18 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 that are stored at the home network. With regard to Privacy Rules that are stored at the home network. With regard to
the scenario shown in Figure 20 the Rule Maker-defined Privacy the scenario shown in Figure 19 the Rule Maker-defined Privacy
Rules are sent from the home network to the visited network (see Rules are sent from the home network to the visited network (see
Section 4.4, Section 4.5 and Section 7.2 for more details). Section 4.4, Section 4.5 and Section 7.2 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 19 the visited network is already in the scenario shown in Figure 18 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
between the location and the user identity might, however, still between the location and the user identity might, however, still
not be possible for the visited network (as explained in not be possible for the visited network (as explained in
Section 7.2). The visited network MUST evaluate ruleset provided Section 7.2). The visited network MUST evaluate ruleset provided
by the home RADIUS server as soon as possible. by the home RADIUS server as soon as possible.
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.
 End of changes. 75 change blocks. 
169 lines changed or deleted 178 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/