idnits 2.17.1 draft-barnes-geopriv-lo-sec-05.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.ii 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 (March 9, 2009) is 5527 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) == Outdated reference: A later version (-10) exists of draft-ietf-geopriv-l7-lcp-ps-09 -- Obsolete informational reference (is this intentional?): RFC 3825 (ref. '6') (Obsoleted by RFC 6225) == Outdated reference: A later version (-19) exists of draft-ietf-geopriv-dhcp-lbyr-uri-option-03 == Outdated reference: A later version (-16) exists of draft-ietf-geopriv-http-location-delivery-13 == Outdated reference: A later version (-27) exists of draft-ietf-geopriv-policy-20 == Outdated reference: A later version (-09) exists of draft-ietf-geopriv-lbyr-requirements-07 == Outdated reference: A later version (-13) exists of draft-ietf-ecrit-framework-08 == Outdated reference: A later version (-20) exists of draft-ietf-ecrit-phonebcp-08 == Outdated reference: A later version (-13) exists of draft-ietf-sip-location-conveyance-12 Summary: 1 error (**), 0 flaws (~~), 9 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: September 10, 2009 Center for Democracy & 8 Technology 9 H. Tschofenig 10 Nokia Siemens Networks 11 H. Schulzrinne 12 Columbia University 13 March 9, 2009 15 An Architecture for Location and Location Privacy in Internet 16 Applications 17 draft-barnes-geopriv-lo-sec-05 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 September 10, 2009. 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 . . . . . . . . . . . . . . . . . 8 83 2.1. Basic Geopriv Scenario . . . . . . . . . . . . . . . . . . 9 84 2.2. Roles and Data Formats . . . . . . . . . . . . . . . . . . 10 85 2.3. Relationships Between Geopriv Roles . . . . . . . . . . . 13 86 3. The Location Life-Cycle . . . . . . . . . . . . . . . . . . . 14 87 3.1. Positioning . . . . . . . . . . . . . . . . . . . . . . . 15 88 3.1.1. Determination Mechanisms and Protocols . . . . . . . . 16 89 3.1.2. Privacy Considerations . . . . . . . . . . . . . . . . 18 90 3.1.3. Security Considerations . . . . . . . . . . . . . . . 20 91 3.2. Location Distribution . . . . . . . . . . . . . . . . . . 20 92 3.2.1. Privacy Rules . . . . . . . . . . . . . . . . . . . . 21 93 3.2.2. Location References . . . . . . . . . . . . . . . . . 24 94 3.2.3. Privacy Considerations . . . . . . . . . . . . . . . . 25 95 3.2.4. Security Considerations . . . . . . . . . . . . . . . 26 96 3.3. Receipt of Location Information . . . . . . . . . . . . . 27 97 3.3.1. Privacy Considerations . . . . . . . . . . . . . . . . 28 98 3.3.2. Security Considerations . . . . . . . . . . . . . . . 28 99 4. Security Considerations . . . . . . . . . . . . . . . . . . . 28 100 4.1. Threats to Location Objects . . . . . . . . . . . . . . . 29 101 4.1.1. Threats to Location Integrity and Authenticity . . . . 30 102 4.1.2. Threats to Location Privacy . . . . . . . . . . . . . 31 103 4.2. Required Assurances . . . . . . . . . . . . . . . . . . . 31 104 4.3. Protocol mechanisms . . . . . . . . . . . . . . . . . . . 33 105 4.4. Mechanisms within the Location Object . . . . . . . . . . 33 106 5. Example Scenarios . . . . . . . . . . . . . . . . . . . . . . 34 107 5.1. Minimal Scenario . . . . . . . . . . . . . . . . . . . . . 35 108 5.2. Location-based Web Services . . . . . . . . . . . . . . . 36 109 5.3. Emergency Calling . . . . . . . . . . . . . . . . . . . . 38 110 5.4. Combination of Services . . . . . . . . . . . . . . . . . 39 111 6. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 112 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44 113 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 114 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45 115 9.1. Normative References . . . . . . . . . . . . . . . . . . . 45 116 9.2. Informative References . . . . . . . . . . . . . . . . . . 45 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46 119 1. Introduction 121 Location-based services (applications that require information about 122 the geographic location of an individual or device) are becoming 123 increasingly common on the Internet. Navigation and direction 124 services, emergency services, friend finders, management of equipment 125 in the field and many other applications require geographic location 126 information about Internet hosts, their users, and other related 127 entities. As the accuracy of location information improves and the 128 expense of calculating and obtaining it declines, the distribution 129 and use of location information in Internet-based services will 130 likely become increasingly pervasive. Ensuring that location 131 information is transmitted and accessed in a secure and privacy- 132 protective way is essential to the future success of these services, 133 as well as the minimization of the privacy harms that could flow from 134 their wide deployment and use. 136 Standards for communicating location information over the Internet 137 have an important role to play in providing a technical basis for 138 privacy and security protection. This document describes a 139 standardized privacy- and security-focused architecture for location- 140 based services in the Internet: the Geopriv architecture. The 141 central component of the Geopriv architecture is the location object, 142 which is used to convey both location information about an individual 143 or device and user-specified privacy rules governing that location 144 information. As location information moves through its life cycle -- 145 positioning, distribution, and finally receipt and use by its 146 ultimate recipient(s) -- Geopriv provides mechanisms to guarantee the 147 integrity and confidentiality of location objects and to ensure that 148 location information is only transmitted in compliance with the 149 user's privacy rules. 151 The goals of this document are two-fold: First, the architecture 152 described revises and expands on the basic Geopriv Requirements 153 [2][3], in order to clarify how these privacy concerns and the 154 Geopriv architecture apply to use cases that have arisen since the 155 publication of those documents. Second, this document should provide 156 a general introduction to Geopriv and Internet location-based 157 services, and be useful as a good first document for readers new to 158 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, in order to ensure that 164 entities that receive location are informed of how to they may use 165 it. By creating a structure to convey the user's preferences along 166 with location information, the likelihood that those preferences will 167 be honored necessarily increases. In particular, no recipient of the 168 location information can disavow knowledge of users' preferences for 169 how their location may be used. The binding of privacy rules to 170 location information can convey users' desire for and expectations of 171 privacy, which in turn helps to bolster social and legal systems' 172 protection of those expectations. 174 Binding of usage rules to sensitive information is a common way of 175 protecting information. Several emerging schemes for expressing 176 copyright information provide for rules to be transmitted together 177 with copyrighted works. The Creative Commons [21] model is the most 178 prominent example, allowing an owner of a work to set four types of 179 rules ("Attribution," "Noncommercial," "No Derivative Works" and 180 "ShareAlike") governing the subsequent use of the work. After the 181 author sets these rules, the rules are conveyed together with the 182 work itself, so that every recipient is aware of the copyright terms 183 of the work. 185 Classification systems for controlling sensitive documents within an 186 organization are another example. In these systems, when a document 187 is created, it is marked with a classification such as "SECRET" or 188 "PROPRIETARY." Each recipient of the document knows from this 189 marking that the document should only be shared with other people who 190 are authorized to access documents with that marking. Classification 191 markings can also convey other sorts of rules, such as a 192 specification for how long the marking is valid (a declassification 193 date). For example, the United States Department of Defense 194 guidelines for classification [4] allow the creator of a document to 195 mark it with a classification level that restricts access (e.g., 196 "SECRET") and an indication of when the document should be 197 declassified or downgraded to a lower classification (e.g., 198 "DECLASSIFY ON December 31, 2011" or "DOWNGRADE TO CONFIDENTIAL ON 199 December 31, 2011"). 201 1.2. Location-Specific Privacy Risks 203 While location-based services raise some privacy concerns that are 204 common to all forms of personal information, many of them are 205 heightened and others are uniquely applicable in the context of 206 location information. 208 Location information is frequently generated on or by mobile devices. 209 Because individuals often carry their mobile devices with them, 210 location information may be used to form a comprehensive record of an 211 individual's movements and activities. While other kinds of data 212 could arguably be considered more sensitive than location information 213 in certain contexts -- an individual's medical records or bank 214 statements, for instance -- these kinds of data provide mere 215 snapshots of an individual's activities at discrete moments in time, 216 or within discrete aspects of their lives. Location information, on 217 the other hand, may be collected everywhere and at any time, often 218 without explicit user interaction, and it may potentially describe 219 both what a person is doing and where he or she is doing it. The 220 fact that an individual's mobile device location is obtained when he 221 is at the bank can reveal that he was at the bank, when he was there, 222 and which branch he uses. Location-based services may allow for 223 amassing such data points about an individual's every movement, 224 potentially spurring the creation of richly detailed profiles of 225 individual behavior. 227 The availability of location information may also allow an 228 individual's whereabouts to unwittingly become more public than 229 desired, with potentially serious consequences. Location information 230 may reveal the fact that an individual was in a particular medical 231 clinic or government building, for example, implying potentially very 232 sensitive information about the individual that was not meant to be 233 shared. The ubiquity of location information may also increase the 234 risks of stalking and domestic violence if perpetrators are able to 235 use (or abuse) location-based services to gain access to location 236 information about their victims. Location information additionally 237 raises significant child safety concerns as more and more children 238 access location-aware devices. 240 Finally, location information is and will continue to be of 241 particular interest to governments and law enforcers around the 242 world. The existence of detailed records of individuals' movements 243 should not automatically facilitate the ability for governments to 244 track their citizens, but in some jurisdictions, laws dictating what 245 government agents must do to obtain location data are either non- 246 existent or out-of-date. 248 1.3. Privacy Paradigms 250 Traditionally, the extent to which data about individuals enjoys 251 privacy protections on the Internet has largely been decided by the 252 recipients of the data. Internet users may or may not be aware of 253 the privacy practices of the entities with whom they share data. 254 Even if they are aware, they have generally been limited to making a 255 binary choice between sharing data with a particular entity or not 256 sharing it. Internet users have not historically been granted the 257 opportunity to express their own privacy preferences to the 258 recipients of their data and to have those preferences honored. 260 This paradigm is problematic because the interests of data recipients 261 are often not aligned with the interests of data subjects. While 262 both parties may agree that data should be collected, used, disclosed 263 and retained as necessary to deliver a particular service to the data 264 subject, they may not agree about how the data should otherwised be 265 used. For example, an Internet user may gladly provide his email 266 address on a Web site to receive a newsletter, but he may not want 267 the Web site to share his email address with marketers, whereas the 268 Web site may profit from such sharing. Neither providing the address 269 for both purposes nor deciding not to provide it is an optimal option 270 from the Internet user's perspective. 272 The Geopriv model departs from this paradigm for privacy protection. 273 As explained above, location information can be uniquely sensitive. 274 And as siloed location-based services emerge and proliferate, they 275 increasingly require standardized protocols for communicating 276 location information between services and entities. Recognizing both 277 of these dynamics, Geopriv gives data subjects the ability to express 278 their choices with respect to their own location information, rather 279 than allowing the recipients of the information to define how it will 280 be used. The combination of heightened privacy risk and the need for 281 standardization compelled the Geopriv designers to shift away from 282 the prevailing Internet privacy model, instead empowering users to 283 express their privacy preferences about the use of their location 284 information. 286 Geopriv does not, by itself, provide technical means through which it 287 can be guaranteed that users' location privacy rules will be honored 288 by recipients. The privacy protections in the Geopriv architecture 289 are largely provided by virtue of the fact that recipients of 290 location (Location Servers and Location Recipients in the below 291 discussion) are informed of relevant privacy rules, and must only use 292 location in accordance with those rules. The distributed nature of 293 the architecture inherently limits the degree to which compliance 294 privacy controls -- the fact that an entity has not used location in 295 an unauthorized way -- can be guaranteed and verified by technical 296 means. (Some security mechanisms can address this problem to a 297 limited extent; see Section 4.) 299 By binding privacy rules to location information, however, Geopriv 300 provides valuable information about users' privacy preferences, so 301 that non-technical forces such as legal contracts, governmental 302 consumer protection authorities, and marketplace feedback can better 303 enforce those privacy preferences. If a commercial recipient of 304 location information, for example, violates the location rules bound 305 to the information, the recipient can in a growing number of 306 countries be charged with violating consumer or data protection laws. 307 In the absence of a binding of rules with location information, 308 consumer protection authorities would be less able to protect 309 consumers whose location information has been abused. 311 2. Overview of the Architecture 313 This section provides an overview of the Geopriv architecture for the 314 secure and private distribution of location information on the 315 Internet. We describe the three phases of the "location life cycle" 316 -- positioning, distribution and receipt -- and discuss how the 317 components of the architecture fit within each phase. The next 318 section provides additional detail about how each phase can be 319 achieved in a private and secure manner. 321 The risks discussed in the previous section all arise from 322 unauthorized disclosure or usage of location information. Thus, the 323 Geopriv architecture has two fundamental privacy goals: 325 1. Ensure that location information is distributed only to 326 authorized entities, and 328 2. Provide information to those entities about how they are 329 authorized to use the location information. 331 If these two goals are met, all parties that receive location 332 information will also receive directives about how they can use that 333 information. Privacy-preserving entities will only engage in 334 authorized uses, and entities that violate privacy will do so 335 knowingly, since they have been informed of what is authorized (and 336 thus, implicitly, of what is not). 338 Privacy rules and their distribution are thus the central technical 339 components of the privacy system, since they inform location 340 recipients about how they are authorized to use that information. 341 The two goals in the preceding paragraph are enabled by two classes 342 of rules: 344 1. Access control rules: Rules that describe which entities may 345 receive location information and in what form 347 2. Usage rules: Rules that describe what uses of location 348 information are authorized 350 Within this framework for privacy, security mechanisms provide 351 support for the application of privacy rules. For example, 352 authentication mechanisms validate the identities of entities 353 requesting location (so that authorization and access-control 354 policies can be applied), and confidentiality mechanisms protect 355 location information en route between privacy-preserving entities. 356 Security mechanisms can also provide assurances that are outside the 357 purview of privacy by, for example, assuring location recipients that 358 location information has been faithfully transmitted to them by its 359 creator. 361 2.1. Basic Geopriv Scenario 363 As location information is transmitted among Internet hosts, it goes 364 through a "location life-cycle:" first, the location is computed 365 based on some external information (positioning), then it is 366 transmitted from one host to another (distribution) until finally it 367 is used by a recipient (receipt). 369 For example, suppose Alice learns of her location from a wireless 370 location service and wishes to share it privately with her friends by 371 way of a presence service. Alice clearly needs to provide the 372 presence server with her location and a list of friends to whom the 373 server can grant access to the location. To enable Alice's friends 374 to preserve her privacy, they need to be provided with privacy rules. 375 Alice may tell some of her friends the rules directly, or she can 376 have the presence server provide the rules to her friends when it 377 provides them with her location. In this way, every friend who 378 receives Alice's location is authorized by Alice to receive it, and 379 every friend who receives it knows the rules. Good friends will obey 380 the rules. If a bad friend breaks them and Alice finds out, the bad 381 friend cannot claim that he was unaware of the rules. 383 Some of Alice's friends will be interested in using Alice's location 384 only for their own purposes (to meet up with her or plot her location 385 over time, for example). The usage rules that they receive direct 386 them as to what they can or cannot do (for example, Alice might not 387 want them keeping her location for more than, say, two weeks). 389 Consider one friend, Bob, who wants to send Alice's location to some 390 of his friends. Bob needs not only usage rules for himself, but also 391 access control rules that describe who he can send information to and 392 rules to give to the recipients. If the rules he received from the 393 presence server authorize him to give Alice's location to others, he 394 may do so; otherwise, he will require additional rules from Alice 395 before he is authorized to distribute her location. If recipients 396 who receive Alice's location from Bob want to distribute the location 397 on further, they must go through the same process as Bob. 399 The whole example is illustrated in the following figure: 401 +----------+ 402 | Wireless | 403 | Location | 404 | Service | 405 +----------+ 406 | 407 | 408 Location 409 | 410 | 411 | +------------More-Rules---------------------->+-----+ 412 | | +---->| Bob |--> ... 413 | | | +-----+ 414 v | | 415 +-------+ +----------+ | 416 | |--Location->| Presence |--Location-+ | +----------+ 417 | Alice | | Service | |---+---->| Friend-1 | 418 | |---Rules--->| |---Rules---+ | +----------+ 419 +-------+ +----------+ | 420 | 421 | +----------+ 422 +---->| Friend-2 | 423 +----------+ 425 Figure 1: Basic Geopriv Scenario 427 2.2. Roles and Data Formats 429 The above example illustrates the five basic roles in the Geopriv 430 architecture: 432 Target: An individual or other entity whose location is conveyed in 433 the Geopriv architecture. The Target is the entity whose privacy 434 Geopriv seeks to protect. Alice is the Target in the figure 435 above. 437 Rule Maker (RM): An individual or entity that creates rules 438 governing access to location information for a Target. In some 439 cases the Rule Maker and the Target will be the same individual or 440 entity (as is the case with Alice), and in other cases they will 441 be separate. For example, a parent may serve as the Rule Maker 442 when the Target is his child, or a corporate security officer may 443 be the Rule Maker for devices owned by the corporation but used by 444 employees. The Rule Maker, however, is not necessarily the owner 445 of a Target device. For example, a corporation may provide a 446 device to an employee but permit the employee to serve as the Rule 447 Maker and set her own privacy rules. 449 Location Generator (LG): The entity that initially determines or 450 gathers the location of the Target. Location Generators may be 451 any sort of software or hardware used to obtain the Target's 452 position (examples include GPS chips and cellular networks). A 453 Target may even be its own Location Generator; devices capable of 454 unassisted satellite-based positioning and devices that accept 455 manually entered location information are two examples. The 456 wireless location service is the Location Generator in the figure 457 above. 459 Location Server (LS): An entity that receives both location 460 information and rules, and applies the rules to the location 461 information to determine what other entities, if any, can receive 462 location information. The first LS in the Geopriv process 463 receives location information from Location Generators and rules 464 from Rule Makers, and then applies the rules to the location 465 information. Location Servers may not necessarily be "servers" in 466 the colloquial sense of hosts in remote data centers servicing 467 requests. Rather, a Location Server can be any software or 468 hardware component that receives and distributes location 469 information. Examples include a server in an access network, a 470 presence server, or a Web browser or other software running on a 471 Target's device. The above example includes four Location 472 Servers: the wireless location service, Alice, the presence 473 service and Bob. 475 Location Recipient (LR): The ultimate end point entity to which 476 location information is distributed. A Location Recipient may ask 477 for location explicitly (by sending a query to a Location Server), 478 or it may receive location asynchronously. Location Recipients do 479 not distribute location information to any other Geopriv entities. 480 Friend-1 an Friend-2 are Location Recipients in the figure above. 482 In general, these entities may or may not be physically separate from 483 each other. 485 Within this architecture, entities acting in Geopriv roles 486 communicate using three types of protocols, which carry Location 487 Objects and Privacy Rules in well-defined data formats: 489 Privacy Rule: A directive that regulates an entity's activities 490 with respect to location information, including the collection, 491 use, disclosure, and retention of the location information. 492 Privacy Rules describe how location information may be used by an 493 entity, the level of detail with which location information may be 494 described to an entity, and the conditions under which location 495 information may be disclosed to an entity. 497 Location Object (LO): An object used to convey location information 498 together with Privacy Rules. Geopriv supports both geodetic 499 location data (latitude/longitude/altitude/etc.) and civic 500 location data (street/city/state/etc.). Either or both types of 501 location information may be present in a single LO. In the 502 positioning phase, a LO may contain location information without 503 Privacy Rules (which are passed from one entity to another during 504 the distribution phase). 506 Positioning Protocol: A protocol used by a Location Generator and a 507 source external to the LG (the Target, for example) to exchange 508 information necessary to determine the Target's location. Many 509 Positioning Protocols also carry a Location Object representing 510 the location derived from this information. 512 Conveyance Protocol: A protocol used by a Location Server to send a 513 Location Object to a Location Recipient or another Location 514 Server. 516 Rules Protocol: A protocol used by a Rule Maker to provide Privacy 517 Rules to a Location Server. 519 The whole example, using Geopriv roles, objects and protocols, is 520 illustrated in the following figure: 522 +----+ 523 | LG | 524 +----+ 525 | 526 | 527 Positioning (LO w/o Rules) 528 Protocol 529 | 530 | +------------Rules Protocol------------------->+----+ 531 | | (Privacy Rules) +---->| LS |--> ... 532 | | | +----+ 533 v | | 534 +-------+ | 535 |Target | Conv. Proto. +----+ Conv. Proto. | +----+ 536 | RM |--------------->| LS |---------------+---->| LR | 537 | LS | (LO w/ Rules) +----+ (LO w/ Rules) | +----+ 538 +-------+ | 539 | +----+ 540 +---->| LR | 541 +----+ 543 Figure 2: Basic Geopriv Scenario 545 2.3. Relationships Between Geopriv Roles 547 Although in the above example there is only a single Location 548 Generator and a single Rule Maker, in some cases a Location Server 549 may receive Location Objects from multiple Location Generators or 550 Rules from multiple Rule Makers. Likewise, a single Location 551 Generator may publish location information to multiple Location 552 Servers, and a single Location Recipient may receive Location Objects 553 from multiple Location Servers. 555 The term "Target" may refer not only to an individual whose location 556 is described by a LO, but also to that individual's device, since the 557 device engages in protocol interactions, not the individual. For the 558 remainder of this document, the term "Target" refers to the device. 559 Geopriv can also be used to convey location information about a 560 device that is not directly linked to a single individual, such as a 561 package or product containing a location-capable sensor, or a device 562 linked to multiple individuals. 564 Although a single individual may use multiple devices, the Geopriv 565 protocols address one device per individual at a time; it is outside 566 the scope of Geopriv to interpolate one individual's location 567 information across multiple devices or to arbitrate between privacy 568 preferences that differ across the individual's devices. 570 There is also typically a close binding between a Location Generator 571 and the first Location Server in the distribution path. These two 572 roles may be played by the same entity, for example, a positioning 573 server that can also be queried for location. While these two roles 574 can be played by different entities, the relationship between them 575 needs to be closely prescribed in order to preserve privacy, since an 576 LS is a privacy-aware entity and an LG may not be. The specific 577 constraints on the relationship between an LG and an LS are described 578 in Section 3.1.2. 580 3. The Location Life-Cycle 582 The previous section gave an example of how an individual's location 583 can be distributed through the Internet. In general, the location 584 life-cycle breaks down into three phases: 586 1. Positioning: A Location Generator determines the Target's 587 location 589 2. Distribution: Location Servers send location from one Location 590 Server to another (possibly several times) 592 3. Receipt: A Location Recipient receives the location and uses it. 594 Each of these phases involves a different set of Geopriv roles, and 595 each has a different set of privacy implications. The Geopriv roles 596 are mapped onto the location life-cycle in the figure below. 598 +----------+ +----------+ 599 | | | Rule |+ 600 | Target | | Maker(s)|| 601 | | | || 602 +----------+ +----------+| 603 ^| +----------+ 604 || Positioning | Rules 605 || Protocol | Protocol 606 || | 607 |V V LO (w/ Rules) 608 +----------+ +----------+ Conveyance +----------+ 609 |Location | LO (w/o Rules) | Location |+ Protocol |Location | 610 |Generator |--------------->| Server(s)||-------+------>|Recipient | 611 | | | || | | 612 +----------+ +----------+| +----------+ 613 +----------+ 614 <-----------><-----------------------------------------><-----------> 615 Positioning Distribution Receipt 617 Figure 3: Location Life-Cycle 619 3.1. Positioning 621 Positioning is the process by which the physical location of the 622 Target is computed, based on some observations about the Target's 623 situation in the physical world. (This process goes by several other 624 names, including Location Determination or Sighting.) The input to 625 the positioning process is some information about the Target, and the 626 outcome is that the Location Generator knows the location of the 627 Target. Said differently, positioning is the process by which a 628 Location Generator generates a Location Object from other information 629 about a Target. 631 Given that they are situated at the beginning of the life-cycle of 632 location information, positioning mechanisms and the protocols that 633 support them play a central role in determining who has access to a 634 Target's location information. At the end of the positioning 635 process, the Location Generator (which may be the Target itself) 636 knows the location of the Target. The LG, and possibly the Target, 637 thus have the capability to distribute the Target's position, and the 638 responsibility to do so in a privacy-preserving manner. 640 In this section, we give a brief taxonomy of current positioning 641 systems, their requirements for protocol support, and the privacy and 642 security requirements for these protocols. 644 3.1.1. Determination Mechanisms and Protocols 646 While the specific positioning mechanisms that can be applied for a 647 given Target are strongly dependent on the physical situation and 648 capabilities of the Target, these mechanisms generally fall into the 649 three categories described in detail below: 651 1. Target-based 653 2. Network-based 655 3. Network-assisted 657 As suggested by the above names, a positioning scheme can rely on the 658 Target, an Internet-accessible resource (not necessarily a network 659 operator), or a combination of the two. For a given scheme, the 660 nature of this reliance will dictate the protocol mechanisms needed 661 to support it. 663 With Target-based positioning mechanisms, the Target is capable of 664 determining its location by itself. This is the case for manually- 665 entered location or for (unassisted) satellite-based positioning 666 (using a Global Navigation Satellite System, or GNSS). In these 667 cases, the Target itself is a Location Generator, and there are no 668 protocols required to support positioning (since no information needs 669 to be communicated). 671 In network-based positioning schemes, a third-party Location 672 Generator (i.e., an Internet host other than the Target) has access 673 to sufficient information about the Target, through out-of-band 674 channels, to establish the position of the Target. In these cases, 675 the Location Generator is the entity that has access to the out-of- 676 band information used for positioning. The most common examples of 677 this type of LG are entities that have a physical relationship to the 678 Target (such as ISPs). In wired networks, wiremap-based location is 679 a network-based technique; in wireless networks, timing and signal- 680 strength based techniques that use measurements from base stations 681 are considered to be network-based. Large-scale IP-to-geo databases 682 (for example, those based on WHOIS data or latency measurements) are 683 also considered to be network-based positioning mechanisms. 685 For network-based positioning as for Target-based, no protocols are 686 strictly necessary to support positioning, since positioning 687 information is collected outside of the location distribution system 688 (at lower layers of the network stack, for example). This does not 689 rule out the use of other Internet protocols (like SNMP) to collect 690 inputs to the positioning process; rather, since these inputs can 691 only be used by certain Location Generators to determine location, 692 they are not controlled as private information. (However, when used 693 in this way, they are Positioning Protocols.) Network-based 694 positioning often provides location to protocols by which the network 695 informs a Target device of its position (Location Configuration 696 Protocols [5]). 698 Network-assisted systems account for the greatest number and 699 diversity of positioning schemes. In these systems, the work of 700 positioning is divided between the Target and an external Location 701 Generator via some communication (possibly over the Internet), 702 typically in one of two ways: 704 1. The Target provides measurements to the LG 706 2. The LG provides assistance data to the Target 708 In this case, "measurements" are understood to be observations about 709 the Target's environment, ranging from wireless signal strengths to 710 the MAC address of a first-hop router. "Assistance" is the 711 complement to measurement, namely the information that enables the 712 computation of location-based on measurements. A set of wireless 713 base station locations (or wireless calibration information) would be 714 an assistance datum, as would be a table mapping routers to buildings 715 in a corporate campus. 717 For example, wireless and wired networks can serve as the basis for 718 network-assisted positioning. In several current 802.11 positioning 719 systems, the Target sends measurements (e.g., MAC addresses and 720 signal strengths) to a Location Generator, and the Location Generator 721 returns a location to the client. In fixed networks, the Target can 722 send its MAC address to the Location Generator, which can query the 723 MAC-layer infrastructure to determine the switch and port to which 724 that MAC address is connected, then query a wire map to determine the 725 location at which the wire connected to that port terminates. 727 As an aside, the common phrase "assisted GPS" ("assisted GNSS" more 728 broadly) actually encompasses techniques that transmit both 729 measurements and assistance data. Systems in which the Target 730 provides the assistance server with data such as pseudo-ranges are 731 measurement-based, while those in which the assistance server provide 732 ephemeris or alamanac data are assistance-based in the above 733 terminology. (Those familiar with GNSS positioning will note that 734 there are of course cases in which both of these interactions occur 735 within a single location determination protocol, so the categories 736 are not mutually exclusive.) 738 Naturally, the exchange of measurement or positioning data between 739 the Target and the LG requires a protocol over which the information 740 is carried. The structure of this protocol will depend on which of 741 the two patterns a network-assisted scheme follows. Conversely, the 742 structure of the protocol will determine which of the two parties 743 (the Target, the LG, or both) is aware of the Target's location at 744 the end of the protocol. 746 In summary, the positioning process can involve three Geopriv roles, 747 and three protocols: 749 Location Generator: An LG supports the positioning process, and if 750 it has applicable Rules may act as a Location Server for Location 751 Objects generated through the positioning process. 753 Target: The Target can act as either as an LG (if it receives 754 location as a result of positioning) or simply as a source of 755 inputs to the positioning process. 757 Location Server: At the end of the positioning process, either the 758 Target or an external Location Generator is enabled to act as an 759 LS, making it subject to privacy requirements, or the LG transmits 760 the information to the first LS (which in this case must obtain 761 Rules from a Rule Maker). 763 Positioning Protocol: The protocol used by the Target and a Location 764 Generator to exchange measurement and assistance data. 766 Rules Protocol: The protocol used by the a Rule Maker to provide 767 privacy rules to a Location Server or Location Generator. 769 Conveyance Protocol: The protocol used by a Location Generator or 770 Location Server to send a Location Object to a Location Recipient 771 or another Location Server. 773 3.1.2. Privacy Considerations 775 At the conclusion of the positioning process, either the Target or an 776 external LG (or both) has access to the location of the Target, and 777 those entities (if they have applicable Rules from the Rule Maker) 778 can act as Location Servers, or they will transmit the location to 779 the first LS in the Geopriv process. 781 If either entity chooses to act as an LS by distributing the Target's 782 location, then it must only do so in authorized ways. This 783 requirement means that an LS must be provided with Privacy Rules for 784 the Target's location, which dictate where the location may be sent, 785 and what Privacy Rules should be sent with it. If no Rules are 786 available to an LS, then it must obey a set of privacy-preserving 787 default rules (namely, the LCP policy described below). 789 The simplest case is when the Target acts as the initiating LS, which 790 happens with a Target-based positioning scheme or a network-assisted 791 scheme that results in the Target knowing its location. In this 792 case, Rules are always available, since the Target (or a user of a 793 Target device) can act as a Rule Maker. This requirement implies 794 that software that implements LS functions on a host (i.e., software 795 that distributes location) MUST provide interfaces for the user to 796 specify both (1) to whom the software may send location information 797 and (2) what Rules should be transmitted along with that location. 799 When an entity other than the Target acts as an initiating LS, then 800 it must follow appropriate Rules to protect the privacy of location 801 that it distributes. If Rules have been provided to it by an 802 authorized Rule Maker -- either as part of the Positioning Protocol 803 or through another channel, e.g., a Rules Protocol -- then the LG 804 (acting as an initial LS) MUST transmit location only as allowed by 805 these Rules. (Note that as for other Location Servers, the decision 806 as to which Rule Makers are authorized is a matter of local policy.) 807 Where possible, Positioning Protocols SHOULD enable the Target to 808 convey Rules to the LG. If an LG supports Positioning Protocols that 809 do not convey Rules and the LG is to serve as an LS, it MUST be able 810 to receive Rules via a Rules Protocol. 812 If an LS (especially an initiating LS) is not provisioned with 813 Privacy Rules that authorize transmission of location information for 814 a given Target, then it MUST transmit location only to the Target, 815 and consider all other recipients unauthorized. This default rule is 816 known as the "LCP Policy", since it underlies the privacy aspects of 817 Location Configuration Protocols (LCPs) [5]. 819 As an aside: There are several Location Configuration Protocols that 820 have been developed within the IETF, both using DHCP [6][7][8] and 821 using HTTP [9]. Within the architecture described in this document, 822 these protocols are Conveyance Protocols: the Location Information 823 Server that provides location through an LCP is a Location Server 824 that provides location to the Target, following the LCP policy. 826 In some deployment scenarios, positioning functions and distribution 827 functions may need to be provided by separate entities. That is, the 828 LG and LS roles may need to be separated, with the LG acting as a 829 "dumb," non-privacy-aware positioning resource, and the LS providing 830 the privacy logic necessary to support distribution (possibly with 831 multiple LSs using the same LG). In order to allow the privacy- 832 unaware LG to distribute location to these LSs while maintaining 833 privacy, the relationship between the LG and set of LSs MUST be 834 tightly constrained, effectively "hard-wired." That is, the LG MUST 835 provide location only to a small fixed set of LSs, and each of these 836 LSs MUST comply with the requirements of this section and those in 837 Section 3.2. 839 3.1.3. Security Considerations 841 Manipulation of Positioning Protocols can expose location through two 842 mechanisms: If a third party can guess measurements that a given 843 Target would provide to the LG, and then use them to get the location 844 of that Target, or if a third party can obtain assistance data that 845 indicate the rough position of the client. To mitigate this risk, a 846 Positioning Protocol SHOULD allow the LG to authenticate Positioning 847 Protocol clients (i.e., the Target or other information sources), in 848 the sense of verifying that measurements presented by a client are 849 likely to be the actual physical values measured by that client (and 850 likewise, that the requested assistance data are consistent with the 851 client's actual rough position). These authentication mechanisms 852 will necessarily rely on the nature of the positioning being done, 853 and may not be technically feasible in all cases. 855 In any case, Positioning Protocols MUST provide confidentiality and 856 integrity protections in order to prevent observation and 857 modification of transmitted positioning data and Location Objects 858 while en route between the positioning client and the LG. 860 If a Location Generator or a Target choose to act as an initiating 861 Location Server, they inherit the security requirements for an LS, 862 described in Section 3.2.4. 864 3.2. Location Distribution 866 When an entity receives location (from an LG or another LS) and 867 redistributes it to other entities, it acts as a Location Server. 868 Location Distribution is the process by which one or more Location 869 Servers move location information from its source (a Location 870 Generator) to its destination (a Location Recipient), in a privacy- 871 preserving manner. 873 The role of a Location Server is thus two-fold: First, it must 874 collect location information and Rules that control access to that 875 information. Rules can be communicated within a Location Object, 876 within a Conveyance Protocol that carries LOs, or through a separate 877 Rules Protocol. Second, the Location Server must process requests 878 for location and apply the Rules to these requests in order to 879 determine whether it is authorized to fulfill them by returning 880 location information. 882 A Location Server thus has at least two types of interactions with 883 other hosts, namely receiving and sending Location Objects through a 884 Conveyance Protocol. An LS may optionally implement a third 885 interaction, allowing Rule Makers to provision it with Rules via a 886 Rules Protocol. The distinction between these two cases is important 887 in practice, because it determines whether the LS has a direct 888 relationship with a Rule Maker: An LS that accepts Rules via a Rules 889 Protocol (or via a direct interaction with the Rule Maker) is known 890 as an "Authorized LS" (LSa), while an LS that acquires all its Rules 891 through a Conveyance Protocol is known as an "Independent LS" (LSi). 893 The location distribution process thus involves three roles and three 894 protocols: 896 Location Servers: Entities that perform the actual transmissions of 897 location, in accordance with available Rules 899 Rule Makers: Entities that set Rules that constrain how location 900 information is disseminated 902 Location Recipients: The ultimate destinations for location 903 information 905 Conveyance Protocols: Protocols used by an LS to transmit Location 906 Objects 908 Rules Protocols: Protocols used by an RM to supply Rules to an LS 910 LO Formats: The structure of a LO, including the available location 911 and Rules semantics. 913 3.2.1. Privacy Rules 915 Privacy Rules are the central mechanism in Geopriv for maintaining a 916 Target's privacy, because they provide a recipient of a LO (an LS or 917 LR) with information on how the LO may be used. 919 Throughout the Geopriv architecture, Privacy Rules are communicated 920 in a rules language with a defined syntax and semantics (a Rules 921 Format). For example, the Common Policy rules language has been 922 defined [10] to provide a framework for broad-based rule 923 specifications. Geopriv Policy [11] defines a language for creating 924 location-specific rules. XCAP [12] can be used as a Rules Protocol 925 to install rules in both of these formats. 927 Privacy Rules follow a default-deny pattern: an empty set of Rules 928 implies that all requests for location should be denied (other than 929 requests made by the Target itself), with each Rule added to the set 930 granting a specific permission. Adding a Rule to a set can never 931 reduce existing permissions; it can only augment them. 933 The following are examples of Privacy Rules governing location 934 distribution: 936 o Retransmit location when requested from example.com 938 o Retransmit location when requested by a specific group of 939 requesters 941 o Retransmit only geodetic location 943 o Retransmit location accurate within 100 meters 945 o Retransmit location only to the first three recipients who request 946 it 948 o Retransmit location only before midnight on December 31, 2009 950 Location Servers enforce Privacy Rules in two ways: by denying 951 requests for location, or by transforming the location information 952 before retransmitting it. Some Rules will only be enforceable 953 through denial. For example, if the entire Rule set for a particular 954 Target consisted of the first Rule listed above, then a Location 955 Server would be required to deny all requests for the Target's 956 location from any recipients other than example.com. On the other 957 hand, the second rule above could be enforced either by rejecting 958 requests for civic location or by stripping out all civic location 959 from a LO received from an LG before retransmitting the LO to any LR 960 that requests it. 962 Location Servers may also receive Rules governing location retention, 963 such as: 965 o Retain location only for 24 hours 967 o Retain location only until December 31, 2009 969 These Rules are simply directives about how long the Target's 970 location information can be retained. 972 Privacy Rules can govern the behavior of both Location Servers and 973 Location Recipients. Rules that direct Location Servers about how to 974 treat a Target's location information are known as Local Rules. 975 Local Rules are used internally by the Location Server to handle 976 requests from Location Recipients. They are not distributed to 977 Location Recipients. 979 Rules that travel inside LOs are known as Forwarded Rules. Forwarded 980 Rules direct Location Servers and Location Recipients about how to 981 handle the location information they receive. Because the Rules 982 themselves may reveal potentially sensitive information about the 983 Target, only the minimal subset of Forwarded Rules necessary to 984 handle the LO is distributed. 986 An example can illustrate the interaction between Local Rules and 987 Forwarded Rules. Suppose Alice provides the following Local Rules to 988 a Location Server: 990 o The LS may retain location only for 24 hours 992 o The LS may retransmit Alice's precise location to Bob, who in turn 993 is permitted to retain the location information for one month 995 o The LS may retransmit Alice's city, state, and country to Steve, 996 who in turn is permitted to retain the location information for 997 one hour 999 o The LS may retransmit Alice's country to a photo-sharing website, 1000 which in turn is permitted to retain the location information 1001 indefinitely and retransmit it to any requesters 1003 When Steve asks for Alice's location, the Location Server (assuming 1004 the request is within the authorized 24-hour window for the LS to 1005 retain Alice's location) can transmit to Steve the limited location 1006 information (city, state, and country) along with Forwarded Rules 1007 instructing Steve to (a) not further retransmit Alice's location 1008 information, and (b) only retain the location information for one 1009 hour. By only sending these specifically applicable Forwarded Rules 1010 to Steve (as opposed to the full set of Local Rules), the LS is 1011 protecting Alice's privacy by not disclosing to Steve that (for 1012 example) Alice allows Bob to obtain more precise location information 1013 than Alice allows Steve to receive. 1015 Geopriv is designed to be usable even by devices with constrained 1016 processing capabilities. To ensure that Forwarded Rules can be 1017 processed on constrained devices, LOs are required to carry only a 1018 limited set of Forwarded Rules, with an option to reference a more 1019 robust set of external Rules. The limited Rule set covers two 1020 privacy aspects: how long the Target's location may be retained 1021 ("Retention"), and whether or not the Target's location may be 1022 retransmitted ("Retransmission"). (The latter rule will never grant 1023 an LR the permission to retransmit, since by definition an LR is a 1024 final end point for a Target's location, but an LS that receives a LO 1025 may be granted this permission.) A LO may contain a pointer to more 1026 robust Rules, such as those shown in the set of six Rules at the 1027 beginning of this section. 1029 3.2.2. Location References 1031 The location distribution process occurs through a series of 1032 transmissions of Location Objects: transmissions of location "by 1033 value." Location "by value" can be expressed in terms of geodetic 1034 location data (latitude/longitude/altitude/etc.) and civic location 1035 data (street/city/state/etc.). 1037 Location can also be distributed "by reference." A Location Object 1038 is represented by reference when it is represented by a URI that can 1039 be dereferenced to obtain the LO. This document summarizes the 1040 concerns about location by reference that are discussed at length in 1041 [13]. 1043 Distribution of location by reference (distribution of location URIs) 1044 offer several benefits. From a practical perspective, it can make 1045 location more compact, more recent, and more easily discoverable. 1046 Location URIs are a more compact way of transmitting location, since 1047 URIs are usually smaller than LOs. A recipient of location can make 1048 multiple requests to a URI over time to receive updated location (if 1049 the URI is configured to provide fresh location rather than a single 1050 "snapshot"). Location URIs can serve as an "LS discovery" mechanism, 1051 in that an entity can provide a location URI to an LS or LR in order 1052 to inform the recipient about which LS it should query to obtain a 1053 Location Object. 1055 From a positioning perspective (i.e., for an LG), location by 1056 reference can offer the additional benefit of "just in time" 1057 positioning. If location is distributed by reference until it is 1058 needed for consumption, the LG (here acting as the referenced LS) 1059 only needs to perform positioning operations when a recipient makes a 1060 request for location. 1062 From a privacy perspective, distributing location as a URI instead of 1063 a Location Object can help protect privacy by forcing each recipient 1064 of the location to request location from the referenced LS, which can 1065 then apply access controls individually to each recipient. Note, 1066 however, that the benefit provided here is contingent on the LS 1067 applying access controls. If the LS does not apply an access control 1068 policy to requests for a location URI (in other words, if enforces 1069 the "possession model" defined in [13]), then transmitting a location 1070 URI presents the same privacy risks as transmitting the Object 1071 itself. Moreover, the use of location URIs without access controls 1072 can introduce additional privacy risks: If URIs are more predictable 1073 than the location (e.g., if they are issued in sequence), then an 1074 attacker to whom the URI has not been sent may be able to guess the 1075 URI and use it to obtain the referenced LO. To mitigate this, 1076 location URIs without access controls MUST be constructed so that 1077 they are unpredictable. 1079 3.2.3. Privacy Considerations 1081 Two types of information are distributed in the location distribution 1082 process: location information and Privacy Rules. Rules can be 1083 communicated either independently (through a Rules Protocol) between 1084 an RM and an LS, or as part of a Location Object carrying location 1085 information. Location information, however, MUST always be 1086 accompanied by Rules -- otherwise, a recipient (whether an LS or an 1087 LR) will not know what uses are authorized, and will not be able to 1088 use the LO. Consequently, LO formats MUST be able to express Rules 1089 that convey appropriate authorizations. 1091 An LS MUST only accept Rules from authorized Rule Makers. For an 1092 LSi, this requirement is met by applying the Rules provided in a LO 1093 to the distribution of that LO. For an LSa, this requirement means 1094 that the LS MUST be configurable with an RM authorization policy. An 1095 LS SHOULD define a prescribed set of RMs that may define Rules for a 1096 given Target or LO. For example, an LS may only allow the Target to 1097 set Rules for itself, or it might allow an RM to set Rules for 1098 several Targets (e.g., a parent for children, or a corporate security 1099 officer for employees). 1101 No matter how Rules are provided to an LS, for each LO it receives, 1102 it MUST combine all Rules that apply to the LO into a rule set that 1103 defines which transmissions are authorized, and it MUST transmit 1104 location only in ways that are authorized by these Rules. 1106 For an LSi, all Rules are provided in the LO. When an LSi receives a 1107 LO, it MUST examine the Rules that accompany that LO in order to 1108 determine how it may use the LO (if any Rules are included by 1109 reference, the LSi SHOULD attempt to download them). If the LO 1110 includes no Rules that allow the LSi to transmit the LO to another 1111 entity, then the LSi MUST NOT transmit the LO. It may, however use 1112 the LO for other purposes, e.g., logging, if these other actions are 1113 authorized. If the LO contains no Rules at all (e.g., if it is in a 1114 format with no Rules syntax), then the LSi MUST delete it. 1116 When an LSa receives a LO, it MUST combine the Rules in the LO with 1117 Rules it has received from RMs. The strategy the LSa uses to combine 1118 these sets of Rules is a matter for local policy, depending on the 1119 relative priority that the LS grants to each source of Rules. Some 1120 example policies: 1122 Union: A transmission of location is authorized if it is authorized 1123 by either a rule in the LO or an RM-provided rule. 1125 Intersection: A transmission of location is authorized if it is 1126 authorized by both a rule in the LO and an RM-provided rule. 1128 RM Override: A transmission of location is authorized if it is 1129 authorized by an RM-provided rule (regardless of the LO Rules) 1131 LO Override: A transmission of location is authorized if it is 1132 authorized by a LO-provided rule (regardless of the RM Rules) 1134 In general, it is RECOMMENDED that an LSi follow either the 1135 "Intersection" policy, since it grants equal weight to all RMs 1136 (including the LO creator). In cases where an external RM is more 1137 trusted than the source of the LO, the "Override" policy may be more 1138 suitable (e.g., if the external RM is the Target, and the LO is 1139 provided by a third party). Conversely, the "LO Override" policy is 1140 best suited to cases where the LO provider is more trused than the RM 1141 (e.g., if the RM is the user of a mobile device LS and the LO is 1142 provided with Rules from the RM's parents or corporate security 1143 office). 1145 3.2.4. Security Considerations 1147 An LS's decisions about how to transmit location are based on the 1148 identities of entities requesting information and other aspects of 1149 requests for location. In order to ensure that these decisions are 1150 made properly, the LS needs assurance of the reliability of 1151 information on the identities of the entities with which the LS 1152 interacts (including LRs, LSs, and RMs) and other information in the 1153 request. 1155 Conveyance Protocols and Rules Protocols MUST provide information on 1156 the identity of the recipient of location (an LR or LS) and the 1157 identity of the RM, respectively. In order to ensure the validity of 1158 this information, these protocols MUST allow for mutual 1159 authentication of both parties, and MUST provide integrity protection 1160 for protocol messages. These security features ensure that the LG 1161 has sufficient information (and sufficiently reliable information) to 1162 make privacy decisions. 1164 As they travel through the Internet within a Conveyance Protocol, 1165 Location Objects necessarily pass through a sequence of 1166 intermediaries, ranging from layer-2 switches to IP routers to 1167 application-layer proxies and gateways. The ability of an LS to 1168 protect privacy by making access-control decisions is reduced if 1169 these intermediaries have access to a Location Object as it travels 1170 between privacy-preserving entities. 1172 A Conveyance Protocol MUST provide end-to-end confidentiality between 1173 an LS that transmits location and the LS or LR that receives it. 1174 When the protocol itself is protected end-to-end between the LS and 1175 the recipient, carrying an unprotected Location Object within this 1176 encrypted channel is sufficient. When the protocol has a mode in 1177 which messages are either unprotected or protected on a hop-by-hop 1178 basis (e.g., between intermediaries in a store-and-forward protocol), 1179 the protocol SHOULD allow the use of encrypted LOs, or for the 1180 transmission of a reference to location in place of a LO [13]. 1182 It is RECOMMENDED that Rule Makers, Location Servers, and Location 1183 Recipients use the security features of Rules Protocols and Coveyance 1184 Protocols to ensure that Rules are installed and applied properly, 1185 and that location is protected en route. 1187 3.3. Receipt of Location Information 1189 After location information has been distributed via a series of 1190 Location Servers, it finally comes to rest with a Location Recipient. 1191 Location Recipients are consumers of location; they do not forward 1192 location information to other entities. (Any recipient of location 1193 information that forwards it to other entities is acting as a 1194 Location Server in the distribution chain. The privacy requirements 1195 for an LS are described in Section 3.2.) 1197 The primary privacy requirement of an LR is to constrain its usage of 1198 location to the set of uses authorized by the Rules in an LO. If an 1199 LR only uses a LO in ways that do not have a privacy impact -- 1200 specifically, if it does not transmit the LO to any other entity, and 1201 does not retain the LO for longer than is required to execute the 1202 Conveyance Protocol -- then no further action is necessary for the LR 1203 to comply with the requirements of this document. 1205 As an example of this simplest case, if a Location Recipient (a) 1206 receives a location, (b) immediately provides to the Target 1207 information or a service based on the location, (c) does not retain 1208 the information, and (d) does not retransmit the location to any 1209 other entity, then the LR will comply with any set of Rules that are 1210 permissible under Geopriv. Thus, a service that, for example, only 1211 provides directions to the closest bookstore in response to an input 1212 of location, and promptly then discards the input location, will be 1213 in compliance with any Geopriv rule set. 1215 LRs that make other uses of a LO (e.g., those that store LOs, or send 1216 them to other service providers to obtain location-based services) 1217 MUST meet the requirements below to assure that these uses are 1218 authorized. 1220 The Location Receipt process thus involves one Geopriv role and two 1221 protocols: 1223 Location Recipients: Entities that accept LOs and use them, subject 1224 to the Privacy Rules they contain 1226 Conveyance Protocols: Protocols by which LOs are delivered to 1227 Location Recipients 1229 LO Formats: The structure of a LO, including the available location 1230 and Rules semantics. 1232 3.3.1. Privacy Considerations 1234 The principle privacy requirement for Location Recipients is to 1235 follow usage rules. When an LR receives a LO, it is REQUIRED to 1236 examine the Rules included with that LO. Any usage the LR makes of 1237 the LO MUST be explicitly authorized by these Rules. Since Rules are 1238 positive grants of permission, any action not explicitly authorized 1239 is denied by default. 1241 In particular, given a LO in a particular format, an LR MUST NOT take 1242 any action that could be authorized by a rule within that format, 1243 unless such an rule is present in the LO to authorize the action. If 1244 such an action were authorized, then the RM would have included a 1245 rule to express this authorization. For instance, the PIDF-LO format 1246 [14] defines a rule that allows an LR to retain the LO for a 1247 specified amount of time; if an LR receives a LO that does not have 1248 such a rule, then it MUST NOT retain the location. 1250 3.3.2. Security Considerations 1252 Since a Location Recipient does not transmit location, there are no 1253 protocol security considerations required to support privacy (only 1254 the LR's compliance with Rules, as described above). 1256 Aside from privacy, Location Recipients often require some assurance 1257 that a LO is reliable (assurance of the integrity, authenticity, and 1258 validity of an LO), since LRs use LOs in order to deliver location- 1259 based services. Threats against this reliability and corresponding 1260 mitigations are discussed in the Security Considerations below. 1262 4. Security Considerations 1264 Security considerations related to the privacy of Location Objects 1265 are discussed throughout this document. In this section we summarize 1266 those concerns and consider security risks not related to privacy. 1268 The life-cycle of a Location Object often consists of a series of 1269 location transmissions (see Figure 4). For example, location might 1270 initially be published to a location configuration server which then 1271 transmits the location to the Target. The Target may then act as a 1272 Location Server and convey this location to a service provider (who 1273 acts as Location Recipient in this transmission) to facilitate some 1274 location-based service. 1276 (Note that although Figure 4 depicts a single "path", a single 1277 location server may transmit location to multiple location recipients 1278 over time; groups of these paths together form a logical distribution 1279 tree, with the location generator as the root node.) 1281 +----+ +----+ +----+ +----+ +----+ 1282 | LG |--->| LS |--->| LS |--->| LS |--->| LR | 1283 +----+ +----+ +----+ +----+ +----+ 1284 | | | 1285 +----+ +----+ +----+ 1286 | RM | | RM | | RM | 1287 +----+ +----+ +----+ 1289 Figure 4: Location Life-Cycle 1291 The location life-cycle gives rise to additional security concerns. 1292 For example, in a scenario where some intermediate location servers 1293 are untrusted, a location recipient may desire additional assurances 1294 that the LO was generated by a trusted LG, and not modified by these 1295 untrusted entities. In this section, we first consider threats and 1296 possible attacks against a Location Object throughout its entire life 1297 cycle. We then describe the assurances that various parties require 1298 to mitigate these threats. Finally, we discuss possible mechanisms 1299 that protocols or location object formats should make available to 1300 provide such assurances. 1302 4.1. Threats to Location Objects 1304 The major threats to the end-to-end security of Location Objects can 1305 be grouped into two categories: First, threats against the integrity 1306 and authenticity of Location Objects can expose entities that rely on 1307 Location Objects to many types of fraud. Second, threats against the 1308 confidentiality of Location Objects can reduce the ability of 1309 location servers to control access to location. 1311 4.1.1. Threats to Location Integrity and Authenticity 1313 A Location Object contains four essential types of information: 1314 Identifiers for the described Target, location information, time- 1315 stamps, and Rules. By grouping values of these various types 1316 together within a single structure, a Location Object encodes a set 1317 of bindings among them. That is, the Location Object asserts that 1318 the identified Target was present at the given location at the given 1319 time; and that the given Rules express the Target's desired policy, 1320 at the given time, for the distribution of his location. Below, we 1321 provide a set of attacks that a malicious party (e.g. an intermediate 1322 LS, an eavesdropper on the path between LS and LR, or the Target 1323 himself) might conduct to falsify one or more of the bindings 1324 asserted by the Location Object. 1326 Note that in all cases the Target identity provided in a Location 1327 Object should be based on an authentication between the Target and 1328 the location generator (e.g. an explicit authentication based on a 1329 shared secret, or an implicit authentication based on the ability to 1330 receive a message). Therefore, the identity binding in a received 1331 Location Object is only as strong as the authentication between the 1332 Target and the location generator (that is, the Location Object can 1333 only attest to the fact that someone at the given location is capable 1334 of authenticating as the given identity). It is vital to the 1335 authenticity of location information that this authentication be as 1336 strong as is feasible in any deployment scenario. However, 1337 mechanisms within a Geopriv Location Object or protocol can provide 1338 no protection from attacks against this authentication mechanism and 1339 thus we do not explicitly consider such attacks. 1341 Place Shifting: Falsifying the location in an otherwise valid 1342 Location Object. For example, Alice pretends to that she is 1343 currently in a location that she has never previously visited. 1345 Time Shifting: Falsifying the time-stamp in an otherwise valid 1346 Location Object. For example, Alice pretends that she is 1347 currently in a location that she has not visited since last year. 1349 Location Theft: Falsifying the identity in an otherwise valid 1350 Location Object. For example, a malicious intermediary sees a 1351 valid Location Object for Alice and produces a Location Object 1352 asserting that Bob is the given location at the given time. 1354 Location-Identity Theft: An attacker replays a stale Location Object 1355 as though it were current. For example, a malicious intermediary 1356 sees a valid Location Object for Alice and replays it later to 1357 make it seem that Alice has not moved. 1359 Location Swapping: Two malicious Targets conspire to produce two 1360 Location Objects asserting that each Target is at the other's 1361 location. For example, Alice pretends that she is at Bob's 1362 location and Bob pretends that he is at Alice's location. (Note 1363 that this attack cannot be prevented if the two attackers are 1364 willing to exchange authentication credentials. Because the 1365 identity assertions in a Location Object are only as strong as the 1366 Target authentication, the goal of Geopriv protocols is to ensure 1367 that this attack is not possible unless both Alice and Bob can 1368 successfully authenticate as the other.) 1370 4.1.2. Threats to Location Privacy 1372 In the Geopriv model, the privacy of location information is 1373 protected by the application of Privacy Rules specified by authorized 1374 rule makers, and by confidentiality protection en route. (For more 1375 information on privacy rule enforcement, see Section 3.2.3).) Below, 1376 we provide a set of attacks that a malicious party might conduct to 1377 allow distribution of a Location Object to unauthorized parties. 1379 Eavesdropping: An unauthorized party observes the Location Object in 1380 transit. For example, a device on the path between a trusted LS 1381 and an authorized LR observes a Location Object sent in the clear. 1383 Rule Tampering: A malicious party modifies a Target's Privacy Rules 1384 and thus causes a trusted LS to unknowingly distribute the 1385 Location Object to unauthorized parties. For example, a device on 1386 the path between an LG and a trusted LS deletes the Privacy Rules 1387 contained in a Location Object and replaces them with a new set of 1388 Rules authorizing all parties to receive the Location Object. 1390 Server Impersonation: A malicious party impersonates a trusted 1391 location server and then knowingly disregards the Privacy Rules. 1392 For example, a man-in-the-middle between the LG and the trusted LS 1393 pretends to be the trusted LS, and then proceeds to distribute the 1394 Location Object to unauthorized entities. 1396 4.2. Required Assurances 1398 We now describe the assurances required by each party involved in 1399 location distribution in order to mitigate the attacks described in 1400 the previous two sections: 1402 Rule Maker: The rule maker is responsible for distributing the 1403 Target's Privacy Rules to the location servers. The primary 1404 assurance required by the Rule Maker is thus that the binding 1405 between the Target's Privacy Rules and the Target's identity is 1406 correctly conveyed to each location server that handles the 1407 Location Object. Ensuring the integrity of the Privacy Rules 1408 distributed to the location servers prevents rule-tampering 1409 attacks. (Note that in many circumstances, the privacy policy of 1410 the Target may itself be sensitive information, in these cases the 1411 Rule Maker also requires the assurance that the binding between 1412 the Target's identity and the Target's Privacy Rules are not 1413 deducible by anyone other than an authorized location server). 1415 Location Server: The Location Server is responsible for enforcing 1416 the Target's privacy policy. The first assurance required by the 1417 location server is that the binding between the Target's Privacy 1418 Rules and the Target's identity is authentic. Authenticating the 1419 rule-maker who created the Privacy Rules prevents rule-tampering 1420 attacks. The second assurance required by the location server is 1421 that the binding between the Target's identity and the Target's 1422 location are not deducible by any entity except as allowed the 1423 Target's privacy policy. Ensuring the confidentiality of these 1424 bindings prevents eavesdropping attacks. (Note that ensuring the 1425 confidentiality of the Location Object also helps to mitigate 1426 location-theft and location-identity-theft attacks, since it makes 1427 it more difficult for an attacker to obtain a valid Location 1428 Object to replay.) 1430 Location Recipient: The Location Recipient is the end consumer of 1431 the Location Object. The location recipient thus requires 1432 assurances about the authenticity of the bindings between the 1433 Target's location, the Target's identity and the time. Ensuring 1434 the authenticity of these bindings prevents place-shifting, time- 1435 shifting, location-theft, and location-identity-theft attacks; and 1436 mitigates location-swapping attacks to the greatest possible 1437 extent. 1439 Location Generator: The Location Generator shares responsibility for 1440 ensuring that the Target's privacy policy is enforced. The 1441 primary assurance required by the Location Generator is that the 1442 Location Server to which the Location Object is initially 1443 published is one that is trusted to enforce the Target's privacy 1444 policy. Authenticating the trusted Location Server mitigates the 1445 risk of server impersonation attacks. (Additionally, in some 1446 scenarios, there may be no Location Server which can be trusted to 1447 sufficiently safe-guard the Target's location information, in 1448 which case the Location Generator may require assurance that 1449 intermediate location servers are unable to deduce the binding 1450 between the Target's identity and the Target's location.) 1452 4.3. Protocol mechanisms 1454 Protocols that carry location can provide strong assurances, but only 1455 for a single segment of the Location Object's life cycle. In 1456 particular, a protocol can provide integrity protection and 1457 confidentiality for the data exchanged, and mutual authentication of 1458 the parties involved in the protocol, by using a secure transport 1459 such as IPsec or TLS. 1461 Additionally, note that if (1) the protocol provides mutual 1462 authentication for every segment; and (2) every entity in the 1463 location distribution exchanges information only with entities with 1464 whom it has a trust relationship, then entities can transitively 1465 obtain assurances regarding the origin and ultimate destination of 1466 the Location Object. Of course, direct assurances are always 1467 preferred over assurances requiring transitive trust, since they 1468 require fewer assumptions. 1470 Using protocol mechanisms alone, the entities can receive assurances 1471 only about a single hop in the distribution chain. For example, 1472 suppose that an LR retrieves location from an LS over an integrity- 1473 and confidentiality-protected channel. The LR knows that the 1474 transmitted LO has not been modified or observed en route. However, 1475 the assurances provided by the protocol do not guarantee that the 1476 transmitted LO was not corrupted before it was sent (e.g., by a 1477 previous LS). Likewise, the LR can verify that the LO was 1478 transmitted by the LS, but cannot verify the origin of the LO if it 1479 is different from the LS. 1481 Security mechanisms in protocols are thus unable to provide direct 1482 assurances over multiple transmissions of an LO. However, it should 1483 be noted that the transmission of location "by reference" can be used 1484 to effectively turn multi-hop paths into single-hop paths. If the 1485 multiple transmissions of a LO are replaced by multiple transmissions 1486 of an identifier (a multi-hop dissemination channel), then the LO 1487 need only traverse a single hop, namely the dereference transaction 1488 between the LR and the dereference server. 1490 4.4. Mechanisms within the Location Object 1492 Assurances as to the integrity and confidentiality of a Location 1493 Object can be provided directly through the Location Object format. 1494 Additionally, the Location Object format can be used to authenticate 1495 the originator of a Location Object. In particular, integrity and 1496 origin authentication can be assured by signing a Location Object 1497 (e.g., using S/MIME or XMLSIG), and confidentiality can be assured by 1498 encrypting the Location Object using a public encryption key 1499 belonging to the intended recipient (e.g. using S/MIME). Recipients 1500 of Location Objects secured in this fashion can obtain assurance as 1501 to the integrity and authenticity of the Location Object even after 1502 it has been handled by untrusted intermediaries. Similarly, a 1503 Location Server (or Location Generator) that guarantees 1504 confidentiality in this fashion can be assured that the Location 1505 Object is protected from unauthorized viewing even in the presence of 1506 untrusted intermediaries. 1508 Although such direct, end-to-end assurances are desirable, and these 1509 mechanisms should be used whenever possible, there are many 1510 deployment scenarios where directly securing a Location Object is 1511 impractical. In particular, in some deployment scenarios a direct 1512 trust relationship may not exist between the creator of the Location 1513 Object and the ultimate recipient. Additionally, in a scenario where 1514 many recipients are authorized to receive a given Location Object, 1515 the creator of the Location Object cannot guarantee end-to-end 1516 confidentiality without knowing precisely which recipient will 1517 receive the Location Object. 1519 An additional challenge in providing end-to-end authenticity 1520 guarantees by signing the Location Object is that in many deployments 1521 different entities may assert different bindings within the same 1522 Location Object. Consider, for example, a scenario where a Location 1523 Generator produces a Location Object that asserts a binding between a 1524 time, a location, and a pseudonym for the Target. Additionally, a 1525 Rule Maker creates a binding between a set of Privacy Rules and a 1526 public Target identity. A presence server receives the Rules binding 1527 from Rule Maker and the Location Object from the Location Generator. 1528 The presence server then generates a new Location Object binding 1529 together the time, the location, the public Target identity and the 1530 Privacy Rules. In such a scenario there is no single entity who can 1531 directly assert the validity of the entire Location Object. In such 1532 a case, a mechanism is needed within the Location Object format that 1533 allows multiple originators to jointly assert various components of 1534 the Location Object bindings. 1536 5. Example Scenarios 1538 This section contains a set of example of how the Geopriv 1539 architecture can be deployed in practice. These examples are meant 1540 to illustrate key points of the architecture, rather than to form an 1541 exhaustive set of use cases. 1543 For convenience and clarity in these examples, we assume that the 1544 Privacy Rules that a LO carries are equivalent to those in a PIDF-LO 1545 Location Object (namely, that the principal Rules that can be set are 1546 limits on the retransmission and retention of the LO). It should be 1547 noted that while these two Rules are the most well-known and 1548 important examples, the specific types of Rules an LS or LR must 1549 consider will in general depend on the types of LO it processes. It 1550 is possible that in some cases, Geopriv entities will have to 1551 consider additional Rules and in others, retention and retransmission 1552 will be unconstrained. For the rest of this section, however, we 1553 assume for simplicity that limiting retention and controlling access 1554 to location are the two primary responsibilities incumbent on a 1555 recipient of location (an LS or LR). 1557 5.1. Minimal Scenario 1559 One of the simplest scenarios in the Geopriv architecture is when a 1560 Target determines its own location and uses that LO to request a 1561 service (e.g., by including the LO in an HTTP POST request or SIP 1562 INVITE message), and the server delivers that service immediately 1563 (e.g., in a 200 OK response in HTTP or SIP), without retaining or 1564 retransmitting the Target's location. The Target acts as an LG by 1565 using a Target-based positioning algorithm (e.g., manual entry), as a 1566 Rule Maker by specifying that the location should be sent to the 1567 server, and as an initial Location Server by interpreting the rule 1568 and transmitting the LO. The server acts as a Location Recipient by 1569 receiving and using the LO. 1571 In this case, the privacy of location information is maintained in 1572 two steps: The first step is that location is only transmitted as 1573 directed by the single Rule Maker, namely the Target. The second 1574 step is simply the fact that the server (i.e., the LR) did not do 1575 anything that created a privacy risk -- it did not retain or 1576 retransmit location. Because the server limits its behavior in this 1577 way, it does not need to read the Rules in the LO (even though they 1578 were provided) -- no rule would prevent it from using location in 1579 this safe manner. 1581 The following outline summarizes this scenario: 1583 o Positioning: Target-based, Target=LG=initial LS 1585 o Distribution hop 1: HTTP UA --> Ephemeral web service, privacy via 1586 user indication 1588 o Receipt: Ephemeral web service delivers response without retaining 1589 or retransmitting location 1591 o Key points: 1593 * LRs that do not behave in ways that risk privacy are Geopriv- 1594 compliant by default. No further action is necessary. 1596 5.2. Location-based Web Services 1598 Many location-based services are delivered over the Web, using 1599 Javascript code to orchestrate a series of HTTP requests for location 1600 specific information. To support these applications, browser 1601 extensions have been developed that support Target-based positioning 1602 (manual entry and GPS) and network-assisted positioning (via AGPS, 1603 and multilateration with 802.11 and cellular signals), exposing 1604 position to web pages through Javascript APIs. 1606 In this scenario, we consider a Target that uses a browser with a 1607 network-assisted positioning extension. When the Target uses this 1608 browser to request location-based services from a web page, the 1609 browser prompts the user to grant the page permission to access the 1610 user's location. If the user grants permission, the browser 1611 extension sends 802.11 signal strength measurements to a positioning 1612 server, which then returns the position of the host. The extension 1613 constructs a Location Object with this location and Rules set by the 1614 user, then passes the LO to the page through its Javascript API. The 1615 page then obtains location-relevant information using an 1616 XMLHttpRequest [15] to a server in the same domain as the page and 1617 renders this information to the user. 1619 At first blush, this scenario seems much more complicated than the 1620 minimal scenario above. However, most of the privacy considerations 1621 are actually the same. 1623 The positioning phase in this scenario begins when the browser 1624 extension contacts the positioning server. The positioning server 1625 acts as a Location Generator, and the protocol that supports this 1626 interaction is a Positioning Protocol. The positioning server 1627 supports the privacy of the location information it provides by 1628 following the LCP Policy, i.e., by providing location information 1629 only to the entity being located. 1631 The distribution phase actually occurs entirely within the Target 1632 host: The single hop in distribution occurs when the browser 1633 extension (an entity under the control of the Target) passes a LO to 1634 the web page (an entity under the control of its author). In this 1635 phase, the browser extension acts as the initiating LS, with the 1636 user/Target as the sole Rule Maker; the user interface for rule- 1637 making is effectively a Rules Protocol, and the extension's API 1638 effectively defines a Conveyance Protocol and LO Format. The web 1639 site acts as Location Recipient when the web page accepts the LO. 1641 The receipt phase encompasses the web site's use of the LO. In this 1642 context, the phrase "web site" encompasses not only the web page, but 1643 also the dedicated supporting logic behind it. Considering the 1644 entire web site as a recipient, rather than a single page, it becomes 1645 clear that by sending the LO in an XMLHttpRequest to a back-end 1646 server is more like passing it to a separate component of the LR (as 1647 opposed to retransmitting it to another entity). Thus, even in this 1648 case, where location-relevant information is obtained from a back-end 1649 server, the LR does not retain or retransmit location, so its 1650 behavior is "privacy-safe" -- it doesn't need to interpret the Rules 1651 in the LO. 1653 However, consider a variation on this scenario where the web page 1654 requests additional information (e.g., a map) from a third-party 1655 site. In this case, since location is being transmitted to a third 1656 party, the web site (either in the web page or in a back-end server) 1657 would need to verify that this transmission is allowed by the LO's 1658 Privacy Rules. Similarly, if the site wanted to log the user's 1659 location information, then it would need to examine the LO to 1660 determine how long this information can be retained. In such a case, 1661 if the LR needs to do something that is not allowed by the Rules, it 1662 may have to deny service to the user (hopefully providing a message 1663 with the reason). Nonetheless, if the Rules permit retention or 1664 retransmission (even if this retransmission is limited by access 1665 control rules), then the LR may do so to the extent the Rules allow. 1667 The following outline summarizes this scenario: 1669 o Positioning: Network-assisted, positioning server=LG, privacy via 1670 LCP Policy 1672 o Rule installation: RM (=Target/user) gives permission to sites and 1673 sets LO Rules 1675 o Distribution hop 1: Browser=LS --> Web site=LR, privacy via user 1676 confirmation 1678 o Receipt: Back-end server delivers location-relevant information 1679 without further retransmission, then deletes location; privacy via 1680 safe behavior 1682 o Key points: 1684 * Privacy in this scenario is provided by a combination of 1685 explicit user direction and Rules in an LO 1687 * Distribution can occur within a host, between mutually 1688 untrusting components 1690 * Some transmissions of location are actually internal to an LR 1691 * LRs that do things that might be constrained by Rules need to 1692 verify that these actions are allowed for a particular LO 1694 5.3. Emergency Calling 1696 Support for emergency calls by Voice-over-IP devices is a critical 1697 use case for location information about Internet hosts. The details 1698 of the Internet architecture for emergency calling are described in 1699 [16][17]. In this architecture, there are three critical steps in 1700 the placement of an emergency call, each involving location 1701 information: 1703 1. Determine the location of the caller 1705 2. Determine the proper Public Safety Answering Point (PSAP) for the 1706 caller's location 1708 3. Send a SIP INVITE message (including the caller's location) to 1709 the PSAP 1711 The first step in an emergency call is to determine the location of 1712 the caller. This step is the positioning phase of the location life- 1713 cycle. Location is determined by whatever means are available to the 1714 caller's device, or to the network, if this step is being done by a 1715 proxy. Whichever entity does the positioning (either the caller or a 1716 proxy) acts as the initiating Location Server, preserving the privacy 1717 of location information by only including it in emergency calls. 1719 The second step in an emergency call encompasses location 1720 distribution and receipt. The entity that is routing the emergency 1721 call sends location though the LoST protocol [18] to a mapping 1722 server. In this role, the routing entity acts as a Location Server, 1723 LoST acts as a Location Conveyance protocol, and the LoST server acts 1724 as a Location Recipient. The LO format within LoST does not allow 1725 Rules to be sent along with location, but because LoST is an 1726 application-specific protocol, the sending of location within a LoST 1727 message authorizes the LoST server to use the location to complete 1728 the protocol, namely to route the message as necessary through the 1729 LoST mapping architecture [19]. That is, the LoST server is 1730 authorized to complete the LoST protocol, but to do nothing else. 1732 The third step in an emergency call is again a combination of 1733 distribution and receipt. The caller (or another entity that inserts 1734 the caller's location) acts as an LS, SIP acts as a Conveyance 1735 Protocol [20], and the PSAP acts as a Location Recipient. In this 1736 specific example, the caller's location is transmitted either as a 1737 PIDF-LO object or as a reference that returns a PIDF-LO (or both); in 1738 the latter case, the reference should be appropriately protected so 1739 that only the PSAP has access. In any case, the receipt of a LO 1740 implies that the PSAP should obey the Rules in those LOs in order to 1741 preserve privacy. Depending on the regulatory environment, the PSAP 1742 may have the option to ignore those constraints in order to respond 1743 to an emergency, or it may be bound to respect these Rules (in spite 1744 of the emergency situation). 1746 The following outline summarizes this scenario: 1748 o Positioning: Any, Target=initial LS 1750 o Distribution/receipt hop 1: Target=LS --> LoST infrastructure (no 1751 Rules), privacy via authorization implicit in protocol 1753 o Distribution/receipt hop 2: Target=LS --> PSAP, privacy via Rules 1754 in LO 1756 o Receipt: PSAP uses location to deliver emergency services 1758 o Key points: 1760 * Privacy in this scenario is provided by a combination of 1761 explicit user direction, implicit authorization particular to a 1762 protocol, and Rules in an LO 1764 * LRs may be constrained to respect or ignore Privacy Rules by 1765 local regulation 1767 5.4. Combination of Services 1769 In modern Internet applications, users frequently receive information 1770 via one channel and broadcast it via another. In this sense, both 1771 users and channels (e.g., web services) become location servers. 1772 Here we consider a more complex example that illustrates this pattern 1773 across multiple logical hops. 1775 Suppose Alice (the Target) subscribes to a wireless ISP that 1776 determines her location using a network-based positioning technique 1777 (e.g., via the location of the base station serving the Target), and 1778 provides that information directly to a location-enhanced presence 1779 provider (which might use SIP, XMPP, or another protocol). The 1780 location-enhanced presence provider allows Alice to specify Rules for 1781 how this location is distributed: which friends should receive 1782 Alice's location and what Rules they should get with it. Alice uses 1783 a few other location-enhanced services as well, so she sends Rules 1784 that allows her location to be shared with those services, and allows 1785 those services to retain and retransmit her location. 1787 Bob is one of Alice's friends, and he receives her location via this 1788 location-enhanced presence service. Noting that she's at their 1789 favorite coffee shop, Bob wants to upload a photo of the two of them 1790 at the coffee shop to a photo-sharing site, along with a LO that 1791 marks the location. Bob checks the Rules in Alice's LO and verifies 1792 that the photo sharing site is one of the services that Alice 1793 authorized. Seeing that Alice has authorized him to give the LO to 1794 the photo-sharing site, he attaches it to the photo and uploads it. 1796 Once the geo-tagged photo is uploaded, the photo sharing site reads 1797 the Rules in the LO and verifies that the site is authorized to store 1798 the photo and to share it with others. Since Alice has allowed the 1799 site the retransmit and retain without any constraints, the site 1800 fulfills Bob's request to make the geo-tagged photo publicly 1801 accessible. 1803 Eve, another user of the photo sharing site, downloads the photo of 1804 Alice and Bob at the coffee shop and receives Alice's LO along with 1805 it. Eve posts the photo and location to her public page on a social 1806 networking site without checking the Rules, even though the LO 1807 doesn't allow Eve to send the location anywhere else. The social 1808 networking site, however, observes that no retransmission or 1809 retention are allowed (both of which it needs for a public posting), 1810 and rejects the upload. 1812 In terms of the location life-cycle, this scenario consists of a 1813 positioning step, followed by four distribution hops and receipt. 1814 Positioning is the simplest step: An LG in Alice's ISP monitors her 1815 location and transmits it to the presence service, maintaining 1816 privacy by only transmitting location to a single entity (to which 1817 privacy responsibilities are delegated). 1819 The first distribution hop occurs when the presence server sends 1820 location to Bob. In this transaction, the presence server acts as an 1821 LS, Alice acts as an RM, and Bob acts as another LS (on the receiving 1822 side). The privacy of this transaction is assured by the fact that 1823 Alice has installed Rules on the presence server that dictate who it 1824 may allow to access her location. The second distribution hop is 1825 when Bob uploads the LO to the photo-sharing site. Here Bob again 1826 acts an LS (on the sending side), preserving the privacy of location 1827 information by verifying that the Rules in the LO allow him to upload 1828 it. The third distribution hop is when the photo-sharing site sends 1829 the LO to Eve, likewise following the Rules -- but a different set of 1830 Rules than Bob, since a LO can specify different rulesets for 1831 different Location Servers. 1833 Eve is the fourth LS in the chain, and fails to comply with Geopriv 1834 by not checking the rule in the LO prior to uploading it to the 1835 social networking site. The site, however, is a responsible LR -- it 1836 checks the Rules in the LO, sees that they don't allow it to use the 1837 location as it needs to, and discards the LO. 1839 The following outline summarizes this scenario: 1841 o Positioning: Network-based, LG in network, privacy via exclusive 1842 relationship with presence service 1844 o Distribution hop 1: Presence server --> Bob, privacy via Alice's 1845 access control rules (installed via Rules Protocol) 1847 o Distribution hop 2: Bob --> photo sharing site, privacy via Rules 1848 for Bob in LO 1850 o Distribution hop 3: Photo sharing site --> Eve, privacy via Rules 1851 for site in LO 1853 o Distribution hop 4: Eve --> Social networking site, violates 1854 privacy by retransmitting 1856 o Recipient: Social networking site, privacy via checking Rules and 1857 discarding 1859 o Key points: 1861 * Privacy can be preserved through multiple hops 1863 * A LO can specify different Rules for different entities 1865 * An LS can still disobey the Rules, but even then, the 1866 architecture still works in some cases 1868 6. Glossary 1870 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 1871 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 1872 document are to be interpreted as described in RFC 2119 [1]. 1874 $ Access Control Rule 1876 A rule that describe which entities may receive location 1877 information and in what form. 1879 $ Authorized Location Server (LSa) 1881 A Location Server that receives Rules from a Rule Maker (in 1882 addition to Rules provided in LOs). An Authorized Location Server 1883 may receive Location Objects containing Privacy Rules from 1884 Location Generators and other Location Servers, and it may also 1885 receive Privacy Rules directly from Rule Makers. 1887 $ civic location 1889 The geographic position of an entity in terms of a postal address 1890 or civic landmark. Examples of such data are room number, street 1891 number, street name, city, ZIP code, county, state and country. 1893 $ geodetic location 1895 The geographic position of an entity in a particular coordinate 1896 system (for example, a latitude-longitude pair). 1898 $ Independent Location Server (LSi) 1900 A Location Server that has no relationship with a Rule Maker. An 1901 Independent Location Server may receive Location Objects 1902 containing Privacy Rules from Location Generators and other 1903 Location Servers, but it does not receive Privacy Rules directly 1904 from Rule Makers. 1906 $ Local Rule 1908 A Privacy Rules that directs a Location Server about how to treat 1909 a Target's location information. Local Rules are used internally 1910 by a Location Server to handle requests from Location Recipients. 1911 They are not distributed to Location Recipients. 1913 $ Location Generator (LG) 1915 An entity that initially determines or gathers the location of a 1916 Target. Location Generators may be any sort of software or 1917 hardware used to obtain a Target's position (examples include GPS 1918 chips and cellular networks). 1920 $ Location Information Server (LIS) 1922 An entity responsible for providing devices within an access 1923 network with information about their own locations. A Location 1924 Information Server uses knowledge of the access network and its 1925 physical topology to generate and distribute location information 1926 to devices. 1928 $ Location Object (LO) 1930 A data unit that conveys location information together with 1931 Privacy Rules within the Geopriv architecture. A Location Object 1932 may convey geodetic location data (latitiude/longitude/altitude), 1933 civic location data (street/city/state/etc.), or both. 1935 $ Location Recipient (LR) 1937 An ultimate end point entity to which a Location Object is 1938 distributed. Location Recipients request location information 1939 about a particular Target from a Location Server. If allowed by 1940 the appropriate Privacy Rules, a Location Recipient will receive 1941 Location Objects describing the Target's location from the 1942 Location Server. 1944 $ Location Server (LS) 1946 An entity that receives Location Objects from Location Generators, 1947 Privacy Rules from Rule Makers, and location requests from 1948 Location Recipients. A Location Server applies the appropriate 1949 Privacy Rules to a Location Object received from a Location 1950 Generator and may disclose the Location Object, in compliance with 1951 the Rules, to Location Recipients. 1953 Location Servers may not necessarily be "servers" in the 1954 colloquial sense of hosts in remote data centers servicing 1955 requests. Rather, a Location Server can be any software or 1956 hardware component that receives and distributes location 1957 information. Examples include a positioning server (with a 1958 location interface) in an access network, a presence server, or a 1959 Web browser or other software running on a Target's device. 1961 $ Privacy Rule 1963 A directive that regulates an entity's activities with respect to 1964 a Target's location information, including the collection, use, 1965 disclosure, and retention of the location information. Privacy 1966 Rules describe how location information may be used by an entity, 1967 the level of detail with which location information may be 1968 described to an entity, and the conditions under which location 1969 information may be disclosed to an entity. Privacy Rules are 1970 communicated from Rule Makers to Location Servers and conveyed in 1971 Location Objects throughout the Geopriv architecture. 1973 $ Rule 1975 See Privacy Rule. 1977 $ Rule Maker (RM) 1979 An individual or entity that is authorized to set Privacy Rules 1980 for a Target. In some cases a Rule Maker and a Target will be the 1981 same individual or entity, and in other cases they will be 1982 separate. For example, a parent may serve as the Rule Maker when 1983 the Target is his child. The Rule Maker is also not necessarily 1984 the owner of a Target device. For example, a corporation may own 1985 a device that it provides to an employee but permit the employee 1986 to serve as the Rule Maker and set her own Privacy Rules. Rule 1987 Makers provide the Privacy Rules associated with a Target to 1988 Location Servers. 1990 $ Forwarded Rule 1992 A Privacy Rule that travels inside a Location Object. Forwarded 1993 Rules direct Location Recipients about how to handle the location 1994 information they receive. Because the Forwarded Rules themselves 1995 may reveal potentially sensitive information about a Target, only 1996 the minimal subset of Forwarded Rules necessary for a Location 1997 Recipient to handle a Location Object is distributed to the 1998 Location Recipient. 2000 $ Target 2002 An individual or other entity whose location is described by a 2003 Location Object. The Target is the entity whose privacy Geopriv 2004 seeks to protect. 2006 $ Usage Rule 2008 A rule that describe what uses of location information are 2009 authorized. 2011 7. Acknowledgements 2013 This work was largely based on the security investigations conducted 2014 as part of the Geopriv Layer-7 Location Configuration Protocol design 2015 team, which produced [5]. We would like to thank all the members of 2016 the design team. 2018 8. IANA Considerations 2020 This document makes no request of IANA. 2022 9. References 2024 9.1. Normative References 2026 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2027 Levels", BCP 14, RFC 2119, March 1997. 2029 9.2. Informative References 2031 [2] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. 2032 Polk, "Geopriv Requirements", RFC 3693, February 2004. 2034 [3] Danley, M., Mulligan, D., Morris, J., and J. Peterson, "Threat 2035 Analysis of the Geopriv Protocol", RFC 3694, February 2004. 2037 [4] U.S. Department of Defense, "National Industrial Security 2038 Program Operating Manual", DoD 5220-22M, January 1995. 2040 [5] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location 2041 Configuration Protocol; Problem Statement and Requirements", 2042 draft-ietf-geopriv-l7-lcp-ps-09 (work in progress), 2043 February 2009. 2045 [6] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host 2046 Configuration Protocol Option for Coordinate-based Location 2047 Configuration Information", RFC 3825, July 2004. 2049 [7] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 2050 and DHCPv6) Option for Civic Addresses Configuration 2051 Information", RFC 4776, November 2006. 2053 [8] Polk, J., "Dynamic Host Configuration Protocol (DHCP) Option 2054 for a Location Uniform Resource Identifier (URI)", 2055 draft-ietf-geopriv-dhcp-lbyr-uri-option-03 (work in progress), 2056 November 2008. 2058 [9] Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, "HTTP 2059 Enabled Location Delivery (HELD)", 2060 draft-ietf-geopriv-http-location-delivery-13 (work in 2061 progress), February 2009. 2063 [10] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk, 2064 J., and J. Rosenberg, "Common Policy: A Document Format for 2065 Expressing Privacy Preferences", RFC 4745, February 2007. 2067 [11] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., and 2068 J. Polk, "Geolocation Policy: A Document Format for Expressing 2069 Privacy Preferences for Location Information", 2070 draft-ietf-geopriv-policy-20 (work in progress), February 2009. 2072 [12] Rosenberg, J., "The Extensible Markup Language (XML) 2073 Configuration Access Protocol (XCAP)", RFC 4825, May 2007. 2075 [13] Marshall, R., "Requirements for a Location-by-Reference 2076 Mechanism", draft-ietf-geopriv-lbyr-requirements-07 (work in 2077 progress), February 2009. 2079 [14] Peterson, J., "A Presence-based GEOPRIV Location Object 2080 Format", RFC 4119, December 2005. 2082 [15] World Wide Web Consortium, "The XMLHttpRequest Object", W3C 2083 document http://www.w3.org/TR/XMLHttpRequest/, April 2008. 2085 [16] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, "Framework 2086 for Emergency Calling using Internet Multimedia", 2087 draft-ietf-ecrit-framework-08 (work in progress), 2088 February 2009. 2090 [17] Rosen, B. and J. Polk, "Best Current Practice for 2091 Communications Services in support of Emergency Calling", 2092 draft-ietf-ecrit-phonebcp-08 (work in progress), February 2009. 2094 [18] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, 2095 "LoST: A Location-to-Service Translation Protocol", RFC 5222, 2096 August 2008. 2098 [19] Schulzrinne, H., "Location-to-URL Mapping Architecture and 2099 Framework", draft-ietf-ecrit-mapping-arch-04 (work in 2100 progress), March 2009. 2102 [20] Polk, J. and B. Rosen, "Location Conveyance for the Session 2103 Initiation Protocol", draft-ietf-sip-location-conveyance-12 2104 (work in progress), November 2008. 2106 URIs 2108 [21] 2110 Authors' Addresses 2112 Richard Barnes 2113 BBN Technologies 2114 9861 Broken Land Pkwy, Suite 400 2115 Columbia, MD 21046 2116 USA 2118 Phone: +1 410 290 6169 2119 Email: rbarnes@bbn.com 2121 Matt Lepinski 2122 BBN Technologies 2123 10 Moulton St 2124 Cambridge, MA 02138 2125 USA 2127 Phone: +1 617 873 5939 2128 Email: mlepinski@bbn.com 2130 Alissa Cooper 2131 Center for Democracy & Technology 2132 1634 I Street NW, Suite 1100 2133 Washington, DC 2134 USA 2136 Email: acooper@cdt.org 2138 John Morris 2139 Center for Democracy & Technology 2140 1634 I Street NW, Suite 1100 2141 Washington, DC 2142 USA 2144 Email: jmorris@cdt.org 2145 Hannes Tschofenig 2146 Nokia Siemens Networks 2147 Linnoitustie 6 2148 Espoo 02600 2149 Finland 2151 Phone: +358 (50) 4871445 2152 Email: Hannes.Tschofenig@gmx.net 2153 URI: http://www.tschofenig.priv.at 2155 Henning Schulzrinne 2156 Columbia University 2157 Department of Computer Science 2158 450 Computer Science Building 2159 New York, NY 10027 2160 US 2162 Phone: +1 212 939 7004 2163 Email: hgs@cs.columbia.edu 2164 URI: http://www.cs.columbia.edu