7 Network Working Group H. Tschofenig, Ed.
8 Request for Comments: 5580 Nokia Siemens Networks
9 Category: Standards Track F. Adrangi
19 Carrying Location Objects in RADIUS and Diameter
23 This document describes procedures for conveying access-network
24 ownership and location information based on civic and geospatial
25 location formats in Remote Authentication Dial-In User Service
26 (RADIUS) and Diameter.
28 The distribution of location information is a privacy-sensitive task.
29 Dealing with mechanisms to preserve the user's privacy is important
30 and is addressed in this document.
34 This document specifies an Internet standards track protocol for the
35 Internet community, and requests discussion and suggestions for
36 improvements. Please refer to the current edition of the "Internet
37 Official Protocol Standards" (STD 1) for the standardization state
38 and status of this protocol. Distribution of this memo is unlimited.
42 Copyright (c) 2009 IETF Trust and the persons identified as the
43 document authors. All rights reserved.
45 This document is subject to BCP 78 and the IETF Trust's Legal
46 Provisions Relating to IETF Documents in effect on the date of
47 publication of this document (http://trustee.ietf.org/license-info).
48 Please review these documents carefully, as they describe your rights
49 and restrictions with respect to this document.
58 Tschofenig, et al. Standards Track [Page 1]
60 RFC 5580 Carrying LOs in RADIUS and Diameter August 2009
65 1. Introduction ....................................................3
66 2. Terminology .....................................................3
67 3. Delivery Methods for Location Information .......................3
68 3.1. Location Delivery Based on Out-of-Band Agreements ..........4
69 3.2. Location Delivery Based on Initial Request .................5
70 3.3. Location Delivery Based on Mid-Session Request .............6
71 3.4. Location Delivery in Accounting Messages ..................10
72 4. Attributes .....................................................11
73 4.1. Operator-Name Attribute ...................................12
74 4.2. Location-Information Attribute ............................14
75 4.3. Location-Data Attribute ...................................16
76 4.3.1. Civic Location Profile .............................17
77 4.3.2. Geospatial Location Profile ........................17
78 4.4. Basic-Location-Policy-Rules Attribute .....................18
79 4.5. Extended-Location-Policy-Rules Attribute ..................20
80 4.6. Location-Capable Attribute ................................21
81 4.7. Requested-Location-Info Attribute .........................23
82 5. Table of Attributes ............................................28
83 6. Diameter RADIUS Interoperability ...............................30
84 7. Security Considerations ........................................31
85 7.1. Communication Security ....................................31
86 7.2. Privacy Considerations ....................................32
87 7.2.1. RADIUS Client ......................................33
88 7.2.2. RADIUS Server ......................................34
89 7.2.3. RADIUS Proxy .......................................34
90 7.3. Identity Information and Location Information .............34
91 8. IANA Considerations ............................................36
92 8.1. New Registry: Operator Namespace Identifier ...............36
93 8.2. New Registry: Location Profiles ...........................37
94 8.3. New Registry: Location-Capable Attribute ..................38
95 8.4. New Registry: Entity Types ................................39
96 8.5. New Registry: Privacy Flags ...............................39
97 8.6. New Registry: Requested-Location-Info Attribute ...........39
98 9. Acknowledgments ................................................40
99 10. References ....................................................42
100 10.1. Normative References .....................................42
101 10.2. Informative References ...................................42
102 Appendix A. Matching with GEOPRIV Requirements ...................45
103 A.1. Distribution of Location Information at the User's
104 Home Network ..............................................45
105 A.2. Distribution of Location Information at the Visited
106 Network ...................................................46
107 A.3. Requirements Matching .....................................47
114 Tschofenig, et al. Standards Track [Page 2]
116 RFC 5580 Carrying LOs in RADIUS and Diameter August 2009
121 This document defines attributes within RADIUS and Diameter that can
122 be used to convey location-related information within authentication
123 and accounting exchanges.
125 Location information may be useful in a number of scenarios.
126 Wireless networks (including wireless LAN) are being deployed in
127 public places such as airports, hotels, shopping malls, and coffee
128 shops by a diverse set of operators such as cellular network
129 operators, Wireless Internet Service Providers (WISPs), and fixed
130 broadband operators. In these situations, the home network may need
131 to know the location of the user in order to enable location-aware
132 billing, location-aware authorization, or other location-aware
133 services. Location information can also prove useful in other
134 situations (such as wired networks) where operator-network ownership
135 and location information may be needed by the home network.
137 In order to preserve user privacy, location information needs to be
138 protected against unauthorized access and distribution. Requirements
139 for access to location information are defined in [RFC3693]. The
140 model includes a Location Generator (LG) that creates location
141 information, a Location Server (LS) that authorizes access to
142 location information, a Location Recipient (LR) that requests and
143 receives information, and a Rule Maker (RM) that provides
144 authorization policies to the LS, which enforces access-control
145 policies on requests to location information. In Appendix A, the
146 requirements for a GEOPRIV using protocol [RFC3693] are compared to
147 the functionality provided by this document.
151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
153 document are to be interpreted as described in [RFC2119].
155 RADIUS-specific terminology is borrowed from [RFC2865] and [RFC2866].
157 Terminology related to privacy issues, location information, and
158 authorization policy rules is taken from [RFC3693].
160 3. Delivery Methods for Location Information
162 The following exchanges show how location information is conveyed in
163 RADIUS. In describing the usage scenarios, we assume that privacy
164 policies allow location to be conveyed in RADIUS; however, as noted
165 in Section 6, similar exchanges can also take place within Diameter.
166 Privacy issues are discussed in Section 7.2.
170 Tschofenig, et al. Standards Track [Page 3]
172 RFC 5580 Carrying LOs in RADIUS and Diameter August 2009
175 3.1. Location Delivery Based on Out-of-Band Agreements
177 Figure 1 shows an example message flow for delivering location
178 information during the network-access authentication and
179 authorization procedure. Upon a network-authentication request from
180 an access-network client, the Network Access Server (NAS) submits a
181 RADIUS Access-Request message that contains Location-Information
182 Attributes among other required attributes. In this scenario,
183 location information is attached to the Access-Request message
184 without an explicit request from the RADIUS server. Note that such
185 an approach with a prior agreement between the RADIUS client and the
186 RADIUS server is only applicable in certain environments, such as in
187 situations where the RADIUS client and server are within the same
188 administrative domain. The Basic-Location-Policy-Rules Attribute is
189 populated based on the defaults described in Section 4.4, unless it
190 has been explicitly configured otherwise.
192 +---------+ +---------+ +---------+
193 | | | Network | | RADIUS |
194 | User | | Access | | Server |
196 +---------+ +---------+ +---------+
198 | Authentication phase | |
200 |---------------------->| |
203 | | + Location-Information |
204 | | + Location-Data |
205 | | + Basic-Location-Policy-Rules|
206 | | + Operator-Name |
207 | |----------------------------->|
210 | |<-----------------------------|
213 |<----------------------| |
216 Figure 1: Location Delivery Based on Out-of-Band Agreements
226 Tschofenig, et al. Standards Track [Page 4]
228 RFC 5580 Carrying LOs in RADIUS and Diameter August 2009
231 3.2. Location Delivery Based on Initial Request
233 If the RADIUS client provides a Location-Capable Attribute in the
234 Access-Request, then the RADIUS server MAY request location
235 information from the RADIUS client if it requires that information
236 for authorization and if location information was not provided in the
237 Access-Request. This exchange is shown in Figure 2. The inclusion
238 of the Location-Capable Attribute in an Access-Request message
239 indicates that the NAS is capable of providing location data in
240 response to an Access-Challenge. The subsequent Access-Challenge
241 message sent from the RADIUS server to the NAS provides a hint
242 regarding the type of desired Location-Information Attributes. The
243 NAS treats the Basic-Location-Policy-Rules and Extended-Location-
244 Policy-Rules Attributes as opaque data (e.g., it echoes these rules
245 provided by the server within the Access-Challenge back in the
246 Access-Request). In the shown message flow, the location attributes
247 are then provided in the subsequent Access-Request message. When
248 evaluating this Access-Request message, the authorization procedure
249 at the RADIUS server might be based on a number of criteria,
250 including the newly defined attributes listed in Section 4.
282 Tschofenig, et al. Standards Track [Page 5]
284 RFC 5580 Carrying LOs in RADIUS and Diameter August 2009
287 +---------+ +---------+ +---------+
288 | | | Network | | RADIUS |
289 | User | | Access | | Server |
291 +---------+ +---------+ +---------+
293 | Authentication phase | |
295 |---------------------->| |
298 | | + Location-Capable |
299 | |--------------------------------->|
301 | | Access-Challenge |
302 | | + Basic-Location-Policy-Rules |
303 | | + Extended-Location-Policy-Rules|
304 | | + Requested-Location-Info |
305 | |<---------------------------------|
308 | | + Location-Information |
309 | | + Location-Data |
310 | | + Basic-Location-Policy-Rules |
311 | | + Extended-Location-Policy-Rules|
312 | |--------------------------------->|
315 : Multiple Protocol Exchanges to perform :
316 : Authentication, Key Exchange, and Authorization :
321 | |<---------------------------------|
324 |<----------------------| |
327 Figure 2: Location Delivery Based on Initial Request
329 3.3. Location Delivery Based on Mid-Session Request
331 The on-demand, mid-session location-delivery method utilizes the
332 Change-of-Authorization Request (CoA-Request) message and the CoA-NAK
333 (CoA-Negative Acknowledgement), defined in [RFC5176]. At any time
338 Tschofenig, et al. Standards Track [Page 6]
340 RFC 5580 Carrying LOs in RADIUS and Diameter August 2009
343 during the session, the Dynamic Authorization Client MAY send a CoA-
344 Request containing session-identification attributes to the NAS
345 (i.e., Dynamic Authorization Server).
347 In order to enable the on-demand, mid-session location-delivery
348 method, the RADIUS server MUST return an instance of the Requested-
349 Location-Info Attribute with the 'FUTURE_REQUESTS' flag set and
350 instances of the Basic-Location-Policy-Rules and Extended-Location-
351 Policy-Rules Attributes in the Access-Accept message for the session.
352 Upon receipt of a CoA-Request message containing a Service-Type
353 Attribute with value "Authorize Only" for the same session, the NAS
354 MUST include location information and echo the previously received
355 Basic-Location-Policy-Rules and Extended-Location-Policy-Rules
356 Attributes in the subsequent Access-Request message.
358 Upon receiving the Access-Request message containing the Service-Type
359 Attribute with a value of Authorize-Only from the NAS, the RADIUS
360 server responds with either an Access-Accept or an Access-Reject
363 The use of dynamic authorization [RFC5176] is necessary when location
364 information is needed on-demand and cannot be obtained from
365 accounting information in a timely fashion.
367 Figure 3 shows the above-described approach graphically.
369 +---------------+ +---------------+ +------+
370 | Dynamic | | Dynamic | |RADIUS|
371 | Authorization | | Authorization | |Server|
372 | Server/NAS | | Client | | |
373 +---------------+ +---------------+ +------+
376 | + Location-Capable | |
377 |----------------------------------------------------------->|
379 | Access-Challenge | |
380 | + Basic-Location-Policy-Rules | |
381 | + Extended-Location-Policy-Rules | |
382 | + Requested-Location-Info | |
383 |<-----------------------------------------------------------|
386 | + Location-Information | |
387 | + Location-Data | |
388 | + Basic-Location-Policy-Rules | |
389 | + Extended-Location-Policy-Rules | |
390 |----------------------------------------------------------->|
394 Tschofenig, et al. Standards Track [Page 7]
396 RFC 5580 Carrying LOs in RADIUS and Diameter August 2009
402 : Multiple Protocol Exchanges to perform :
403 : Authentication, Key Exchange, and Authorization :
404 : ...continued... | :
409 | + Requested-Location-Info | |
410 (FUTURE_REQUESTS,...) | |
411 | + Basic-Location-Policy-Rules | |
412 | + Extended-Location-Policy-Rules | |
413 |<-----------------------------------------------------------|
416 : <<Some time later>> : :
419 | CoA + Service-Type "Authorize Only" + State | |
420 |<--------------------------------------------| |
422 | CoA NAK + Service-Type "Authorize Only" | |
424 | + Error-Cause "Request Initiated" | |
425 |-------------------------------------------->| |
428 | + Service-Type "Authorize Only" | |
430 | + Location-Information | |
431 | + Location-Data | |
432 | + Basic-Location-Policy-Rules | |
433 | + Extended-Location-Policy-Rules | |
434 |----------------------------------------------------------->|
436 |<-----------------------------------------------------------|
439 Figure 3: Location Delivery Based on CoA with
440 Service-Type 'Authorize Only'
442 When the Dynamic Authorization Client wants to change the values of
443 the requested location information, or set the values of the
444 requested location information for the first time, it may do so
445 without triggering a reauthorization. Assuming that the NAS had
446 previously sent an Access-Request containing a Location-Capable
450 Tschofenig, et al. Standards Track [Page 8]
452 RFC 5580 Carrying LOs in RADIUS and Diameter August 2009
455 Attribute, the Dynamic Authorization Client (DAC) can send a CoA-
456 Request to the NAS without a Service-Type Attribute, but include the
457 NAS identifiers and session identifiers as per [RFC5176] and the
458 Requested-Location-Info, Basic-Location-Policy-Rules, and Extended-
459 Location-Policy-Rules Attributes. The Requested-Location-Info,
460 Basic-Location-Policy-Rules, and Extended-Location-Policy-Rules
461 Attributes MUST NOT be used for session identification.
463 Figure 4 shows this approach graphically.
465 +---------------+ +---------------+ +------+
466 | Dynamic | | Dynamic | |RADIUS|
467 | Authorization | | Authorization | |Server|
468 | Server/NAS | | Client | | |
469 +---------------+ +---------------+ +------+
473 | + Location-Capable | |
474 |----------------------------------------------------------->|
476 | Access-Challenge | |
477 | + Basic-Location-Policy-Rules | |
478 | + Extended-Location-Policy-Rules | |
479 | + Requested-Location-Info | |
480 |<-----------------------------------------------------------|
483 | + Location-Information | |
484 | + Location-Data | |
485 | + Basic-Location-Policy-Rules | |
486 | + Extended-Location-Policy-Rules | |
487 |----------------------------------------------------------->|
491 : Multiple Protocol Exchanges to perform :
492 : Authentication, Key Exchange, and Authorization :
493 : ...continued... | :
498 | + Requested-Location-Info | |
499 | + Basic-Location-Policy-Rules | |
500 | + Extended-Location-Policy-Rules | |
501 |<-----------------------------------------------------------|
506 Tschofenig, et al. Standards Track [Page 9]
508 RFC 5580 Carrying LOs in RADIUS and Diameter August 2009
513 : <<Some time later>> : :
517 | + Requested-Location-Info | |
518 | + Basic-Location-Policy-Rules | |
519 | + Extended-Location-Policy-Rules | |
520 |<--------------------------------------------| |
523 |-------------------------------------------->| |
526 : <<Further exchanges later>> : :
529 Figure 4: Location Delivery Based on CoA
531 3.4. Location Delivery in Accounting Messages
533 Location information may also be reported in accounting messages.
534 Accounting messages are generated when the session starts, when the
535 session stops, and periodically during the lifetime of the session.
536 Accounting messages may also be generated when the user roams during
539 Accounting information may be needed by the billing system to
540 calculate the user's bill. For example, there may be different
541 tariffs or tax rates applied based on the location.
543 If the RADIUS server needs to obtain location information in
544 accounting messages, then it needs to include a Requested-Location-
545 Info Attribute with the Access-Accept message. The Basic-Location-
546 Policy-Rules and the Extended-Location-Policy-Rules Attributes are to
547 be echoed in the Accounting-Request if indicated in the Access-
550 Figure 5 shows the message exchange.
562 Tschofenig, et al. Standards Track [Page 10]
564 RFC 5580 Carrying LOs in RADIUS and Diameter August 2009
567 +---------+ +---------+ +---------+
568 | | | Network | | RADIUS |
569 | User | | Access | | Server |
571 +---------+ +---------+ +---------+
574 : Initial Protocol Interaction :
575 : (details omitted) :
579 | | + Requested-Location-Info |
580 | | + Basic-Location-Policy-Rules |
581 | | + Extended-Location-Policy-Rules|
582 | |<---------------------------------|
585 |<----------------------| |
587 | | Accounting-Request |
588 | | + Location-Information |
589 | | + Location-Data |
590 | | + Basic-Location-Policy-Rules |
591 | | + Extended-Location-Policy-Rules|
592 | |--------------------------------->|
594 | | Accounting-Response |
595 | |<---------------------------------|
598 Figure 5: Location Delivery in Accounting Messages
602 It is important to note that the location-specific parts of the
603 attributes defined below are not meant to be processed by the RADIUS
604 server. Instead, a location-server-specific component used in
605 combination with the RADIUS server is responsible for receiving,
606 processing, and further distributing location information (in
607 combination with proper access control and privacy protection). As
608 such, from a RADIUS server point of view, location information is
609 treated as opaque data.
618 Tschofenig, et al. Standards Track [Page 11]
620 RFC 5580 Carrying LOs in RADIUS and Diameter August 2009
623 4.1. Operator-Name Attribute
625 This attribute carries the operator namespace identifier and the
626 operator name. The operator name is combined with the namespace
627 identifier to uniquely identify the owner of an access network. The
628 value of the Operator-Name is a non-NULL terminated text whose length
629 MUST NOT exceed 253 bytes.
631 The Operator-Name Attribute SHOULD be sent in Access-Request and
632 Accounting-Request messages where the Acc-Status-Type is set to
633 Start, Interim, or Stop.
635 A summary of the Operator-Name Attribute is shown below.
638 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
639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
640 | Type | Length | Text ...
641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
655 The format is shown below. The data type of this field is a text.
656 All fields are transmitted from left to right:
659 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
660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
661 | Namespace ID | Operator-Name ...
662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
674 Tschofenig, et al. Standards Track [Page 12]
676 RFC 5580 Carrying LOs in RADIUS and Diameter August 2009
681 The value within this field contains the operator namespace
682 identifier. The Namespace ID value is encoded in ASCII.
684 Example: '1' (0x31) for REALM
688 The text field of variable length contains an Access Network
689 Operator Name. This field is a RADIUS-based data type of Text.
691 The Namespace ID field provides information about the operator
692 namespace. This document defines four values for this attribute,
693 which are listed below. Additional namespace identifiers must be
694 registered with IANA (see Section 8.1) and must be associated with an
695 organization responsible for managing the namespace.
699 This namespace can be used to indicate operator names based on
700 Transferred Account Data Interchange Group (TADIG) codes, as
701 defined in [GSM]. TADIG codes are assigned by the TADIG Working
702 Group within the Global System for Mobile Communications (GSM)
703 Association. The TADIG code consists of two fields, with a total
704 length of five ASCII characters consisting of a three-character
705 country code and a two-character alphanumeric operator (or
710 The REALM operator namespace can be used to indicate operator
711 names based on any registered domain name. Such names are
712 required to be unique, and the rights to use a given realm name
713 are obtained coincident with acquiring the rights to use a
714 particular Fully Qualified Domain Name (FQDN). Since this
715 operator is limited to ASCII, any registered domain name that
716 contains non-ASCII characters must be converted to ASCII. The
717 Punycode encoding [RFC3492] is used for this purpose.
721 The E212 namespace can be used to indicate operator names based on
722 the Mobile Country Code (MCC) and Mobile Network Code (MNC)
723 defined in [ITU212]. The MCC/MNC values are assigned by the
724 Telecommunications Standardization Bureau (TSB) within the ITU-T
730 Tschofenig, et al. Standards Track [Page 13]
732 RFC 5580 Carrying LOs in RADIUS and Diameter August 2009
735 and by designated administrators in different countries. The E212
736 value consists of three ASCII digits containing the MCC, followed
737 by two or three ASCII digits containing the MNC.
741 The ICC namespace can be used to indicate operator names based on
742 International Telecommunication Union (ITU) Carrier Codes (ICC)
743 defined in [ITU1400]. ICC values are assigned by national
744 regulatory authorities and are coordinated by the
745 Telecommunication Standardization Bureau (TSB) within the ITU
746 Telecommunication Standardization Sector (ITU-T). When using the
747 ICC namespace, the attribute consists of three uppercase ASCII
748 characters containing a three-letter alphabetic country code, as
749 defined in [ISO], followed by one to six uppercase alphanumeric
750 ASCII characters containing the ICC itself.
752 4.2. Location-Information Attribute
754 The Location-Information Attribute MAY be sent in the Access-Request
755 message, the Accounting-Request message, both of these messages, or
756 no message. For the Accounting-Request message, the Acc-Status-Type
757 may be set to Start, Interim, or Stop.
759 The Location-Information Attribute provides meta-data about the
760 location information, such as sighting time, time-to-live, location-
761 determination method, etc.
763 The format is shown below.
766 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
767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
768 | Type | Length | String ...
769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
775 127 - Location-Information
786 Tschofenig, et al. Standards Track [Page 14]
788 RFC 5580 Carrying LOs in RADIUS and Diameter August 2009
793 The format is shown below. The data type of this field is a
794 string. All fields are transmitted from left to right:
797 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
798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
799 | Index | Code | Entity |
800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
814 The 16-bit unsigned integer value allows this attribute to provide
815 information relating to the information included in the Location-
816 Data Attribute to which it refers (via the Index).
820 This field indicates the content of the location profile carried
821 in the Location-Data Attribute. Two profiles are defined in this
822 document -- namely, a civic location profile (see Section 4.3.1)
823 that uses value (0) and a geospatial location profile (see
824 Section 4.3.2) that uses the value (1).
828 This field encodes which location this attribute refers to as an
829 unsigned 8-bit integer value. Location information can refer to
830 different entities. This document registers two entity values,
833 Value (0) describes the location of the user's client device.
835 Value (1) describes the location of the RADIUS client.
837 The registry used for these values is established by this
838 document, see Section 8.4.
842 Tschofenig, et al. Standards Track [Page 15]
844 RFC 5580 Carrying LOs in RADIUS and Diameter August 2009
847 Sighting Time (64 bits)
849 This field indicates when the location information was accurate.
850 The data type of this field is a string, and the content is
851 expressed in the 64-bit Network Time Protocol (NTP) timestamp
854 Time-to-Live (64 bits):
856 This field gives a hint regarding for how long location
857 information should be considered current. The data type of this
858 field is a string and the content is expressed in the 64-bit
859 Network Time Protocol (NTP) timestamp format [RFC1305]. Note that
860 the Time-to-Live field is different than the Retention Expires
861 field used in the Basic-Location-Policy-Rules Attribute, see
862 Section 4.4. The Retention Expires field indicates the time the
863 recipient is no longer permitted to possess the location
868 Describes the way that the location information was determined.
869 This field MUST contain the value of exactly one IANA-registered
870 'method' token [RFC4119].
872 The length of the Location-Information Attribute MUST NOT exceed 253
875 4.3. Location-Data Attribute
877 The Location-Data Attribute MAY be sent in Access-Request and
878 Accounting-Request messages. For the Accounting-Request message, the
879 Acc-Status-Type may be set to Start, Interim, or Stop.
881 The format is shown below.
884 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
885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
886 | Type | Length | String ...
887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
898 Tschofenig, et al. Standards Track [Page 16]
900 RFC 5580 Carrying LOs in RADIUS and Diameter August 2009
909 The format is shown below. The data type of this field is a
910 string. All fields are transmitted from left to right:
913 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
914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
915 | Index | Location ...
916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
922 The 16-bit unsigned integer value allows this attribute to
923 associate the Location-Data Attribute with the Location-
924 Information Attributes.
928 The format of the location data depends on the location profile.
929 This document defines two location profiles. Details of the
930 location profiles are described below.
932 4.3.1. Civic Location Profile
934 Civic location is a popular way to describe the location of an
935 entity. This section defines the civic location-information profile
936 corresponding to the value (0) indicated in the Code field of the
937 Location-Information Attribute. The location format is based on the
938 encoding format defined in Section 3.1 of [RFC4776], whereby the
939 first 3 octets are not put into the Location field of the above-
940 described RADIUS Location-Data Attribute (i.e., the code for the DHCP
941 option, the length of the DHCP option, and the 'what' element are not
944 4.3.2. Geospatial Location Profile
946 This section defines the geospatial location-information profile
947 corresponding to the value (1) indicated in the Code field of the
948 Location-Information Attribute. Geospatial location information is
949 encoded as an opaque object, and the format is based on the Location
954 Tschofenig, et al. Standards Track [Page 17]
956 RFC 5580 Carrying LOs in RADIUS and Diameter August 2009
959 Configuration Information (LCI) format defined in Section 2 of
960 [RFC3825] but starts with the third octet (i.e., the code for the
961 DHCP option and the length field is not included).
963 4.4. Basic-Location-Policy-Rules Attribute
965 The Basic-Location-Policy-Rules Attribute MAY be sent in Access-
966 Request, Access-Accept, Access-Challenge, Change-of-Authorization,
967 and Accounting-Request messages.
969 Policy rules control the distribution of location information. In
970 order to understand and process the Basic-Location-Policy-Rules
971 Attribute, RADIUS clients are obligated to utilize a default value of
972 Basic-Location-Policy-Rules, unless explicitly configured otherwise,
973 and to echo the Basic-Location-Policy-Rules Attribute that they
974 receive from a server. As a default, the Note Well field does not
975 carry a pointer to human-readable privacy policies, the
976 retransmission-allowed is set to zero (0), i.e., further distribution
977 is not allowed, and the Retention Expires field is set to 24 hours.
979 With regard to authorization policies, this document reuses work done
980 in [RFC4119] and encodes those policies in a non-XML format. Two
981 fields ('Sighting Time' and 'Time-to-Live') are additionally included
982 in the Location-Information Attribute to conform to the GEOPRIV
983 requirements [RFC3693], Section 2.7.
985 The format of the Basic-Location-Policy-Rules Attribute is shown
989 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
990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
991 | Type | Length | String ...
992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
998 129 - Basic-Location-Policy-Rules
1010 Tschofenig, et al. Standards Track [Page 18]
1012 RFC 5580 Carrying LOs in RADIUS and Diameter August 2009
1017 The format is shown below. The data type of this field is a
1018 string. All fields are transmitted from left to right:
1021 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
1022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1023 | Flags | Retention Expires ...
1024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1025 | Retention Expires ...
1026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1027 | Retention Expires | Note Well ...
1028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1032 This document reuses fields from the RFC 4119 [RFC4119] 'usage-rules'
1033 element. These fields have the following meaning:
1037 The Flags field is a bit mask. Only the first bit (R) is defined
1038 in this document, and it corresponds to the Retransmission Allowed
1042 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
1043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1044 |R|o o o o o o o o o o o o o o o|
1045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1047 R = Retransmission Allowed
1050 All reserved bits MUST be zero. When the value of the Retransmission
1051 Allowed field is set to zero (0), then the recipient of this Location
1052 Object is not permitted to share the enclosed location information,
1053 or the object as a whole, with other parties. The value of '1'
1054 allows this attribute to share the location information with other
1055 parties by considering the extended policy rules.
1057 Retention Expires (64 bits):
1059 This field specifies an absolute date at which time the Recipient
1060 is no longer permitted to possess the location information. The
1061 data type of this field is a string and the format is a 64-bit NTP
1062 timestamp [RFC1305].
1066 Tschofenig, et al. Standards Track [Page 19]
1068 RFC 5580 Carrying LOs in RADIUS and Diameter August 2009
1071 Note Well (variable):
1073 This field contains a URI that points to human-readable privacy
1074 instructions. The data type of this field is a string. This
1075 field is useful when location information is distributed to third-
1076 party entities, which can include humans in a location-based
1077 service. RADIUS entities are not supposed to process this field.
1079 Whenever a Location Object leaves the RADIUS ecosystem, the URI in
1080 the Note Well Attribute MUST be expanded to the human-readable
1081 text. For example, when the Location Object is transferred to a
1082 SIP-based environment, then the human-readable text is placed into
1083 the 'note-well' element of the 'usage-rules' element contained in
1084 the PIDF-LO (Presence Information Data Format - Location Object)
1085 document (see [RFC4119]). The Note Well field may be empty.
1087 4.5. Extended-Location-Policy-Rules Attribute
1089 The Extended-Location-Policy-Rules Attribute MAY be sent in Access-
1090 Request, Access-Accept, Access-Challenge, Access-Reject, Change-of-
1091 Authorization, and Accounting-Request messages.
1093 The Ruleset Reference field of this attribute is of variable length.
1094 It contains a URI that indicates where the richer ruleset can be
1095 found. This URI SHOULD use the HTTPS URI scheme. As a deviation
1096 from [RFC4119], this field only contains a reference and does not
1097 carry an attached, extended ruleset. This modification is motivated
1098 by the size limitations imposed by RADIUS.
1100 In order to understand and process the Extended-Location-Policy-Rules
1101 Attribute, RADIUS clients are obligated to attach the URI to the
1102 Extended-Location-Policy-Rules Attribute when they are explicitly
1103 configured to do so, and to echo the Extended-Location-Policy-Rules
1104 Attribute that they receive from a server. There is no expectation
1105 that RADIUS clients will need to retrieve data at the URL specified
1106 in the attribute or to parse the XML policies.
1108 The format of the Extended-Location-Policy-Rules Attribute is shown
1112 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
1113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1114 | Type | Length | String ...
1115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1116 | String (cont.) ...
1117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1122 Tschofenig, et al. Standards Track [Page 20]
1124 RFC 5580 Carrying LOs in RADIUS and Diameter August 2009
1129 130 - Extended-Location-Policy-Rules
1137 This field is at least two octets in length, and the format is
1138 shown below. The data type of this field is a string. The fields
1139 are transmitted from left to right:
1142 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
1143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1144 | Ruleset Reference ...
1145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1149 This field contains a URI that points to the policy rules.
1151 4.6. Location-Capable Attribute
1153 The Location-Capable Attribute allows an NAS (or client function of a
1154 proxy server) to indicate support for the functionality specified in
1155 this document. The Location-Capable Attribute with the value for
1156 'Location Capable' MUST be sent with the Access-Request messages, if
1157 the NAS supports the functionality described in this document and is
1158 capable of sending location information. A RADIUS server MUST NOT
1159 challenge for location information unless the Location-Capable
1160 Attribute has been sent to it.
1163 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
1164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1165 | Type | Length | Integer |
1166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1172 131 - Location-Capable Attribute
1178 Tschofenig, et al. Standards Track [Page 21]
1180 RFC 5580 Carrying LOs in RADIUS and Diameter August 2009
1189 The content of the Integer field encodes the requested
1190 capabilities. Each capability value represents a bit position.
1192 This document specifies the following capabilities.
1200 The RADIUS client uses the CIVIC_LOCATION to indicate that it is
1201 able to return civic location based on the location profile
1202 defined in Section 4.3.1.
1206 A numerical value of this token is '1'.
1214 The RADIUS client uses the GEO_LOCATION to indicate that it is
1215 able to return geodetic location based on the location profile
1216 defined in Section 4.3.2.
1220 A numerical value of this token is '2'.
1234 Tschofenig, et al. Standards Track [Page 22]
1236 RFC 5580 Carrying LOs in RADIUS and Diameter August 2009
1241 The numerical value representing USERS_LOCATION indicates that the
1242 RADIUS client is able to provide a Location-Information Attribute
1243 with the Entity Attribute expressing the value of zero (0), i.e.,
1244 the RADIUS client is capable of returning the location information
1245 of the user's client device.
1249 A numerical value of this token is '4'.
1257 The numerical value representing NAS_LOCATION indicates that the
1258 RADIUS client is able to provide a Location-Information Attribute
1259 that contains location information with the Entity Attribute
1260 expressing the value of one (1), i.e., the RADIUS client is
1261 capable of returning the location information of the NAS.
1265 A numerical value of this token is '8'.
1267 4.7. Requested-Location-Info Attribute
1269 The Requested-Location-Info Attribute allows the RADIUS server to
1270 indicate which location information about which entity it wants to
1271 receive. The latter aspect refers to the entities that are indicated
1272 in the Entity field of the Location-Information Attribute.
1274 The Requested-Location-Info Attribute MAY be sent in an Access-
1275 Accept, Access-Challenge, or Change-of-Authorization packet.
1277 If the RADIUS server wants to dynamically decide on a per-request
1278 basis to ask for location information from the RADIUS client, then
1279 the following cases need to be differentiated. If the RADIUS client
1280 and the RADIUS server have agreed out-of-band to mandate the transfer
1281 of location information for every network-access authentication
1282 request, then the processing listed below is not applicable.
1290 Tschofenig, et al. Standards Track [Page 23]
1292 RFC 5580 Carrying LOs in RADIUS and Diameter August 2009
1295 o If the RADIUS server requires location information for computing
1296 the authorization decision and the RADIUS client does not provide
1297 it with the Access-Request message, then the Requested-Location-
1298 Info Attribute is attached to the Access-Challenge with a hint
1299 about what is required.
1301 o If the RADIUS server does not receive the requested information in
1302 response to the Access-Challenge (including the Requested-
1303 Location-Info Attribute), then the RADIUS server may respond with
1304 an Access-Reject message with an Error-Cause Attribute (including
1305 the "Location-Info-Required" value).
1307 o If the RADIUS server would like location information in the
1308 Accounting-Request message but does not require it for computing
1309 an authorization decision, then the Access-Accept message MUST
1310 include a Required-Info Attribute. This is typically the case
1311 when location information is used only for billing. The RADIUS
1312 client SHOULD attach location information, if available, to the
1313 Accounting-Request (unless authorization policies dictate
1314 something different).
1316 If the RADIUS server does not send a Requested-Location-Info
1317 Attribute, then the RADIUS client MUST NOT attach location
1318 information to messages towards the RADIUS server. The user's
1319 authorization policies, if available, MUST be consulted by the RADIUS
1320 server before requesting location information delivery from the
1323 Figure 6 shows a simple protocol exchange where the RADIUS server
1324 indicates the desire to obtain location information, namely civic
1325 location information of the user, to grant access. Since the
1326 Requested-Location-Info Attribute is attached to the Access-
1327 Challenge, the RADIUS server indicates that location information is
1328 required for computing an authorization decision.
1346 Tschofenig, et al. Standards Track [Page 24]
1348 RFC 5580 Carrying LOs in RADIUS and Diameter August 2009
1351 +---------+ +---------+
1352 | RADIUS | | RADIUS |
1353 | Client | | Server |
1354 +---------+ +---------+
1358 | + Location-Capable |
1359 | ('CIVIC_LOCATION', |
1362 | 'USERS_LOCATION') |
1363 |--------------------------------->|
1365 | Access-Challenge |
1366 | + Requested-Location-Info |
1367 | ('CIVIC_LOCATION', |
1368 | 'USERS_LOCATION') |
1369 | + Basic-Location-Policy-Rules |
1370 | + Extended-Location-Policy-Rules |
1371 |<---------------------------------|
1374 | + Location-Information |
1376 | + Basic-Location-Policy-Rules |
1377 | + Extended-Location-Policy-Rules |
1378 |--------------------------------->|
1382 Figure 6: RADIUS Server Requesting Location Information
1384 The Requested-Location-Info Attribute MUST be sent by the RADIUS
1385 server, in the absence of an out-of-band agreement, if it wants the
1386 RADIUS client to return location information and if authorization
1387 policies permit it. This Requested-Location-Info Attribute MAY
1388 appear in the Access-Accept or in the Access-Challenge message.
1390 A summary of the attribute is shown below.
1393 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
1394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1395 | Type | Length | Integer ...
1396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1402 Tschofenig, et al. Standards Track [Page 25]
1404 RFC 5580 Carrying LOs in RADIUS and Diameter August 2009
1409 132 - Requested-Location-Info Attribute
1417 The content of the Integer field encodes the requested information
1418 attributes. Each capability value represents a bit position.
1420 This document specifies the following capabilities:
1428 The RADIUS server uses the Requested-Location-Info Attribute with
1429 the value set to CIVIC_LOCATION to request specific location
1430 information from the RADIUS client. The numerical value
1431 representing CIVIC_LOCATION requires the RADIUS client to attach
1432 civic location attributes. CIVIC_LOCATION refers to the location
1433 profile defined in Section 4.3.1.
1437 A numerical value of this token is '1'.
1445 The RADIUS server uses the Requested-Location-Info Attribute with
1446 the value set to GEO_LOCATION to request specific location
1447 information from the RADIUS client. The numerical value
1448 representing GEO_LOCATION requires the RADIUS client to attach
1449 geospatial location attributes. GEO_LOCATION refers to the
1450 location profile described in Section 4.3.2.
1454 A numerical value of this token is '2'.
1458 Tschofenig, et al. Standards Track [Page 26]
1460 RFC 5580 Carrying LOs in RADIUS and Diameter August 2009
1469 The numerical value representing USERS_LOCATION indicates that the
1470 RADIUS client MUST send a Location-Information Attribute with the
1471 Entity Attribute expressing the value of zero (0). Hence, there
1472 is a one-to-one relationship between the USERS_LOCATION token and
1473 the value of zero (0) of the Entity Attribute inside the Location-
1474 Information Attribute. A value of zero indicates that the
1475 location information in the Location-Information Attribute refers
1476 to the user's client device.
1480 A numerical value of this token is '4'.
1488 The numerical value representing NAS_LOCATION indicates that the
1489 RADIUS client MUST send a Location-Information Attribute that
1490 contains location information with the Entity Attribute expressing
1491 the value of one (1). Hence, there is a one-to-one relationship
1492 between the NAS_LOCATION token and the value of one (1) of the
1493 Entity Attribute inside the Location-Information Attribute. A
1494 value of one indicates that the location information in the
1495 Location-Information Attribute refers to the RADIUS client.
1499 A numerical value of this token is '8'.
1507 The numerical value representing FUTURE_REQUESTS indicates that
1508 the RADIUS client MUST provide future Access-Requests for the same
1509 session with the same type of information as returned in the
1510 initial Access-Request message.
1514 Tschofenig, et al. Standards Track [Page 27]
1516 RFC 5580 Carrying LOs in RADIUS and Diameter August 2009
1521 A numerical value of this token is '16'.
1529 The RADIUS server uses this token to request that the RADIUS
1530 client stop sending location information.
1534 A numerical value of this token is '32'.
1536 If neither the NAS_LOCATION nor the USERS_LOCATION bit is set, then
1537 per-default the location of the user's client device is returned (if
1538 authorization policies allow it). If both the NAS_LOCATION and the
1539 USERS_LOCATION bits are set, then the returned location information
1540 has to be put into separate attributes. If neither the
1541 CIVIC_LOCATION nor the GEO_LOCATION bit is set in the Requested-
1542 Location-Info Attribute, then no location information is returned.
1543 If both the CIVIC_LOCATION and the GEO_LOCATION bits are set, then
1544 the location information has to be put into separate attributes. The
1545 value of NAS_LOCATION and USERS_LOCATION refers to the location
1546 information requested via CIVIC_LOCATION and GEO_LOCATION.
1548 As an example, if the bits for NAS_LOCATION, USERS_LOCATION, and
1549 GEO_LOCATION are set, then the location information of the RADIUS
1550 client and the users' client device are returned in a geospatial-
1553 5. Table of Attributes
1555 The following table provides a guide to which attributes may be found
1556 in which RADIUS messages, and in what quantity.
1570 Tschofenig, et al. Standards Track [Page 28]
1572 RFC 5580 Carrying LOs in RADIUS and Diameter August 2009
1575 Request Accept Reject Challenge Accounting # Attribute
1577 0-1 0-1 0 0 0+ 126 Operator-Name
1578 0+ 0 0 0 0+ 127 Location-Information
1579 0+ 0 0 0 0+ 128 Location-Data
1580 0-1 0-1 0-1 0-1 0-1 129 Basic-Location-
1582 0-1 0-1 0-1 0-1 0-1 130 Extended-Location-
1584 0-1 0 0 0 0 131 Location-Capable
1585 0 0-1 0 0-1 0 132 Requested-Location-Info
1586 0 0 0-1 0 0 101 Error-Cause (*)
1588 (*) Note: The Error-Cause Attribute contains the value for the
1589 'Location-Info-Required' error.
1591 Change-of-Authorization Messages
1593 Request ACK NAK # Attribute
1594 0-1 0 0 129 Basic-Location-Policy-Rules
1595 0-1 0 0 130 Extended-Location-Policy-Rules
1596 0-1 0 0 132 Requested-Location-Info
1600 0 This attribute MUST NOT be present.
1601 0+ Zero or more instances of this attribute MAY be present.
1602 0-1 Zero or one instance of this attribute MAY be present.
1603 1 Exactly one instance of this attribute MUST be present.
1604 1+ One or more of these attributes MUST be present.
1606 Figure 7: Table of Attributes
1608 The Error-Cause Attribute is defined in [RFC5176].
1610 The Location-Information and the Location-Data Attribute MAY appear
1611 more than once. For example, if the server asks for civic and
1612 geospatial location information, two Location-Information Attributes
1615 The attributes defined in this document are not used in any messages
1616 other than the ones listed in Figure 7.
1618 IANA allocated a new value (509) from the Error-Cause registry with
1619 the semantics of 'Location-Info-Required'.
1626 Tschofenig, et al. Standards Track [Page 29]
1628 RFC 5580 Carrying LOs in RADIUS and Diameter August 2009
1631 6. Diameter RADIUS Interoperability
1633 When used in Diameter, the attributes defined in this specification
1634 can be used as Diameter attribute-value pairs (AVPs) from the code
1635 space 1-255 (RADIUS attribute-compatibility space). No additional
1636 Diameter code values are therefore allocated. The data types and
1637 flag rules, as defined in [RFC3588], for the Diameter AVPs are as
1640 +---------------------+
1642 +----+-----+------+-----+----+
1643 | | |SHOULD| MUST| |
1644 Attribute Name Value Type |MUST| MAY | NOT | NOT|Encr|
1645 +---------------------------------+----+-----+------+-----+----+
1646 |Operator-Name OctetString| | P | | V,M | Y |
1647 |Location-Information OctetString| | P | | V,M | Y |
1648 |Location-Data OctetString| | P | | V,M | Y |
1649 |Basic-Location- | | | | | |
1650 | Policy-Rules OctetString| | P | | V,M | Y |
1651 |Extended-Location- | | | | | |
1652 | Policy-Rules OctetString| | P | | V,M | Y |
1653 |Requested- | | | | | |
1654 | Location-Info OctetString| | P | | V,M | Y |
1655 |Location-Capable OctetString| | P | | V,M | Y |
1656 +---------------------------------+----+-----+------+-----+----+
1658 The RADIUS attributes in this specification have no special
1659 translation requirements for Diameter-to-RADIUS or RADIUS-to-Diameter
1660 gateways; they are copied as is, except for changes relating to
1661 headers, alignment, and padding. See also Section 4.1 of [RFC3588]
1662 and Section 9 of [RFC4005].
1664 What this specification says about the applicability of the
1665 attributes for RADIUS Access-Request packets applies in Diameter to
1666 AA-Request [RFC4005] or Diameter-EAP-Request [RFC4072]. What is said
1667 about Access-Challenge applies in Diameter to AA-Answer [RFC4005] or
1668 Diameter-EAP-Answer [RFC4072] with the Result-Code AVP set to
1669 DIAMETER_MULTI_ROUND_AUTH. What is said about Access-Accept applies
1670 in Diameter to AA-Answer or Diameter-EAP-Answer messages that
1671 indicate success. Similarly, what is said about RADIUS Access-Reject
1672 packets applies in Diameter to AA-Answer or Diameter-EAP-Answer
1673 messages that indicate failure.
1675 What is said about CoA-Request applies in Diameter to Re-Auth-Request
1682 Tschofenig, et al. Standards Track [Page 30]
1684 RFC 5580 Carrying LOs in RADIUS and Diameter August 2009
1687 What is said about Accounting-Request applies in Diameter to
1688 Accounting-Request [RFC4005] as well.
1690 Note that these AVPs may be used by Diameter applications other than
1691 RFC 4005 [RFC4005] and RFC 4072 [RFC4072]. The above-mentioned
1692 applications are, however, likely to be relevant in the context of
1695 7. Security Considerations
1697 A number of security aspects are relevant for the distribution of
1698 location information via RADIUS. These aspects are discussed in
1699 separate subsections.
1701 7.1. Communication Security
1703 Requirements for the protection of a Location Object are defined in
1704 [RFC3693] -- namely, mutual end-point authentication, data object
1705 integrity, data object confidentiality, and replay protection.
1707 If no authentication, integrity, and replay protection between the
1708 participating RADIUS entities is provided, then adversaries can spoof
1709 and modify transmitted attributes. Two security mechanisms are
1710 proposed for RADIUS:
1712 o [RFC2865] proposes the usage of a static key that raised concerns
1713 regarding the lack of dynamic key management. At the time of
1714 writing, work is ongoing to address some shortcomings of the
1715 [RFC2865] attribute regarding security protection.
1717 o RADIUS over IPsec [RFC3579] enables the use of standard key-
1718 management mechanisms, such as Kerberized Internet Negotiation of
1719 Keys (KINK), the Internet Key Exchange Protocol (IKE), and IKEv2
1720 [RFC4306], to establish IPsec security associations.
1721 Confidentiality protection MUST be used to prevent an eavesdropper
1722 from gaining access to location information. Confidentiality
1723 protection is already present for other reasons in many
1724 environments, such as for the transport of keying material in the
1725 context of Extensible Authentication Protocol (EAP) authentication
1726 and authorization. Hence, this requirement is, in many
1727 environments, already fulfilled. Mutual authentication MUST be
1728 provided between neighboring RADIUS entities to prevent man-in-
1729 the-middle attacks. Since mutual authentication is already
1730 required for key transport within RADIUS messages, it does not
1731 represent a deployment obstacle. Since IPsec protection is
1732 already suggested as a mechanism to protect RADIUS, no additional
1733 considerations need to be addressed beyond those described in
1738 Tschofenig, et al. Standards Track [Page 31]
1740 RFC 5580 Carrying LOs in RADIUS and Diameter August 2009
1743 In case IPsec protection is not available for some reason and RADIUS-
1744 specific security mechanisms have to be used, then the following
1745 considerations apply. The Access-Request message is not integrity
1746 protected. This would allow an adversary to change the contents of
1747 the Location Object or to insert, modify, and delete attributes or
1748 individual fields. To address these problems, the Message-
1749 Authenticator (80) can be used to integrity protect the entire
1750 Access-Request packet. The Message-Authenticator (80) is also
1751 required when EAP is used and, hence, is supported by many modern
1754 Access-Request packets including location attribute(s) without a
1755 Message-Authenticator (80) Attribute SHOULD be silently discarded by
1756 the RADIUS server. A RADIUS server supporting location attributes
1757 MUST calculate the correct value of the Message-Authenticator (80)
1758 and MUST silently discard the packet if it does not match the value
1761 Access-Accept messages, including location attribute(s), without a
1762 Message-Authenticator (80) Attribute SHOULD be silently discarded by
1763 the NAS. An NAS supporting location attributes MUST calculate the
1764 correct value of a received Message-Authenticator (80) and MUST
1765 silently discard the packet if it does not match the value sent.
1767 RADIUS and Diameter make some assumptions about the trust between
1768 traversed RADIUS entities in the sense that object-level security is
1769 not provided by either RADIUS or Diameter. Hence, some trust has to
1770 be placed on the RADIUS entities to behave according to the defined
1771 rules. Furthermore, the RADIUS protocol does not involve the user in
1772 their protocol interaction except for tunneling authentication
1773 information (such as EAP messages) through their infrastructure.
1774 RADIUS and Diameter have even become a de facto protocol for key
1775 distribution for network-access authentication applications. Hence,
1776 in the past there were some concerns about the trust placed into the
1777 infrastructure -- particularly from the security area -- when it
1778 comes to keying. The EAP keying infrastructure is described in
1781 7.2. Privacy Considerations
1783 This section discusses privacy implications for the distribution of
1784 location information within RADIUS. Note also that it is possible
1785 for the RADIUS server to obtain some amount of location information
1786 from the NAS identifier. This document, however, describes
1787 procedures to convey more accurate location information about the end
1788 host and/or the network. In a number of deployment environments,
1789 location information about the network also reveals the current
1794 Tschofenig, et al. Standards Track [Page 32]
1796 RFC 5580 Carrying LOs in RADIUS and Diameter August 2009
1799 location of the user with a certain degree of precision, depending on
1800 the location-determination mechanism used, the update frequency, the
1801 size of the network, and other factors, such as movement traces.
1803 Three types of use cases have to be differentiated:
1805 o The RADIUS server does not want to receive location information
1806 from the RADIUS client.
1808 o In case there is an out-of-band agreement between the entity
1809 responsible for the NAS and the entity operating the RADIUS
1810 server, location information may be sent without an explicit
1811 request from the RADIUS server.
1813 o The RADIUS server dynamically requests location information from
1816 7.2.1. RADIUS Client
1818 The RADIUS client MUST behave according to the following guidelines:
1820 o If neither an out-of-band agreement exists nor location
1821 information is requested by the RADIUS server, then location
1822 information is not disclosed by the RADIUS client.
1824 o The RADIUS client MUST pass location information to other entities
1825 (e.g., when information is written to a local database or to the
1826 log files) only together with the policy rules. The entity
1827 receiving the location information (together with the policies)
1828 MUST follow the guidance given with these rules.
1830 o A RADIUS client MUST include Basic-Location-Policy-Rules and
1831 Extended-Location-Policy-Rules Attributes that are configured
1832 within an Access-Request packet.
1834 o NAS implementations supporting this specification, which are
1835 configured to provide location information, MUST echo Basic-
1836 Location-Policy-Rules and Extended-Location-Policy-Rules
1837 Attributes unmodified within a subsequent Access-Request packet.
1838 In addition, an Access-Request packet sent with a Service-Type
1839 value of "Authorize Only" MUST include the Basic-Location-Policy-
1840 Rules or Extended-Location-Policy-Rules Attributes that were
1841 received in a previous Access-Accept if the FUTURE_REQUESTS flag
1842 was set in the Requested-Location-Info Attribute.
1850 Tschofenig, et al. Standards Track [Page 33]
1852 RFC 5580 Carrying LOs in RADIUS and Diameter August 2009
1855 7.2.2. RADIUS Server
1857 The RADIUS server is a natural place for storing authorization
1858 policies since the user typically has some sort of trust relationship
1859 with the entity operating the RADIUS server. Once the infrastructure
1860 is deployed and location-aware applications are available, there
1861 might be a strong desire to use location information for other
1864 The Common Policy framework [RFC4745] that was extended for
1865 geolocation privacy [GEO-POLICY] is tailored for this purpose.
1866 The Extensible Markup Language (XML) Configuration Access Protocol
1867 (XCAP) [RFC4825] gives users the ability to change their privacy
1868 policies using a standardized protocol. These policies are an
1869 important tool for limiting further distribution of the user's
1870 location to other location-based services.
1872 The RADIUS server MUST behave according to the following guidelines:
1874 o The RADIUS server MUST attach available rules to the Access-
1875 Accept, Access-Reject, or Access-Challenge message when the RADIUS
1876 client is supposed to provide location information.
1878 o When location information is made available to other entities
1879 (e.g., writing to stable storage for later billing processing),
1880 then the RADIUS server MUST attach the privacy rules to location
1885 A RADIUS proxy, behaving as a combined RADIUS client and RADIUS
1886 server, MUST follow the rules described in Sections 7.2.1 and 7.2.2.
1888 7.3. Identity Information and Location Information
1890 For the envisioned usage scenarios, the identity of the user and his
1891 device is tightly coupled to the transfer of location information.
1892 If the identity can be determined by the visited network or RADIUS
1893 brokers, then it is possible to correlate location information with a
1894 particular user. As such, it allows the visited network and brokers
1895 to learn the movement patterns of users.
1897 The user's identity can be "leaked" to the visited network or RADIUS
1898 brokers in a number of ways:
1900 o The user's device may employ a fixed Media Access Control (MAC)
1901 address or base its IP address on such an address. This enables
1902 the correlation of the particular device to its different
1906 Tschofenig, et al. Standards Track [Page 34]
1908 RFC 5580 Carrying LOs in RADIUS and Diameter August 2009
1911 locations. Techniques exist to avoid the use of an IP address
1912 that is based on a MAC address [RFC4941]. Some link layers make
1913 it possible to avoid MAC addresses or change them dynamically.
1915 o Network-access authentication procedures, such as the PPP
1916 Challenge Handshake Authentication Protocol (CHAP) [RFC1994] or
1917 EAP [RFC4187], may reveal the user's identity as a part of the
1918 authentication procedure. Techniques exist to avoid this problem
1919 in EAP methods, for instance by employing private Network Access
1920 Identifiers (NAIs) [RFC4282] in the EAP Identity Response message
1921 and by method-specific private identity exchanges in the EAP
1922 method (e.g., [RFC4187], [RFC5281], [PEAP], and [RFC5106]).
1923 Support for identity privacy within CHAP is not available.
1925 o RADIUS may return information from the home network to the visited
1926 one in a manner that makes it possible to either identify the user
1927 or at least correlate his session with other sessions, such as the
1928 use of static data in a Class Attribute [RFC2865] or in some
1929 accounting attribute usage scenarios [RFC4372].
1931 o Mobility protocols may reveal some long-term identifier, such as a
1934 o Application-layer protocols may reveal other permanent
1937 To prevent the correlation of identities with location information,
1938 it is necessary to prevent leakage of identity information from all
1939 sources, not just one.
1941 Unfortunately, most users are not educated about the importance of
1942 identity confidentiality, and some protocols lack support for
1943 identity-privacy mechanisms. This problem is made worse by the fact
1944 that users may be unable to choose particular protocols, as the
1945 choice is often dictated by the type of network operator they use,
1946 the type of network they wish to access, the kind of equipment they
1947 have, or the type of authentication method they are using.
1949 A scenario where the user is attached to the home network is, from a
1950 privacy point of view, simpler than a scenario where a user roams
1951 into a visited network, since the NAS and the home RADIUS server are
1952 in the same administrative domain. No direct relationship between
1953 the visited and the home network operator may be available, and some
1954 RADIUS brokers need to be consulted. With subscription-based network
1955 access as used today, the user has a contractual relationship with
1956 the home network provider that could (theoretically) allow higher
1962 Tschofenig, et al. Standards Track [Page 35]
1964 RFC 5580 Carrying LOs in RADIUS and Diameter August 2009
1967 privacy considerations to be applied (including policy rules stored
1968 at the home network itself, for the purpose of restricting further
1971 In many cases it is necessary to secure the transport of location
1972 information along the RADIUS infrastructure. Mechanisms to achieve
1973 this functionality are discussed in Section 7.1.
1975 8. IANA Considerations
1977 The Attribute Types and Attribute Values defined in this document
1978 have been registered by the Internet Assigned Numbers Authority
1979 (IANA) from the RADIUS namespaces as described in the "IANA
1980 Considerations" section of RFC 3575 [RFC3575], in accordance with BCP
1981 26 [RFC5226]. Additionally, the Attribute Type has been registered
1982 in the Diameter namespace. For RADIUS attributes and registries
1983 created by this document, IANA placed them in the Radius Types
1986 This document defines the following attributes:
1989 Location-Information
1991 Basic-Location-Policy-Rules
1992 Extended-Location-Policy-Rules
1994 Requested-Location-Info
1996 Please refer to Section 5 for the registered list of numbers.
1998 IANA has also assigned a new value (509) for the Error-Cause
1999 Attribute [RFC5176] of "Location-Info-Required" according to this
2002 Additionally, IANA created the following new registries listed in the
2005 8.1. New Registry: Operator Namespace Identifier
2007 This document also defines an Operator Namespace Identifier registry
2008 (used in the Namespace ID field of the Operator-Name Attribute).
2009 Note that this document requests IANA only to maintain a registry of
2010 existing namespaces for use in this identifier field, and not to
2011 establish any namespaces or place any values within namespaces.
2018 Tschofenig, et al. Standards Track [Page 36]
2020 RFC 5580 Carrying LOs in RADIUS and Diameter August 2009
2023 IANA added the following values to the Operator Namespace Identifier
2024 registry using a numerical identifier (allocated in sequence), a
2025 token for the operator namespace, and a contact person for the
2028 +----------+--------------------+------------------------------------+
2029 |Identifier| Operator Namespace | Contact Person |
2031 +----------+--------------------+------------------------------------+
2032 | 0x30 | TADIG | TD.13 Coordinator |
2033 | | | (td13@gsm.org) |
2034 | 0x31 | REALM | IETF O&M Area Directors |
2035 | | | (ops-ads@ietf.org) |
2036 | 0x32 | E212 | ITU Director |
2037 | | | (tsbdir@itu.int) |
2038 | 0x33 | ICC | ITU Director |
2039 | | | (tsbdir@itu.int) |
2040 +----------+--------------------+------------------------------------+
2042 Note that the above identifier values represent the ASCII value '0'
2043 (decimal 48 or hex 0x30), '1' (decimal 49, or hex 0x31), '2' (decimal
2044 50, or hex 0x32), and '3' (decimal 51, or hex 0x33). This encoding
2045 was chosen to simplify parsing.
2047 Requests to IANA for a new value for a Namespace ID, i.e., values
2048 from 0x34 to 0xFE, will be approved by Expert Review. A designated
2049 expert will be appointed by the IESG.
2051 The Expert Reviewer should ensure that a new entry is indeed required
2052 or could fit within an existing database, e.g., whether there is a
2053 real requirement to provide a token for a Namespace ID because one is
2054 already up and running, or whether the REALM identifier plus the name
2055 should be recommended to the requester. In addition, the Expert
2056 Reviewer should ascertain to some reasonable degree of diligence that
2057 a new entry is a correct reference to an operator namespace whenever
2058 a new one is registered.
2060 8.2. New Registry: Location Profiles
2062 Section 4.2 defines the Location-Information Attribute and a Code
2063 field that contains an 8-bit integer value. Two values, zero and
2064 one, are defined in this document, namely:
2066 Value (0): Civic location profile described in Section 4.3.1
2068 Value (1): Geospatial location profile described in Section 4.3.2
2070 The remaining values are reserved for future use.
2074 Tschofenig, et al. Standards Track [Page 37]
2076 RFC 5580 Carrying LOs in RADIUS and Diameter August 2009
2079 Following the policies outlined in [RFC3575], the available bits with
2080 a description of their semantics will be assigned after the Expert
2081 Review process. Updates can be provided based on expert approval
2082 only. Based on expert approval, it is possible to mark entries as
2083 "deprecated". A designated expert will be appointed by the IESG.
2085 Each registration must include the value and the corresponding
2086 semantics of the defined location profile.
2088 8.3. New Registry: Location-Capable Attribute
2090 Section 4.6 defines the Location-Capable Attribute that contains a
2091 bit map. 32 bits are available, from which 4 bits are defined by this
2092 document. This document creates a new IANA registry for the
2093 Location-Capable Attribute. IANA added the following values to this
2096 +----------+----------------------+
2097 | Value | Capability Token |
2098 +----------+----------------------+
2099 | 1 | CIVIC_LOCATION |
2100 | 2 | GEO_LOCATION |
2101 | 4 | USERS_LOCATION |
2102 | 8 | NAS_LOCATION |
2103 +----------+----------------------+
2105 Following the policies outlined in [RFC3575], the available bits with
2106 a description of their semantics will be assigned after the Expert
2107 Review process. Updates can be provided based on expert approval
2108 only. Based on expert approval, it is possible to mark entries as
2109 "deprecated". A designated expert will be appointed by the IESG.
2111 Each registration must include:
2115 Capability Token (i.e., an identifier of the capability)
2119 Brief description indicating the meaning of the 'info' element.
2123 A numerical value that is placed into the Capability Attribute
2124 representing a bit in the bit-string of the Requested-Location-
2130 Tschofenig, et al. Standards Track [Page 38]
2132 RFC 5580 Carrying LOs in RADIUS and Diameter August 2009
2135 8.4. New Registry: Entity Types
2137 Section 4.2 defines the Location-Information Attribute that contains
2138 an 8-bit Entity field. Two values are registered by this document,
2141 Value (0) describes the location of the user's client device.
2143 Value (1) describes the location of the RADIUS client.
2145 All other values are reserved for future use.
2147 Following the policies outlined in [RFC3575], the available bits with
2148 a description of their semantics will be assigned after the Expert
2149 Review process. Updates can be provided based on expert approval
2150 only. Based on expert approval, it is possible to mark entries as
2151 "deprecated". A designated expert will be appointed by the IESG.
2153 Each registration must include the value and a corresponding
2156 8.5. New Registry: Privacy Flags
2158 Section 4.4 defines the Basic-Location-Policy-Rules Attribute that
2159 contains flags indicating privacy settings. 16 bits are available,
2160 from which a single bit, bit (0), indicating 'retransmission allowed'
2161 is defined by this document. Bits 1-15 are reserved for future use.
2163 Following the policies outline in [RFC3575], the available bits with
2164 a description of their semantics will be assigned after the Expert
2165 Review process. Updates can be provided based on expert approval
2166 only. Based on expert approval, it is possible to mark entries as
2167 "deprecated". A designated expert will be appointed by the IESG.
2169 Each registration must include the bit position and the semantics of
2172 8.6. New Registry: Requested-Location-Info Attribute
2174 Section 4.7 defines the Requested-Location-Info Attribute that
2175 contains a bit map. 32 bits are available, from which 6 bits are
2176 defined by this document. This document creates a new IANA registry
2177 for the Requested-Location-Info Attribute. IANA added the following
2178 values to this registry:
2186 Tschofenig, et al. Standards Track [Page 39]
2188 RFC 5580 Carrying LOs in RADIUS and Diameter August 2009
2191 +----------+----------------------+
2192 | Value | Capability Token |
2193 +----------+----------------------+
2194 | 1 | CIVIC_LOCATION |
2195 | 2 | GEO_LOCATION |
2196 | 4 | USERS_LOCATION |
2197 | 8 | NAS_LOCATION |
2198 | 16 | FUTURE_REQUESTS |
2200 +----------+----------------------+
2202 The semantics of these values are defined in Section 4.7.
2204 Following the policies outlined in [RFC3575], new Capability Tokens,
2205 with a description of their semantics for usage with the Requested-
2206 Location-Info Attribute, will be assigned after the Expert Review
2207 process. Updates can be provided based on expert approval only.
2208 Based on expert approval, it is possible to mark entries as
2209 "deprecated". A designated expert will be appointed by the IESG.
2211 Each registration must include:
2215 Capability Token (i.e., an identifier of the capability)
2219 Brief description indicating the meaning of the 'info' element.
2223 A numerical value that is placed into the Capability Attribute
2224 representing a bit in the bit-string of the Requested-Location-
2229 The authors would like to thank the following people for their help
2230 with an initial version of this document and for their input: Chuck
2231 Black, Paul Congdon, Jouni Korhonen, Sami Ala-luukko, Farooq Bari, Ed
2232 Van Horne, Mark Grayson, Jukka Tuomi, Jorge Cuellar, and Christian
2242 Tschofenig, et al. Standards Track [Page 40]
2244 RFC 5580 Carrying LOs in RADIUS and Diameter August 2009
2247 Henning Schulzrinne provided the civic location information content
2248 found in this document. The geospatial location-information format
2249 is based on work done by James Polk, John Schnizlein, and Marc
2250 Linsner. The authorization policy format is based on the work done
2253 The authors would like to thank Victor Lortz, Anthony Leibovitz, Jose
2254 Puthenkulam, Bernrad Aboba, Jari Arkko, Parviz Yegani, Serge Manning,
2255 Kuntal Chowdury, Pasi Eronen, Blair Bullock and Eugene Chang for
2256 their feedback to an initial version of this document. We would like
2257 to thank Jari Arkko for his textual contributions. Lionel Morand
2258 provided detailed feedback on numerous issues. His comments helped
2259 to improve the quality of this document. Jouni Korhonen, Victor
2260 Fajardo, Tolga Asveren, and John Loughney helped us with the Diameter
2261 RADIUS interoperability section. Andreas Pashalidis reviewed a later
2262 version document and provided a number of comments. Alan DeKok,
2263 Lionel Morand, Jouni Korhonen, David Nelson, and Emile van Bergen
2264 provided guidance on the Requested-Location-Info Attribute and
2265 participated in the capability-exchange discussions. Allison Mankin,
2266 Jouni Korhonen, and Pasi Eronen provided text for the Operator
2267 Namespace Identifier registry. Jouni Korhonen interacted with the
2268 GSMA to find a contact person for the TADIG operator namespace, and
2269 Scott Bradner consulted the ITU-T to find a contact person for the
2270 E212 and the ICC operator namespace.
2272 This document is based on the discussions within the IETF GEOPRIV
2273 Working Group. Therefore, the authors thank Henning Schulzrinne,
2274 James Polk, John Morris, Allison Mankin, Randall Gellens, Andrew
2275 Newton, Ted Hardie, and Jon Peterson for their time discussing a
2276 number of issues with us. We thank Stephen Hayes for aligning this
2277 work with 3GPP activities.
2279 We would like to thank members of the Wimax Forum Global Roaming
2280 Working Group (GRWG) for their feedback on the Operator-Name
2281 attribute. Ray Jong Kiem helped us with his detailed description to
2282 correct the document.
2284 The RADEXT Working Group chairs, David Nelson and Bernard Aboba,
2285 provided several draft reviews and we would like to thank them for
2286 the help and their patience.
2288 Finally, we would like to thank Dan Romascanu, Glen Zorn, Russ
2289 Housley, Jari Arkko, Ralph Droms, Adrial Farrel, Tim Polk, and Lars
2290 Eggert for the IETF Last Call comments; Derek Atkins for his security
2291 area directorate review; and Yoshiko Chong for spotting a bug in the
2292 IANA Considerations section.
2298 Tschofenig, et al. Standards Track [Page 41]
2300 RFC 5580 Carrying LOs in RADIUS and Diameter August 2009
2305 10.1. Normative References
2307 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
2308 Requirement Levels", BCP 14, RFC 2119, March 1997.
2310 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
2311 "Remote Authentication Dial In User Service (RADIUS)",
2312 RFC 2865, June 2000.
2314 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of
2315 Unicode for Internationalized Domain Names in
2316 Applications (IDNA)", RFC 3492, March 2003.
2318 [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote
2319 Authentication Dial In User Service)", RFC 3575,
2322 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and
2323 J. Arkko, "Diameter Base Protocol", RFC 3588,
2326 [RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
2327 Configuration Protocol Option for Coordinate-based
2328 Location Configuration Information", RFC 3825,
2331 [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol
2332 (DHCPv4 and DHCPv6) Option for Civic Addresses
2333 Configuration Information", RFC 4776, November 2006.
2335 [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
2336 Aboba, "Dynamic Authorization Extensions to Remote
2337 Authentication Dial In User Service (RADIUS)",
2338 RFC 5176, January 2008.
2340 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing
2341 an IANA Considerations Section in RFCs", BCP 26,
2344 10.2. Informative References
2346 [GEO-POLICY] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar,
2347 J., and J. Polk, "Geolocation Policy: A Document Format
2348 for Expressing Privacy Preferences for Location
2349 Information", Work in Progress, February 2009.
2354 Tschofenig, et al. Standards Track [Page 42]
2356 RFC 5580 Carrying LOs in RADIUS and Diameter August 2009
2359 [GMLv3] "Open Geography Markup Language (GML) Implementation
2360 Specification", OGC 02-023r4, January 2003,
2361 <http://www.opengis.org/techno/implementation.htm>.
2363 [GSM] "TADIG Naming Conventions", Version 4.1, GSM
2364 Association Official Document TD.13, June 2006.
2366 [ISO] "Codes for the representation of names of countries and
2367 their subdivisions - Part 1: Country codes",
2370 [ITU1400] "Designations for interconnections among operators'
2371 networks", ITU-T Recommendation M.1400, January 2004.
2373 [ITU212] "The international identification plan for mobile
2374 terminals and mobile users", ITU-T
2375 Recommendation E.212, May 2004.
2377 [PEAP] Josefsson, S., Palekar, A., Simon, D., and G. Zorn,
2378 "Protected EAP Protocol (PEAP) Version 2", Work
2379 in Progress, October 2004.
2381 [RFC1305] Mills, D., "Network Time Protocol (Version 3)
2382 Specification, Implementation", RFC 1305, March 1992.
2384 [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication
2385 Protocol (CHAP)", RFC 1994, August 1996.
2387 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
2389 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote
2390 Authentication Dial In User Service) Support For
2391 Extensible Authentication Protocol (EAP)", RFC 3579,
2394 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J.,
2395 and J. Polk, "Geopriv Requirements", RFC 3693,
2398 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
2399 "Diameter Network Access Server Application", RFC 4005,
2402 [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible
2403 Authentication Protocol (EAP) Method Requirements for
2404 Wireless LANs", RFC 4017, March 2005.
2410 Tschofenig, et al. Standards Track [Page 43]
2412 RFC 5580 Carrying LOs in RADIUS and Diameter August 2009
2415 [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter
2416 Extensible Authentication Protocol (EAP) Application",
2417 RFC 4072, August 2005.
2419 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
2420 Format", RFC 4119, December 2005.
2422 [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication
2423 Protocol Method for 3rd Generation Authentication and
2424 Key Agreement (EAP-AKA)", RFC 4187, January 2006.
2426 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
2427 Network Access Identifier", RFC 4282, December 2005.
2429 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
2430 RFC 4306, December 2005.
2432 [RFC4372] Adrangi, F., Lior, A., Korhonen, J., and J. Loughney,
2433 "Chargeable User Identity", RFC 4372, January 2006.
2435 [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar,
2436 J., Polk, J., and J. Rosenberg, "Common Policy: A
2437 Document Format for Expressing Privacy Preferences",
2438 RFC 4745, February 2007.
2440 [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML)
2441 Configuration Access Protocol (XCAP)", RFC 4825,
2444 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
2445 Extensions for Stateless Address Autoconfiguration in
2446 IPv6", RFC 4941, September 2007.
2448 [RFC5106] Tschofenig, H., Kroeselberg, D., Pashalidis, A., Ohba,
2449 Y., and F. Bersani, "The Extensible Authentication
2450 Protocol-Internet Key Exchange Protocol version 2 (EAP-
2451 IKEv2) Method", RFC 5106, February 2008.
2453 [RFC5281] Funk, P. and S. Blake-Wilson, "Extensible
2454 Authentication Protocol Tunneled Transport Layer
2455 Security Authenticated Protocol Version 0 (EAP-
2456 TTLSv0)", RFC 5281, August 2008.
2466 Tschofenig, et al. Standards Track [Page 44]
2468 RFC 5580 Carrying LOs in RADIUS and Diameter August 2009
2471 Appendix A. Matching with GEOPRIV Requirements
2473 This section compares the requirements for a GEOPRIV using protocol,
2474 described in [RFC3693], against the approach of distributing Location
2475 Objects with RADIUS.
2477 In Appendices A.1 and A.2, we discuss privacy implications when
2478 RADIUS entities make location information available to other parties.
2479 In Appendix A.3, the requirements are matched against these two
2482 A.1. Distribution of Location Information at the User's Home Network
2484 When location information is conveyed from the RADIUS client to the
2485 RADIUS server, then it might subsequently be made available for
2486 different purposes. This section discusses the privacy implications
2487 for making location information available to other entities.
2489 To use a more generic scenario, we assume that the visited RADIUS and
2490 the home RADIUS server belong to different administrative domains.
2491 The Location Recipient obtains location information about a
2492 particular Target via protocols specified outside the scope of this
2493 document (e.g., SIP, HTTP, or an API).
2495 The subsequent figure shows the interacting entities graphically.
2497 visited network | home network
2505 +----------+ | V +----------+
2506 |Location | | +----------+ notification |Location |
2507 |Generator | | |Location |<------------->|Recipient |
2508 +----------+ publication |Server | interface | |
2509 |RADIUS |<------------->+----------+ +----------+
2510 |Client | interface |RADIUS | E.g., SIP/HTTP
2511 +----------+ | |Server |
2517 Figure 8: Location Server at the Home Network
2522 Tschofenig, et al. Standards Track [Page 45]
2524 RFC 5580 Carrying LOs in RADIUS and Diameter August 2009
2527 The term 'Rule Holder' in Figure 8 denotes the entity that creates
2528 the authorization ruleset.
2530 A.2. Distribution of Location Information at the Visited Network
2532 This section describes a scenario where location information is made
2533 available to Location Recipients by a Location Server in the visited
2534 network. Some identifier needs to be used as an index within the
2535 location database. One possible identifier is the Network Access
2536 Identifier. RFC 4282 [RFC4282] and RFC 4372 [RFC4372] provide
2537 background regarding whether entities in the visited network can
2538 obtain the user's NAI in cleartext.
2540 The visited network provides location information to a Location
2541 Recipient (e.g., via SIP or HTTP). This document enables the NAS to
2542 obtain the user's privacy policy via the interaction with the RADIUS
2543 server. Otherwise, only default policies, which are very
2544 restrictive, are available. This allows the Location Server in the
2545 visited network to ensure they act according to the user's policies.
2547 The subsequent figure shows the interacting entities graphically.
2578 Tschofenig, et al. Standards Track [Page 46]
2580 RFC 5580 Carrying LOs in RADIUS and Diameter August 2009
2583 visited network | home network
2592 notification | | Holder |
2600 |Server | | +----------+
2601 +----------+ Rule Transport|RADIUS |
2602 |RADIUS |<------------->|Server |
2603 |Client | RADIUS +----------+
2609 Figure 9: Location Server at the Visited Network
2611 Location information always travels with privacy policies. This
2612 document enables the RADIUS client to obtain these policies. The
2613 Location Server can subsequently act according to these policies to
2614 provide access control using the Extended-Location-Policy-Rules and
2615 to adhere to the privacy statements in the Basic-Location-Policy-
2618 A.3. Requirements Matching
2620 Section 7.1 of [RFC3693] details the requirements of a "Location
2621 Object". We discuss these requirements in the subsequent list.
2623 Req. 1. (Location Object generalities):
2625 * Regarding requirement 1.1, the syntax and semantics of the
2626 Location Object are taken from [RFC3825] and [RFC4776]. It is
2627 furthermore possible to convert it to the format used in the
2628 Geography Markup Language (GMLv3) [GMLv3], as used with PIDF-LO
2634 Tschofenig, et al. Standards Track [Page 47]
2636 RFC 5580 Carrying LOs in RADIUS and Diameter August 2009
2639 * Regarding requirement 1.2, a number of fields in the civic
2640 location-information format are optional.
2642 * Regarding requirement 1.3, the inclusion of type of place item
2643 (CAtype 29) used in the DHCP civic format gives a further
2644 classification of the location. This attribute can be seen as
2647 * Regarding requirement 1.4, this document does not define the
2648 format of the location information.
2650 * Regarding requirement 1.5, location information is only sent
2651 from the RADIUS client to the RADIUS server.
2653 * Regarding requirement 1.6, the Location Object contains both
2654 location information and privacy rules. Location information
2655 is described in Sections 4.2, 4.3.1, and 4.3.2. The
2656 corresponding privacy rules are detailed in Sections 4.4 and
2659 * Regarding requirement 1.7, the Location Object is usable in a
2660 variety of protocols. The format of the object is reused from
2661 other documents, as detailed in Sections 4.2, 4.3.1, 4.3.2,
2664 * Regarding requirement 1.8, the encoding of the Location Object
2665 has an emphasis on a lightweight encoding format to be used
2668 Req. 2. (Location Object fields):
2670 * Regarding requirement 2.1, the target identifier is carried
2671 within the network-access authentication protocol (e.g., within
2672 the EAP-Identity Response when EAP is used and/or within the
2673 EAP method itself). As described in Section 7.2 of this
2674 document, it has a number of advantages if this identifier is
2675 not carried in clear. This is possible with certain EAP
2676 methods whereby the identity in the EAP-Identity Response only
2677 contains information relevant for routing the response to the
2678 user's home network. The user identity is protected by the
2679 authentication and key exchange protocol.
2681 * Regarding requirement 2.2, the Location Recipient is, in the
2682 main scenario, the home RADIUS server. For a scenario where
2683 the Location Recipient is obtaining location information from
2684 the Location Server via HTTP or SIP, the respective mechanisms
2690 Tschofenig, et al. Standards Track [Page 48]
2692 RFC 5580 Carrying LOs in RADIUS and Diameter August 2009
2695 defined in these protocols are used to identify the recipient.
2696 The Location Generator cannot, a priori, know the recipients if
2697 they are not defined in this protocol.
2699 * Regarding requirement 2.3, the credentials of the Location
2700 Recipient are known to the RADIUS entities based on the
2701 security mechanisms defined in the RADIUS protocol itself.
2702 Section 7 of this document describes these security mechanisms
2703 offered by the RADIUS protocol. The same is true for
2706 * Regarding requirement 2.5, Sections 4.2, 4.3.1, and 4.3.2
2707 describe the content of the Location fields. Since the
2708 location format itself is not defined in this document, motion
2709 and direction vectors as listed in requirement 2.6 are not
2712 * Regarding requirement 2.6, this document provides the
2713 capability for the RADIUS server to indicate what type of
2714 location information it would like to see from the RADIUS
2717 * Regarding requirement 2.7, timing information is provided with
2718 the 'Sighting Time' and 'Time-to-Live' fields defined in
2721 * Regarding requirement 2.8, a reference to an external (more
2722 detailed ruleset) is provided with the Extended-Location-
2723 Policy-Rules Attribute in Section 4.5.
2725 * Regarding requirement 2.9, security headers and trailers are
2726 provided as part of the RADIUS protocol or even as part of
2729 * Regarding requirement 2.10, a version number in RADIUS is
2730 provided with the IANA registration of the attributes. New
2731 attributes are assigned a new IANA number.
2733 Req. 3. (Location Data Types):
2735 * Regarding requirement 3.1, this document reuses civic and
2736 geospatial location information as described in Sections 4.3.2
2739 * With the support of civic and geospatial location information,
2740 support of requirement 3.2 is fulfilled.
2746 Tschofenig, et al. Standards Track [Page 49]
2748 RFC 5580 Carrying LOs in RADIUS and Diameter August 2009
2751 * Regarding requirement 3.3, the geospatial location information
2752 used by this document only refers to absolute coordinates.
2753 However, the granularity of the location information can be
2754 reduced with the help of the AltRes, LoRes, and LaRes fields
2755 described in [RFC3825].
2757 * Regarding requirement 3.4, further Location Data Types can be
2758 added via new coordinate reference systems (CRSs -- see the
2759 Datum field in [RFC3825]) and via extensions to [RFC3825] and
2762 Section 7.2 of [RFC3693] details the requirements of a "using
2763 protocol". These requirements are listed below.
2765 Req. 4.: The using protocol has to obey the privacy and security
2766 instructions coded in the Location Object (LO) regarding the
2767 transmission and storage of the LO. This document requires that
2768 entities that aim to make location information available to third
2769 parties be required to obey the privacy instructions.
2771 Req. 5.: The using protocol will typically facilitate that the keys
2772 associated with the credentials are transported to the respective
2773 parties, that is, key establishment is the responsibility of the
2774 using protocol. Section 7 of this document specifies how security
2775 mechanisms are used in RADIUS and how they can be reused to
2776 provide security protection for the Location Object.
2777 Additionally, the privacy considerations (see Section 7.2) are
2778 also relevant for this requirement.
2780 Req. 6. (Single Message Transfer): In particular, for tracking of
2781 small target devices, the design should allow a single message/
2782 packet transmission of location as a complete transaction. The
2783 encoding of the Location Object is specifically tailored towards
2784 the inclusion into a single message that even respects the (Path)
2787 Section 7.3 of [RFC3693] details the requirements of a "Rule-based
2788 Location Data Transfer". These requirements are listed below.
2790 Req. 7. (LS Rules): With the scenario shown in Figure 8, the
2791 decision of a Location Server to provide a Location Recipient
2792 access to location information is based on Rule Maker-defined
2793 privacy rules that are stored at the home network. With regard to
2794 the scenario shown in Figure 9, the Rule Maker-defined privacy
2795 rules are sent from the RADIUS server to the NAS (see Sections
2796 4.4, 4.5, and 7.2 for more details).
2802 Tschofenig, et al. Standards Track [Page 50]
2804 RFC 5580 Carrying LOs in RADIUS and Diameter August 2009
2807 Req. 8. (LG Rules): For all usage scenarios, it is possible to
2808 consider the privacy rule before transmitting location information
2809 from the NAS to the RADIUS server or even to third parties. In
2810 the case of an out-of-band agreement between the owner of the NAS
2811 and the owner of the RADIUS server, privacy might be applied on a
2812 higher granularity. For the scenario shown in Figure 8, the
2813 visited network is already in possession of the user's location
2814 information prior to the authentication and authorization of the
2815 user. A correlation between the location and the user identity
2816 might, however, still not be possible for the visited network (as
2817 explained in Section 7.2). A Location Server in the visited
2818 network has to evaluate available rulesets.
2820 Req. 9. (Viewer Rules): The Rule Maker might define (via mechanisms
2821 outside the scope of this document) which policy rules are
2822 disclosed to other entities.
2824 Req. 10. (Full Rule language): GEOPRIV has defined a rule language
2825 capable of expressing a wide range of privacy rules that is
2826 applicable in the area of the distribution of Location Objects. A
2827 basic ruleset is provided with the Basic-Location-Policy-Rules
2828 Attribute (Section 4.4). A reference to the extended ruleset is
2829 carried in Section 4.5. The format of these rules is described in
2830 [RFC4745] and [GEO-POLICY].
2832 Req. 11. (Limited Rule language): A limited (or basic) ruleset is
2833 provided by the Policy-Information Attribute in Section 4.4 (and
2834 as introduced with PIDF-LO [RFC4119]).
2836 Section 7.4 of [RFC3693] details the requirements of a "Location
2837 Object Privacy and Security". These requirements are listed below.
2839 Req. 12 (Identity Protection): Support for unlinkable pseudonyms is
2840 provided by the usage of a corresponding authentication and key-
2841 exchange protocol. Such protocols are available, for example,
2842 with the support of EAP as network-access authentication methods.
2843 Some EAP methods support passive user-identity confidentiality,
2844 whereas others even support active user-identity confidentiality.
2845 This issue is further discussed in Section 7. The importance for
2846 user-identity confidentiality and identity protection has already
2847 been recognized as an important property (see, for example, a
2848 document on EAP method requirements for wireless LANs [RFC4017]).
2850 Req. 13. (Credential Requirements): As described in Section 7 ,
2851 RADIUS signaling messages can be protected with IPsec. This
2852 allows a number of authentication and key exchange protocols to be
2853 used as part of IKE, IKEv2, or KINK.
2858 Tschofenig, et al. Standards Track [Page 51]
2860 RFC 5580 Carrying LOs in RADIUS and Diameter August 2009
2863 Req. 14. (Security Features): GEOPRIV defines a few security
2864 requirements for the protection of Location Objects, such as
2865 mutual end-point authentication, data object integrity, data
2866 object confidentiality, and replay protection. As described in
2867 Section 7, these requirements are fulfilled with the usage of
2868 IPsec if mutual authentication refers to the RADIUS entities
2869 (acting as various GEOPRIV entities) that directly communicate
2872 Req. 15. (Minimal Crypto): A minimum of security mechanisms are
2873 mandated by the usage of RADIUS. Communication security for
2874 Location Objects between RADIUS infrastructure elements is
2875 provided by the RADIUS protocol (including IPsec and its dynamic
2876 key-management framework), rather than relying on object security
2877 via S/SIME (which is not available with RADIUS).
2914 Tschofenig, et al. Standards Track [Page 52]
2916 RFC 5580 Carrying LOs in RADIUS and Diameter August 2009
2921 Hannes Tschofenig (editor)
2922 Nokia Siemens Networks
2927 Phone: +358 (50) 4871445
2928 EMail: Hannes.Tschofenig@gmx.net
2929 URI: http://www.tschofenig.priv.at
2934 2111 N.E. 25th Avenue
2938 EMail: farid.adrangi@intel.com
2942 Bridgewater Systems Corporation
2944 Ottawa, Ontario K2K 3J1
2947 EMail: mark.jones@bridgewatersystems.com
2951 Bridgewater Systems Corporation
2953 Ottawa, Ontario K2K 3J1
2956 EMail: avi@bridgewatersystems.com
2960 Microsoft Corporation
2965 EMail: bernarda@microsoft.com
2970 Tschofenig, et al. Standards Track [Page 53]
projects / freeradius.git / blob