idnits 2.17.00 (12 Aug 2021) /tmp/idnits23975/draft-ietf-geopriv-arch-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3693, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3694, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3693, updated by this document, for RFC5378 checks: 2002-06-25) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 9, 2009) is 4698 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '19' is defined on line 1845, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 1848, but no explicit reference was found in the text == Outdated reference: draft-ietf-geopriv-policy has been published as RFC 6772 == Outdated reference: draft-ietf-geopriv-l7-lcp-ps has been published as RFC 5687 -- Obsolete informational reference (is this intentional?): RFC 3825 (ref. '9') (Obsoleted by RFC 6225) == Outdated reference: A later version (-19) exists of draft-ietf-geopriv-dhcp-lbyr-uri-option-04 == Outdated reference: draft-ietf-geopriv-http-location-delivery has been published as RFC 5985 == Outdated reference: draft-ietf-geopriv-lbyr-requirements has been published as RFC 5808 == Outdated reference: draft-ietf-ecrit-framework has been published as RFC 6443 == Outdated reference: draft-ietf-ecrit-phonebcp has been published as RFC 6881 == Outdated reference: draft-ietf-ecrit-mapping-arch has been published as RFC 5582 Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GEOPRIV R. Barnes 3 Internet-Draft M. Lepinski 4 Updates: 3693, 3694 BBN Technologies 5 (if approved) A. Cooper 6 Intended status: BCP J. Morris 7 Expires: January 10, 2010 Center for Democracy & 8 Technology 9 H. Tschofenig 10 Nokia Siemens Networks 11 H. Schulzrinne 12 Columbia University 13 July 9, 2009 15 An Architecture for Location and Location Privacy in Internet 16 Applications 17 draft-ietf-geopriv-arch-00 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. This document may contain material 23 from IETF Documents or IETF Contributions published or made publicly 24 available before November 10, 2008. The person(s) controlling the 25 copyright in some of this material may not have granted the IETF 26 Trust the right to allow modifications of such material outside the 27 IETF Standards Process. Without obtaining an adequate license from 28 the person(s) controlling the copyright in such materials, this 29 document may not be modified outside the IETF Standards Process, and 30 derivative works of it may not be created outside the IETF Standards 31 Process, except to format it for publication as an RFC or to 32 translate it into languages other than English. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as Internet- 37 Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/ietf/1id-abstracts.txt. 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html. 50 This Internet-Draft will expire on January 10, 2010. 52 Copyright Notice 54 Copyright (c) 2009 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents in effect on the date of 59 publication of this document (http://trustee.ietf.org/license-info). 60 Please review these documents carefully, as they describe your rights 61 and restrictions with respect to this document. 63 Abstract 65 Location-based services (such as navigation applications, emergency 66 services, management of equipment in the field) need geographic 67 location information about Internet hosts, their users, and other 68 related entities. These applications need to securely gather and 69 transfer location information for location services, and at the same 70 time protect the privacy of the individuals involved. This document 71 describes an architecture for privacy-preserving location-based 72 services in the Internet, focusing on authorization, security, and 73 privacy requirements for the data formats and protocols used by these 74 services. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 79 1.1. Binding Rules to Data . . . . . . . . . . . . . . . . . . 4 80 1.2. Location-Specific Privacy Risks . . . . . . . . . . . . . 5 81 1.3. Privacy Paradigms . . . . . . . . . . . . . . . . . . . . 6 82 2. Overview of the Architecture . . . . . . . . . . . . . . . . . 7 83 2.1. Basic Geopriv Scenario . . . . . . . . . . . . . . . . . . 8 84 2.2. Roles and Data Formats . . . . . . . . . . . . . . . . . . 9 85 2.3. Relationships Between Geopriv Roles . . . . . . . . . . . 12 86 3. The Location Life-Cycle . . . . . . . . . . . . . . . . . . . 13 87 3.1. Positioning . . . . . . . . . . . . . . . . . . . . . . . 14 88 3.1.1. Determination Mechanisms and Protocols . . . . . . . . 14 89 3.1.2. Privacy Considerations for Positioning . . . . . . . . 16 90 3.1.3. Security Considerations for Positioning . . . . . . . 17 91 3.2. Location Distribution . . . . . . . . . . . . . . . . . . 17 92 3.2.1. Privacy Rules . . . . . . . . . . . . . . . . . . . . 18 93 3.2.2. Location Configuration . . . . . . . . . . . . . . . . 20 94 3.2.3. Location References . . . . . . . . . . . . . . . . . 20 95 3.2.4. Privacy Considerations for Distribution . . . . . . . 21 96 3.2.5. Security Considerations for Distribution . . . . . . . 22 97 3.3. Location Use . . . . . . . . . . . . . . . . . . . . . . . 23 98 3.3.1. Privacy Considerations for Use . . . . . . . . . . . . 24 99 3.3.2. Security Considerations for Use . . . . . . . . . . . 24 100 4. Security Considerations . . . . . . . . . . . . . . . . . . . 24 101 4.1. Threats to Location Objects . . . . . . . . . . . . . . . 24 102 4.1.1. Threats to Location Integrity and Authenticity . . . . 25 103 4.1.2. Threats to Location Privacy . . . . . . . . . . . . . 26 104 4.2. Required Assurances . . . . . . . . . . . . . . . . . . . 26 105 4.3. Protocol mechanisms . . . . . . . . . . . . . . . . . . . 28 106 4.4. Mechanisms within the Location Object . . . . . . . . . . 28 107 5. Example Scenarios . . . . . . . . . . . . . . . . . . . . . . 29 108 5.1. Minimal Scenario . . . . . . . . . . . . . . . . . . . . . 30 109 5.2. Location-based Web Services . . . . . . . . . . . . . . . 30 110 5.3. Emergency Calling . . . . . . . . . . . . . . . . . . . . 33 111 5.4. Combination of Services . . . . . . . . . . . . . . . . . 34 112 6. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 113 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39 114 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 115 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 116 9.1. Normative References . . . . . . . . . . . . . . . . . . . 39 117 9.2. Informative References . . . . . . . . . . . . . . . . . . 39 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 120 1. Introduction 122 Location-based services (applications that require information about 123 the geographic location of an individual or device) are becoming 124 increasingly common on the Internet. Navigation and direction 125 services, emergency services, friend finders, management of equipment 126 in the field and many other applications require geographic location 127 information about Internet hosts, their users, and other related 128 entities. As the accuracy of location information improves and the 129 expense of calculating and obtaining it declines, the distribution 130 and use of location information in Internet-based services will 131 likely become increasingly pervasive. Ensuring that location 132 information is transmitted and accessed in a secure and privacy- 133 protective way is essential to the future success of these services, 134 as well as the minimization of the privacy harms that could flow from 135 their wide deployment and use. 137 Standards for communicating location information over the Internet 138 have an important role to play in providing a technical basis for 139 privacy and security protection. This document describes a 140 standardized privacy- and security-focused architecture for location- 141 based services in the Internet: the Geopriv architecture. The 142 central component of the Geopriv architecture is the location object, 143 which is used to convey both location information about an individual 144 or device and user-specified privacy rules governing that location 145 information. As location information moves through its life cycle -- 146 positioning, distribution, and use by its ultimate recipient(s) -- 147 Geopriv provides mechanisms to secure the integrity and 148 confidentiality of location objects and to ensure that location 149 information is only transmitted in compliance with the user's privacy 150 rules. 152 The goals of this document are two-fold: First, the architecture 153 described revises and expands on the basic Geopriv Requirements 154 [2][3], in order to clarify how these privacy concerns and the 155 Geopriv architecture apply to use cases that have arisen since the 156 publication of those documents. Second, this document provides a 157 general introduction to Geopriv and Internet location-based services, 158 and is useful as a good first document for readers new to Geopriv. 160 1.1. Binding Rules to Data 162 A central feature of the Geopriv architecture is that location 163 information is always bound to privacy rules to ensure that entities 164 that receive location are informed of how they may use it. These 165 rules can convey simple directives ("do not share my location with 166 others"), or more robust preferences ("allow my spouse to know my 167 exact location all of the time, but only allow my boss to know it 168 during work hours"). By creating a structure to convey the user's 169 preferences along with location information, the likelihood that 170 those preferences will be honored necessarily increases. In 171 particular, no recipient of the location information can disavow 172 knowledge of users' preferences for how their location may be used. 173 The binding of privacy rules to location information can convey 174 users' desire for and expectations of privacy, which in turn helps to 175 bolster social and legal systems' protection of those expectations. 177 Binding of usage rules to sensitive information is a common way of 178 protecting information. Several emerging schemes for expressing 179 copyright information provide for rules to be transmitted together 180 with copyrighted works. The Creative Commons [21] model is the most 181 prominent example, allowing an owner of a work to set four types of 182 rules ("Attribution," "Noncommercial," "No Derivative Works" and 183 "ShareAlike") governing the subsequent use of the work. After the 184 author sets these rules, the rules are conveyed together with the 185 work itself, so that every recipient is aware of the copyright terms. 187 Classification systems for controlling sensitive documents within an 188 organization are another example. In these systems, when a document 189 is created, it is marked with a classification such as "SECRET" or 190 "PROPRIETARY." Each recipient of the document knows from this 191 marking that the document should only be shared with other people who 192 are authorized to access documents with that marking. Classification 193 markings can also convey other sorts of rules, such as a 194 specification for how long the marking is valid (a declassification 195 date). The United States Department of Defense guidelines for 196 classification [4] provides one example. 198 1.2. Location-Specific Privacy Risks 200 While location-based services raise some privacy concerns that are 201 common to all forms of personal information, many of them are 202 heightened and others are uniquely applicable in the context of 203 location information. 205 Location information is frequently generated on or by mobile devices. 206 Because individuals often carry their mobile devices with them, 207 location data may be collected everywhere and at any time, often 208 without user interaction, and it may potentially describe both what a 209 person is doing and where he or she is doing it. For example, 210 location data can reveal the fact that an individual was at a 211 particular medical clinic at a particular time. The ubiquity of 212 location information may also increase the risks of stalking and 213 domestic violence if perpetrators are able to use (or abuse) 214 location-based services to gain access to location information about 215 their victims. 217 Location information is also of particular interest to governments 218 and law enforcers around the world. The existence of detailed 219 records of individuals' movements should not automatically facilitate 220 the ability for governments to track their citizens, but in some 221 jurisdictions, laws dictating what government agents must do to 222 obtain location data are either non-existent or out-of-date. 224 1.3. Privacy Paradigms 226 Traditionally, the extent to which data about individuals enjoys 227 privacy protections on the Internet has largely been decided by the 228 recipients of the data. Internet users may or may not be aware of 229 the privacy practices of the entities with whom they share data. 230 Even if they are aware, they have generally been limited to making a 231 binary choice between sharing data with a particular entity or not 232 sharing it. Internet users have not historically been granted the 233 opportunity to express their own privacy preferences to the 234 recipients of their data and to have those preferences honored. 236 This paradigm is problematic because the interests of data recipients 237 are often not aligned with the interests of data subjects. While 238 both parties may agree that data should be collected, used, disclosed 239 and retained as necessary to deliver a particular service to the data 240 subject, they may not agree about how the data should otherwise be 241 used. For example, an Internet user may gladly provide his email 242 address on a Web site to receive a newsletter, but he may not want 243 the Web site to share his email address with marketers, whereas the 244 Web site may profit from such sharing. Neither providing the address 245 for both purposes nor deciding not to provide it is an optimal option 246 from the Internet user's perspective. 248 The Geopriv model departs from this paradigm for privacy protection. 249 As explained above, location information can be uniquely sensitive. 250 And as siloed location-based services emerge and proliferate, they 251 increasingly require standardized protocols for communicating 252 location information between services and entities. Recognizing both 253 of these dynamics, Geopriv gives data subjects the ability to express 254 their choices with respect to their own location information, rather 255 than allowing the recipients of the information to define how it will 256 be used. The combination of heightened privacy risk and the need for 257 standardization compelled the Geopriv designers to shift away from 258 the prevailing Internet privacy model, instead empowering users to 259 express their privacy preferences about the use of their location 260 information. 262 Geopriv does not, by itself, provide technical means through which it 263 can be guaranteed that users' location privacy rules will be honored 264 by recipients. The privacy protections in the Geopriv architecture 265 are largely provided by virtue of the fact that recipients of 266 location are informed of relevant privacy rules, and are expected to 267 only use location in accordance with those rules. The distributed 268 nature of the architecture inherently limits the degree to which 269 compliance can be guaranteed and verified by technical means. 270 Section 4 describes how some security mechanisms can address this to 271 a limited extent. 273 By binding privacy rules to location information, however, Geopriv 274 provides valuable information about users' privacy preferences, so 275 that non-technical forces such as legal contracts, governmental 276 consumer protection authorities, and marketplace feedback can better 277 enforce those privacy preferences. If a commercial recipient of 278 location information, for example, violates the location rules bound 279 to the information, the recipient can in a growing number of 280 countries be charged with violating consumer or data protection laws. 281 In the absence of a binding of rules with location information, 282 consumer protection authorities would be less able to protect 283 consumers whose location information has been abused. 285 2. Overview of the Architecture 287 This section provides an overview of the Geopriv architecture for the 288 secure and private distribution of location information on the 289 Internet. We describe the three phases of the "location life cycle" 290 -- positioning, distribution and use -- and discuss how the 291 components of the architecture fit within each phase. The next 292 section provides additional detail about how each phase can be 293 achieved in a private and secure manner. 295 The risks discussed in the previous section all arise from 296 unauthorized disclosure or usage of location information. Thus, the 297 Geopriv architecture has two fundamental privacy goals: 299 1. Ensure that location information is distributed only to 300 authorized entities, and 302 2. Provide information to those entities about how they are 303 authorized to use the location information. 305 If these two goals are met, all parties that receive location 306 information will also receive directives about how they can use that 307 information. Privacy-preserving entities will only engage in 308 authorized uses, and entities that violate privacy will do so 309 knowingly, since they have been informed of what is authorized (and 310 thus, implicitly, of what is not). 312 Privacy rules and their distribution are thus the central technical 313 components of the privacy system, since they inform location 314 recipients about how they are authorized to use that information. 315 The two goals in the preceding paragraph are enabled by two classes 316 of rules: 318 1. Access control rules: Rules that describe which entities may 319 receive location information and in what form 321 2. Usage rules: Rules that describe what uses of location 322 information are authorized 324 Within this framework for privacy, security mechanisms provide 325 support for the application of privacy rules. For example, 326 authentication mechanisms validate the identities of entities 327 requesting location (so that authorization and access-control 328 policies can be applied), and confidentiality mechanisms protect 329 location information en route between privacy-preserving entities. 330 Security mechanisms can also provide assurances that are outside the 331 purview of privacy by, for example, assuring location recipients that 332 location information has been faithfully transmitted to them by its 333 creator. 335 2.1. Basic Geopriv Scenario 337 As location information is transmitted among Internet hosts, it goes 338 through a "location life-cycle:" first, the location is computed 339 based on some external information (positioning), then it is 340 transmitted from one host to another (distribution) until finally it 341 is used by a recipient (use). 343 For example, suppose Alice learns of her location from a wireless 344 location service and wishes to share it privately with her friends by 345 way of a presence service. Alice clearly needs to provide the 346 presence server with her location and rules about which friends can 347 be provided with her location. To enable Alice's friends to preserve 348 her privacy, they need to be provided with privacy rules. Alice may 349 tell some of her friends the rules directly, or she can have the 350 presence server provide the rules to her friends when it provides 351 them with her location. In this way, every friend who receives 352 Alice's location is authorized by Alice to receive it, and every 353 friend who receives it knows the rules. Good friends will obey the 354 rules. If a bad friend breaks them and Alice finds out, the bad 355 friend cannot claim that he was unaware of the rules. 357 Some of Alice's friends will be interested in using Alice's location 358 only for their own purposes (to meet up with her or plot her location 359 over time, for example). The usage rules that they receive direct 360 them as to what they can or cannot do (for example, Alice might not 361 want them keeping her location for more than, say, two weeks). 363 Consider one friend, Bob, who wants to send Alice's location to some 364 of his friends. To operate in a privacy-protective way, Bob needs 365 not only usage rules for himself, but also access control rules that 366 describe who he can send information to and rules to give to the 367 recipients. If the rules he received from the presence server 368 authorize him to give Alice's location to others, he may do so; 369 otherwise, he will require additional rules from Alice before he is 370 authorized to distribute her location. If recipients who receive 371 Alice's location from Bob want to distribute the location on further, 372 they must go through the same process as Bob. 374 The whole example is illustrated in the following figure: 376 +----------+ 377 | Wireless | 378 | Location | 379 | Service | Retrieve 380 +----------+ Access Control Rules 381 | +--------------------------------+ 382 | | +--------------------------+ | 383 Location | | Access | | 384 | | | Control Rules v | 385 | | | +-----+ 386 | | | | | 387 | | | | Bob |--> ... 388 | | | +----->| | 389 v v | | +-----+ 390 +-------+ +----------+ | 391 | |--Location->| Presence |--Location---->| +----------+ 392 | Alice | | Server | |---->| Friend-1 | 393 | |---Rules--->| |---Rules------>| +----------+ 394 +-------+ +----------+ | 395 | 396 | +----------+ 397 +---->| Friend-2 | 398 +----------+ 400 Figure 1: Basic Geopriv Scenario 402 2.2. Roles and Data Formats 404 The above example illustrates the five basic roles in the Geopriv 405 architecture: 407 Target: An individual or other entity whose location is sought in 408 the Geopriv architecture. The Target is the entity whose privacy 409 Geopriv seeks to protect. Alice is the Target in Figure 1. 411 Rule Maker (RM): Performs the role of creating rules governing 412 access to location information for a Target. In some cases the 413 Target performs the Rule Maker role (as is the case with Alice), 414 and in other cases they are separate. For example, a parent may 415 serve as the Rule Maker when the Target is his child, or a 416 corporate security officer may serve as the Rule Maker for devices 417 owned by the corporation but used by employees. The Rule Maker is 418 also not necessarily the owner of a Target device. For example, a 419 corporation may provide a device to an employee but permit the 420 employee to serve as the Rule Maker and set her own privacy rules. 422 Location Generator (LG): Performs the roles of initially 423 determining or gathering the location of the Target and providing 424 it to Location Servers. Location Generators may be any sort of 425 software or hardware used to obtain the Target's location 426 (examples include GPS chips and cellular networks). A Target may 427 even perform the Location Generator role for itself; devices 428 capable of unassisted satellite-based positioning and devices that 429 accept manually entered location information are two examples. 430 The wireless location service plays the Location Generator role in 431 Figure 1. 433 Location Server (LS): Performs the roles of receiving location 434 information and rules, applying the rules to the location 435 information to determine what other entities, if any, can receive 436 location information, and providing the location to Location 437 Recpients. Location Servers receive location information from 438 Location Generators and rules from Rule Makers, and then apply the 439 rules to the location information. Location Servers may not 440 necessarily be "servers" in the colloquial sense of hosts in 441 remote data centers servicing requests. Rather, a Location Server 442 can be any software or hardware component that distributes 443 location information. Examples include a server in an access 444 network, a presence server, or a Web browser or other software 445 running on a Target's device. The above example includes three 446 Location Servers: Alice, the presence service and Bob. 448 Location Recipient (LR): Performs the role of receiving location 449 information. A Location Recipient may ask for location explicitly 450 (by sending a query to a Location Server), or it may receive 451 location asynchronously. The presence service, Bob, Friend-1 and 452 Friend-2 are Location Recipients in Figure 1. 454 In general, these roles may or may not be performed by physically 455 separate entities, as demonstrated by the entities in Figure 1, many 456 of which perform multiple roles. It is not uncommon for the same 457 entity to perform both the LG and LS roles, or both the LR and LS 458 roles. A single entity may take on multiple roles simply by virtue 459 of its own capabilities and the permissions provided to it. 461 Two data formats are necessary within this architecture: 463 Location Object (LO): An object used to convey location information 464 together with Privacy Rules. Geopriv supports both geodetic 465 location data (latitude/longitude/altitude/etc.) and civic 466 location data (street/city/state/etc.). Either or both types of 467 location information may be present in a single LO. Location 468 Objects typically include some sort of identifier associated with 469 the Target. 471 Privacy Rule: A directive that regulates an entity's activities 472 with respect to location information, including the collection, 473 use, disclosure, and retention of the location information. 474 Privacy Rules describe which entities may obtain location 475 information in what form (access control rules) and how location 476 information may be used by an entity (usage rules). 478 The whole example, using Geopriv roles and formats, is illustrated in 479 the following figure: 481 +----+ 482 | LG | 483 +----+ 484 ^ 485 | 486 Positioning 487 Data 488 | 489 | +------------Privacy Rules------------------>+----+ 490 | | +---->| LR |--> ... 491 | | | | LS | 492 v | | +----+ 493 +-------+ | 494 |Target | +----+ | +----+ 495 | RM |--------------->| LR |---------------+---->| LR | 496 | LS | LO | LS | LO | +----+ 497 | | +----+ | 498 +-------+ | 499 | +----+ 500 +---->| LR | 501 +----+ 503 Figure 2: Basic Geopriv Scenario 505 2.3. Relationships Between Geopriv Roles 507 Although in the above example there is only a single Location 508 Generator and a single Rule Maker, in some cases a Location Server 509 may receive Location Objects from multiple Location Generators or 510 Rules from multiple Rule Makers. Likewise, a single Location 511 Generator may publish location information to multiple Location 512 Servers, and a single Location Recipient may receive Location Objects 513 from multiple Location Servers. 515 The term "Target" may refer not only to an individual whose location 516 is described by a LO, but also to that individual's device, since the 517 device engages in protocol interactions, not the individual. For the 518 remainder of this document, the term "Target" refers to the device. 519 Geopriv can also be used to convey location information about a 520 device that is not directly linked to a single individual, such as a 521 package or product containing a location-capable sensor, or a device 522 linked to multiple individuals. 524 3. The Location Life-Cycle 526 The previous section gave an example of how an individual's location 527 can be distributed through the Internet. In general, the location 528 life-cycle breaks down into three phases: 530 1. Positioning: A Location Generator determines the Target's 531 location 533 2. Distribution: Location Servers send location to Location 534 Recipients, which may in turn act as Location Servers and further 535 distribute location to other Location Recipients (possibly 536 several times) 538 3. Use: A Location Recipient receives the location and uses it. 540 Each of these phases involves a different set of Geopriv roles and 541 each has a different set of privacy and security implications. The 542 Geopriv roles are mapped onto the location life-cycle in the figure 543 below. 545 +----------+ +----------+ 546 | | | Rule |+ 547 | Target | | Maker(s)|| 548 | | | || 549 +----------+ +----------+| 550 ^| +----------+ 551 || Positioning | Rules 552 || Data | 553 || | 554 |V V 555 +----------+ +----------+ +----------+ 556 |Location | Location | Location |+ LO |Location | 557 |Generator |--------------->| Server(s)||-------------->|Recipient | 558 | | | || | | 559 +----------+ +----------+| +----------+ 560 +----------+ 561 <-------------------------><---------------------------><-----------> 562 Positioning Distribution Use 564 Figure 3: Location Life-Cycle 566 3.1. Positioning 568 Positioning is the process by which the physical location of the 569 Target is computed, based on some observations about the Target's 570 situation in the physical world. (This process goes by several other 571 names, including Location Determination or Sighting.) The input to 572 the positioning process is some information about the Target, and the 573 outcome is that the Location Generator knows the location of the 574 Target. 576 In this section, we give a brief taxonomy of current positioning 577 systems, their requirements for protocol support, and the privacy and 578 security requirements for positioning. 580 3.1.1. Determination Mechanisms and Protocols 582 While the specific positioning mechanisms that can be applied for a 583 given Target are strongly dependent on the physical situation and 584 capabilities of the Target, these mechanisms generally fall into the 585 three categories described in detail below: 587 o Target-based 589 o Network-based 591 o Network-assisted 593 As suggested by the above names, a positioning scheme can rely on the 594 Target, an Internet-accessible resource (not necessarily a network 595 operator), or a combination of the two. For a given scheme, the 596 nature of this reliance will dictate the protocol mechanisms needed 597 to support it. 599 With Target-based positioning mechanisms, the Target is capable of 600 determining its location by itself. This is the case for manually- 601 entered location or for (unassisted) satellite-based positioning 602 (using a Global Navigation Satellite System, or GNSS). In these 603 cases, the Target acts as its own Location Generator, and there are 604 no protocols required to support positioning (since no information 605 needs to be communicated). 607 In network-based positioning schemes, an external Location Generator 608 (an Internet host other than the Target) has access to sufficient 609 information about the Target, through out-of-band channels, to 610 establish the position of the Target. The most common examples of 611 this type of LG are entities that have a physical relationship to the 612 Target (such as ISPs). In wired networks, wiremap-based location is 613 a network-based technique; in wireless networks, timing and signal- 614 strength based techniques that use measurements from base stations 615 are considered to be network-based. Large-scale IP-to-geo databases 616 (for example, those based on WHOIS data or latency measurements) are 617 also considered to be network-based positioning mechanisms. 619 For network-based positioning as for Target-based, no protocols are 620 strictly necessary to support positioning, since positioning 621 information is collected outside of the location distribution system 622 (at lower layers of the network stack, for example). This does not 623 rule out the use of other Internet protocols (like SNMP) to collect 624 inputs to the positioning process. Rather, since these inputs can 625 only be used by certain Location Generators to determine location, 626 they are not controlled as private information. Network-based 627 positioning often provides location to protocols by which the network 628 informs a Target device of its own location (these are known as 629 Location Configuration Protocols, see Section 3.2.2 for further 630 discussion). 632 Network-assisted systems account for the greatest number and 633 diversity of positioning schemes. In these systems, the work of 634 positioning is divided between the Target and an external Location 635 Generator via some communication (possibly over the Internet), 636 typically in one of two ways: 638 o The Target provides measurements to the LG 640 o The LG provides assistance data to the Target 642 "Measurements" are understood to be observations about the Target's 643 environment, ranging from wireless signal strengths to the MAC 644 address of a first-hop router. "Assistance" is the complement to 645 measurement, namely the information that enables the computation of 646 location based on measurements. A set of wireless base station 647 locations (or wireless calibration information) would be an 648 assistance datum, as would be a table that maps routers to buildings 649 in a corporate campus. 651 For example, wireless and wired networks can serve as the basis for 652 network-assisted positioning. In several current 802.11 positioning 653 systems, the Target sends measurements (e.g., MAC addresses and 654 signal strengths) to a Location Generator, and the Location Generator 655 returns a location to the client. In wired networks, the Target can 656 send its MAC address to the Location Generator, which can query the 657 MAC-layer infrastructure to determine the switch and port to which 658 that MAC address is connected, then query a wire map to determine the 659 location at which the wire connected to that port terminates. 661 As an aside, the common phrase "assisted GPS" ("assisted GNSS" more 662 broadly) actually encompasses techniques that transmit both 663 measurements and assistance data. Systems in which the Target 664 provides the Location Generator with GNSS measurements are 665 measurement-based, while those in which the assistance server provide 666 ephemeris or alamanac data are assistance-based in the above 667 terminology. (Those familiar with GNSS positioning will note that 668 there are of course cases in which both of these interactions occur 669 within a single location determination protocol, so the categories 670 are not mutually exclusive.) 672 Naturally, the exchange of measurement or positioning data between 673 the Target and the LG requires a protocol over which the information 674 is carried. The structure of this protocol will depend on which of 675 the two patterns a network-assisted scheme follows. Conversely, the 676 structure of the protocol will determine which of the two parties 677 (the Target, the LG, or both) is aware of the Target's location at 678 the end of the protocol interaction. 680 3.1.2. Privacy Considerations for Positioning 682 Positioning is the first point at which location may be associated 683 with a particular Target's identity. Local identifiers, unlinked 684 pseudonyms, or private identifiers that are not linked to the real 685 identity of the Target should be used as forms of identity whenever 686 possible. This provides privacy protection by disassociating the 687 location from the Target's identity before it is distributed. 689 At the conclusion of the positioning process, the entity acting as 690 the LG has the Target's location (if the Target is performing the LG 691 role, then they both have it). If the entity acting as the LG also 692 performs the role of LS, the privacy considerations in Section 3.2.4 693 apply. 695 In some deployment scenarios, positioning functions and distribution 696 functions may need to be provided by separate entities, in which case 697 the LG and LS roles will not be performed by the same entity. In 698 this situation, the LG acts as a "dumb," non-privacy-aware 699 positioning resource, and the LS provides the privacy logic necessary 700 to support distribution (possibly with multiple LSes using the same 701 LG). In order to allow the privacy-unaware LG to distribute location 702 to these LSes while maintaining privacy, the relationship between the 703 LG and its set of LSes MUST be tightly constrained, effectively 704 "hard-wired." That is, the LG MUST only provide location to a small 705 fixed set of LSes, and each of these LSes MUST comply with the 706 requirements of Section 3.2.4. 708 3.1.3. Security Considerations for Positioning 710 Manipulation of the positioning process can expose location through 711 two mechanisms: If a third party can guess measurements that a given 712 Target would send and use them to get the location of that Target, or 713 if a third party can obtain assistance data that indicate the rough 714 position of the Target. To mitigate this risk, the LG should be able 715 to authenticate positioning clients (the Target or other information 716 sources) in the sense of verifying that measurements presented by a 717 client are likely to be the actual physical values measured by that 718 client (and likewise, that the requested assistance data are 719 consistent with the client's actual rough position). These 720 authentication mechanisms will necessarily rely on the nature of the 721 positioning being done, and may not be technically feasible in all 722 cases. 724 In any case, protocols used for positioning must provide 725 confidentiality and integrity protections in order to prevent 726 observation and modification of transmitted positioning data while en 727 route between the positioning client and the LG. 729 If a Location Generator or a Target chooses to act as a Location 730 Server, it inherits the security requirements for an LS, described in 731 Section 3.2.5. 733 3.2. Location Distribution 735 When an entity receives location (from an LG or an LS) and 736 redistributes it to other entities, it acts as a Location Server. 737 Location Distribution is the process by which one or more Location 738 Servers provide LOs to Location Recipients in a privacy-preserving 739 manner. 741 The role of a Location Server is thus two-fold: First, it must 742 collect location information and Rules that control access to that 743 information. Rules can be communicated within a Location Object, 744 within a protocol that carries LOs, or through a separate protocol 745 that carries Rules. Second, the Location Server must process 746 requests for location and apply the Rules to these requests in order 747 to determine whether it is authorized to fulfill them by returning 748 location information. 750 A Location Server thus has at least two types of interactions with 751 other hosts, namely receiving and sending Location Objects. An LS 752 may optionally implement a third interaction, allowing Rule Makers to 753 provision it with Rules. The distinction between these two cases is 754 important in practice, because it determines whether the LS has a 755 direct relationship with a Rule Maker: An LS that accepts Rules 756 directly from a Rule Maker has such a relationship, while an LS that 757 acquires all its Rules through LOs does not. 759 3.2.1. Privacy Rules 761 Privacy Rules are the central mechanism in Geopriv for maintaining a 762 Target's privacy, because they provide a recipient of a LO (an LS or 763 LR) with information on how the LO may be used. 765 Throughout the Geopriv architecture, Privacy Rules are communicated 766 in rules languages with a defined syntax and semantics. For example, 767 the Common Policy rules language has been defined [5] to provide a 768 framework for broad-based rule specifications. Geopriv Policy [6] 769 defines a language for creating location-specific rules. XCAP [7] 770 can be used as a protocol to install rules in both of these formats. 772 Privacy Rules follow a default-deny pattern: an empty set of Rules 773 implies that all requests for location should be denied (other than 774 requests made by the Target itself), with each Rule added to the set 775 granting a specific permission. Adding a Rule to a set can never 776 reduce existing permissions; it can only augment them. 778 The following are examples of Privacy Rules governing location 779 distribution: 781 o Retransmit location when requested from example.com 783 o Retransmit only city and country 785 o Retransmit location with no less than a 100 meter radius of 786 uncertainty 788 o Retransmit location only for the next two weeks 790 Location Servers enforce Privacy Rules in two ways: by denying 791 requests for location, or by transforming the location information 792 before retransmitting it. 794 Location Servers may also receive Rules governing location retention, 795 such as "Retain location only for 48 hours." Such Rules are simply 796 directives about how long the Target's location information can be 797 retained. 799 Privacy Rules can govern the behavior of both Location Servers and 800 Location Recipients. Rules that direct Location Servers about how to 801 treat a Target's location information are known as Local Rules. 802 Local Rules are used internally by the Location Server to handle 803 requests from Location Recipients. They are not distributed to 804 Location Recipients. 806 Forwarded Rules, on the other hand, travel inside LOs and direct 807 Location Servers and Location Recipients about how to handle the 808 location information they receive. Because the Rules themselves may 809 reveal potentially sensitive information about the Target, only the 810 minimal subset of Forwarded Rules necessary to handle the LO is 811 distributed. 813 An example can illustrate the interaction between Local Rules and 814 Forwarded Rules. Suppose Alice provides the following Local Rules to 815 a Location Server: 817 o The LS may retransmit Alice's precise location to Bob, who in turn 818 is permitted to retain the location information for one month 820 o The LS may retransmit Alice's city, state, and country to Steve, 821 who in turn is permitted to retain the location information for 822 one hour 824 o The LS may retransmit Alice's country to a photo-sharing website, 825 which in turn is permitted to retain the location information for 826 one year and retransmit it to any requesters 828 When Steve asks for Alice's location, the Location Server can 829 transmit to Steve the limited location information (city, state, and 830 country) along with Forwarded Rules instructing Steve to (a) not 831 further retransmit Alice's location information, and (b) only retain 832 the location information for one hour. By only sending these 833 specifically applicable Forwarded Rules to Steve (as opposed to the 834 full set of Local Rules), the LS is protecting Alice's privacy by not 835 disclosing to Steve that (for example) Alice allows Bob to obtain 836 more precise location information than Alice allows Steve to receive. 838 Geopriv is designed to be usable even by devices with constrained 839 processing capabilities. To ensure that Forwarded Rules can be 840 processed on constrained devices, LOs are required to carry only a 841 limited set of Forwarded Rules, with an option to reference a more 842 robust set of external Rules. The limited Rule set covers two 843 privacy aspects: how long the Target's location may be retained 844 ("Retention"), and whether or not the Target's location may be 845 retransmitted ("Retransmission"). A LO may contain a pointer to more 846 robust Rules, such as those shown in the set of four Rules at the 847 beginning of this section. 849 3.2.2. Location Configuration 851 Some performing the Location Generator role are designed only to 852 provide Targets with their own locations (as opposed to distributing 853 a Target's location to others). The process of providing a Target 854 with its own location is known within Geopriv as Location 855 Configuration, and the LG that provides such location is often 856 described as a Location Information Server (LIS). Protocols used 857 exclusively to communicate location from a LIS to a Target are known 858 as Location Configuration Protocols [8]. Several such protocols have 859 been developed within Geopriv [9][10][11][12]. 861 By definition, a LIS needs only to follow a simple privacy-preserving 862 policy: transmit a Target's location only to the Target itself. This 863 is known as the "LCP policy." 865 Importantly, if an LS is also serving in the role of LG and it has 866 not been provisioned with Privacy Rules for a particular Target, it 867 MUST follow the LCP policy, whether it is a LIS or not. In the 868 positioning phase, an entity serving the roles of both LG and LS that 869 has not received Privacy Rules must follow this policy. The same is 870 true for any LS in the distribution phase. 872 3.2.3. Location References 874 The location distribution process occurs through a series of 875 transmissions of Location Objects: transmissions of location "by 876 value." Location "by value" can be expressed in terms of geodetic 877 location data (latitude/longitude/altitude/etc.) and civic location 878 data (street/city/state/etc.). 880 Location can also be distributed "by reference," where a reference is 881 represented by a URI that can be dereferenced to obtain the LO. This 882 document summarizes the properties of location-by-reference that are 883 discussed at length in [13]. 885 Distribution of location by reference (distribution of location URIs) 886 offer several benefits. Location URIs are a more compact way of 887 transmitting location, since URIs are usually smaller than LOs. A 888 recipient of location can make multiple requests to a URI over time 889 to receive updated location (if the URI is configured to provide 890 fresh location rather than a single "snapshot"). 892 From a positioning perspective, location by reference can offer the 893 additional benefit of "just in time" positioning. If location is 894 distributed by reference, an entity acting as a combined LG/LS only 895 needs to perform positioning operations when a recipient dereferences 896 a previously distributed URI. 898 From a privacy perspective, distributing location as a URI instead of 899 as a Location Object can help protect privacy by forcing each 900 recipient of the location to request location from the referenced LS, 901 which can then apply access controls individually to each recipient. 902 But the benefit provided here is contingent on the LS applying access 903 controls. If the LS does not apply an access control policy to 904 requests for a location URI (in other words, if it enforces the 905 "possession model" defined in [13]), then transmitting a location URI 906 presents the same privacy risks as transmitting the Location Object 907 itself. Moreover, the use of location URIs without access controls 908 can introduce additional privacy risks: If URIs predictable, an 909 attacker to whom the URI has not been sent may be able to guess the 910 URI and use it to obtain the referenced LO. To mitigate this, 911 location URIs without access controls need to be constructed so that 912 they contain a random component with sufficient entropy to make 913 guessing infeasible. 915 3.2.4. Privacy Considerations for Distribution 917 Location information MUST be accompanied by Rules throughout the 918 distribution process. Otherwise, a recipient will not know what uses 919 are authorized, and will not be able to use the LO. Consequently, 920 LOs MUST be able to express Rules that convey appropriate 921 authorizations. 923 An LS MUST only accept Rules from authorized Rule Makers. For an LS 924 that receives Rules exclusively in LOs and has no direct relationship 925 with a Rule Maker, this requirement is met by applying the Rules 926 provided in a LO to the distribution of that LO. For an LS with a 927 direct relationship to a Rule Maker, this requirement means that the 928 LS MUST be configurable with an RM authorization policy. An LS 929 SHOULD define a prescribed set of RMs that may provide Rules for a 930 given Target or LO. For example, an LS may only allow the Target to 931 set Rules for itself, or it might allow an RM to set Rules for 932 several Targets (e.g., a parent for children, or a corporate security 933 officer for employees). 935 No matter how Rules are provided to an LS, for each LO it receives, 936 it MUST combine all Rules that apply to the LO into a Rule set that 937 defines which transmissions are authorized, and it MUST transmit 938 location only in ways that are authorized by these Rules. 940 An LS that receives Rules exclusively through LOs MUST examine the 941 Rules that accompany a given LO in order to determine how the LS may 942 use the LO (if any Rules are included by reference, the LS SHOULD 943 attempt to download them). If the LO includes no Rules that allow 944 the LS to transmit the LO to another entity, then the LS MUST NOT 945 transmit the LO. If the LO contains no Rules at all (if it is in a 946 format with no Rules syntax, for example), then the LS MUST delete 947 it. 949 An LS that receives Rules both directly from one or more Rule Makers 950 and through LOs MUST combine the Rules in a given LO with Rules it 951 has received from the RMs. The strategy the LS uses to combine these 952 sets of Rules is a matter for local policy, depending on the relative 953 priority that the LS grants to each source of Rules. Some example 954 policies: 956 Union: A transmission of location is authorized if it is authorized 957 by either a rule in the LO or an RM-provided rule. 959 Intersection: A transmission of location is authorized if it is 960 authorized by both a rule in the LO and an RM-provided rule. 962 RM Override: A transmission of location is authorized if it is 963 authorized by an RM-provided rule (regardless of the LO Rules). 965 LO Override: A transmission of location is authorized if it is 966 authorized by a LO-provided rule (regardless of the RM Rules). 968 In general, it is RECOMMENDED that an LS follow the "Intersection" 969 policy, since it grants equal weight to all RMs (including the LO 970 creator). In cases where an external RM is more trusted than the 971 source of the LO, the "RM Override" policy may be more suitable (for 972 example, if the external RM is the Target, and the LO is provided by 973 a third party). Conversely, the "LO Override" policy is best suited 974 to cases where the LO provider is more trused than the RM (for 975 example, if the RM is the user of a mobile device LS and the LO 976 contains Rules from the RM's parents or corporate security office). 978 3.2.5. Security Considerations for Distribution 980 An LS's decisions about how to transmit location are based on the 981 identities of entities requesting information and other aspects of 982 requests for location. In order to ensure that these decisions are 983 made properly, the LS needs assurance of the reliability of 984 information on the identities of the entities with which the LS 985 interacts (including LRs, LSes, and RMs) and other information in the 986 request. 988 Protocols to convey LOs and protocols to convey Rules MUST provide 989 information on the identity of the recipient of location and the 990 identity of the RM, respectively. In order to ensure the validity of 991 this information, these protocols MUST allow for mutual 992 authentication of both parties, and MUST provide integrity protection 993 for protocol messages. These security features ensure that the LG 994 has sufficient information (and sufficiently reliable information) to 995 make privacy decisions. 997 As they travel through the Internet, Location Objects necessarily 998 pass through a sequence of intermediaries, ranging from layer-2 999 switches to IP routers to application-layer proxies and gateways. 1000 The ability of an LS to protect privacy by making access-control 1001 decisions is reduced if these intermediaries have access to a 1002 Location Object as it travels between privacy-preserving entities. 1004 Protocols carrying LOs MUST provide end-to-end confidentiality 1005 between an LS that transmits location and the LR that receives it. 1006 When the protocol itself is protected end-to-end between the LS and 1007 the recipient, carrying an unprotected Location Object within this 1008 encrypted channel is sufficient. When the protocol has a mode in 1009 which messages are either unprotected or protected on a hop-by-hop 1010 basis (e.g., between intermediaries in a store-and-forward protocol), 1011 the protocol SHOULD allow the use of encrypted LOs, or for the 1012 transmission of a reference to location in place of a LO [13]. 1014 3.3. Location Use 1016 The primary privacy requirement of a Location Recipient is to 1017 constrain its usage of location to the set of uses authorized by the 1018 Rules in a LO. If an LR only uses a LO in ways that have minimal 1019 privacy impact -- specifically, if it does not transmit the LO to any 1020 other entity, and does not retain the LO for longer than is required 1021 to complete its interaction with the LS -- then no further action is 1022 necessary for the LR to comply with Geopriv requirements. 1024 As an example of this simplest case, if a Location Recipient (a) 1025 receives a location, (b) immediately provides to the Target 1026 information or a service based on the location, (c) does not retain 1027 the information, and (d) does not retransmit the location to any 1028 other entity, then the LR will comply with any set of Rules that are 1029 permissible under Geopriv. Thus, a service that, for example, only 1030 provides directions to the closest bookstore in response to an input 1031 of location, and promptly then discards the input location, will be 1032 in compliance with any Geopriv Rule set. 1034 LRs that make other uses of a LO (e.g., those that store LOs, or send 1035 them to other service providers to obtain location-based services) 1036 MUST meet the requirements below to assure that these uses are 1037 authorized. 1039 3.3.1. Privacy Considerations for Use 1041 The principle privacy requirement for Location Recipients is to 1042 follow usage rules. When an LR receives a LO, it is REQUIRED to 1043 examine the Rules included with that LO. Any usage the LR makes of 1044 the LO MUST be explicitly authorized by these Rules. Since Rules are 1045 positive grants of permission, any action not explicitly authorized 1046 is denied by default. 1048 3.3.2. Security Considerations for Use 1050 Since the Location Recipient role does not involve transmission of 1051 location, there are no protocol security considerations required to 1052 support privacy. 1054 Aside from privacy, Location Recipients often require some assurance 1055 that a LO is reliable (assurance of the integrity, authenticity, and 1056 validity of an LO), since LRs use LOs in order to deliver location- 1057 based services. Threats against this reliability and corresponding 1058 mitigations are discussed in the Security Considerations below. 1060 4. Security Considerations 1062 Security considerations related to the privacy of Location Objects 1063 are discussed throughout this document. In this section we summarize 1064 those concerns and consider security risks not related to privacy. 1066 The life-cycle of a Location Object often consists of a series of 1067 location transmissions. In a scenario where some intermediaries are 1068 untrusted, a location recipient may desire additional assurances that 1069 the LO was generated by a trusted LG, and not modified by these 1070 untrusted entities. In this section, we first consider threats and 1071 possible attacks against a Location Object throughout its entire life 1072 cycle. We then describe the assurances that various parties require 1073 to mitigate these threats. Finally, we discuss possible mechanisms 1074 that protocols or Location Object formats should make available to 1075 provide such assurances. 1077 4.1. Threats to Location Objects 1079 The major threats to the end-to-end security of Location Objects can 1080 be grouped into two categories: First, threats against the integrity 1081 and authenticity of Location Objects can expose entities that rely on 1082 Location Objects to many types of fraud. Second, threats against the 1083 confidentiality of Location Objects can allow unauthorized access to 1084 location information. 1086 4.1.1. Threats to Location Integrity and Authenticity 1088 A Location Object contains four essential types of information: 1089 Identifiers for the described Target, location information, time- 1090 stamps, and Rules. By grouping values of these various types 1091 together within a single structure, a Location Object encodes a set 1092 of bindings among them. That is, the Location Object asserts that 1093 the identified Target was present at the given location at the given 1094 time and that the given Rules express the Target's desired policy at 1095 that time for the distribution of his location. Below, we provide a 1096 set of attacks that a malicious party (an intermediate LS, an 1097 eavesdropper on the path between LS and LR, or the Target himself) 1098 might conduct to falsify one or more of the bindings asserted by the 1099 Location Object. 1101 In all cases the Target identity provided in a Location Object should 1102 be based on an authentication between the Target and the Location 1103 Generator (an explicit authentication based on a shared secret, or an 1104 implicit authentication based on the ability to receive a message, 1105 for example). Therefore, the identity binding in a received Location 1106 Object is only as strong as the authentication between the Target and 1107 the Location Generator (that is, the Location Object can only attest 1108 to the fact that someone at the given location is capable of 1109 authenticating as the given identity). It is vital to the 1110 authenticity of location information that this authentication be as 1111 strong as is feasible in any deployment scenario. However, 1112 mechanisms within a Geopriv Location Object or protocol can provide 1113 no protection from attacks against this authentication mechanism and 1114 thus we do not explicitly consider such attacks. 1116 Place Shifting: Falsifying the location in an otherwise valid 1117 Location Object. For example, Alice pretends that she is 1118 currently in a location that she has never previously visited. 1120 Time Shifting: Falsifying the time-stamp in an otherwise valid 1121 Location Object. For example, Alice pretends that she is 1122 currently in a location that she has not visited since last year. 1124 Location Theft: Falsifying the identity in an otherwise valid 1125 Location Object. For example, a malicious intermediary sees a 1126 valid Location Object for Alice and produces a Location Object 1127 asserting that Bob is at the given location at the given time. 1129 Location-Identity Theft: Replaying a stale Location Object as though 1130 it were current. For example, a malicious intermediary sees a 1131 valid Location Object for Alice and replays it later to make it 1132 seem that Alice has not moved. 1134 Location Swapping: Two malicious Targets conspire to produce two 1135 Location Objects asserting that each Target is at the other's 1136 location. For example, Alice pretends that she is at Bob's 1137 location and Bob pretends that he is at Alice's location. (Note 1138 that this attack cannot be prevented if the two attackers are 1139 willing to exchange authentication credentials. Because the 1140 identity assertions in a Location Object are only as strong as the 1141 Target authentication, the goal of Geopriv protocols is to ensure 1142 that this attack is not possible unless both Alice and Bob can 1143 successfully authenticate as the other.) 1145 4.1.2. Threats to Location Privacy 1147 In the Geopriv model, the privacy of location information is 1148 protected by the application of Privacy Rules specified by authorized 1149 Rule Makers and by confidentiality protection en route. (For more 1150 information on Privacy Rule enforcement, see Section 3.2.4). Below, 1151 we provide a set of attacks that a malicious party might conduct to 1152 allow distribution of a Location Object to unauthorized parties. 1154 Eavesdropping: An unauthorized party observes the Location Object in 1155 transit. For example, a device on the path between a trusted LS 1156 and an authorized LR observes a Location Object sent in the clear. 1158 Rule Tampering: A malicious party modifies a Target's Privacy Rules 1159 and thus causes a trusted LS to unknowingly distribute the 1160 Location Object to unauthorized parties. For example, a device on 1161 the path between an LG and a trusted LS deletes the Privacy Rules 1162 contained in a Location Object and replaces them with a new set of 1163 Rules authorizing all parties to receive the Location Object. 1165 Server Impersonation: A malicious party impersonates a trusted 1166 Location Server and then knowingly disregards the Privacy Rules. 1167 For example, a man-in-the-middle between the LG and the trusted LS 1168 pretends to be the trusted LS, and then proceeds to distribute the 1169 Location Object to unauthorized entities. 1171 4.2. Required Assurances 1173 We now describe the assurances required by each party involved in 1174 location distribution in order to mitigate the attacks described in 1175 the previous two sections: 1177 Rule Maker: The Rule Maker is responsible for distributing the 1178 Target's Privacy Rules to the location servers. The primary 1179 assurance required by the Rule Maker is thus that the binding 1180 between the Target's Privacy Rules and the Target's identity is 1181 correctly conveyed to each location server that handles the 1182 Location Object. Ensuring the integrity of the Privacy Rules 1183 distributed to the location servers prevents rule-tampering 1184 attacks. In many circumstances, the privacy policy of the Target 1185 may itself be sensitive information; in these cases, the Rule 1186 Maker also requires the assurance that the binding between the 1187 Target's identity and the Target's Privacy Rules are not deducible 1188 by anyone other than an authorized Location Server. 1190 Location Server: The Location Server is responsible for enforcing 1191 the Target's Privacy Rules. The first assurance required by the 1192 Location Server is that the binding between the Target's Privacy 1193 Rules and the Target's identity is authentic. Authenticating the 1194 Rule Maker who created the Privacy Rules prevents rule-tampering 1195 attacks. The second assurance required by the Location Server is 1196 that the binding between the Target's identity and the Target's 1197 location are not deducible by any entity except as allowed the 1198 Target's Privacy Rules. Ensuring the confidentiality of these 1199 bindings prevents eavesdropping attacks. (Note that ensuring the 1200 confidentiality of the Location Object also helps to mitigate 1201 location-theft and location-identity-theft attacks, since it makes 1202 it more difficult for an attacker to obtain a valid Location 1203 Object to replay.) 1205 Location Recipient: The Location Recipient is the consumer of the 1206 Location Object. The Location Recipient thus requires assurances 1207 about the authenticity of the bindings between the Target's 1208 location, the Target's identity and the time. Ensuring the 1209 authenticity of these bindings prevents place-shifting, time- 1210 shifting, location-theft, and location-identity-theft attacks and 1211 mitigates location-swapping attacks to the greatest possible 1212 extent. 1214 Location Generator: The Location Generator shares responsibility for 1215 protecting the Target's privacy. The primary assurance required 1216 by the Location Generator is that the Location Server to which the 1217 Location Object is initially published is one that is trusted to 1218 enforce the Target's Privacy Rules. Authenticating the trusted 1219 Location Server mitigates the risk of server impersonation 1220 attacks. Additionally, in some scenarios, there may be no 1221 Location Server which can be trusted to sufficiently safe-guard 1222 the Target's location information, in which case the Location 1223 Generator may require assurance that intermediate Location Servers 1224 are unable to deduce the binding between the Target's identity and 1225 the Target's location. 1227 4.3. Protocol mechanisms 1229 Protocols that carry location can provide strong assurances, but only 1230 for a single segment of the Location Object's life cycle. In 1231 particular, a protocol can provide integrity protection and 1232 confidentiality for the data exchanged, and mutual authentication of 1233 the parties involved in the protocol, by using a secure transport 1234 such as IPsec or TLS. 1236 Additionally, if (1) the protocol provides mutual authentication for 1237 every segment; and (2) every entity in the location distribution 1238 chain exchanges information only with entities with whom it has a 1239 trust relationship, then entities can transitively obtain assurances 1240 regarding the origin and ultimate destination of the Location Object. 1241 Of course, direct assurances are always preferred over assurances 1242 requiring transitive trust, since they require fewer assumptions. 1244 Using protocol mechanisms alone, the entities can receive assurances 1245 only about a single hop in the distribution chain. For example, 1246 suppose that an LR receives location from an LS over an integrity- 1247 and confidentiality-protected channel. The LR knows that the 1248 transmitted LO has not been modified or observed en route. However, 1249 the assurances provided by the protocol do not guarantee that the 1250 transmitted LO was not corrupted before it was sent to the LS (by a 1251 previous LS, for example). Likewise, the LR can verify that the LO 1252 was transmitted by the LS, but cannot verify the origin of the LO if 1253 it did not originate with the LS. 1255 Security mechanisms in protocols are thus unable to provide direct 1256 assurances over multiple transmissions of an LO. However, it should 1257 be noted that the transmission of location "by reference" can be used 1258 to effectively turn multi-hop paths into single-hop paths. If the 1259 multiple transmissions of a LO are replaced by multiple transmissions 1260 of URI (a multi-hop dissemination channel), then the LO need only 1261 traverse a single hop, namely the dereference transaction between the 1262 LR and the dereference server. 1264 4.4. Mechanisms within the Location Object 1266 Assurances as to the integrity and confidentiality of a Location 1267 Object can be provided directly through the Location Object format. 1268 Additionally, the Location Object format can be used to authenticate 1269 the originator of a Location Object. In particular, integrity and 1270 origin authentication can be assured by signing a Location Object 1271 (e.g., using S/MIME or XMLSIG), and confidentiality can be assured by 1272 encrypting the Location Object using a public encryption key 1273 belonging to the intended recipient (e.g. using S/MIME). Recipients 1274 of Location Objects secured in this fashion can obtain assurance as 1275 to the integrity and authenticity of the Location Object even after 1276 it has been handled by untrusted intermediaries. Similarly, a 1277 Location Server (or Location Generator) that guarantees 1278 confidentiality in this fashion can be assured that the Location 1279 Object is protected from unauthorized viewing even in the presence of 1280 untrusted intermediaries. 1282 Although such direct, end-to-end assurances are desirable, and these 1283 mechanisms should be used whenever possible, there are many 1284 deployment scenarios where directly securing a Location Object is 1285 impractical. In particular, in some deployment scenarios a direct 1286 trust relationship may not exist between the creator of the Location 1287 Object and the recipient. Additionally, in a scenario where many 1288 recipients are authorized to receive a given Location Object, the 1289 creator of the Location Object cannot guarantee end-to-end 1290 confidentiality without knowing precisely which recipient will 1291 receive the Location Object. 1293 An additional challenge in providing end-to-end authenticity 1294 guarantees through signing of the Location Object is that in many 1295 deployments different entities may assert different bindings within 1296 the same Location Object. Consider, for example, a scenario where a 1297 Location Generator produces a Location Object that asserts a binding 1298 between a time, a location, and a pseudonym for the Target. 1299 Additionally, a Rule Maker creates a binding between a set of Privacy 1300 Rules and a public Target identity. A Location Server receives the 1301 Rules binding from Rule Maker and the Location Object from the 1302 Location Generator. The Location Server then generates a new 1303 Location Object binding together the time, the location, the public 1304 Target identity and the Privacy Rules. In such a scenario there is 1305 no single entity who can directly assert the validity of the entire 1306 Location Object. In such a case, a mechanism is needed within the 1307 Location Object format that allows multiple originators to jointly 1308 assert various components of the Location Object bindings. 1310 5. Example Scenarios 1312 This section contains a set of example of how the Geopriv 1313 architecture can be deployed in practice. These examples are meant 1314 to illustrate key points of the architecture, rather than to form an 1315 exhaustive set of use cases. 1317 For convenience and clarity in these examples, we assume that the 1318 Privacy Rules that a LO carries are equivalent to those in a PIDF-LO 1319 Location Object (namely, that the principal Rules that can be set are 1320 limits on the retransmission and retention of the LO). While these 1321 two Rules are the most well-known and important examples, the 1322 specific types of Rules an LS or LR must consider will in general 1323 depend on the types of LO it processes. 1325 5.1. Minimal Scenario 1327 One of the simplest scenarios in the Geopriv architecture is when a 1328 Target determines its own location and uses that LO to request a 1329 service (e.g., by including the LO in an HTTP POST request or SIP 1330 INVITE message), and the server delivers that service immediately 1331 (e.g., in a 200 OK response in HTTP or SIP), without retaining or 1332 retransmitting the Target's location. The Target acts as an LG by 1333 using a Target-based positioning algorithm (e.g., manual entry), as a 1334 Rule Maker by specifying that the location should be sent to the 1335 server, and as a Location Server by interpreting the rule and 1336 transmitting the LO. The server acts as a Location Recipient by 1337 receiving and using the LO. 1339 In this case, the privacy of location information is maintained in 1340 two steps: The first step is that location is only transmitted as 1341 directed by the single Rule Maker, namely the Target. The second 1342 step is simply the fact that the server, as LR, does not do anything 1343 that creates a privacy risk -- it does not retain or retransmit 1344 location. Because the server limits its behavior in this way, it 1345 does not need to read the Rules in the LO (even though they were 1346 provided) -- no Rule would prevent it from using location in this 1347 safe manner. 1349 The following outline summarizes this scenario: 1351 o Positioning: Target-based, Target=LG 1353 o Distribution hop 1: HTTP UA --> Ephemeral web service, privacy via 1354 user indication 1356 o Use: Ephemeral web service delivers response without retaining or 1357 retransmitting location 1359 o Key points: 1361 * LRs that do not behave in ways that risk privacy are Geopriv- 1362 compliant by default. No further action is necessary. 1364 5.2. Location-based Web Services 1366 Many location-based services are delivered over the Web, using 1367 Javascript code to orchestrate a series of HTTP requests for location 1368 specific information. To support these applications, browser 1369 extensions have been developed that support Target-based positioning 1370 (manual entry and GPS) and network-assisted positioning (via AGPS, 1371 and multilateration with 802.11 and cellular signals), exposing 1372 position to web pages through Javascript APIs. 1374 In this scenario, we consider a Target that uses a browser with a 1375 network-assisted positioning extension. When the Target uses this 1376 browser to request location-based services from a web page, the 1377 browser prompts the user to grant the page permission to access the 1378 user's location. If the user grants permission, the browser 1379 extension sends 802.11 signal strength measurements to a positioning 1380 server, which then returns the position of the host. The extension 1381 constructs a Location Object with this location and Rules set by the 1382 user, then passes the LO to the page through its Javascript API. The 1383 page then obtains location-relevant information using an 1384 XMLHttpRequest [14] to a server in the same domain as the page and 1385 renders this information to the user. 1387 At first blush, this scenario seems much more complicated than the 1388 minimal scenario above. However, most of the privacy considerations 1389 are actually the same. 1391 The positioning phase in this scenario begins when the browser 1392 extension contacts the positioning server. The positioning server 1393 acts as a Location Generator. 1395 The distribution phase actually occurs entirely within the Target 1396 host. This phase begins when the positioning server, now acting as 1397 LS, follows the LCP policy by providing location only to the Target. 1398 The next hop in distribution occurs when the browser extension (an 1399 entity under the control of the Target) passes a LO to the web page 1400 (an entity under the control of its author). In this phase, the 1401 browser extension acts as an LS, with the user/Target as the sole 1402 Rule Maker; the user interface for rule-making is effectively a 1403 protocol for conveying Rules, and the extension's API effectively 1404 defines a a way to communicate LOs and a LO Format. The web site 1405 acts as Location Recipient when the web page accepts the LO. 1407 The use phase encompasses the web site's use of the LO. In this 1408 context, the phrase "web site" encompasses not only the web page, but 1409 also the dedicated supporting logic behind it. Considering the 1410 entire web site as a recipient, rather than a single page, it becomes 1411 clear that sending the LO in an XMLHttpRequest to a back-end server 1412 is like passing it to a separate component of the LR (as opposed to 1413 retransmitting it to another entity). Thus, even in this case, where 1414 location-relevant information is obtained from a back-end server, the 1415 LR does not retain or retransmit location, so its behavior is 1416 "privacy-safe" -- it doesn't need to interpret the Rules in the LO. 1418 However, consider a variation on this scenario where the web page 1419 requests additional information (a map, for instance) from a third- 1420 party site. In this case, since location is being transmitted to a 1421 third party, the web site (either in the web page or in a back-end 1422 server) would need to verify that this transmission is allowed by the 1423 LO's Privacy Rules. Similarly, if the site wanted to log the user's 1424 location information, then it would need to examine the LO to 1425 determine how long this information can be retained. In such a case, 1426 if the LR needs to do something that is not allowed by the Rules, it 1427 may have to deny service to the user (hopefully providing a message 1428 with the reason). Nonetheless, if the Rules permit retention or 1429 retransmission (even if this retransmission is limited by access 1430 control rules), then the LR may do so to the extent the Rules allow. 1432 The following outline summarizes this scenario: 1434 o Positioning: Network-assisted, positioning server=LG 1436 o Rule installation: RM (=Target/user) gives permission to sites and 1437 sets LO Rules 1439 o Distribution hop 1: positioning server=LS --> Target, privacy via 1440 LCP policy 1442 o Distribution hop 2: Browser=LS --> Web site=LR, privacy via user 1443 confirmation 1445 o Use: Back-end server delivers location-relevant information 1446 without further retransmission, then deletes location; privacy via 1447 safe behavior 1449 o Key points: 1451 * Privacy in this scenario is provided by a combination of 1452 explicit user direction and Rules in an LO 1454 * Distribution can occur within a host, between mutually 1455 untrusting components 1457 * Some transmissions of location are actually internal to an LR 1459 * LRs that do things that might be constrained by Rules need to 1460 verify that these actions are allowed for a particular LO 1462 5.3. Emergency Calling 1464 Support for emergency calls by Voice-over-IP devices is a critical 1465 use case for location information about Internet hosts. The details 1466 of the Internet architecture for emergency calling are described in 1467 [15][16]. In this architecture, there are three critical steps in 1468 the placement of an emergency call, each involving location 1469 information: 1471 1. Determine the location of the caller 1473 2. Determine the proper Public Safety Answering Point (PSAP) for the 1474 caller's location 1476 3. Send a SIP INVITE message (including the caller's location) to 1477 the PSAP 1479 The first step in an emergency call is to determine the location of 1480 the caller. This step is the positioning phase of the location life- 1481 cycle. Location is determined by whatever means are available to the 1482 caller's device, or to the network, if this step is being done by a 1483 proxy. Whichever entity does the positioning (either the caller or a 1484 proxy) acts as an Location Server, preserving the privacy of location 1485 information by only including it in emergency calls. 1487 The second step in an emergency call encompasses location 1488 distribution and use. The entity that is routing the emergency call 1489 sends location though the LoST protocol [17] to a mapping server. In 1490 this role, the routing entity acts as a Location Server and the LoST 1491 server acts as a Location Recipient. The LO format within LoST does 1492 not allow Rules to be sent along with location, but because LoST is 1493 an application-specific protocol, the sending of location within a 1494 LoST message authorizes the LoST server to use the location to 1495 complete the protocol, namely to route the message as necessary 1496 through the LoST mapping architecture [18]. That is, the LoST server 1497 is authorized to complete the LoST protocol, but to do nothing else. 1499 The third step in an emergency call is again a combination of 1500 distribution and use. The caller (or another entity that inserts the 1501 caller's location) acts as an LS and the PSAP acts as a Location 1502 Recipient. In this specific example, the caller's location is 1503 transmitted either as a PIDF-LO object or as a reference that returns 1504 a PIDF-LO (or both); in the latter case, the reference should be 1505 appropriately protected so that only the PSAP has access. In any 1506 case, the receipt of a LO implies that the PSAP should obey the Rules 1507 in those LOs in order to preserve privacy. Depending on the 1508 regulatory environment, the PSAP may have the option to ignore those 1509 constraints in order to respond to an emergency, or it may be bound 1510 to respect these Rules (in spite of the emergency situation). 1512 The following outline summarizes this scenario: 1514 o Positioning: Any 1516 o Distribution/use hop 1: Target=LS --> LoST infrastructure (no 1517 Rules), privacy via authorization implicit in protocol 1519 o Distribution/use hop 2: Target=LS --> PSAP, privacy via Rules in 1520 LO 1522 o Use: PSAP uses location to deliver emergency services 1524 o Key points: 1526 * Privacy in this scenario is provided by a combination of 1527 explicit user direction, implicit authorization particular to a 1528 protocol, and Rules in an LO 1530 * LRs may be constrained to respect or ignore Privacy Rules by 1531 local regulation 1533 5.4. Combination of Services 1535 In modern Internet applications, users frequently receive information 1536 via one channel and broadcast it via another. In this sense, both 1537 users and channels (e.g., web services) become location servers. 1538 Here we consider a more complex example that illustrates this pattern 1539 across multiple logical hops. 1541 Suppose Alice (the Target) subscribes to a wireless ISP that 1542 determines her location using a network-based positioning technique 1543 (e.g., via the location of the base station serving the Target), and 1544 provides that information directly to a location-enhanced presence 1545 provider (which might use SIP, XMPP, or another protocol). The 1546 location-enhanced presence provider allows Alice to specify Rules for 1547 how this location is distributed: which friends should receive 1548 Alice's location and what Rules they should get with it. Alice uses 1549 a few other location-enhanced services as well, so she sends Rules 1550 that allow her location to be shared with those services, and allow 1551 those services to retain and retransmit her location. 1553 Bob is one of Alice's friends, and he receives her location via this 1554 location-enhanced presence service. Noting that she's at their 1555 favorite coffee shop, Bob wants to upload a photo of the two of them 1556 at the coffee shop to a photo-sharing site, along with a LO that 1557 marks the location. Bob checks the Rules in Alice's LO and verifies 1558 that the photo sharing site is one of the services that Alice 1559 authorized. Seeing that Alice has authorized him to give the LO to 1560 the photo-sharing site, he attaches it to the photo and uploads it. 1562 Once the geo-tagged photo is uploaded, the photo sharing site reads 1563 the Rules in the LO and verifies that the site is authorized to store 1564 the photo and to share it with others. Since Alice has allowed the 1565 site to retransmit and retain without any constraints, the site 1566 fulfills Bob's request to make the geo-tagged photo publicly 1567 accessible. 1569 Eve, another user of the photo sharing site, downloads the photo of 1570 Alice and Bob at the coffee shop and receives Alice's LO along with 1571 it. Eve posts the photo and location to her public page on a social 1572 networking site without checking the Rules, even though the LO 1573 doesn't allow Eve to send the location anywhere else. The social 1574 networking site, however, observes that no retransmission or 1575 retention are allowed (both of which it needs for a public posting), 1576 and rejects the upload. 1578 In terms of the location life-cycle, this scenario consists of a 1579 positioning step, followed by four distribution hops and use. 1580 Positioning is the simplest step: An LG in Alice's ISP monitors her 1581 location and transmits it to the presence service, maintaining 1582 privacy by only transmitting location to a single entity (to which 1583 Alice has delegated privacy responsibilities). 1585 The first distribution hop occurs when the presence server sends 1586 location to Bob. In this transaction, the presence server acts as an 1587 LS, Alice acts as an RM, and Bob acts as an LR. The privacy of this 1588 transaction is assured by the fact that Alice has installed Rules on 1589 the presence server that dictate who it may allow to access her 1590 location. The second distribution hop is when Bob uploads the LO to 1591 the photo-sharing site. Here Bob acts as an LS, preserving the 1592 privacy of location information by verifying that the Rules in the LO 1593 allow him to upload it. The third distribution hop is when the 1594 photo-sharing site sends the LO to Eve, likewise following the Rules 1595 -- but a different set of Rules than Bob, since a LO can specify 1596 different Rule sets for different Location Servers. 1598 Eve is the fourth LS in the chain, and fails to comply with Geopriv 1599 by not checking the Rules in the LO prior to uploading the LO to the 1600 social networking site. The site, however, is a responsible LR -- it 1601 checks the Rules in the LO, sees that they don't allow it to use the 1602 location as it needs to, and discards the LO. 1604 The following outline summarizes this scenario: 1606 o Positioning: Network-based, LG in network, privacy via exclusive 1607 relationship with presence service 1609 o Distribution/use hop 1: Presence server --> Bob, privacy via 1610 Alice's access control rules 1612 o Distribution/use hop 2: Bob --> photo sharing site, privacy via 1613 Rules for Bob in LO 1615 o Distribution/use hop 3: Photo sharing site --> Eve, privacy via 1616 Rules for site in LO 1618 o Distribution/use hop 4: Eve --> Social networking site, violates 1619 privacy by retransmitting 1621 o Use: Social networking site, privacy via checking Rules and 1622 discarding 1624 o Key points: 1626 * Privacy can be preserved through multiple hops 1628 * A LO can specify different Rules for different entities 1630 * An LS can still disobey the Rules, but even then, the 1631 architecture still works in some cases 1633 6. Glossary 1635 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 1636 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 1637 document are to be interpreted as described in RFC 2119 [1]. 1639 $ Access Control Rule 1641 A rule that describe which entities may receive location 1642 information and in what form. 1644 $ civic location 1646 The geographic position of an entity in terms of a postal address 1647 or civic landmark. Examples of such data are room number, street 1648 number, street name, city, ZIP code, county, state and country. 1650 $ geodetic location 1652 The geographic position of an entity in a particular coordinate 1653 system (for example, a latitude-longitude pair). 1655 $ Local Rule 1657 A Privacy Rules that directs a Location Server about how to treat 1658 a Target's location information. Local Rules are used internally 1659 by a Location Server to handle requests from Location Recipients. 1660 They are not distributed to Location Recipients. 1662 $ Location Generator (LG) 1664 Performs the role of initially determining or gathering the 1665 location of a Target. Location Generators may be any sort of 1666 software or hardware used to obtain a Target's location (examples 1667 include GPS chips and cellular networks). 1669 $ Location Information Server (LIS) 1671 An entity responsible for providing devices within an access 1672 network with information about their own locations. A Location 1673 Information Server uses knowledge of the access network and its 1674 physical topology to generate and distribute location information 1675 to devices. 1677 $ Location Object (LO) 1679 A data unit that conveys location information together with 1680 Privacy Rules within the Geopriv architecture. A Location Object 1681 may convey geodetic location data (latitiude/longitude/altitude), 1682 civic location data (street/city/state/etc.), or both. 1684 $ Location Recipient (LR) 1686 An ultimate end point entity to which a Location Object is 1687 distributed. Location Recipients request location information 1688 about a particular Target from a Location Server. If allowed by 1689 the appropriate Privacy Rules, a Location Recipient will receive 1690 Location Objects describing the Target's location from the 1691 Location Server. 1693 $ Location Server (LS) 1694 An entity that receives Location Objects from Location Generators, 1695 Privacy Rules from Rule Makers, and location requests from 1696 Location Recipients. A Location Server applies the appropriate 1697 Privacy Rules to a Location Object received from a Location 1698 Generator and may disclose the Location Object, in compliance with 1699 the Rules, to Location Recipients. 1701 Location Servers may not necessarily be "servers" in the 1702 colloquial sense of hosts in remote data centers servicing 1703 requests. Rather, a Location Server can be any software or 1704 hardware component that receives and distributes location 1705 information. Examples include a positioning server (with a 1706 location interface) in an access network, a presence server, or a 1707 Web browser or other software running on a Target's device. 1709 $ Privacy Rule 1711 A directive that regulates an entity's activities with respect to 1712 a Target's location information, including the collection, use, 1713 disclosure, and retention of the location information. Privacy 1714 Rules describe how location information may be used by an entity, 1715 the level of detail with which location information may be 1716 described to an entity, and the conditions under which location 1717 information may be disclosed to an entity. Privacy Rules are 1718 communicated from Rule Makers to Location Servers and conveyed in 1719 Location Objects throughout the Geopriv architecture. 1721 $ Rule 1723 See Privacy Rule. 1725 $ Rule Maker (RM) 1727 An individual or entity that is authorized to set Privacy Rules 1728 for a Target. In some cases a Rule Maker and a Target will be the 1729 same individual or entity, and in other cases they will be 1730 separate. For example, a parent may serve as the Rule Maker when 1731 the Target is his child. The Rule Maker is also not necessarily 1732 the owner of a Target device. For example, a corporation may own 1733 a device that it provides to an employee but permit the employee 1734 to serve as the Rule Maker and set her own Privacy Rules. Rule 1735 Makers provide the Privacy Rules associated with a Target to 1736 Location Servers. 1738 $ Forwarded Rule 1739 A Privacy Rule that travels inside a Location Object. Forwarded 1740 Rules direct Location Recipients about how to handle the location 1741 information they receive. Because the Forwarded Rules themselves 1742 may reveal potentially sensitive information about a Target, only 1743 the minimal subset of Forwarded Rules necessary for a Location 1744 Recipient to handle a Location Object is distributed to the 1745 Location Recipient. 1747 $ Target 1749 An individual or other entity whose location is described by a 1750 Location Object. The Target is the entity whose privacy Geopriv 1751 seeks to protect. 1753 $ Usage Rule 1755 A rule that describe what uses of location information are 1756 authorized. 1758 7. Acknowledgements 1760 Section 4 is largely based on the security investigations conducted 1761 as part of the Geopriv Layer-7 Location Configuration Protocol design 1762 team, which produced [8]. We would like to thank all the members of 1763 the design team. 1765 8. IANA Considerations 1767 This document makes no request of IANA. 1769 9. References 1771 9.1. Normative References 1773 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1774 Levels", BCP 14, RFC 2119, March 1997. 1776 9.2. Informative References 1778 [2] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. 1779 Polk, "Geopriv Requirements", RFC 3693, February 2004. 1781 [3] Danley, M., Mulligan, D., Morris, J., and J. Peterson, "Threat 1782 Analysis of the Geopriv Protocol", RFC 3694, February 2004. 1784 [4] U.S. Department of Defense, "National Industrial Security 1785 Program Operating Manual", DoD 5220-22M, January 1995. 1787 [5] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk, 1788 J., and J. Rosenberg, "Common Policy: A Document Format for 1789 Expressing Privacy Preferences", RFC 4745, February 2007. 1791 [6] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., and 1792 J. Polk, "Geolocation Policy: A Document Format for Expressing 1793 Privacy Preferences for Location Information", 1794 draft-ietf-geopriv-policy-20 (work in progress), February 2009. 1796 [7] Rosenberg, J., "The Extensible Markup Language (XML) 1797 Configuration Access Protocol (XCAP)", RFC 4825, May 2007. 1799 [8] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location 1800 Configuration Protocol; Problem Statement and Requirements", 1801 draft-ietf-geopriv-l7-lcp-ps-09 (work in progress), 1802 February 2009. 1804 [9] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host 1805 Configuration Protocol Option for Coordinate-based Location 1806 Configuration Information", RFC 3825, July 2004. 1808 [10] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 1809 and DHCPv6) Option for Civic Addresses Configuration 1810 Information", RFC 4776, November 2006. 1812 [11] Polk, J., "Dynamic Host Configuration Protocol (DHCP) IPv4 and 1813 IPv6 Option for a Location Uniform Resource Identifier (URI)", 1814 draft-ietf-geopriv-dhcp-lbyr-uri-option-04 (work in progress), 1815 March 2009. 1817 [12] Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, "HTTP 1818 Enabled Location Delivery (HELD)", 1819 draft-ietf-geopriv-http-location-delivery-15 (work in 1820 progress), June 2009. 1822 [13] Marshall, R., "Requirements for a Location-by-Reference 1823 Mechanism", draft-ietf-geopriv-lbyr-requirements-07 (work in 1824 progress), February 2009. 1826 [14] World Wide Web Consortium, "The XMLHttpRequest Object", W3C 1827 document http://www.w3.org/TR/XMLHttpRequest/, April 2008. 1829 [15] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, "Framework 1830 for Emergency Calling using Internet Multimedia", 1831 draft-ietf-ecrit-framework-09 (work in progress), March 2009. 1833 [16] Rosen, B. and J. Polk, "Best Current Practice for 1834 Communications Services in support of Emergency Calling", 1835 draft-ietf-ecrit-phonebcp-11 (work in progress), June 2009. 1837 [17] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, 1838 "LoST: A Location-to-Service Translation Protocol", RFC 5222, 1839 August 2008. 1841 [18] Schulzrinne, H., "Location-to-URL Mapping Architecture and 1842 Framework", draft-ietf-ecrit-mapping-arch-04 (work in 1843 progress), March 2009. 1845 [19] Peterson, J., "A Presence-based GEOPRIV Location Object 1846 Format", RFC 4119, December 2005. 1848 [20] Polk, J. and B. Rosen, "Location Conveyance for the Session 1849 Initiation Protocol", draft-ietf-sip-location-conveyance-13 1850 (work in progress), March 2009. 1852 URIs 1854 [21] 1856 Authors' Addresses 1858 Richard Barnes 1859 BBN Technologies 1860 9861 Broken Land Pkwy, Suite 400 1861 Columbia, MD 21046 1862 USA 1864 Phone: +1 410 290 6169 1865 Email: rbarnes@bbn.com 1867 Matt Lepinski 1868 BBN Technologies 1869 10 Moulton St 1870 Cambridge, MA 02138 1871 USA 1873 Phone: +1 617 873 5939 1874 Email: mlepinski@bbn.com 1875 Alissa Cooper 1876 Center for Democracy & Technology 1877 1634 I Street NW, Suite 1100 1878 Washington, DC 1879 USA 1881 Email: acooper@cdt.org 1883 John Morris 1884 Center for Democracy & Technology 1885 1634 I Street NW, Suite 1100 1886 Washington, DC 1887 USA 1889 Email: jmorris@cdt.org 1891 Hannes Tschofenig 1892 Nokia Siemens Networks 1893 Linnoitustie 6 1894 Espoo 02600 1895 Finland 1897 Phone: +358 (50) 4871445 1898 Email: Hannes.Tschofenig@gmx.net 1899 URI: http://www.tschofenig.priv.at 1901 Henning Schulzrinne 1902 Columbia University 1903 Department of Computer Science 1904 450 Computer Science Building 1905 New York, NY 10027 1906 US 1908 Phone: +1 212 939 7004 1909 Email: hgs@cs.columbia.edu 1910 URI: http://www.cs.columbia.edu