diff options
Diffstat (limited to 'doc/rfc/rfc5580.txt')
| -rw-r--r-- | doc/rfc/rfc5580.txt | 2971 |
1 files changed, 2971 insertions, 0 deletions
diff --git a/doc/rfc/rfc5580.txt b/doc/rfc/rfc5580.txt new file mode 100644 index 0000000..cfd323f --- /dev/null +++ b/doc/rfc/rfc5580.txt @@ -0,0 +1,2971 @@ + + + + + + +Network Working Group H. Tschofenig, Ed. +Request for Comments: 5580 Nokia Siemens Networks +Category: Standards Track F. Adrangi + Intel + M. Jones + A. Lior + Bridgewater + B. Aboba + Microsoft Corporation + August 2009 + + + Carrying Location Objects in RADIUS and Diameter + +Abstract + + This document describes procedures for conveying access-network + ownership and location information based on civic and geospatial + location formats in Remote Authentication Dial-In User Service + (RADIUS) and Diameter. + + The distribution of location information is a privacy-sensitive task. + Dealing with mechanisms to preserve the user's privacy is important + and is addressed in this document. + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (c) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents in effect on the date of + publication of this document (http://trustee.ietf.org/license-info). + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. + + + + + + + + +Tschofenig, et al. Standards Track [Page 1] + +RFC 5580 Carrying LOs in RADIUS and Diameter August 2009 + + +Table of Contents + + 1. Introduction ....................................................3 + 2. Terminology .....................................................3 + 3. Delivery Methods for Location Information .......................3 + 3.1. Location Delivery Based on Out-of-Band Agreements ..........4 + 3.2. Location Delivery Based on Initial Request .................5 + 3.3. Location Delivery Based on Mid-Session Request .............6 + 3.4. Location Delivery in Accounting Messages ..................10 + 4. Attributes .....................................................11 + 4.1. Operator-Name Attribute ...................................12 + 4.2. Location-Information Attribute ............................14 + 4.3. Location-Data Attribute ...................................16 + 4.3.1. Civic Location Profile .............................17 + 4.3.2. Geospatial Location Profile ........................17 + 4.4. Basic-Location-Policy-Rules Attribute .....................18 + 4.5. Extended-Location-Policy-Rules Attribute ..................20 + 4.6. Location-Capable Attribute ................................21 + 4.7. Requested-Location-Info Attribute .........................23 + 5. Table of Attributes ............................................28 + 6. Diameter RADIUS Interoperability ...............................30 + 7. Security Considerations ........................................31 + 7.1. Communication Security ....................................31 + 7.2. Privacy Considerations ....................................32 + 7.2.1. RADIUS Client ......................................33 + 7.2.2. RADIUS Server ......................................34 + 7.2.3. RADIUS Proxy .......................................34 + 7.3. Identity Information and Location Information .............34 + 8. IANA Considerations ............................................36 + 8.1. New Registry: Operator Namespace Identifier ...............36 + 8.2. New Registry: Location Profiles ...........................37 + 8.3. New Registry: Location-Capable Attribute ..................38 + 8.4. New Registry: Entity Types ................................39 + 8.5. New Registry: Privacy Flags ...............................39 + 8.6. New Registry: Requested-Location-Info Attribute ...........39 + 9. Acknowledgments ................................................40 + 10. References ....................................................42 + 10.1. Normative References .....................................42 + 10.2. Informative References ...................................42 + Appendix A. Matching with GEOPRIV Requirements ...................45 + A.1. Distribution of Location Information at the User's + Home Network ..............................................45 + A.2. Distribution of Location Information at the Visited + Network ...................................................46 + A.3. Requirements Matching .....................................47 + + + + + + +Tschofenig, et al. Standards Track [Page 2] + +RFC 5580 Carrying LOs in RADIUS and Diameter August 2009 + + +1. Introduction + + This document defines attributes within RADIUS and Diameter that can + be used to convey location-related information within authentication + and accounting exchanges. + + Location information may be useful in a number of scenarios. + Wireless networks (including wireless LAN) are being deployed in + public places such as airports, hotels, shopping malls, and coffee + shops by a diverse set of operators such as cellular network + operators, Wireless Internet Service Providers (WISPs), and fixed + broadband operators. In these situations, the home network may need + to know the location of the user in order to enable location-aware + billing, location-aware authorization, or other location-aware + services. Location information can also prove useful in other + situations (such as wired networks) where operator-network ownership + and location information may be needed by the home network. + + In order to preserve user privacy, location information needs to be + protected against unauthorized access and distribution. Requirements + for access to location information are defined in [RFC3693]. The + model includes a Location Generator (LG) that creates location + information, a Location Server (LS) that authorizes access to + location information, a Location Recipient (LR) that requests and + receives information, and a Rule Maker (RM) that provides + authorization policies to the LS, which enforces access-control + policies on requests to location information. In Appendix A, the + requirements for a GEOPRIV using protocol [RFC3693] are compared to + the functionality provided by this document. + +2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + RADIUS-specific terminology is borrowed from [RFC2865] and [RFC2866]. + + Terminology related to privacy issues, location information, and + authorization policy rules is taken from [RFC3693]. + +3. Delivery Methods for Location Information + + The following exchanges show how location information is conveyed in + RADIUS. In describing the usage scenarios, we assume that privacy + policies allow location to be conveyed in RADIUS; however, as noted + in Section 6, similar exchanges can also take place within Diameter. + Privacy issues are discussed in Section 7.2. + + + +Tschofenig, et al. Standards Track [Page 3] + +RFC 5580 Carrying LOs in RADIUS and Diameter August 2009 + + +3.1. Location Delivery Based on Out-of-Band Agreements + + Figure 1 shows an example message flow for delivering location + information during the network-access authentication and + authorization procedure. Upon a network-authentication request from + an access-network client, the Network Access Server (NAS) submits a + RADIUS Access-Request message that contains Location-Information + Attributes among other required attributes. In this scenario, + location information is attached to the Access-Request message + without an explicit request from the RADIUS server. Note that such + an approach with a prior agreement between the RADIUS client and the + RADIUS server is only applicable in certain environments, such as in + situations where the RADIUS client and server are within the same + administrative domain. The Basic-Location-Policy-Rules Attribute is + populated based on the defaults described in Section 4.4, unless it + has been explicitly configured otherwise. + + +---------+ +---------+ +---------+ + | | | Network | | RADIUS | + | User | | Access | | Server | + | | | Server | | | + +---------+ +---------+ +---------+ + | | | + | Authentication phase | | + | begin | | + |---------------------->| | + | | | + | | Access-Request | + | | + Location-Information | + | | + Location-Data | + | | + Basic-Location-Policy-Rules| + | | + Operator-Name | + | |----------------------------->| + | | | + | | Access-Accept | + | |<-----------------------------| + | Authentication | | + | Success | | + |<----------------------| | + | | | + + Figure 1: Location Delivery Based on Out-of-Band Agreements + + + + + + + + + +Tschofenig, et al. Standards Track [Page 4] + +RFC 5580 Carrying LOs in RADIUS and Diameter August 2009 + + +3.2. Location Delivery Based on Initial Request + + If the RADIUS client provides a Location-Capable Attribute in the + Access-Request, then the RADIUS server MAY request location + information from the RADIUS client if it requires that information + for authorization and if location information was not provided in the + Access-Request. This exchange is shown in Figure 2. The inclusion + of the Location-Capable Attribute in an Access-Request message + indicates that the NAS is capable of providing location data in + response to an Access-Challenge. The subsequent Access-Challenge + message sent from the RADIUS server to the NAS provides a hint + regarding the type of desired Location-Information Attributes. The + NAS treats the Basic-Location-Policy-Rules and Extended-Location- + Policy-Rules Attributes as opaque data (e.g., it echoes these rules + provided by the server within the Access-Challenge back in the + Access-Request). In the shown message flow, the location attributes + are then provided in the subsequent Access-Request message. When + evaluating this Access-Request message, the authorization procedure + at the RADIUS server might be based on a number of criteria, + including the newly defined attributes listed in Section 4. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Tschofenig, et al. Standards Track [Page 5] + +RFC 5580 Carrying LOs in RADIUS and Diameter August 2009 + + + +---------+ +---------+ +---------+ + | | | Network | | RADIUS | + | User | | Access | | Server | + | | | Server | | | + +---------+ +---------+ +---------+ + | | | + | Authentication phase | | + | begin | | + |---------------------->| | + | | | + | | Access-Request | + | | + Location-Capable | + | |--------------------------------->| + | | | + | | Access-Challenge | + | | + Basic-Location-Policy-Rules | + | | + Extended-Location-Policy-Rules| + | | + Requested-Location-Info | + | |<---------------------------------| + | | | + | | Access-Request | + | | + Location-Information | + | | + Location-Data | + | | + Basic-Location-Policy-Rules | + | | + Extended-Location-Policy-Rules| + | |--------------------------------->| + | | | + : : : + : Multiple Protocol Exchanges to perform : + : Authentication, Key Exchange, and Authorization : + : ...continued... : + : : : + | | | + | | Access-Accept | + | |<---------------------------------| + | Authentication | | + | Success | | + |<----------------------| | + | | | + + Figure 2: Location Delivery Based on Initial Request + +3.3. Location Delivery Based on Mid-Session Request + + The on-demand, mid-session location-delivery method utilizes the + Change-of-Authorization Request (CoA-Request) message and the CoA-NAK + (CoA-Negative Acknowledgement), defined in [RFC5176]. At any time + + + + +Tschofenig, et al. Standards Track [Page 6] + +RFC 5580 Carrying LOs in RADIUS and Diameter August 2009 + + + during the session, the Dynamic Authorization Client MAY send a CoA- + Request containing session-identification attributes to the NAS + (i.e., Dynamic Authorization Server). + + In order to enable the on-demand, mid-session location-delivery + method, the RADIUS server MUST return an instance of the Requested- + Location-Info Attribute with the 'FUTURE_REQUESTS' flag set and + instances of the Basic-Location-Policy-Rules and Extended-Location- + Policy-Rules Attributes in the Access-Accept message for the session. + Upon receipt of a CoA-Request message containing a Service-Type + Attribute with value "Authorize Only" for the same session, the NAS + MUST include location information and echo the previously received + Basic-Location-Policy-Rules and Extended-Location-Policy-Rules + Attributes in the subsequent Access-Request message. + + Upon receiving the Access-Request message containing the Service-Type + Attribute with a value of Authorize-Only from the NAS, the RADIUS + server responds with either an Access-Accept or an Access-Reject + message. + + The use of dynamic authorization [RFC5176] is necessary when location + information is needed on-demand and cannot be obtained from + accounting information in a timely fashion. + + Figure 3 shows the above-described approach graphically. + + +---------------+ +---------------+ +------+ + | Dynamic | | Dynamic | |RADIUS| + | Authorization | | Authorization | |Server| + | Server/NAS | | Client | | | + +---------------+ +---------------+ +------+ + | | | + | Access-Request | | + | + Location-Capable | | + |----------------------------------------------------------->| + | | | + | Access-Challenge | | + | + Basic-Location-Policy-Rules | | + | + Extended-Location-Policy-Rules | | + | + Requested-Location-Info | | + |<-----------------------------------------------------------| + | | | + | Access-Request | | + | + Location-Information | | + | + Location-Data | | + | + Basic-Location-Policy-Rules | | + | + Extended-Location-Policy-Rules | | + |----------------------------------------------------------->| + + + +Tschofenig, et al. Standards Track [Page 7] + +RFC 5580 Carrying LOs in RADIUS and Diameter August 2009 + + + | | | + | | | + : | : + : Multiple Protocol Exchanges to perform : + : Authentication, Key Exchange, and Authorization : + : ...continued... | : + : | : + | | | + | | | + | Access-Accept | | + | + Requested-Location-Info | | + (FUTURE_REQUESTS,...) | | + | + Basic-Location-Policy-Rules | | + | + Extended-Location-Policy-Rules | | + |<-----------------------------------------------------------| + | | | + : : : + : <<Some time later>> : : + : : : + | | | + | CoA + Service-Type "Authorize Only" + State | | + |<--------------------------------------------| | + | | | + | CoA NAK + Service-Type "Authorize Only" | | + | + State | | + | + Error-Cause "Request Initiated" | | + |-------------------------------------------->| | + | | | + | Access-Request | | + | + Service-Type "Authorize Only" | | + | + State | | + | + Location-Information | | + | + Location-Data | | + | + Basic-Location-Policy-Rules | | + | + Extended-Location-Policy-Rules | | + |----------------------------------------------------------->| + | Access-Accept | | + |<-----------------------------------------------------------| + | | | + + Figure 3: Location Delivery Based on CoA with + Service-Type 'Authorize Only' + + When the Dynamic Authorization Client wants to change the values of + the requested location information, or set the values of the + requested location information for the first time, it may do so + without triggering a reauthorization. Assuming that the NAS had + previously sent an Access-Request containing a Location-Capable + + + +Tschofenig, et al. Standards Track [Page 8] + +RFC 5580 Carrying LOs in RADIUS and Diameter August 2009 + + + Attribute, the Dynamic Authorization Client (DAC) can send a CoA- + Request to the NAS without a Service-Type Attribute, but include the + NAS identifiers and session identifiers as per [RFC5176] and the + Requested-Location-Info, Basic-Location-Policy-Rules, and Extended- + Location-Policy-Rules Attributes. The Requested-Location-Info, + Basic-Location-Policy-Rules, and Extended-Location-Policy-Rules + Attributes MUST NOT be used for session identification. + + Figure 4 shows this approach graphically. + + +---------------+ +---------------+ +------+ + | Dynamic | | Dynamic | |RADIUS| + | Authorization | | Authorization | |Server| + | Server/NAS | | Client | | | + +---------------+ +---------------+ +------+ + | | | + | | | + | Access-Request | | + | + Location-Capable | | + |----------------------------------------------------------->| + | | | + | Access-Challenge | | + | + Basic-Location-Policy-Rules | | + | + Extended-Location-Policy-Rules | | + | + Requested-Location-Info | | + |<-----------------------------------------------------------| + | | | + | Access-Request | | + | + Location-Information | | + | + Location-Data | | + | + Basic-Location-Policy-Rules | | + | + Extended-Location-Policy-Rules | | + |----------------------------------------------------------->| + | | | + | | | + : | : + : Multiple Protocol Exchanges to perform : + : Authentication, Key Exchange, and Authorization : + : ...continued... | : + : | : + | | | + | | | + | Access-Accept | | + | + Requested-Location-Info | | + | + Basic-Location-Policy-Rules | | + | + Extended-Location-Policy-Rules | | + |<-----------------------------------------------------------| + + + + +Tschofenig, et al. Standards Track [Page 9] + +RFC 5580 Carrying LOs in RADIUS and Diameter August 2009 + + + | | | + : : : + : <<Some time later>> : : + : : : + | | | + | CoA | | + | + Requested-Location-Info | | + | + Basic-Location-Policy-Rules | | + | + Extended-Location-Policy-Rules | | + |<--------------------------------------------| | + | | | + | CoA ACK | | + |-------------------------------------------->| | + | | | + : : : + : <<Further exchanges later>> : : + : : : + + Figure 4: Location Delivery Based on CoA + +3.4. Location Delivery in Accounting Messages + + Location information may also be reported in accounting messages. + Accounting messages are generated when the session starts, when the + session stops, and periodically during the lifetime of the session. + Accounting messages may also be generated when the user roams during + handoff. + + Accounting information may be needed by the billing system to + calculate the user's bill. For example, there may be different + tariffs or tax rates applied based on the location. + + If the RADIUS server needs to obtain location information in + accounting messages, then it needs to include a Requested-Location- + Info Attribute with the Access-Accept message. The Basic-Location- + Policy-Rules and the Extended-Location-Policy-Rules Attributes are to + be echoed in the Accounting-Request if indicated in the Access- + Accept. + + Figure 5 shows the message exchange. + + + + + + + + + + + +Tschofenig, et al. Standards Track [Page 10] + +RFC 5580 Carrying LOs in RADIUS and Diameter August 2009 + + + +---------+ +---------+ +---------+ + | | | Network | | RADIUS | + | User | | Access | | Server | + | | | Server | | | + +---------+ +---------+ +---------+ + | | | + : : : + : Initial Protocol Interaction : + : (details omitted) : + : : : + | | | + | | Access-Accept | + | | + Requested-Location-Info | + | | + Basic-Location-Policy-Rules | + | | + Extended-Location-Policy-Rules| + | |<---------------------------------| + | Authentication | | + | Success | | + |<----------------------| | + | | | + | | Accounting-Request | + | | + Location-Information | + | | + Location-Data | + | | + Basic-Location-Policy-Rules | + | | + Extended-Location-Policy-Rules| + | |--------------------------------->| + | | | + | | Accounting-Response | + | |<---------------------------------| + | | | + + Figure 5: Location Delivery in Accounting Messages + +4. Attributes + + It is important to note that the location-specific parts of the + attributes defined below are not meant to be processed by the RADIUS + server. Instead, a location-server-specific component used in + combination with the RADIUS server is responsible for receiving, + processing, and further distributing location information (in + combination with proper access control and privacy protection). As + such, from a RADIUS server point of view, location information is + treated as opaque data. + + + + + + + + +Tschofenig, et al. Standards Track [Page 11] + +RFC 5580 Carrying LOs in RADIUS and Diameter August 2009 + + +4.1. Operator-Name Attribute + + This attribute carries the operator namespace identifier and the + operator name. The operator name is combined with the namespace + identifier to uniquely identify the owner of an access network. The + value of the Operator-Name is a non-NULL terminated text whose length + MUST NOT exceed 253 bytes. + + The Operator-Name Attribute SHOULD be sent in Access-Request and + Accounting-Request messages where the Acc-Status-Type is set to + Start, Interim, or Stop. + + A summary of the Operator-Name Attribute is shown below. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Text ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Text (cont.) ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: + + 126 - Operator-Name + + Length: + + >= 4 + + Text: + + The format is shown below. The data type of this field is a text. + All fields are transmitted from left to right: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Namespace ID | Operator-Name ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Operator-Name ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + + + +Tschofenig, et al. Standards Track [Page 12] + +RFC 5580 Carrying LOs in RADIUS and Diameter August 2009 + + + Namespace ID: + + The value within this field contains the operator namespace + identifier. The Namespace ID value is encoded in ASCII. + + Example: '1' (0x31) for REALM + + Operator-Name: + + The text field of variable length contains an Access Network + Operator Name. This field is a RADIUS-based data type of Text. + + The Namespace ID field provides information about the operator + namespace. This document defines four values for this attribute, + which are listed below. Additional namespace identifiers must be + registered with IANA (see Section 8.1) and must be associated with an + organization responsible for managing the namespace. + + TADIG ('0' (0x30)): + + This namespace can be used to indicate operator names based on + Transferred Account Data Interchange Group (TADIG) codes, as + defined in [GSM]. TADIG codes are assigned by the TADIG Working + Group within the Global System for Mobile Communications (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 alphanumeric operator (or + company) ID. + + REALM ('1' (0x31)): + + 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). Since this + operator is limited to ASCII, any registered domain name that + contains non-ASCII characters must be converted to ASCII. The + Punycode encoding [RFC3492] is used for this purpose. + + E212 ('2' (0x32)): + + The E212 namespace can be used to indicate operator names based on + the Mobile Country Code (MCC) and Mobile Network Code (MNC) + defined in [ITU212]. The MCC/MNC values are assigned by the + Telecommunications Standardization Bureau (TSB) within the ITU-T + + + + + +Tschofenig, et al. Standards Track [Page 13] + +RFC 5580 Carrying LOs in RADIUS and Diameter August 2009 + + + and by 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. + + ICC ('3' (0x33)): + + The ICC namespace can be used to indicate operator names based on + International Telecommunication Union (ITU) Carrier Codes (ICC) + defined in [ITU1400]. ICC values are assigned by national + regulatory authorities and are coordinated by the + Telecommunication Standardization Bureau (TSB) within the ITU + Telecommunication Standardization Sector (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 [ISO], followed by one to six uppercase alphanumeric + ASCII characters containing the ICC itself. + +4.2. Location-Information Attribute + + The Location-Information Attribute MAY be sent in the Access-Request + message, the Accounting-Request message, both of these messages, or + no message. For the Accounting-Request message, the Acc-Status-Type + may be set to Start, Interim, or Stop. + + The Location-Information Attribute provides meta-data about the + location information, such as sighting time, time-to-live, location- + determination method, etc. + + The format is shown below. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | String (cont.) ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: + + 127 - Location-Information + + Length: + + >= 23 + + + + + + +Tschofenig, et al. Standards Track [Page 14] + +RFC 5580 Carrying LOs in RADIUS and Diameter August 2009 + + + String: + + The format is shown below. The data type of this field is a + string. All fields are transmitted from left to right: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Index | Code | Entity | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sighting Time ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sighting Time | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Time-to-Live ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Time-to-Live | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Method ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Index (16 bits): + + The 16-bit unsigned integer value allows this attribute to provide + information relating to the information included in the Location- + Data Attribute to which it refers (via the Index). + + Code (8 bits): + + This field indicates the content of the location profile carried + in the Location-Data Attribute. Two profiles are defined in this + document -- namely, a civic location profile (see Section 4.3.1) + that uses value (0) and a geospatial location profile (see + Section 4.3.2) that uses the value (1). + + Entity (8 bits): + + This field encodes which location this attribute refers to as an + unsigned 8-bit integer value. Location information can refer to + different entities. This document registers two entity values, + namely: + + Value (0) describes the location of the user's client device. + + Value (1) describes the location of the RADIUS client. + + The registry used for these values is established by this + document, see Section 8.4. + + + +Tschofenig, et al. Standards Track [Page 15] + +RFC 5580 Carrying LOs in RADIUS and Diameter August 2009 + + + Sighting Time (64 bits) + + This field indicates when the location information was accurate. + The data type of this field is a string, and the content is + expressed in the 64-bit Network Time Protocol (NTP) timestamp + format [RFC1305]. + + Time-to-Live (64 bits): + + This field gives a hint regarding for how long location + information should be considered current. The data type of this + field is a string and the content is expressed in the 64-bit + Network Time Protocol (NTP) timestamp format [RFC1305]. Note that + the Time-to-Live field is different than the Retention Expires + field used in the Basic-Location-Policy-Rules Attribute, see + Section 4.4. The Retention Expires field indicates the time the + recipient is no longer permitted to possess the location + information. + + Method (variable): + + Describes the way that the location information was determined. + This field MUST contain the value of exactly one IANA-registered + 'method' token [RFC4119]. + + The length of the Location-Information Attribute MUST NOT exceed 253 + octets. + +4.3. Location-Data Attribute + + The Location-Data Attribute MAY be sent in Access-Request and + Accounting-Request messages. For the Accounting-Request message, the + Acc-Status-Type may be set to Start, Interim, or Stop. + + The format is shown below. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | String (cont.) ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: + + 128 - Location-Data + + + + +Tschofenig, et al. Standards Track [Page 16] + +RFC 5580 Carrying LOs in RADIUS and Diameter August 2009 + + + Length: + + >= 5 + + String: + + The format is shown below. The data type of this field is a + string. All fields are transmitted from left to right: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Index | Location ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Location ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Index (16 bits): + + The 16-bit unsigned integer value allows this attribute to + associate the Location-Data Attribute with the Location- + Information Attributes. + + Location (variable): + + The format of the location data depends on the location profile. + This document defines two location profiles. Details of the + location profiles are described below. + +4.3.1. Civic Location Profile + + Civic location is a popular way to describe the location of an + entity. This section defines the civic location-information profile + corresponding to the value (0) indicated in the Code field of the + Location-Information Attribute. The location format is based on the + encoding format defined in Section 3.1 of [RFC4776], whereby the + first 3 octets are not put into the Location field of the above- + described RADIUS Location-Data Attribute (i.e., the code for the DHCP + option, the length of the DHCP option, and the 'what' element are not + included). + +4.3.2. Geospatial Location Profile + + This section defines the geospatial location-information profile + corresponding to the value (1) indicated in the Code field of the + Location-Information Attribute. Geospatial location information is + encoded as an opaque object, and the format is based on the Location + + + + +Tschofenig, et al. Standards Track [Page 17] + +RFC 5580 Carrying LOs in RADIUS and Diameter August 2009 + + + Configuration Information (LCI) format defined in Section 2 of + [RFC3825] but starts with the third octet (i.e., the code for the + DHCP option and the length field is not included). + +4.4. Basic-Location-Policy-Rules Attribute + + The Basic-Location-Policy-Rules Attribute MAY be sent in Access- + Request, Access-Accept, Access-Challenge, Change-of-Authorization, + and Accounting-Request messages. + + Policy rules control the distribution of location information. In + order to understand and process the Basic-Location-Policy-Rules + Attribute, RADIUS clients are obligated to utilize a default value of + Basic-Location-Policy-Rules, unless explicitly configured otherwise, + and to echo the Basic-Location-Policy-Rules Attribute that they + receive from a server. As a default, the Note Well field does not + carry a pointer to human-readable privacy policies, the + retransmission-allowed is set to zero (0), i.e., further distribution + is not allowed, and the Retention Expires field is set to 24 hours. + + With regard to authorization policies, this document reuses work done + in [RFC4119] and encodes those policies in a non-XML format. Two + fields ('Sighting Time' and 'Time-to-Live') are additionally included + in the Location-Information Attribute to conform to the GEOPRIV + requirements [RFC3693], Section 2.7. + + The format of the Basic-Location-Policy-Rules Attribute is shown + below. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | String (cont.) ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: + + 129 - Basic-Location-Policy-Rules + + Length: + + >= 12 + + + + + + + +Tschofenig, et al. Standards Track [Page 18] + +RFC 5580 Carrying LOs in RADIUS and Diameter August 2009 + + + String: + + The format is shown below. The data type of this field is a + string. All fields are transmitted from left to right: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Flags | Retention Expires ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Retention Expires ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Retention Expires | Note Well ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Note Well ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + This document reuses fields from the RFC 4119 [RFC4119] 'usage-rules' + element. These fields have the following meaning: + + Flags (16 bits): + + The Flags field is a bit mask. Only the first bit (R) is defined + in this document, and it corresponds to the Retransmission Allowed + field: + + 0 1 + 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 = Retransmission Allowed + o = reserved. + + All reserved bits MUST be zero. When the value of the Retransmission + Allowed field is set to zero (0), then the recipient of this Location + Object is not permitted to share the enclosed location information, + or the object as a whole, with other parties. The value of '1' + allows this attribute to share the location information with other + parties by considering the extended policy rules. + + Retention Expires (64 bits): + + This field specifies an absolute date at which time the Recipient + 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 + timestamp [RFC1305]. + + + +Tschofenig, et al. Standards Track [Page 19] + +RFC 5580 Carrying LOs in RADIUS and Diameter August 2009 + + + Note Well (variable): + + This field contains a URI that points to human-readable privacy + instructions. The data type of this field is a string. This + field is useful when location information is distributed to third- + party entities, which can include humans in a location-based + service. RADIUS entities are not supposed to process this field. + + Whenever a Location Object leaves the RADIUS ecosystem, the URI in + the Note Well Attribute MUST be expanded to the human-readable + text. For example, when the Location Object is transferred to a + SIP-based environment, then the human-readable text is placed into + the 'note-well' element of the 'usage-rules' element contained in + the PIDF-LO (Presence Information Data Format - Location Object) + document (see [RFC4119]). The Note Well field may be empty. + +4.5. Extended-Location-Policy-Rules Attribute + + The Extended-Location-Policy-Rules Attribute MAY be sent in Access- + Request, Access-Accept, Access-Challenge, Access-Reject, Change-of- + Authorization, and Accounting-Request messages. + + The Ruleset Reference field of this attribute is of variable length. + It contains a URI that indicates where the richer ruleset can be + found. This URI SHOULD use the HTTPS URI scheme. As a deviation + from [RFC4119], this field only contains a reference and does not + carry an attached, extended ruleset. This modification is motivated + by the size limitations imposed by RADIUS. + + In order to understand and process the Extended-Location-Policy-Rules + Attribute, RADIUS clients are obligated to attach the URI to the + Extended-Location-Policy-Rules Attribute when they are explicitly + configured to do so, and to echo the Extended-Location-Policy-Rules + Attribute that they receive from a server. There is no expectation + that RADIUS clients will need to retrieve data at the URL specified + in the attribute or to parse the XML policies. + + The format of the Extended-Location-Policy-Rules Attribute is shown + below. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | String ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | String (cont.) ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + +Tschofenig, et al. Standards Track [Page 20] + +RFC 5580 Carrying LOs in RADIUS and Diameter August 2009 + + + Type: + + 130 - Extended-Location-Policy-Rules + + Length: + + >= 3 + + String: + + This field is at least two octets in length, and the format is + shown below. The data type of this field is a string. The fields + are transmitted from left to right: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Ruleset Reference ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Ruleset Reference: + + This field contains a URI that points to the policy rules. + +4.6. Location-Capable Attribute + + The Location-Capable Attribute allows an NAS (or client function of a + proxy server) to indicate support for the functionality specified in + this document. The Location-Capable Attribute with the value for + 'Location Capable' MUST be sent with the Access-Request messages, if + the NAS supports the functionality described in this document and is + capable of sending location information. A RADIUS server MUST NOT + challenge for location information unless the Location-Capable + Attribute has been sent to it. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Integer | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Integer (cont.) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: + + 131 - Location-Capable Attribute + + + + + +Tschofenig, et al. Standards Track [Page 21] + +RFC 5580 Carrying LOs in RADIUS and Diameter August 2009 + + + Length: + + 6 + + Integer: + + The content of the Integer field encodes the requested + capabilities. Each capability value represents a bit position. + + This document specifies the following capabilities. + + Name: + + CIVIC_LOCATION + + Description: + + The RADIUS client uses the CIVIC_LOCATION to indicate that it is + able to return civic location based on the location profile + defined in Section 4.3.1. + + Numerical Value: + + A numerical value of this token is '1'. + + Name: + + GEO_LOCATION + + Description: + + The RADIUS client uses the GEO_LOCATION to indicate that it is + able to return geodetic location based on the location profile + defined in Section 4.3.2. + + Numerical Value: + + A numerical value of this token is '2'. + + Name: + + USERS_LOCATION + + + + + + + + + +Tschofenig, et al. Standards Track [Page 22] + +RFC 5580 Carrying LOs in RADIUS and Diameter August 2009 + + + Description: + + The numerical value representing USERS_LOCATION indicates that the + RADIUS client is able to provide a Location-Information Attribute + with the Entity Attribute expressing the value of zero (0), i.e., + the RADIUS client is capable of returning the location information + of the user's client device. + + Numerical Value: + + A numerical value of this token is '4'. + + Name: + + NAS_LOCATION + + Description: + + The numerical value representing NAS_LOCATION indicates that the + RADIUS client is able to provide a Location-Information Attribute + that contains location information with the Entity Attribute + expressing the value of one (1), i.e., the RADIUS client is + capable of returning the location information of the NAS. + + Numerical Value: + + A numerical value of this token is '8'. + +4.7. Requested-Location-Info Attribute + + The Requested-Location-Info Attribute allows the RADIUS server to + indicate which location information about which entity it wants to + receive. The latter aspect refers to the entities that are indicated + in the Entity field of the Location-Information Attribute. + + The Requested-Location-Info Attribute MAY be sent in an Access- + Accept, Access-Challenge, or Change-of-Authorization packet. + + If the RADIUS server wants to dynamically decide on a per-request + basis to ask for location information from the RADIUS client, then + the following cases need to be differentiated. If the RADIUS client + and the RADIUS server have agreed out-of-band to mandate the transfer + of location information for every network-access authentication + request, then the processing listed below is not applicable. + + + + + + + +Tschofenig, et al. Standards Track [Page 23] + +RFC 5580 Carrying LOs in RADIUS and Diameter August 2009 + + + o If the RADIUS server requires location information for computing + the authorization decision and the RADIUS client does not provide + it with the Access-Request message, then the Requested-Location- + Info Attribute is attached to the Access-Challenge with a hint + about what is required. + + o If the RADIUS server does not receive the requested information in + response to the Access-Challenge (including the Requested- + Location-Info Attribute), then the RADIUS server may respond with + an Access-Reject message with an Error-Cause Attribute (including + the "Location-Info-Required" value). + + o If the RADIUS server would like location information in the + Accounting-Request message but does not require it for computing + an authorization decision, then the Access-Accept message MUST + include a Required-Info Attribute. This is typically the case + when location information is used only for billing. The RADIUS + client SHOULD attach location information, if available, to the + Accounting-Request (unless authorization policies dictate + something different). + + If the RADIUS server does not send a Requested-Location-Info + Attribute, then the RADIUS client MUST NOT attach location + information to messages towards the RADIUS server. The user's + authorization policies, if available, MUST be consulted by the RADIUS + server before requesting location information delivery from the + RADIUS client. + + Figure 6 shows a simple protocol exchange where the RADIUS server + indicates the desire to obtain location information, namely civic + location information of the user, to grant access. Since the + Requested-Location-Info Attribute is attached to the Access- + Challenge, the RADIUS server indicates that location information is + required for computing an authorization decision. + + + + + + + + + + + + + + + + + +Tschofenig, et al. Standards Track [Page 24] + +RFC 5580 Carrying LOs in RADIUS and Diameter August 2009 + + + +---------+ +---------+ + | RADIUS | | RADIUS | + | Client | | Server | + +---------+ +---------+ + | | + | | + | Access-Request | + | + Location-Capable | + | ('CIVIC_LOCATION', | + | 'GEO_LOCATION', | + | 'NAS_LOCATION', | + | 'USERS_LOCATION') | + |--------------------------------->| + | | + | Access-Challenge | + | + Requested-Location-Info | + | ('CIVIC_LOCATION', | + | 'USERS_LOCATION') | + | + Basic-Location-Policy-Rules | + | + Extended-Location-Policy-Rules | + |<---------------------------------| + | | + | Access-Request | + | + Location-Information | + | + Location-Data | + | + Basic-Location-Policy-Rules | + | + Extended-Location-Policy-Rules | + |--------------------------------->| + | | + | .... | + + Figure 6: RADIUS Server Requesting Location Information + + The Requested-Location-Info Attribute MUST be sent by the RADIUS + server, in the absence of an out-of-band agreement, if it wants the + RADIUS client to return location information and if authorization + policies permit it. This Requested-Location-Info Attribute MAY + appear in the Access-Accept or in the Access-Challenge message. + + A summary of the attribute is shown below. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Integer ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Integer (cont.) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + +Tschofenig, et al. Standards Track [Page 25] + +RFC 5580 Carrying LOs in RADIUS and Diameter August 2009 + + + Type: + + 132 - Requested-Location-Info Attribute + + Length: + + 6 + + Integer: + + The content of the Integer field encodes the requested information + attributes. Each capability value represents a bit position. + + This document specifies the following capabilities: + + Name: + + CIVIC_LOCATION + + Description: + + The RADIUS server uses the Requested-Location-Info Attribute with + the value set to CIVIC_LOCATION to request specific location + information from the RADIUS client. The numerical value + representing CIVIC_LOCATION requires the RADIUS client to attach + civic location attributes. CIVIC_LOCATION refers to the location + profile defined in Section 4.3.1. + + Numerical Value: + + A numerical value of this token is '1'. + + Name: + + GEO_LOCATION + + Description: + + The RADIUS server uses the Requested-Location-Info Attribute with + the value set to GEO_LOCATION to request specific location + information from the RADIUS client. The numerical value + representing GEO_LOCATION requires the RADIUS client to attach + geospatial location attributes. GEO_LOCATION refers to the + location profile described in Section 4.3.2. + + Numerical Value: + + A numerical value of this token is '2'. + + + +Tschofenig, et al. Standards Track [Page 26] + +RFC 5580 Carrying LOs in RADIUS and Diameter August 2009 + + + Name: + + USERS_LOCATION + + Description: + + The numerical value representing USERS_LOCATION indicates that the + RADIUS client MUST send a Location-Information Attribute with the + Entity Attribute expressing the value of zero (0). Hence, there + is a one-to-one relationship between the USERS_LOCATION token and + the value of zero (0) of the Entity Attribute inside the Location- + Information Attribute. A value of zero indicates that the + location information in the Location-Information Attribute refers + to the user's client device. + + Numerical Value: + + A numerical value of this token is '4'. + + Name: + + NAS_LOCATION + + Description: + + The numerical value representing NAS_LOCATION indicates that the + RADIUS client MUST send a Location-Information Attribute that + contains location information with the Entity Attribute expressing + the value of one (1). Hence, there is a one-to-one relationship + between the NAS_LOCATION token and the value of one (1) of the + Entity Attribute inside the Location-Information Attribute. A + value of one indicates that the location information in the + Location-Information Attribute refers to the RADIUS client. + + Numerical Value: + + A numerical value of this token is '8'. + + Name: + + FUTURE_REQUESTS + + Description: + + The numerical value representing FUTURE_REQUESTS indicates that + the RADIUS client MUST provide future Access-Requests for the same + session with the same type of information as returned in the + initial Access-Request message. + + + +Tschofenig, et al. Standards Track [Page 27] + +RFC 5580 Carrying LOs in RADIUS and Diameter August 2009 + + + Numerical Value: + + A numerical value of this token is '16'. + + Name: + + NONE + + Description: + + The RADIUS server uses this token to request that the RADIUS + client stop sending location information. + + Numerical Value: + + A numerical value of this token is '32'. + + 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 + authorization policies allow it). If both the NAS_LOCATION and the + USERS_LOCATION bits are set, then the returned location information + has to be put into separate attributes. If neither the + CIVIC_LOCATION nor the GEO_LOCATION bit is set in the Requested- + Location-Info Attribute, then no location information is returned. + If both the CIVIC_LOCATION and the GEO_LOCATION bits are set, then + the location information has to be put into separate attributes. The + value of NAS_LOCATION and USERS_LOCATION refers to the location + information requested via CIVIC_LOCATION and GEO_LOCATION. + + As an example, if the bits for NAS_LOCATION, USERS_LOCATION, and + GEO_LOCATION are set, then the location information of the RADIUS + client and the users' client device are returned in a geospatial- + location format. + +5. Table of Attributes + + The following table provides a guide to which attributes may be found + in which RADIUS messages, and in what quantity. + + + + + + + + + + + + + +Tschofenig, et al. Standards Track [Page 28] + +RFC 5580 Carrying LOs in RADIUS and Diameter August 2009 + + + Request Accept Reject Challenge Accounting # Attribute + Request + 0-1 0-1 0 0 0+ 126 Operator-Name + 0+ 0 0 0 0+ 127 Location-Information + 0+ 0 0 0 0+ 128 Location-Data + 0-1 0-1 0-1 0-1 0-1 129 Basic-Location- + Policy-Rules + 0-1 0-1 0-1 0-1 0-1 130 Extended-Location- + Policy-Rules + 0-1 0 0 0 0 131 Location-Capable + 0 0-1 0 0-1 0 132 Requested-Location-Info + 0 0 0-1 0 0 101 Error-Cause (*) + + (*) Note: The Error-Cause Attribute contains the value for the + 'Location-Info-Required' error. + + Change-of-Authorization Messages + + Request ACK NAK # Attribute + 0-1 0 0 129 Basic-Location-Policy-Rules + 0-1 0 0 130 Extended-Location-Policy-Rules + 0-1 0 0 132 Requested-Location-Info + + Legend: + + 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 7: Table of Attributes + + The Error-Cause Attribute is defined in [RFC5176]. + + The Location-Information and the Location-Data Attribute MAY appear + more than once. For example, if the server asks for civic and + geospatial location information, two Location-Information Attributes + need to be sent. + + The attributes defined in this document are not used in any messages + other than the ones listed in Figure 7. + + IANA allocated a new value (509) from the Error-Cause registry with + the semantics of 'Location-Info-Required'. + + + + + + +Tschofenig, et al. Standards Track [Page 29] + +RFC 5580 Carrying LOs in RADIUS and Diameter August 2009 + + +6. Diameter RADIUS Interoperability + + When used in Diameter, the attributes defined in this specification + can be used as Diameter attribute-value pairs (AVPs) from the code + space 1-255 (RADIUS attribute-compatibility space). No additional + Diameter code values are therefore allocated. The data types and + flag rules, as defined in [RFC3588], for the Diameter AVPs are as + follows: + + +---------------------+ + | AVP Flag rules | + +----+-----+------+-----+----+ + | | |SHOULD| MUST| | + Attribute Name Value Type |MUST| MAY | NOT | NOT|Encr| + +---------------------------------+----+-----+------+-----+----+ + |Operator-Name OctetString| | P | | V,M | Y | + |Location-Information OctetString| | P | | V,M | Y | + |Location-Data OctetString| | P | | V,M | Y | + |Basic-Location- | | | | | | + | Policy-Rules OctetString| | P | | V,M | Y | + |Extended-Location- | | | | | | + | Policy-Rules OctetString| | P | | V,M | Y | + |Requested- | | | | | | + | Location-Info OctetString| | P | | V,M | Y | + |Location-Capable OctetString| | P | | V,M | Y | + +---------------------------------+----+-----+------+-----+----+ + + The RADIUS attributes in this specification have no special + translation requirements for Diameter-to-RADIUS or RADIUS-to-Diameter + gateways; they are copied as is, except for changes relating to + headers, alignment, and padding. See also Section 4.1 of [RFC3588] + and Section 9 of [RFC4005]. + + What this specification says about the applicability of the + attributes for RADIUS Access-Request packets applies in Diameter to + AA-Request [RFC4005] or Diameter-EAP-Request [RFC4072]. What is said + about Access-Challenge applies in Diameter to AA-Answer [RFC4005] or + Diameter-EAP-Answer [RFC4072] with the Result-Code AVP set to + DIAMETER_MULTI_ROUND_AUTH. What is said about Access-Accept applies + in Diameter to AA-Answer or Diameter-EAP-Answer messages that + indicate success. Similarly, what is said about RADIUS Access-Reject + packets applies in Diameter to AA-Answer or Diameter-EAP-Answer + messages that indicate failure. + + What is said about CoA-Request applies in Diameter to Re-Auth-Request + [RFC4005]. + + + + + +Tschofenig, et al. Standards Track [Page 30] + +RFC 5580 Carrying LOs in RADIUS and Diameter August 2009 + + + What is said about Accounting-Request applies in Diameter to + Accounting-Request [RFC4005] as well. + + Note that these AVPs may be used by Diameter applications other than + RFC 4005 [RFC4005] and RFC 4072 [RFC4072]. The above-mentioned + applications are, however, likely to be relevant in the context of + this document. + +7. Security Considerations + + A number of security aspects are relevant for the distribution of + location information via RADIUS. These aspects are discussed in + separate subsections. + +7.1. Communication Security + + Requirements for the protection of a Location Object are defined in + [RFC3693] -- namely, mutual end-point authentication, data object + integrity, data object confidentiality, and replay protection. + + If no authentication, integrity, and replay protection between the + participating RADIUS entities is provided, then adversaries can spoof + and modify transmitted attributes. Two security mechanisms are + proposed for RADIUS: + + o [RFC2865] proposes the usage of a static key that raised concerns + regarding the lack of dynamic key management. At the time of + writing, work is ongoing to address some shortcomings of the + [RFC2865] attribute regarding security protection. + + o RADIUS over IPsec [RFC3579] enables the use of standard key- + management mechanisms, such as Kerberized Internet Negotiation of + Keys (KINK), the Internet Key Exchange Protocol (IKE), and IKEv2 + [RFC4306], to establish IPsec security associations. + Confidentiality protection MUST be used to prevent an eavesdropper + from gaining access to location information. Confidentiality + protection is already present for other reasons in many + environments, such as for the transport of keying material in the + context of Extensible Authentication Protocol (EAP) authentication + and authorization. Hence, this requirement is, in many + environments, already fulfilled. Mutual authentication MUST be + provided between neighboring RADIUS entities to prevent man-in- + the-middle attacks. Since mutual authentication is already + required for key transport within RADIUS messages, it does not + represent a deployment obstacle. Since IPsec protection is + already suggested as a mechanism to protect RADIUS, no additional + considerations need to be addressed beyond those described in + [RFC3579]. + + + +Tschofenig, et al. Standards Track [Page 31] + +RFC 5580 Carrying LOs in RADIUS and Diameter August 2009 + + + In case IPsec protection is not available for some reason and RADIUS- + specific security mechanisms have to be used, then the following + considerations apply. The Access-Request message is not integrity + protected. This would allow an adversary to change the contents of + the Location Object or to insert, modify, and delete attributes or + individual fields. To address these problems, the Message- + Authenticator (80) can be used to integrity protect the entire + Access-Request packet. The Message-Authenticator (80) is also + required when EAP is used and, hence, is supported by many modern + RADIUS servers. + + Access-Request packets including location attribute(s) without a + Message-Authenticator (80) Attribute SHOULD be silently discarded by + the RADIUS server. A RADIUS server supporting location attributes + MUST calculate the correct value of the Message-Authenticator (80) + and MUST silently discard the packet if it does not match the value + sent. + + Access-Accept messages, including location attribute(s), without a + Message-Authenticator (80) Attribute SHOULD be silently discarded by + the NAS. An NAS supporting location attributes MUST calculate the + correct value of a received Message-Authenticator (80) and MUST + silently discard the packet if it does not match the value sent. + + RADIUS and Diameter make some assumptions about the trust between + traversed RADIUS entities in the sense that object-level security is + not provided by either RADIUS or Diameter. Hence, some trust has to + be placed on the RADIUS entities to behave according to the defined + rules. Furthermore, the RADIUS protocol does not involve the user in + their protocol interaction except for tunneling authentication + information (such as EAP messages) through their infrastructure. + RADIUS and Diameter have even become a de facto protocol for key + distribution for network-access authentication applications. Hence, + in the past there were some concerns about the trust placed into the + infrastructure -- particularly from the security area -- when it + comes to keying. The EAP keying infrastructure is described in + [RFC4282]. + +7.2. Privacy Considerations + + This section discusses privacy implications for the distribution of + location information within RADIUS. Note also that it is possible + for the RADIUS server to obtain some amount of location information + from the NAS identifier. This document, however, describes + procedures to convey more accurate location information about the end + host and/or the network. In a number of deployment environments, + location information about the network also reveals the current + + + + +Tschofenig, et al. Standards Track [Page 32] + +RFC 5580 Carrying LOs in RADIUS and Diameter August 2009 + + + location of the user with a certain degree of precision, depending on + the location-determination mechanism used, the update frequency, the + size of the network, and other factors, such as movement traces. + + Three types of use cases have to be differentiated: + + o The RADIUS server does not want to receive location information + from the RADIUS client. + + o In case there is an out-of-band agreement between the entity + responsible for the NAS and the entity operating the RADIUS + server, location information may be sent without an explicit + request from the RADIUS server. + + o The RADIUS server dynamically requests location information from + the NAS. + +7.2.1. RADIUS Client + + The RADIUS client MUST behave according to the following guidelines: + + o If neither an out-of-band agreement exists nor location + information is requested by the RADIUS server, then location + information is not disclosed by the RADIUS client. + + o The RADIUS client MUST pass location information to other entities + (e.g., when information is written to a local database or to the + log files) only together with the policy rules. The entity + receiving the location information (together with the policies) + MUST follow the guidance given with these rules. + + o A RADIUS client MUST include Basic-Location-Policy-Rules and + Extended-Location-Policy-Rules Attributes that are configured + within an Access-Request packet. + + o NAS implementations supporting this specification, which are + configured to provide location information, MUST echo Basic- + Location-Policy-Rules and Extended-Location-Policy-Rules + Attributes unmodified within a subsequent Access-Request packet. + In addition, an Access-Request packet sent with a Service-Type + value of "Authorize Only" MUST include the Basic-Location-Policy- + Rules or Extended-Location-Policy-Rules Attributes that were + received in a previous Access-Accept if the FUTURE_REQUESTS flag + was set in the Requested-Location-Info Attribute. + + + + + + + +Tschofenig, et al. Standards Track [Page 33] + +RFC 5580 Carrying LOs in RADIUS and Diameter August 2009 + + +7.2.2. RADIUS Server + + The RADIUS server is a natural place for storing authorization + policies since the user typically has some sort of trust relationship + with the entity operating the RADIUS server. Once the infrastructure + is deployed and location-aware applications are available, there + might be a strong desire to use location information for other + purposes as well. + + The Common Policy framework [RFC4745] that was extended for + geolocation privacy [GEO-POLICY] is tailored for this purpose. + The Extensible Markup Language (XML) Configuration Access Protocol + (XCAP) [RFC4825] gives users the ability to change their privacy + policies using a standardized protocol. These policies are an + important tool for limiting further distribution of the user's + location to other location-based services. + + The RADIUS server MUST behave according to the following guidelines: + + o The RADIUS server MUST attach available rules to the Access- + Accept, Access-Reject, or Access-Challenge message when the RADIUS + client is supposed to provide location information. + + o When location information is made available to other entities + (e.g., writing to stable storage for later billing processing), + then the RADIUS server MUST attach the privacy rules to location + information. + +7.2.3. RADIUS Proxy + + A RADIUS proxy, behaving as a combined RADIUS client and RADIUS + server, MUST follow the rules described in Sections 7.2.1 and 7.2.2. + +7.3. Identity Information and Location Information + + For the envisioned usage scenarios, the identity of the user and his + device is tightly coupled to the transfer of location information. + If the identity can be determined by the visited network or RADIUS + brokers, then it is possible to correlate location information with a + particular user. As such, it allows the visited network and brokers + to learn the movement patterns of users. + + The user's identity can be "leaked" to the visited network or RADIUS + brokers in a number of ways: + + o The user's device may employ a fixed Media Access Control (MAC) + address or base its IP address on such an address. This enables + the correlation of the particular device to its different + + + +Tschofenig, et al. Standards Track [Page 34] + +RFC 5580 Carrying LOs in RADIUS and Diameter August 2009 + + + locations. Techniques exist to avoid the use of an IP address + that is based on a MAC address [RFC4941]. Some link layers make + it possible to avoid MAC addresses or change them dynamically. + + o Network-access authentication procedures, such as the PPP + Challenge Handshake Authentication Protocol (CHAP) [RFC1994] or + EAP [RFC4187], may reveal the user's identity as a part of the + authentication procedure. Techniques exist to avoid this problem + in EAP methods, for instance by employing private Network Access + Identifiers (NAIs) [RFC4282] in the EAP Identity Response message + and by method-specific private identity exchanges in the EAP + method (e.g., [RFC4187], [RFC5281], [PEAP], and [RFC5106]). + Support for identity privacy within CHAP is not available. + + o RADIUS may return information from the home network to the visited + one in a manner that makes it possible to either identify the user + or at least correlate his session with other sessions, such as the + use of static data in a Class Attribute [RFC2865] or in some + accounting attribute usage scenarios [RFC4372]. + + o Mobility protocols may reveal some long-term identifier, such as a + home address. + + o Application-layer protocols may reveal other permanent + identifiers. + + To prevent the correlation of identities with location information, + it is necessary to prevent leakage of identity information from all + sources, not just one. + + Unfortunately, most users are not educated about the importance of + identity confidentiality, and some protocols lack support for + identity-privacy mechanisms. This problem is made worse by the fact + that users may be unable to choose particular protocols, as the + choice is often dictated by the type of network operator they use, + the type of network they wish to access, the kind of equipment they + have, or the type of authentication method they are using. + + A scenario where the user is attached to the home network is, from a + privacy point of view, simpler than a scenario where a user roams + into a visited network, since the NAS and the home RADIUS server are + in the same administrative domain. No direct relationship between + the visited and the home network operator may be available, and some + RADIUS brokers need to be consulted. With subscription-based network + access as used today, the user has a contractual relationship with + the home network provider that could (theoretically) allow higher + + + + + +Tschofenig, et al. Standards Track [Page 35] + +RFC 5580 Carrying LOs in RADIUS and Diameter August 2009 + + + privacy considerations to be applied (including policy rules stored + at the home network itself, for the purpose of restricting further + distribution). + + In many cases it is necessary to secure the transport of location + information along the RADIUS infrastructure. Mechanisms to achieve + this functionality are discussed in Section 7.1. + +8. IANA Considerations + + The Attribute Types and Attribute Values defined in this document + have been registered by the Internet Assigned Numbers Authority + (IANA) from the RADIUS namespaces as described in the "IANA + Considerations" section of RFC 3575 [RFC3575], in accordance with BCP + 26 [RFC5226]. Additionally, the Attribute Type has been registered + in the Diameter namespace. For RADIUS attributes and registries + created by this document, IANA placed them in the Radius Types + registry. + + This document defines the following attributes: + + Operator-Name + Location-Information + Location-Data + Basic-Location-Policy-Rules + Extended-Location-Policy-Rules + Location-Capable + Requested-Location-Info + + Please refer to Section 5 for the registered list of numbers. + + IANA has also assigned a new value (509) for the Error-Cause + Attribute [RFC5176] of "Location-Info-Required" according to this + document. + + Additionally, IANA created the following new registries listed in the + subsections below. + +8.1. New Registry: Operator Namespace Identifier + + This document also defines an Operator Namespace Identifier registry + (used in the Namespace ID field of the Operator-Name Attribute). + Note that this document requests IANA only to maintain a registry of + existing namespaces for use in this identifier field, and not to + establish any namespaces or place any values within namespaces. + + + + + + +Tschofenig, et al. Standards Track [Page 36] + +RFC 5580 Carrying LOs in RADIUS and Diameter August 2009 + + + IANA added the following values to the Operator Namespace Identifier + registry using a numerical identifier (allocated in sequence), a + token for the operator namespace, and a contact person for the + registry. + + +----------+--------------------+------------------------------------+ + |Identifier| Operator Namespace | Contact Person | + | | Token | | + +----------+--------------------+------------------------------------+ + | 0x30 | TADIG | TD.13 Coordinator | + | | | (td13@gsm.org) | + | 0x31 | REALM | IETF O&M Area Directors | + | | | (ops-ads@ietf.org) | + | 0x32 | E212 | ITU Director | + | | | (tsbdir@itu.int) | + | 0x33 | ICC | ITU Director | + | | | (tsbdir@itu.int) | + +----------+--------------------+------------------------------------+ + + Note that the above identifier values represent the ASCII value '0' + (decimal 48 or hex 0x30), '1' (decimal 49, or hex 0x31), '2' (decimal + 50, or hex 0x32), and '3' (decimal 51, or hex 0x33). This encoding + was chosen to simplify parsing. + + Requests to IANA for a new value for a Namespace ID, i.e., values + from 0x34 to 0xFE, will be approved by Expert Review. A designated + expert will be appointed by the IESG. + + 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 + real requirement to provide a token for a Namespace ID because one is + already up and running, or whether the REALM identifier plus the name + should be recommended to the requester. In addition, the Expert + Reviewer should ascertain to some reasonable degree of diligence that + a new entry is a correct reference to an operator namespace whenever + a new one is registered. + +8.2. New Registry: Location Profiles + + Section 4.2 defines the Location-Information Attribute and a Code + field that contains an 8-bit integer value. Two values, zero and + one, are defined in this document, namely: + + Value (0): Civic location profile described in Section 4.3.1 + + Value (1): Geospatial location profile described in Section 4.3.2 + + The remaining values are reserved for future use. + + + +Tschofenig, et al. Standards Track [Page 37] + +RFC 5580 Carrying LOs in RADIUS and Diameter August 2009 + + + Following the policies outlined in [RFC3575], the available bits with + a description of their semantics will be assigned after the Expert + Review process. Updates can be provided based on expert approval + only. Based on expert approval, it is possible to mark entries as + "deprecated". A designated expert will be appointed by the IESG. + + Each registration must include the value and the corresponding + semantics of the defined location profile. + +8.3. New Registry: Location-Capable Attribute + + Section 4.6 defines the Location-Capable Attribute that contains a + bit map. 32 bits are available, from which 4 bits are defined by this + document. This document creates a new IANA registry for the + Location-Capable Attribute. IANA added the following values to this + registry: + + +----------+----------------------+ + | Value | Capability Token | + +----------+----------------------+ + | 1 | CIVIC_LOCATION | + | 2 | GEO_LOCATION | + | 4 | USERS_LOCATION | + | 8 | NAS_LOCATION | + +----------+----------------------+ + + Following the policies outlined in [RFC3575], the available bits with + a description of their semantics will be assigned after the Expert + Review process. Updates can be provided based on expert approval + only. Based on expert approval, it is possible to mark entries as + "deprecated". A designated expert will be appointed by the IESG. + + Each registration must include: + + Name: + + Capability Token (i.e., an identifier of the capability) + + Description: + + Brief description indicating the meaning of the 'info' element. + + Numerical Value: + + A numerical value that is placed into the Capability Attribute + representing a bit in the bit-string of the Requested-Location- + Info Attribute. + + + + +Tschofenig, et al. Standards Track [Page 38] + +RFC 5580 Carrying LOs in RADIUS and Diameter August 2009 + + +8.4. New Registry: Entity Types + + Section 4.2 defines the Location-Information Attribute that contains + an 8-bit Entity field. Two values are registered by this document, + namely: + + Value (0) describes the location of the user's client device. + + Value (1) describes the location of the RADIUS client. + + All other values are reserved for future use. + + Following the policies outlined in [RFC3575], the available bits with + a description of their semantics will be assigned after the Expert + Review process. Updates can be provided based on expert approval + only. Based on expert approval, it is possible to mark entries as + "deprecated". A designated expert will be appointed by the IESG. + + Each registration must include the value and a corresponding + description. + +8.5. New Registry: Privacy Flags + + Section 4.4 defines the Basic-Location-Policy-Rules Attribute that + contains flags indicating privacy settings. 16 bits are available, + from which a single bit, bit (0), indicating 'retransmission allowed' + is defined by this document. Bits 1-15 are reserved for future use. + + Following the policies outline in [RFC3575], the available bits with + a description of their semantics will be assigned after the Expert + Review process. Updates can be provided based on expert approval + only. Based on expert approval, it is possible to mark entries as + "deprecated". A designated expert will be appointed by the IESG. + + Each registration must include the bit position and the semantics of + the bit. + +8.6. New Registry: Requested-Location-Info Attribute + + Section 4.7 defines the Requested-Location-Info Attribute that + contains a bit map. 32 bits are available, from which 6 bits are + defined by this document. This document creates a new IANA registry + for the Requested-Location-Info Attribute. IANA added the following + values to this registry: + + + + + + + +Tschofenig, et al. Standards Track [Page 39] + +RFC 5580 Carrying LOs in RADIUS and Diameter August 2009 + + + +----------+----------------------+ + | Value | Capability Token | + +----------+----------------------+ + | 1 | CIVIC_LOCATION | + | 2 | GEO_LOCATION | + | 4 | USERS_LOCATION | + | 8 | NAS_LOCATION | + | 16 | FUTURE_REQUESTS | + | 32 | NONE | + +----------+----------------------+ + + The semantics of these values are defined in Section 4.7. + + Following the policies outlined in [RFC3575], new Capability Tokens, + with a description of their semantics for usage with the Requested- + Location-Info Attribute, will be assigned after the Expert Review + process. Updates can be provided based on expert approval only. + Based on expert approval, it is possible to mark entries as + "deprecated". A designated expert will be appointed by the IESG. + + Each registration must include: + + Name: + + Capability Token (i.e., an identifier of the capability) + + Description: + + Brief description indicating the meaning of the 'info' element. + + Numerical Value: + + A numerical value that is placed into the Capability Attribute + representing a bit in the bit-string of the Requested-Location- + Info Attribute. + +9. Acknowledgments + + The authors would like to thank the following people for their help + with an initial version of this document and for their input: Chuck + Black, Paul Congdon, Jouni Korhonen, Sami Ala-luukko, Farooq Bari, Ed + Van Horne, Mark Grayson, Jukka Tuomi, Jorge Cuellar, and Christian + Guenther. + + + + + + + + +Tschofenig, et al. Standards Track [Page 40] + +RFC 5580 Carrying LOs in RADIUS and Diameter August 2009 + + + Henning Schulzrinne provided the civic location information content + found in this document. The geospatial location-information format + is based on work done by James Polk, John Schnizlein, and Marc + Linsner. The authorization policy format is based on the work done + by Jon Peterson. + + The authors would like to thank Victor Lortz, Anthony Leibovitz, Jose + Puthenkulam, Bernrad Aboba, Jari Arkko, Parviz Yegani, Serge Manning, + Kuntal Chowdury, Pasi Eronen, Blair Bullock and Eugene Chang for + their feedback to an initial version of this document. We would like + to thank Jari Arkko for his textual contributions. Lionel Morand + provided detailed feedback on numerous issues. His comments helped + to improve the quality of this document. Jouni Korhonen, Victor + Fajardo, Tolga Asveren, and John Loughney helped us with the Diameter + RADIUS interoperability section. Andreas Pashalidis reviewed a later + version document and provided a number of comments. Alan DeKok, + Lionel Morand, Jouni Korhonen, David Nelson, and Emile van Bergen + provided guidance on the Requested-Location-Info Attribute and + participated in the capability-exchange discussions. Allison Mankin, + Jouni Korhonen, and Pasi Eronen provided text for the Operator + Namespace Identifier registry. Jouni Korhonen interacted with the + GSMA to find a contact person for the TADIG operator namespace, and + Scott Bradner consulted the ITU-T to find a contact person for the + E212 and the ICC operator namespace. + + This document is based on the discussions within the IETF GEOPRIV + Working Group. Therefore, the authors thank Henning Schulzrinne, + James Polk, John Morris, Allison Mankin, Randall Gellens, Andrew + Newton, Ted Hardie, and Jon Peterson for their time discussing a + number of issues with us. We thank Stephen Hayes for aligning this + work with 3GPP activities. + + We would like to thank members of the Wimax Forum Global Roaming + Working Group (GRWG) for their feedback on the Operator-Name + attribute. Ray Jong Kiem helped us with his detailed description to + correct the document. + + The RADEXT Working Group chairs, David Nelson and Bernard Aboba, + provided several draft reviews and we would like to thank them for + the help and their patience. + + Finally, we would like to thank Dan Romascanu, Glen Zorn, Russ + Housley, Jari Arkko, Ralph Droms, Adrial Farrel, Tim Polk, and Lars + Eggert for the IETF Last Call comments; Derek Atkins for his security + area directorate review; and Yoshiko Chong for spotting a bug in the + IANA Considerations section. + + + + + +Tschofenig, et al. Standards Track [Page 41] + +RFC 5580 Carrying LOs in RADIUS and Diameter August 2009 + + +10. References + +10.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, + "Remote Authentication Dial In User Service (RADIUS)", + RFC 2865, June 2000. + + [RFC3492] Costello, A., "Punycode: A Bootstring encoding of + Unicode for Internationalized Domain Names in + Applications (IDNA)", RFC 3492, March 2003. + + [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote + Authentication Dial In User Service)", RFC 3575, + July 2003. + + [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and + J. Arkko, "Diameter Base Protocol", RFC 3588, + September 2003. + + [RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host + Configuration Protocol Option for Coordinate-based + Location Configuration Information", RFC 3825, + July 2004. + + [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol + (DHCPv4 and DHCPv6) Option for Civic Addresses + Configuration Information", RFC 4776, November 2006. + + [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. + Aboba, "Dynamic Authorization Extensions to Remote + Authentication Dial In User Service (RADIUS)", + RFC 5176, January 2008. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing + an IANA Considerations Section in RFCs", BCP 26, + RFC 5226, May 2008. + +10.2. Informative References + + [GEO-POLICY] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, + J., and J. Polk, "Geolocation Policy: A Document Format + for Expressing Privacy Preferences for Location + Information", Work in Progress, February 2009. + + + + +Tschofenig, et al. Standards Track [Page 42] + +RFC 5580 Carrying LOs in RADIUS and Diameter August 2009 + + + [GMLv3] "Open Geography Markup Language (GML) Implementation + Specification", OGC 02-023r4, January 2003, + <http://www.opengis.org/techno/implementation.htm>. + + [GSM] "TADIG Naming Conventions", Version 4.1, GSM + Association Official Document TD.13, June 2006. + + [ISO] "Codes for the representation of names of countries and + their subdivisions - Part 1: Country codes", + ISO 3166-1, 1997. + + [ITU1400] "Designations for interconnections among operators' + networks", ITU-T Recommendation M.1400, January 2004. + + [ITU212] "The international identification plan for mobile + terminals and mobile users", ITU-T + Recommendation E.212, May 2004. + + [PEAP] Josefsson, S., Palekar, A., Simon, D., and G. Zorn, + "Protected EAP Protocol (PEAP) Version 2", Work + in Progress, October 2004. + + [RFC1305] Mills, D., "Network Time Protocol (Version 3) + Specification, Implementation", RFC 1305, March 1992. + + [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication + Protocol (CHAP)", RFC 1994, August 1996. + + [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. + + [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote + Authentication Dial In User Service) Support For + Extensible Authentication Protocol (EAP)", RFC 3579, + September 2003. + + [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., + and J. Polk, "Geopriv Requirements", RFC 3693, + February 2004. + + [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, + "Diameter Network Access Server Application", RFC 4005, + August 2005. + + [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible + Authentication Protocol (EAP) Method Requirements for + Wireless LANs", RFC 4017, March 2005. + + + + + +Tschofenig, et al. Standards Track [Page 43] + +RFC 5580 Carrying LOs in RADIUS and Diameter August 2009 + + + [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter + Extensible Authentication Protocol (EAP) Application", + RFC 4072, August 2005. + + [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object + Format", RFC 4119, December 2005. + + [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication + Protocol Method for 3rd Generation Authentication and + Key Agreement (EAP-AKA)", RFC 4187, January 2006. + + [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The + Network Access Identifier", RFC 4282, December 2005. + + [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", + RFC 4306, December 2005. + + [RFC4372] Adrangi, F., Lior, A., Korhonen, J., and J. Loughney, + "Chargeable User Identity", RFC 4372, January 2006. + + [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, + J., Polk, J., and J. Rosenberg, "Common Policy: A + Document Format for Expressing Privacy Preferences", + RFC 4745, February 2007. + + [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) + Configuration Access Protocol (XCAP)", RFC 4825, + May 2007. + + [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy + Extensions for Stateless Address Autoconfiguration in + IPv6", RFC 4941, September 2007. + + [RFC5106] Tschofenig, H., Kroeselberg, D., Pashalidis, A., Ohba, + Y., and F. Bersani, "The Extensible Authentication + Protocol-Internet Key Exchange Protocol version 2 (EAP- + IKEv2) Method", RFC 5106, February 2008. + + [RFC5281] Funk, P. and S. Blake-Wilson, "Extensible + Authentication Protocol Tunneled Transport Layer + Security Authenticated Protocol Version 0 (EAP- + TTLSv0)", RFC 5281, August 2008. + + + + + + + + + +Tschofenig, et al. Standards Track [Page 44] + +RFC 5580 Carrying LOs in RADIUS and Diameter August 2009 + + +Appendix A. Matching with GEOPRIV Requirements + + This section compares the requirements for a GEOPRIV using protocol, + described in [RFC3693], against the approach of distributing Location + Objects with RADIUS. + + In Appendices A.1 and A.2, we discuss privacy implications when + RADIUS entities make location information available to other parties. + In Appendix A.3, the requirements are matched against these two + scenarios. + +A.1. Distribution of Location Information at the User's Home Network + + When location information is conveyed from the RADIUS client to the + RADIUS server, then it might subsequently be made available for + different purposes. This section discusses the privacy implications + for making location information available to other entities. + + To use a more generic scenario, we assume that the visited RADIUS and + the home RADIUS server belong to different administrative domains. + The Location Recipient obtains location information about a + particular Target via protocols specified outside the scope of this + document (e.g., SIP, HTTP, or an API). + + The subsequent figure shows the interacting entities graphically. + + visited network | home network + | + | +----------+ + | | Rule | + | | Holder | + | +----+-----+ + | | + | rule|interface + +----------+ | V +----------+ + |Location | | +----------+ notification |Location | + |Generator | | |Location |<------------->|Recipient | + +----------+ publication |Server | interface | | + |RADIUS |<------------->+----------+ +----------+ + |Client | interface |RADIUS | E.g., SIP/HTTP + +----------+ | |Server | + | +----------+ + E.g., NAS RADIUS + | + | + + Figure 8: Location Server at the Home Network + + + + +Tschofenig, et al. Standards Track [Page 45] + +RFC 5580 Carrying LOs in RADIUS and Diameter August 2009 + + + The term 'Rule Holder' in Figure 8 denotes the entity that creates + the authorization ruleset. + +A.2. Distribution of Location Information at the Visited Network + + This section describes a scenario where location information is made + available to Location Recipients by a Location Server in the visited + network. Some identifier needs to be used as an index within the + location database. One possible identifier is the Network Access + Identifier. RFC 4282 [RFC4282] and RFC 4372 [RFC4372] provide + background regarding whether entities in the visited network can + obtain the user's NAI in cleartext. + + The visited network provides location information to a Location + Recipient (e.g., via SIP or HTTP). This document enables the NAS to + obtain the user's privacy policy via the interaction with the RADIUS + server. Otherwise, only default policies, which are very + restrictive, are available. This allows the Location Server in the + visited network to ensure they act according to the user's policies. + + The subsequent figure shows the interacting entities graphically. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Tschofenig, et al. Standards Track [Page 46] + +RFC 5580 Carrying LOs in RADIUS and Diameter August 2009 + + + visited network | home network + | + +----------+ | + |Location | | + |Recipient | | + | | | + +----------+ | + ^ | +----------+ + | | | Rule | + notification | | Holder | + interface | | | + | | +----+-----+ + | | | + | | rule|interface + v | | + +----------+ | | + |Location | | v + |Server | | +----------+ + +----------+ Rule Transport|RADIUS | + |RADIUS |<------------->|Server | + |Client | RADIUS +----------+ + +----------+ | + |Location | | + |Generator | + +----------+ + + Figure 9: Location Server at the Visited Network + + Location information always travels with privacy policies. This + document enables the RADIUS client to obtain these policies. The + Location Server can subsequently act according to these policies to + provide access control using the Extended-Location-Policy-Rules and + to adhere to the privacy statements in the Basic-Location-Policy- + Rules. + +A.3. Requirements Matching + + Section 7.1 of [RFC3693] details the requirements of a "Location + Object". We discuss these requirements in the subsequent list. + + Req. 1. (Location Object generalities): + + * Regarding requirement 1.1, the syntax and semantics of the + Location Object are taken from [RFC3825] and [RFC4776]. It is + furthermore possible to convert it to the format used in the + Geography Markup Language (GMLv3) [GMLv3], as used with PIDF-LO + [RFC4119]. + + + + +Tschofenig, et al. Standards Track [Page 47] + +RFC 5580 Carrying LOs in RADIUS and Diameter August 2009 + + + * Regarding requirement 1.2, a number of fields in the civic + location-information format are optional. + + * Regarding requirement 1.3, the inclusion of type of place item + (CAtype 29) used in the DHCP civic format gives a further + classification of the location. This attribute can be seen as + an extension. + + * Regarding requirement 1.4, this document does not define the + format of the location information. + + * Regarding requirement 1.5, location information is only sent + from the RADIUS client to the RADIUS server. + + * Regarding requirement 1.6, the Location Object contains both + location information and privacy rules. Location information + is described in Sections 4.2, 4.3.1, and 4.3.2. The + corresponding privacy rules are detailed in Sections 4.4 and + 4.5. + + * Regarding requirement 1.7, the Location Object is usable in a + variety of protocols. The format of the object is reused from + other documents, as detailed in Sections 4.2, 4.3.1, 4.3.2, + 4.4, and 4.5. + + * Regarding requirement 1.8, the encoding of the Location Object + has an emphasis on a lightweight encoding format to be used + with RADIUS. + + Req. 2. (Location Object fields): + + * Regarding requirement 2.1, the target identifier is carried + within the network-access authentication protocol (e.g., within + the EAP-Identity Response when EAP is used and/or within the + EAP method itself). As described in Section 7.2 of this + document, it has a number of advantages if this identifier is + not carried in clear. This is possible with certain EAP + methods whereby the identity in the EAP-Identity Response only + contains information relevant for routing the response to the + user's home network. The user identity is protected by the + authentication and key exchange protocol. + + * Regarding requirement 2.2, the Location Recipient is, in the + main scenario, the home RADIUS server. For a scenario where + the Location Recipient is obtaining location information from + the Location Server via HTTP or SIP, the respective mechanisms + + + + + +Tschofenig, et al. Standards Track [Page 48] + +RFC 5580 Carrying LOs in RADIUS and Diameter August 2009 + + + defined in these protocols are used to identify the recipient. + The Location Generator cannot, a priori, know the recipients if + they are not defined in this protocol. + + * Regarding requirement 2.3, the credentials of the Location + Recipient are known to the RADIUS entities based on the + security mechanisms defined in the RADIUS protocol itself. + Section 7 of this document describes these security mechanisms + offered by the RADIUS protocol. The same is true for + requirement 2.4. + + * Regarding requirement 2.5, Sections 4.2, 4.3.1, and 4.3.2 + describe the content of the Location fields. Since the + location format itself is not defined in this document, motion + and direction vectors as listed in requirement 2.6 are not + defined. + + * Regarding requirement 2.6, this document provides the + capability for the RADIUS server to indicate what type of + location information it would like to see from the RADIUS + client. + + * Regarding requirement 2.7, timing information is provided with + the 'Sighting Time' and 'Time-to-Live' fields defined in + Section 4.2. + + * Regarding requirement 2.8, a reference to an external (more + detailed ruleset) is provided with the Extended-Location- + Policy-Rules Attribute in Section 4.5. + + * Regarding requirement 2.9, security headers and trailers are + provided as part of the RADIUS protocol or even as part of + IPsec. + + * Regarding requirement 2.10, a version number in RADIUS is + provided with the IANA registration of the attributes. New + attributes are assigned a new IANA number. + + Req. 3. (Location Data Types): + + * Regarding requirement 3.1, this document reuses civic and + geospatial location information as described in Sections 4.3.2 + and 4.3.1. + + * With the support of civic and geospatial location information, + support of requirement 3.2 is fulfilled. + + + + + +Tschofenig, et al. Standards Track [Page 49] + +RFC 5580 Carrying LOs in RADIUS and Diameter August 2009 + + + * Regarding requirement 3.3, the geospatial location information + used by this document only refers to absolute coordinates. + However, the granularity of the location information can be + reduced with the help of the AltRes, LoRes, and LaRes fields + described in [RFC3825]. + + * Regarding requirement 3.4, further Location Data Types can be + added via new coordinate reference systems (CRSs -- see the + Datum field in [RFC3825]) and via extensions to [RFC3825] and + [RFC4776]. + + Section 7.2 of [RFC3693] details the requirements of a "using + protocol". These requirements are listed below. + + Req. 4.: The using protocol has to obey the privacy and security + instructions coded in the Location Object (LO) regarding the + transmission and storage of the LO. This document requires that + entities that aim to make location information available to third + parties be required to obey the privacy instructions. + + Req. 5.: The using protocol will typically facilitate that the keys + associated with the credentials are transported to the respective + parties, that is, key establishment is the responsibility of the + using protocol. Section 7 of this document specifies how security + mechanisms are used in RADIUS and how they can be reused to + provide security protection for the Location Object. + Additionally, the privacy considerations (see Section 7.2) are + also relevant for this requirement. + + Req. 6. (Single Message Transfer): In particular, for tracking of + small target devices, the design should allow a single message/ + packet transmission of location as a complete transaction. The + encoding of the Location Object is specifically tailored towards + the inclusion into a single message that even respects the (Path) + MTU size. + + Section 7.3 of [RFC3693] details the requirements of a "Rule-based + Location Data Transfer". These requirements are listed below. + + Req. 7. (LS Rules): With the scenario shown in Figure 8, the + decision of a Location Server to provide a Location Recipient + access to location information is based on Rule Maker-defined + privacy rules that are stored at the home network. With regard to + the scenario shown in Figure 9, the Rule Maker-defined privacy + rules are sent from the RADIUS server to the NAS (see Sections + 4.4, 4.5, and 7.2 for more details). + + + + + +Tschofenig, et al. Standards Track [Page 50] + +RFC 5580 Carrying LOs in RADIUS and Diameter August 2009 + + + Req. 8. (LG Rules): For all usage scenarios, it is possible to + consider the privacy rule before transmitting location information + from the NAS to the RADIUS server or even to third parties. In + the case of an out-of-band agreement between the owner of the NAS + and the owner of the RADIUS server, privacy might be applied on a + higher granularity. For the scenario shown in Figure 8, the + visited network is already in possession of the user's location + information prior to the authentication and authorization of the + user. A correlation between the location and the user identity + might, however, still not be possible for the visited network (as + explained in Section 7.2). A Location Server in the visited + network has to evaluate available rulesets. + + Req. 9. (Viewer Rules): The Rule Maker might define (via mechanisms + outside the scope of this document) which policy rules are + disclosed to other entities. + + Req. 10. (Full Rule language): GEOPRIV has defined a rule language + capable of expressing a wide range of privacy rules that is + applicable in the area of the distribution of Location Objects. A + basic ruleset is provided with the Basic-Location-Policy-Rules + Attribute (Section 4.4). A reference to the extended ruleset is + carried in Section 4.5. The format of these rules is described in + [RFC4745] and [GEO-POLICY]. + + Req. 11. (Limited Rule language): A limited (or basic) ruleset is + provided by the Policy-Information Attribute in Section 4.4 (and + as introduced with PIDF-LO [RFC4119]). + + Section 7.4 of [RFC3693] details the requirements of a "Location + Object Privacy and Security". These requirements are listed below. + + Req. 12 (Identity Protection): Support for unlinkable pseudonyms is + provided by the usage of a corresponding authentication and key- + exchange protocol. Such protocols are available, for example, + with the support of EAP as network-access authentication methods. + Some EAP methods support passive user-identity confidentiality, + whereas others even support active user-identity confidentiality. + This issue is further discussed in Section 7. The importance for + user-identity confidentiality and identity protection has already + been recognized as an important property (see, for example, a + document on EAP method requirements for wireless LANs [RFC4017]). + + Req. 13. (Credential Requirements): As described in Section 7 , + RADIUS signaling messages can be protected with IPsec. This + allows a number of authentication and key exchange protocols to be + used as part of IKE, IKEv2, or KINK. + + + + +Tschofenig, et al. Standards Track [Page 51] + +RFC 5580 Carrying LOs in RADIUS and Diameter August 2009 + + + Req. 14. (Security Features): GEOPRIV defines a few security + requirements for the protection of Location Objects, such as + mutual end-point authentication, data object integrity, data + object confidentiality, and replay protection. As described in + Section 7, these requirements are fulfilled with the usage of + IPsec if mutual authentication refers to the RADIUS entities + (acting as various GEOPRIV entities) that directly communicate + with each other. + + Req. 15. (Minimal Crypto): A minimum of security mechanisms are + mandated by the usage of RADIUS. Communication security for + Location Objects between RADIUS infrastructure elements is + provided by the RADIUS protocol (including IPsec and its dynamic + key-management framework), rather than relying on object security + via S/SIME (which is not available with RADIUS). + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Tschofenig, et al. Standards Track [Page 52] + +RFC 5580 Carrying LOs in RADIUS and Diameter August 2009 + + +Authors' Addresses + + Hannes Tschofenig (editor) + Nokia Siemens Networks + Linnoitustie 6 + Espoo 02600 + Finland + + Phone: +358 (50) 4871445 + EMail: Hannes.Tschofenig@gmx.net + URI: http://www.tschofenig.priv.at + + + Farid Adrangi + Intel Corporatation + 2111 N.E. 25th Avenue + Hillsboro OR + USA + + EMail: farid.adrangi@intel.com + + + Mark Jones + Bridgewater Systems Corporation + 303 Terry Fox Drive + Ottawa, Ontario K2K 3J1 + CANADA + + EMail: mark.jones@bridgewatersystems.com + + + Avi Lior + Bridgewater Systems Corporation + 303 Terry Fox Drive + Ottawa, Ontario K2K 3J1 + CANADA + + EMail: avi@bridgewatersystems.com + + + Bernard Aboba + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052 + USA + + EMail: bernarda@microsoft.com + + + + +Tschofenig, et al. Standards Track [Page 53] + |