idnits 2.17.1 draft-ietf-geopriv-arch-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. -- 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 lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 11, 2010) is 4943 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '27' is defined on line 1761, but no explicit reference was found in the text == Outdated reference: A later version (-27) exists of draft-ietf-geopriv-policy-21 -- Obsolete informational reference (is this intentional?): RFC 3825 (ref. '10') (Obsoleted by RFC 6225) == Outdated reference: A later version (-19) exists of draft-ietf-geopriv-dhcp-lbyr-uri-option-08 -- Obsolete informational reference (is this intentional?): RFC 5246 (ref. '17') (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 2616 (ref. '19') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Outdated reference: A later version (-13) exists of draft-ietf-ecrit-framework-11 == Outdated reference: A later version (-20) exists of draft-ietf-ecrit-phonebcp-15 -- Obsolete informational reference (is this intentional?): RFC 3920 (ref. '25') (Obsoleted by RFC 6120) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 8 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: April 14, 2011 Center for Democracy & 8 Technology 9 H. Tschofenig 10 Nokia Siemens Networks 11 H. Schulzrinne 12 Columbia University 13 October 11, 2010 15 An Architecture for Location and Location Privacy in Internet 16 Applications 17 draft-ietf-geopriv-arch-03 19 Abstract 21 Location-based services (such as navigation applications, emergency 22 services, management of equipment in the field) need geographic 23 location information about Internet hosts, their users, and other 24 related entities. These applications need to securely gather and 25 transfer location information for location services, and at the same 26 time protect the privacy of the individuals involved. This document 27 describes an architecture for privacy-preserving location-based 28 services in the Internet, focusing on authorization, security, and 29 privacy requirements for the data formats and protocols used by these 30 services. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on April 14, 2011. 49 Copyright Notice 51 Copyright (c) 2010 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 1.1. Binding Rules to Data . . . . . . . . . . . . . . . . . . 4 68 1.2. Location-Specific Privacy Risks . . . . . . . . . . . . . 5 69 1.3. Privacy Paradigms . . . . . . . . . . . . . . . . . . . . 6 70 2. Terminology Conventions . . . . . . . . . . . . . . . . . . . 7 71 3. Overview of the Architecture . . . . . . . . . . . . . . . . . 7 72 3.1. Basic Geopriv Scenario . . . . . . . . . . . . . . . . . . 8 73 3.2. Roles and Data Formats . . . . . . . . . . . . . . . . . . 10 74 4. The Location Life-Cycle . . . . . . . . . . . . . . . . . . . 13 75 4.1. Positioning . . . . . . . . . . . . . . . . . . . . . . . 14 76 4.1.1. Determination Mechanisms and Protocols . . . . . . . . 14 77 4.1.2. Privacy Considerations for Positioning . . . . . . . . 16 78 4.1.3. Security Considerations for Positioning . . . . . . . 17 79 4.2. Location Distribution . . . . . . . . . . . . . . . . . . 17 80 4.2.1. Privacy Rules . . . . . . . . . . . . . . . . . . . . 18 81 4.2.2. Location Configuration . . . . . . . . . . . . . . . . 20 82 4.2.3. Location References . . . . . . . . . . . . . . . . . 20 83 4.2.4. Privacy Considerations for Distribution . . . . . . . 21 84 4.2.5. Security Considerations for Distribution . . . . . . . 23 85 4.3. Location Use . . . . . . . . . . . . . . . . . . . . . . . 24 86 4.3.1. Privacy Considerations for Use . . . . . . . . . . . . 24 87 4.3.2. Security Considerations for Use . . . . . . . . . . . 24 88 5. Security Considerations . . . . . . . . . . . . . . . . . . . 25 89 6. Example Scenarios . . . . . . . . . . . . . . . . . . . . . . 27 90 6.1. Minimal Scenario . . . . . . . . . . . . . . . . . . . . . 27 91 6.2. Location-based Web Services . . . . . . . . . . . . . . . 28 92 6.3. Emergency Calling . . . . . . . . . . . . . . . . . . . . 30 93 6.4. Combination of Services . . . . . . . . . . . . . . . . . 32 94 7. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 95 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37 96 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 97 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 98 10.1. Normative References . . . . . . . . . . . . . . . . . . . 37 99 10.2. Informative References . . . . . . . . . . . . . . . . . . 37 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 102 1. Introduction 104 Location-based services (applications that require information about 105 the geographic location of an individual or device) are becoming 106 increasingly common on the Internet. Navigation and direction 107 services, emergency services, friend finders, management of equipment 108 in the field and many other applications require geographic location 109 information about Internet hosts, their users, and other related 110 entities. As the accuracy of location information improves and the 111 expense of calculating and obtaining it declines, the distribution 112 and use of location information in Internet-based services will 113 likely become increasingly pervasive. Ensuring that location 114 information is transmitted and accessed in a secure and privacy- 115 protective way is essential to the future success of these services, 116 as well as the minimization of the privacy harms that could flow from 117 their wide deployment and use. 119 Standards for communicating location information over the Internet 120 have an important role to play in providing a technical basis for 121 privacy and security protection. This document describes a 122 standardized privacy- and security-focused architecture for location- 123 based services in the Internet: the Geopriv architecture. The 124 central component of the Geopriv architecture is the location object, 125 which is used to convey both location information about an individual 126 or device and user-specified privacy rules governing that location 127 information. As location information moves through its life cycle -- 128 positioning, distribution, and use by its ultimate recipient(s) -- 129 Geopriv provides mechanisms to secure the integrity and 130 confidentiality of location objects and to ensure that location 131 information is only transmitted in compliance with the user's privacy 132 rules. 134 The goals of this document are two-fold: First, the architecture 135 described revises and expands on the basic Geopriv Requirements 136 [2][3], in order to clarify how these privacy concerns and the 137 Geopriv architecture apply to use cases that have arisen since the 138 publication of those documents. Second, this document provides a 139 general introduction to Geopriv and Internet location-based services, 140 and is useful as a good first document for readers new to Geopriv. 142 1.1. Binding Rules to Data 144 A central feature of the Geopriv architecture is that location 145 information is always bound to privacy rules to ensure that entities 146 that receive location are informed of how they may use it. These 147 rules can convey simple directives ("do not share my location with 148 others"), or more robust preferences ("allow my spouse to know my 149 exact location all of the time, but only allow my boss to know it 150 during work hours"). By creating a structure to convey the user's 151 preferences along with location information, the likelihood that 152 those preferences will be honored necessarily increases. In 153 particular, no recipient of the location information can disavow 154 knowledge of users' preferences for how their location may be used. 155 The binding of privacy rules to location information can convey 156 users' desire for and expectations of privacy, which in turn helps to 157 bolster social and legal systems' protection of those expectations. 159 Binding of usage rules to sensitive information is a common way of 160 protecting information. Several emerging schemes for expressing 161 copyright information provide for rules to be transmitted together 162 with copyrighted works. The Creative Commons [28] model is the most 163 prominent example, allowing an owner of a work to set four types of 164 rules ("Attribution," "Noncommercial," "No Derivative Works" and 165 "ShareAlike") governing the subsequent use of the work. After the 166 author sets these rules, the rules are conveyed together with the 167 work itself, so that every recipient is aware of the copyright terms. 169 Classification systems for controlling sensitive documents within an 170 organization are another example. In these systems, when a document 171 is created, it is marked with a classification such as "SECRET" or 172 "PROPRIETARY." Each recipient of the document knows from this 173 marking that the document should only be shared with other people who 174 are authorized to access documents with that marking. Classification 175 markings can also convey other sorts of rules, such as a 176 specification for how long the marking is valid (a declassification 177 date). The United States Department of Defense guidelines for 178 classification [4] provide one example. 180 1.2. Location-Specific Privacy Risks 182 While location-based services raise some privacy concerns that are 183 common to all forms of personal information, many of them are 184 heightened and others are uniquely applicable in the context of 185 location information. 187 Location information is frequently generated on or by mobile devices. 188 Because individuals often carry their mobile devices with them, 189 location data may be collected everywhere and at any time, often 190 without user interaction, and it may potentially describe both what a 191 person is doing and where he or she is doing it. For example, 192 location data can reveal the fact that an individual was at a 193 particular medical clinic at a particular time. The ubiquity of 194 location information may also increase the risks of stalking and 195 domestic violence if perpetrators are able to use (or abuse) 196 location-based services to gain access to location information about 197 their victims. 199 Location information is also of particular interest to governments 200 and law enforcers around the world. The existence of detailed 201 records of individuals' movements should not automatically facilitate 202 the ability for governments to track their citizens, but in some 203 jurisdictions, laws dictating what government agents must do to 204 obtain location data are either non-existent or out-of-date. 206 1.3. Privacy Paradigms 208 Traditionally, the extent to which data about individuals enjoys 209 privacy protections on the Internet has largely been decided by the 210 recipients of the data. Internet users may or may not be aware of 211 the privacy practices of the entities with whom they share data. 212 Even if they are aware, they have generally been limited to making a 213 binary choice between sharing data with a particular entity or not 214 sharing it. Internet users have not historically been granted the 215 opportunity to express their own privacy preferences to the 216 recipients of their data and to have those preferences honored. 218 This paradigm is problematic because the interests of data recipients 219 are often not aligned with the interests of data subjects. While 220 both parties may agree that data should be collected, used, disclosed 221 and retained as necessary to deliver a particular service to the data 222 subject, they may not agree about how the data should otherwise be 223 used. For example, an Internet user may gladly provide his email 224 address on a Web site to receive a newsletter, but he may not want 225 the Web site to share his email address with marketers, whereas the 226 Web site may profit from such sharing. Neither providing the address 227 for both purposes nor deciding not to provide it is an optimal option 228 from the Internet user's perspective. 230 The Geopriv model departs from this paradigm for privacy protection. 231 As explained above, location information can be uniquely sensitive. 232 And as siloed location-based services emerge and proliferate, they 233 increasingly require standardized protocols for communicating 234 location information between services and entities. Recognizing both 235 of these dynamics, Geopriv gives data subjects the ability to express 236 their choices with respect to their own location information, rather 237 than allowing the recipients of the information to define how it will 238 be used. The combination of heightened privacy risk and the need for 239 standardization compelled the Geopriv designers to shift away from 240 the prevailing Internet privacy model, instead empowering users to 241 express their privacy preferences about the use of their location 242 information. 244 Geopriv does not, by itself, provide technical means through which it 245 can be guaranteed that users' location privacy rules will be honored 246 by recipients. The privacy protections in the Geopriv architecture 247 are largely provided by virtue of the fact that recipients of 248 location are informed of relevant privacy rules, and are expected to 249 only use location in accordance with those rules. The distributed 250 nature of the architecture inherently limits the degree to which 251 compliance can be guaranteed and verified by technical means. 252 Section 5 describes how some security mechanisms can address this to 253 a limited extent. 255 By binding privacy rules to location information, however, Geopriv 256 provides valuable information about users' privacy preferences, so 257 that non-technical forces such as legal contracts, governmental 258 consumer protection authorities, and marketplace feedback can better 259 enforce those privacy preferences. If a commercial recipient of 260 location information, for example, violates the location rules bound 261 to the information, the recipient can in a growing number of 262 countries be charged with violating consumer or data protection laws. 263 In the absence of a binding of rules with location information, 264 consumer protection authorities would be less able to protect 265 individuals whose location information has been abused. 267 2. Terminology Conventions 269 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 270 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 271 document are to be interpreted as described in RFC 2119 [1]. 273 3. Overview of the Architecture 275 This section provides an overview of the Geopriv architecture for the 276 secure and private distribution of location information on the 277 Internet. We describe the three phases of the "location life cycle" 278 -- positioning, distribution and use -- and discuss how the 279 components of the architecture fit within each phase. The next 280 section provides additional detail about how each phase can be 281 achieved in a private and secure manner. 283 The risks discussed in the previous section all arise from 284 unauthorized disclosure or usage of location information. Thus, the 285 Geopriv architecture has two fundamental privacy goals: 287 1. Ensure that location information is distributed only to 288 authorized entities, and 290 2. Provide information to those entities about how they are 291 authorized to use the location information. 293 If these two goals are met, all parties that receive location 294 information will also receive directives about how they can use that 295 information. Privacy-preserving entities will only engage in 296 authorized uses, and entities that violate privacy will do so 297 knowingly, since they have been informed of what is authorized (and 298 thus, implicitly, of what is not). 300 Privacy rules and their distribution are thus the central technical 301 components of the privacy system, since they inform location 302 recipients about how they are authorized to use that information. 303 The two goals in the preceding paragraph are enabled by two classes 304 of rules: 306 1. Access control rules: Rules that describe which entities may 307 receive location information and in what form 309 2. Usage rules: Rules that describe what uses of location 310 information are authorized 312 Within this framework for privacy, security mechanisms provide 313 support for the application of privacy rules. For example, 314 authentication mechanisms validate the identities of entities 315 requesting location (so that authorization and access-control 316 policies can be applied), and confidentiality mechanisms protect 317 location information en route between privacy-preserving entities. 318 Security mechanisms can also provide assurances that are outside the 319 purview of privacy by, for example, assuring location recipients that 320 location information has been faithfully transmitted to them by its 321 creator. 323 3.1. Basic Geopriv Scenario 325 As location information is transmitted among Internet hosts, it goes 326 through a "location life-cycle": first, the location is computed 327 based on some external information (positioning), then it is 328 transmitted from one host to another (distribution) until finally it 329 is used by a recipient (use). 331 For example, suppose Alice is using a mobile device, she learns of 332 her location from a wireless location service, and she wishes to 333 share her location privately with her friends by way of a presence 334 service. Alice clearly needs to provide the presence server with her 335 location and rules about which friends can be provided with her 336 location. To enable Alice's friends to preserve her privacy, they 337 need to be provided with privacy rules. Alice may tell some of her 338 friends the rules directly, or she can have the presence server 339 provide the rules to her friends when it provides them with her 340 location. In this way, every friend who receives Alice's location is 341 authorized by Alice to receive it, and every friend who receives it 342 knows the rules. Good friends will obey the rules. If a bad friend 343 breaks them and Alice finds out, the bad friend cannot claim that he 344 was unaware of the rules. 346 Some of Alice's friends will be interested in using Alice's location 347 only for their own purposes (to meet up with her or plot her location 348 over time, for example). The usage rules that they receive direct 349 them as to what they can or cannot do (for example, Alice might not 350 want them keeping her location for more than, say, two weeks). 352 Consider one friend, Bob, who wants to send Alice's location to some 353 of his friends. To operate in a privacy-protective way, Bob needs 354 not only usage rules for himself, but also access control rules that 355 describe who he can send information to and rules to give to the 356 recipients. If the rules he received from the presence server 357 authorize him to give Alice's location to others, he may do so; 358 otherwise, he will require additional rules from Alice before he is 359 authorized to distribute her location. If recipients who receive 360 Alice's location from Bob want to distribute the location on further, 361 they must go through the same process as Bob. 363 The whole example is illustrated in the following figure: 365 +----------+ 366 | Wireless | 367 | Location | 368 | Service | Retrieve 369 +----------+ Access Control Rules 370 | +-----------------------------------+ 371 | | +-----------------------------+ | 372 Location | | Access | | 373 | | | Control Rules v | 374 | | | +-----+ 375 | | | | | 376 | | | | Bob |--> ... 377 | | | +----->| | 378 v v | | +-----+ 379 +----------+ +----------+ | 380 | |Device| |--Location->| Presence |--Location---->| +----------+ 381 | -------- | | Server | |---->| Friend-1 | 382 | |---Rules--->| |---Rules------>| +----------+ 383 | Alice | +----------+ | 384 +----------+ | 385 | +----------+ 386 +---->| Friend-2 | 387 +----------+ 389 Figure 1: Basic Geopriv Scenario 391 3.2. Roles and Data Formats 393 The above example illustrates the six basic roles in the Geopriv 394 architecture: 396 Target: An individual or other entity whose location is sought in 397 the Geopriv architecture. In many cases the Target will be the 398 human user of a Device, but it can also be an object such as a 399 vehicle or shipping container to which a Device is attached. In 400 some instances the Target will be the Device itself. The Target 401 is the entity whose privacy Geopriv seeks to protect. Alice is 402 the Target in Figure 1. 404 Device: The technical device whose location is tracked as a proxy 405 for the location of a Target. Alice's device is the Device in 406 Figure 1. 408 Rule Maker (RM): Performs the role of creating rules governing 409 access to location information for a Target. In some cases the 410 Target performs the Rule Maker role (as is the case with Alice), 411 and in other cases they are separate. For example, a parent may 412 serve as the Rule Maker when the Target is his child, or a 413 corporate security officer may serve as the Rule Maker for devices 414 owned by the corporation but used by employees. The Rule Maker is 415 also not necessarily the owner of the Device. For example, a 416 corporation may provide a Device to an employee but permit the 417 employee to serve as the Rule Maker and set her own privacy rules. 419 Location Generator (LG): Performs the roles of initially 420 determining or gathering the location of the Device and providing 421 it to Location Servers. Location Generators may be any sort of 422 software or hardware used to obtain the Device's location 423 (examples include GPS chips and cellular networks). A Device may 424 even perform the Location Generator role for itself; Devices 425 capable of unassisted satellite-based positioning and Devices that 426 accept manually entered location information are two examples. 427 The wireless location service plays the Location Generator role in 428 Figure 1. 430 Location Server (LS): Performs the roles of receiving location 431 information and rules, applying the rules to the location 432 information to determine what other entities, if any, can receive 433 location information, and providing the location to Location 434 Recpients. Location Servers receive location information from 435 Location Generators and rules from Rule Makers, and then apply the 436 rules to the location information. Location Servers may not 437 necessarily be "servers" in the colloquial sense of hosts in 438 remote data centers servicing requests. Rather, a Location Server 439 can be any software or hardware component that distributes 440 location information. Examples include a server in an access 441 network, a presence server, or a Web browser or other software 442 running on a Device. The above example includes three Location 443 Servers: Alice, the presence service and Bob. 445 Location Recipient (LR): Performs the role of receiving location 446 information. A Location Recipient may ask for location explicitly 447 (by sending a query to a Location Server), or it may receive 448 location asynchronously. The presence service, Bob, Friend-1 and 449 Friend-2 are Location Recipients in Figure 1. 451 In general, these roles may or may not be performed by physically 452 separate entities, as demonstrated by the entities in Figure 1, many 453 of which perform multiple roles. It is not uncommon for the same 454 entity to perform both the Location Generator and Location Server 455 roles, or both the Location Recipient and Location Server roles. A 456 single entity may take on multiple roles simply by virtue of its own 457 capabilities and the permissions provided to it. 459 Although in the above example there is only a single Location 460 Generator and a single Rule Maker, in some cases a Location Server 461 may receive Location Objects from multiple Location Generators or 462 Rules from multiple Rule Makers. Likewise, a single Location 463 Generator may publish location information to multiple Location 464 Servers, and a single Location Recipient may receive Location Objects 465 from multiple Location Servers. 467 There is a close relationship between a Target and its Device. The 468 term "Device" is used when discussing protocol interactions, whereas 469 the term "Target" is used when discussing generically the person or 470 object being located and its privacy. While in the example above 471 there is a one-to-one relationship between the Target and the Device, 472 Geopriv can also be used to convey location information about a 473 device that is not directly linked to a single individual or object, 474 such as a Device shared by multiple individuals. 476 Two data formats are necessary within this architecture: 478 Location Object (LO): An object used to convey location information 479 together with Privacy Rules. Geopriv supports both geodetic 480 location data (latitude/longitude/altitude/etc.) and civic 481 location data (street/city/state/etc.). Either or both types of 482 location information may be present in a single LO (see the 483 considerations in [5] for LOs containing multiple locations). 484 Location Objects typically include some sort of identifier 485 associated with the Target. 487 Privacy Rule: A directive that regulates an entity's activities 488 with respect to location information, including the collection, 489 use, disclosure, and retention of the location information. 490 Privacy Rules describe which entities may obtain location 491 information in what form (access control rules) and how location 492 information may be used by an entity (usage rules). 494 The whole example, using Geopriv roles and formats, is illustrated in 495 the following figure: 497 +----+ 498 | LG | 499 +----+ 500 ^ 501 | 502 Positioning 503 Data 504 | 505 | +------------Privacy Rules------------------>+----+ 506 | | +---->| LR |--> ... 507 | | | | LS | 508 v | | +----+ 509 +-------+ | 510 |Target | +----+ | +----+ 511 |Device |--------------->| LR |---------------+---->| LR | 512 | RM | LO | LS | LO | +----+ 513 | LS | +----+ | 514 +-------+ | 515 | +----+ 516 +---->| LR | 517 +----+ 519 Figure 2: Basic Geopriv Scenario 521 4. The Location Life-Cycle 523 The previous section gave an example of how an individual's location 524 can be distributed through the Internet. In general, the location 525 life-cycle breaks down into three phases: 527 1. Positioning: A Location Generator determines the Device's 528 location. 530 2. Distribution: Location Servers send location to Location 531 Recipients, which may in turn act as Location Servers and further 532 distribute location to other Location Recipients (possibly 533 several times). 535 3. Use: A Location Recipient receives the location and uses it. 537 Each of these phases involves a different set of Geopriv roles and 538 each has a different set of privacy and security implications. The 539 Geopriv roles are mapped onto the location life-cycle in the figure 540 below. 542 +----------+ +----------+ 543 | | | Rule |+ 544 | Device | | Maker(s)|| 545 | | | || 546 +----------+ +----------+| 547 ^| +----------+ 548 || Positioning | Rules 549 || Data | 550 || | 551 |V V 552 +----------+ +----------+ +----------+ 553 |Location | Location | Location |+ LO |Location | 554 |Generator |--------------->| Server(s)||-------------->|Recipient | 555 | | | || | | 556 +----------+ +----------+| +----------+ 557 +----------+ 558 <-------------------------><---------------------------><-----------> 559 Positioning Distribution Use 561 Figure 3: Location Life-Cycle 563 4.1. Positioning 565 Positioning is the process by which the physical location of the 566 Device is computed, based on some observations about the Device's 567 situation in the physical world. (This process goes by several other 568 names, including Location Determination or Sighting.) The input to 569 the positioning process is some information about the Device, and the 570 outcome is that the LG knows the location of the Device. 572 In this section, we give a brief taxonomy of current positioning 573 systems, their requirements for protocol support, and the privacy and 574 security requirements for positioning. 576 4.1.1. Determination Mechanisms and Protocols 578 While the specific positioning mechanisms that can be applied for a 579 given Device are strongly dependent on the physical situation and 580 capabilities of the Device, these mechanisms generally fall into the 581 three categories described in detail below: 583 o Device-based 585 o Network-based 587 o Network-assisted 588 As suggested by the above names, a positioning scheme can rely on the 589 Device, an Internet-accessible resource (not necessarily a network 590 operator), or a combination of the two. For a given scheme, the 591 nature of this reliance will dictate the protocol mechanisms needed 592 to support it. 594 With Device-based positioning mechanisms, the Device is capable of 595 determining its location by itself. This is the case for manually- 596 entered location or for (unassisted) satellite-based positioning 597 (using a Global Navigation Satellite System, or GNSS). In these 598 cases, the Device acts as its own LG, and there are no protocols 599 required to support positioning (since no information needs to be 600 communicated). 602 In network-based positioning schemes, an external LG (an Internet 603 host other than the Device) has access to sufficient information 604 about the Device, through out-of-band channels, to establish the 605 position of the Device. The most common examples of this type of LG 606 are entities that have a physical relationship to the Device (such as 607 ISPs). In wired networks, wiremap-based location is a network-based 608 technique; in wireless networks, timing and signal-strength based 609 techniques that use measurements from base stations are considered to 610 be network-based. Large-scale IP-to-geo databases (for example, 611 those based on WHOIS data or latency measurements) are also 612 considered to be network-based positioning mechanisms. 614 For network-based positioning as for Device-based, no protocols are 615 strictly necessary to support positioning, since positioning 616 information is collected outside of the location distribution system 617 (at lower layers of the network stack, for example). This does not 618 rule out the use of other Internet protocols (like SNMP) to collect 619 inputs to the positioning process. Rather, since these inputs can 620 only be used by certain LGs to determine location, they are not 621 controlled as private information. Network-based positioning often 622 provides location to protocols by which the network informs a Device 623 of its own location (these are known as Location Configuration 624 Protocols, see Section 4.2.2 for further discussion). 626 Network-assisted systems account for the greatest number and 627 diversity of positioning schemes. In these systems, the work of 628 positioning is divided between the Device and an external LG via some 629 communication (possibly over the Internet), typically in one of two 630 ways: 632 o The Device provides measurements to the LG 634 o The LG provides assistance data to the Device 635 "Measurements" are understood to be observations about the Device's 636 environment, ranging from wireless signal strengths to the MAC 637 address of a first-hop router. "Assistance" is the complement to 638 measurement, namely the positioning information that enables the 639 computation of location based on measurements. A set of wireless 640 base station locations (or wireless calibration information) would be 641 an assistance datum, as would be a table that maps routers to 642 buildings in a corporate campus. 644 For example, wireless and wired networks can serve as the basis for 645 network-assisted positioning. In several current 802.11 positioning 646 systems, the Device sends measurements (e.g., MAC addresses and 647 signal strengths) to an LG, and the LG returns a location to the 648 client. In wired networks, the Device can send its MAC address to 649 the LG, which can query the MAC-layer infrastructure to determine the 650 switch and port to which that MAC address is connected, then query a 651 wire map to determine the location at which the wire connected to 652 that port terminates. 654 As an aside, the common phrase "assisted GPS" ("assisted GNSS" more 655 broadly) actually encompasses techniques that transmit both 656 measurements and assistance data. Systems in which the Device 657 provides the LG with GNSS measurements are measurement-based, while 658 those in which the assistance server provide ephemeris or alamanac 659 data are assistance-based in the above terminology. (Those familiar 660 with GNSS positioning will note that there are of course cases in 661 which both of these interactions occur within a single location 662 determination protocol, so the categories are not mutually 663 exclusive.) 665 Naturally, the exchange of measurement or positioning data between 666 the Device and the LG requires a protocol over which the information 667 is carried. The structure of this protocol will depend on which of 668 the two patterns a network-assisted scheme follows. Conversely, the 669 structure of the protocol will determine which of the two parties 670 (the Device, the LG, or both) is aware of the Device's location at 671 the end of the protocol interaction. 673 4.1.2. Privacy Considerations for Positioning 675 Positioning is the first point at which location may be associated 676 with a particular Target's identity. Local identifiers, unlinked 677 pseudonyms, or private identifiers that are not linked to the real 678 identity of the Target should be used as forms of identity whenever 679 possible. This provides privacy protection by disassociating the 680 location from the Target's identity before it is distributed. 682 At the conclusion of the positioning process, the entity acting as 683 the LG has the Device's location (if the Device is performing the LG 684 role, then they both have it). If the entity acting as the LG also 685 performs the role of LS, the privacy considerations in Section 4.2.4 686 apply. 688 In some deployment scenarios, positioning functions and distribution 689 functions may need to be provided by separate entities, in which case 690 the LG and LS roles will not be performed by the same entity. In 691 this situation, the LG acts as a "dumb," non-privacy-aware 692 positioning resource, and the LS provides the privacy logic necessary 693 to support distribution (possibly with multiple LSes using the same 694 LG). In order to allow the privacy-unaware LG to distribute location 695 to these LSes while maintaining privacy, the relationship between the 696 LG and its set of LSes MUST be tightly constrained, effectively 697 "hard-wired." That is, the LG MUST only provide location to a small 698 fixed set of LSes, and each of these LSes MUST comply with the 699 requirements of Section 4.2.4. 701 4.1.3. Security Considerations for Positioning 703 Manipulation of the positioning process can expose location through 704 two mechanisms: 706 1) A third party could guess or derive measurements about a specific 707 device and use them to get the location of that Device. To mitigate 708 this risk, the LG SHOULD be able to authenticate and authorize 709 devices providing measurements and, if possible, verify that the 710 presented measurements are likely to be the actual physical values 711 measured by that client. These security procedures rely on the type 712 of positioning being done, and may not be technically feasible in all 713 cases. 715 2) By eavesdropping, a third party may be able to obtain measurements 716 sent by the Device itself that indicate the rough position of the 717 Device. To mitigate this risk, protocols used for positioning MUST 718 provide confidentiality and integrity protections in order to prevent 719 observation and modification of transmitted positioning data while en 720 route between the Target and the LG. 722 If an LG or a Target chooses to act as an LS, it inherits the 723 security requirements for an LS, described in Section 4.2.5. 725 4.2. Location Distribution 727 When an entity receives location (from an LG or an LS) and 728 redistributes it to other entities, it acts as an LS. Location 729 Distribution is the process by which one or more LSes provide LOs to 730 LRs in a privacy-preserving manner. 732 The role of an LS is thus two-fold: First, it must collect location 733 information and Rules that control access to that information. Rules 734 can be communicated within an LO, within a protocol that carries LOs, 735 or through a separate protocol that carries Rules. Second, the LS 736 must process requests for location and apply the Rules to these 737 requests in order to determine whether it is authorized to fulfill 738 them by returning location. 740 An LS thus has at least two types of interactions with other hosts, 741 namely receiving and sending LOs. An LS may optionally implement a 742 third interaction, allowing Rule Makers to provision it with Rules. 743 The distinction between these two cases is important in practice, 744 because it determines whether the LS has a direct relationship with a 745 Rule Maker: An LS that accepts Rules directly from a Rule Maker has 746 such a relationship, while an LS that acquires all its Rules through 747 LOs does not. 749 4.2.1. Privacy Rules 751 Privacy Rules are the central mechanism in Geopriv for maintaining a 752 Target's privacy, because they provide a recipient of an LO (an LS or 753 LR) with information on how the LO may be used. 755 Throughout the Geopriv architecture, Privacy Rules are communicated 756 in rules languages with a defined syntax and semantics. For example, 757 the Common Policy rules language has been defined [6] to provide a 758 framework for broad-based rule specifications. Geopriv Policy [7] 759 defines a language for creating location-specific rules. XCAP [8] 760 can be used as a protocol to install rules in both of these formats. 762 Privacy Rules follow a default-deny pattern: an empty set of Rules 763 implies that all requests for location should be denied (other than 764 requests made by the Target itself), with each Rule added to the set 765 granting a specific permission. Adding a Rule can only augment 766 privacy protections because all Rules are positive grants of 767 permission. 769 The following are examples of Privacy Rules governing location 770 distribution: 772 o Retransmit location when requested from example.com 774 o Retransmit only city and country 776 o Retransmit location with no less than a 100 meter radius of 777 uncertainty 779 o Retransmit location only for the next two weeks 781 LSes enforce Privacy Rules in two ways: by denying requests for 782 location, or by transforming the location information before 783 retransmitting it. 785 LSes may also receive Rules governing location retention, such as 786 "Retain location only for 48 hours." Such Rules are simply 787 directives about how long the Target's location information can be 788 retained. 790 Privacy Rules can govern the behavior of both LSes and LRs. Rules 791 that direct LSes about how to treat a Target's location information 792 are known as Local Rules. Local Rules are used internally by the LS 793 to handle requests from LRs. They are not distributed to LRs. 795 Forwarded Rules, on the other hand, travel inside LOs and direct LSes 796 and LRs about how to handle the location information they receive. 797 Because the Rules themselves may reveal potentially sensitive 798 information about the Target, only the minimal subset of Forwarded 799 Rules necessary to handle the LO is distributed. 801 An example can illustrate the interaction between Local Rules and 802 Forwarded Rules. Suppose Alice provides the following Local Rules to 803 an LS: 805 o The LS may retransmit Alice's precise location to Bob, who in turn 806 is permitted to retain the location information for one month 808 o The LS may retransmit Alice's city, state, and country to Steve, 809 who in turn is permitted to retain the location information for 810 one hour 812 o The LS may retransmit Alice's country to a photo-sharing website, 813 which in turn is permitted to retain the location information for 814 one year and retransmit it to any requesters 816 When Steve asks for Alice's location, the LS can transmit to Steve 817 the limited location information (city, state, and country) along 818 with Forwarded Rules instructing Steve to (a) not further retransmit 819 Alice's location information, and (b) only retain the location 820 information for one hour. By only sending these specifically 821 applicable Forwarded Rules to Steve (as opposed to the full set of 822 Local Rules), the LS is protecting Alice's privacy by not disclosing 823 to Steve that (for example) Alice allows Bob to obtain more precise 824 location information than Alice allows Steve to receive. 826 Geopriv is designed to be usable even by devices with constrained 827 processing capabilities. To ensure that Forwarded Rules can be 828 processed on constrained devices, LOs are required to carry only a 829 limited set of Forwarded Rules, with an option to reference a more 830 robust set of external Rules. The limited Rule set covers two 831 privacy aspects: how long the Target's location may be retained 832 ("Retention"), and whether or not the Target's location may be 833 retransmitted ("Retransmission"). A LO may contain a pointer to more 834 robust Rules, such as those shown in the set of four Rules at the 835 beginning of this section. 837 4.2.2. Location Configuration 839 Some entities performing the LG role are designed only to provide 840 Targets with their own locations (as opposed to distributing a 841 Target's location to others). The process of providing a Target with 842 its own location is known within Geopriv as Location Configuration. 843 The term Location Information Server (LIS) is often used to describe 844 the entity that performs this function (although a LIS may also 845 perform other functions, such as providing a Target's location to 846 other entities). 848 A Location Configuration Protocol (LCP) [9] is one mechanism that can 849 be used by a Device to discover its own location from a LIS. LCPs 850 provide functions in the way they obtain, transport and deliver 851 location requests and responses between a LIS and a Device such that 852 the LIS can trust that the location requests and responses handled 853 via the LCP are in fact from/to the Target. Several LCPs have been 854 developed within Geopriv [10][11][12][13]. 856 A LIS whose sole purpose is to perform Location Configuration need 857 only follow a simple privacy-preserving policy: transmit a Target's 858 location only to the Target itself. This is known as the "LCP 859 policy." 861 Importantly, if an LS is also serving in the role of LG and it has 862 not been provisioned with Privacy Rules for a particular Target, it 863 MUST follow the LCP policy, whether it is a LIS or not. In the 864 positioning phase, an entity serving the roles of both LG and LS that 865 has not received Privacy Rules must follow this policy. The same is 866 true for any LS in the distribution phase. 868 4.2.3. Location References 870 The location distribution process occurs through a series of 871 transmissions of LOs: transmissions of location "by value." Location 872 "by value" can be expressed in terms of geodetic location data 873 (latitude/longitude/altitude/etc.) and civic location data (street/ 874 city/state/etc.). 876 Location can also be distributed "by reference," where a reference is 877 represented by a URI that can be dereferenced to obtain the LO. This 878 document summarizes the properties of location-by-reference that are 879 discussed at length in [14]. 881 Distribution of location by reference (distribution of location URIs) 882 offer several benefits. Location URIs are a more compact way of 883 transmitting location, since URIs are usually smaller than LOs. A 884 recipient of location can make multiple requests to a URI over time 885 to receive updated location (if the URI is configured to provide 886 fresh location rather than a single "snapshot"). 888 From a positioning perspective, location by reference can offer the 889 additional benefit of "just in time" positioning. If location is 890 distributed by reference, an entity acting as a combined LG/LS only 891 needs to perform positioning operations when a recipient dereferences 892 a previously distributed URI. 894 From a privacy perspective, distributing location as a URI instead of 895 as an LO can help protect privacy by forcing each recipient of the 896 location to request location from the referenced LS, which can then 897 apply access controls individually to each recipient. But the 898 benefit provided here is contingent on the LS applying access 899 controls. If the LS does not apply an access control policy to 900 requests for a location URI (in other words, if it enforces the 901 "possession model" defined in [14]), then transmitting a location URI 902 presents the same privacy risks as transmitting the LO itself. 903 Moreover, the use of location URIs without access controls can 904 introduce additional privacy risks: If URIs predictable, an attacker 905 to whom the URI has not been sent may be able to guess the URI and 906 use it to obtain the referenced LO. To mitigate this, location URIs 907 without access controls need to be constructed so that they contain a 908 random component with sufficient entropy to make guessing infeasible. 910 4.2.4. Privacy Considerations for Distribution 912 Location information MUST be accompanied by Rules throughout the 913 distribution process. Otherwise, a recipient will not know what uses 914 are authorized, and will not be able to use the LO. Consequently, 915 LOs MUST be able to express Rules that convey appropriate 916 authorizations. 918 An LS MUST only accept Rules from authorized Rule Makers. For an LS 919 that receives Rules exclusively in LOs and has no direct relationship 920 with a Rule Maker, this requirement is met by applying the Rules 921 provided in an LO to the distribution of that LO. For an LS with a 922 direct relationship to a Rule Maker, this requirement means that the 923 LS MUST be configurable with an RM authorization policy. An LS 924 SHOULD define a prescribed set of RMs that may provide Rules for a 925 given Target or LO. For example, an LS may only allow the Target to 926 set Rules for itself, or it might allow an RM to set Rules for 927 several Targets (e.g., a parent for children, or a corporate security 928 officer for employees). 930 No matter how Rules are provided to an LS, for each LO it receives, 931 it MUST combine all Rules that apply to the LO into a Rule set that 932 defines which transmissions are authorized, and it MUST transmit 933 location only in ways that are authorized by these Rules. 935 An LS that receives Rules exclusively through LOs MUST examine the 936 Rules that accompany a given LO in order to determine how the LS may 937 use the LO (if any Rules are included by reference, the LS SHOULD 938 attempt to download them). If the LO includes no Rules that allow 939 the LS to transmit the LO to another entity, then the LS MUST NOT 940 transmit the LO. If the LO contains no Rules at all (if it is in a 941 format with no Rules syntax, for example), then the LS MUST delete it 942 (emergency services provide an exception in that Rules can be implicit, 943 see [15]). If the LO included Rules by reference, but these Rules 944 were not obtained for any reason, the LS MUST NOT transmit the LO and 945 MUST delete it. 947 An LS that receives Rules both directly from one or more Rule Makers 948 and through LOs MUST combine the Rules in a given LO with Rules it 949 has received from the RMs. The strategy the LS uses to combine these 950 sets of Rules is a matter for local policy, depending on the relative 951 priority that the LS grants to each source of Rules. Some example 952 policies: 954 Union: A transmission of location is authorized if it is authorized 955 by either a rule in the LO or an RM-provided rule. 957 Intersection: A transmission of location is authorized if it is 958 authorized by both a rule in the LO and an RM-provided rule. 960 RM Override: A transmission of location is authorized if it is 961 authorized by an RM-provided rule (regardless of the LO Rules). 963 LO Override: A transmission of location is authorized if it is 964 authorized by an LO-provided rule (regardless of the RM Rules). 966 Different policies may be applicable in different scenarios. In 967 cases where an external RM is more trusted than the source of the LO, 968 the "RM Override" policy may be suitable (for example, if the 969 external RM is the Target, and the LO is provided by a third party). 970 Conversely, the "LO Override" policy is better suited to cases where 971 the LO provider is more trused than the RM (for example, if the RM is 972 the user of a mobile device LS and the LO contains Rules from the 973 RM's parents or corporate security office). The "Intersection" 974 policy takes the strictest view of the permission grants, giving 975 equal weight to all RMs (including the LO creator). 977 Each of these policies will also have different privacy consequences. 978 Following the "Intersection" policy ensures that the most privacy- 979 protective subset of all RMs' rules will be followed. The "Union" 980 policy and both "Override" policies may defy the expectations of any 981 RM (including, potentially, the Target) whose policy is not followed. 982 For example, if a Target acting as an RM sets Rules and those Rules 983 are overridden by the application of a more permissive LO Override 984 policy that has been set by the Target's parent or employer acting as 985 an RM, the retransmission or retention of the Target's data may come 986 as a surprise to the Target. For this reason, it is RECOMMENDED that 987 LSes provide a way for RMs to be able to find out which policy will 988 be applied to the distribution of a given LO. 990 4.2.5. Security Considerations for Distribution 992 An LS's decisions about how to transmit location are based on the 993 identities of entities requesting information and other aspects of 994 requests for location. In order to ensure that these decisions are 995 made properly, the LS needs assurance of the reliability of 996 information on the identities of the entities with which the LS 997 interacts (including LRs, LSes, and RMs) and other information in the 998 request. 1000 Protocols to convey LOs and protocols to convey Rules MUST provide 1001 information on the identity of the recipient of location and the 1002 identity of the RM, respectively. In order to ensure the validity of 1003 this information, these protocols MUST allow for mutual 1004 authentication of both parties, and MUST provide integrity protection 1005 for protocol messages. These security features ensure that the LG 1006 has sufficient information (and sufficiently reliable information) to 1007 make privacy decisions. 1009 As they travel through the Internet, LOs necessarily pass through a 1010 sequence of intermediaries, ranging from layer-2 switches to IP 1011 routers to application-layer proxies and gateways. The ability of an 1012 LS to protect privacy by making access control decisions is reduced 1013 if these intermediaries have access to an LO as it travels between 1014 privacy-preserving entities. 1016 Ideally, LOs SHOULD be transmitted with confidentiality protection 1017 end-to-end between an LS that transmits location and the LR that 1018 receives it. In some cases, the protocol conveying an LO provides 1019 confidentiality protection as a built-in security solution for its 1020 signaling (and potentially its data traffic). In this case, carrying 1021 an unprotected LOs within such an encrypted channel is sufficient. 1022 Many protocols, however, are offering communication modes where 1023 messages are either unprotected or protected on a hop-by-hop basis 1024 (for example, between intermediaries in a store-and-forward 1025 protocol). In such a case it is RECOMMENDED that the protocol allows 1026 for the use of encrypted LOs, or for the transmission of a reference 1027 to location in place of an LO [14]. 1029 4.3. Location Use 1031 The primary privacy requirement of an LR is to constrain its usage of 1032 location to the set of uses authorized by the Rules in an LO. If an 1033 LR only uses an LO in ways that have minimal privacy impact -- 1034 specifically, if it does not transmit the LO to any other entity, and 1035 does not retain the LO for longer than is required to complete its 1036 interaction with the LS -- then no further action is necessary for 1037 the LR to comply with Geopriv requirements. 1039 As an example of this simplest case, if an LR (a) receives a 1040 location, (b) immediately provides to the Target information or a 1041 service based on the location, (c) does not retain the information, 1042 and (d) does not retransmit the location to any other entity, then 1043 the LR will comply with any set of Rules that are permissible under 1044 Geopriv. Thus, a service that, for example, only provides directions 1045 to the closest bookstore in response to an input of location, and 1046 promptly then discards the input location, will be in compliance with 1047 any Geopriv Rule set. 1049 LRs that make other uses of an LO (e.g., those that store LOs, or 1050 send them to other service providers to obtain location-based 1051 services) MUST meet the requirements below to assure that these uses 1052 are authorized. 1054 4.3.1. Privacy Considerations for Use 1056 The principal privacy requirement for LRs is to follow usage rules. 1057 Any LR that wants to retransmit or retain the LO is REQUIRED to 1058 examine the rules included with that LO. Any usage the LR makes of 1059 the LO MUST be explicitly authorized by these Rules. Since Rules are 1060 positive grants of permission, any action not explicitly authorized 1061 is denied by default. 1063 4.3.2. Security Considerations for Use 1065 Since the LR role does not involve transmission of location, there 1066 are no protocol security considerations required to support privacy 1067 (other than ensuring that data does not leak unintentionally caused 1068 by security breaches). 1070 Aside from privacy, LRs often require some assurance that an LO is 1071 reliable (assurance of the integrity, authenticity, and validity of 1072 an LO), since LRs use LOs in order to deliver location-based 1073 services. Threats against this reliability and corresponding 1074 mitigations are discussed in the Security Considerations below. 1076 5. Security Considerations 1078 Security considerations related to the privacy of LOs are discussed 1079 throughout this document. In this section we summarize those 1080 concerns and consider security risks not related to privacy. 1082 The life-cycle of an LO often consists of a series of location 1083 transmissions. Protocols that carry location can provide strong 1084 assurances, but only for a single segment of the LO's life cycle. In 1085 particular, a protocol can provide integrity protection and 1086 confidentiality for the data exchanged, and mutual authentication of 1087 the parties involved in the protocol, by using a secure transport 1088 such as IPSec [16] or TLS [17]. 1090 Additionally, if (1) the protocol provides mutual authentication for 1091 every segment, and (2) every entity in the location distribution 1092 chain exchanges information only with entities with whom it has a 1093 trust relationship, entities can transitively obtain assurances 1094 regarding the origin and ultimate destination of the LO. Of course, 1095 direct assurances are always preferred over assurances requiring 1096 transitive trust, since they require fewer assumptions. 1098 Using protocol mechanisms alone, the entities can receive assurances 1099 only about a single hop in the distribution chain. For example, 1100 suppose that an LR receives location from an LS over an integrity- 1101 and confidentiality-protected channel. The LR knows that the 1102 transmitted LO has not been modified or observed en route. However, 1103 the assurances provided by the protocol do not guarantee that the 1104 transmitted LO was not corrupted before it was sent to the LS (by a 1105 previous LS, for example). Likewise, the LR can verify that the LO 1106 was transmitted by the LS, but cannot verify the origin of the LO if 1107 it did not originate with the LS. 1109 Security mechanisms in protocols are thus unable to provide direct 1110 assurances over multiple transmissions of an LO. However, the 1111 transmission of location "by reference" can be used to effectively 1112 turn multi-hop paths into single-hop paths. If the multiple 1113 transmissions of an LO are replaced by multiple transmissions of a 1114 URI (a multi-hop dissemination channel), the LO need only traverse a 1115 single hop, namely the dereference transaction between the LR and the 1116 dereference server. The requirements for securing location passed by 1117 reference [14] are applicable in this case. 1119 The major threats to the security of LOs can be grouped into two 1120 categories. First, threats against the integrity and authenticity of 1121 LOs can expose entities that rely on LOs. Second, threats against 1122 the confidentiality of LOs can allow unauthorized access to location 1123 information. 1125 An LO contains four essential types of information: identifiers for 1126 the described Target, location information, time- stamps, and Rules. 1127 By grouping values of these various types together within a single 1128 structure, an LO encodes a set of bindings among them. That is, the 1129 LO asserts that the identified Target was present at the given 1130 location at the given time and that the given Rules express the 1131 Target's desired policy at that time for the distribution of his 1132 location. Below, we provide a description of the assurances required 1133 by each party involved in the location distribution in order to 1134 mitigate the possible attacks on these bindings. 1136 Rule Maker: The Rule Maker is responsible for creating the Target's 1137 Privacy Rules and for uploading them to the LSes. The primary 1138 assurance required by the Rule Maker is that the Target's Privacy 1139 Rules are correctly associated with the Target's identity when 1140 they are conveyed to each LS that handles the LO. Ensuring the 1141 integrity of the Privacy Rules distributed to the LSes prevents 1142 rule-tampering attacks. In many circumstances, the privacy policy 1143 of the Target may itself be sensitive information; in these cases, 1144 the Rule Maker also requires the assurance that the binding 1145 between the Target's identity and the Target's Privacy Rules are 1146 not deducible by anyone other than an authorized LS. 1148 Location Server: The Location Server is responsible for enforcing 1149 the Target's Privacy Rules. The first assurance required by the 1150 LS is that the binding between the Target's Privacy Rules and the 1151 Target's identity is authentic. Authenticating and authorizing 1152 the Rule Maker who creates, updates and deletes the Privacy Rules 1153 prevents rule-tampering attacks. The LS has to ensure that the 1154 authorization policies are not exposed to third parties, if so 1155 desired by the Rule Maker (when the rules themselves are privacy- 1156 sensitive). 1158 Location Recipient: The Location Recipient is the consumer of the 1159 LO. The LR thus requires assurances about the authenticity of the 1160 bindings between the Target's location, the Target's identity and 1161 the time. Ensuring the authenticity of these bindings helps to 1162 prevent various attacks, such falsifying the location, modifying 1163 the time-stamp, faking the identity, replaying LOss. 1165 Location Generator: The primary assurance required by the Location 1166 Generator is that the LS to which the LO is initially published is 1167 one that is trusted to enforce the Target's Privacy Rules. 1168 Authenticating the trusted LS mitigates the risk of server 1169 impersonation attacks. Additionally, the LG is responsible for 1170 the location determination process, which is also sensible from a 1171 security perspective because wrong input provided by external 1172 entites can lead to undesireable disclosure or access to location 1173 information. 1175 Assurances as to the integrity and confidentiality of a Location 1176 Object can be provided directly through the LO format. RFC 4119 [18] 1177 provides a description for usage of S/MIME to integrity and 1178 confidentiality protection. Although such direct, end-to-end 1179 assurances are desirable, and these mechanisms should be used 1180 whenever possible, there are many deployment scenarios where directly 1181 securing an LO is impractical. For example, in some deployment 1182 scenarios a direct trust relationship may not exist between the 1183 creator of the Location Object and the recipient. Additionally, in a 1184 scenario where many recipients are authorized to receive a given LO, 1185 the creator of the LO cannot guarantee end-to-end confidentiality 1186 without knowing precisely which recipient will receive the LO. Many 1187 of these cases can, however, be addressed by the usage of a Location- 1188 by-Reference (possibly combined with an LO). 1190 6. Example Scenarios 1192 This section contains a set of example of how the Geopriv 1193 architecture can be deployed in practice. These examples are meant 1194 to illustrate key points of the architecture, rather than to form an 1195 exhaustive set of use cases. 1197 For convenience and clarity in these examples, we assume that the 1198 Privacy Rules that an LO carries are equivalent to those in a PIDF-LO 1199 (namely, that the principal Rules that can be set are limits on the 1200 retransmission and retention of the LO). While these two Rules are 1201 the most well-known and important examples, the specific types of 1202 Rules an LS or LR must consider will in general depend on the types 1203 of LO it processes. 1205 6.1. Minimal Scenario 1207 One of the simplest scenarios in the Geopriv architecture is when a 1208 Device determines its own location and uses that LO to request a 1209 service (e.g., by including the LO in an HTTP POST request [19] or 1210 SIP INVITE message [20]), and the server delivers that service 1211 immediately (e.g., in a 200 OK response in HTTP or SIP), without 1212 retaining or retransmitting the Device's location. The Device acts 1213 as an LG by using a Device-based positioning algorithm (e.g., manual 1214 entry) and as an LS by interpreting the rule and transmitting the LO. 1215 The Target acts as a Rule Maker by specifying that the location 1216 should be sent to the server. The server acts as an LR by receiving 1217 and using the LO. 1219 In this case, the privacy of location information is maintained in 1220 two steps: The first step is that location is only transmitted as 1221 directed by the single Rule Maker, namely the Target. The second 1222 step is simply the fact that the server, as LR, does not do anything 1223 that creates a privacy risk -- it does not retain or retransmit 1224 location. Because the server limits its behavior in this way, it 1225 does not need to read the Rules in the LO (even though they were 1226 provided) -- no Rule would prevent it from using location in this 1227 safe manner. 1229 The following outline summarizes this scenario: 1231 o Positioning: Device-based, Device=LG 1233 o Distribution hop 1: HTTP UA --> Ephemeral web service, privacy via 1234 user indication 1236 o Use: Ephemeral web service delivers response without retaining or 1237 retransmitting location 1239 o Key points: 1241 * LRs that do not behave in ways that risk privacy are Geopriv- 1242 compliant by default. No further action is necessary. 1244 6.2. Location-based Web Services 1246 Many location-based services are delivered over the Web, using 1247 Javascript code to orchestrate a series of HTTP requests for location 1248 specific information. To support these applications, browser 1249 extensions have been developed that support Device-based positioning 1250 (manual entry and Global Positioning System (GPS)) and network- 1251 assisted positioning (via Assisted GPS (AGPS), and multilateration 1252 with 802.11 and cellular signals), exposing location to web pages 1253 through Javascript APIs. 1255 In this scenario, we consider a Target that uses a browser with a 1256 network-assisted positioning extension. When the Target uses this 1257 browser to request location-based services from a web page, the 1258 browser prompts the user to grant the page permission to access the 1259 user's location. If the user grants permission, the browser 1260 extension sends 802.11 signal strength measurements to a positioning 1261 server, which then returns the position of the host. The extension 1262 constructs an LO with this location and Rules set by the user, then 1263 passes the LO to the page through its Javascript API. The page then 1264 obtains location-relevant information using an XMLHttpRequest [21] to 1265 a server in the same domain as the page and renders this information 1266 to the user. 1268 At first blush, this scenario seems much more complicated than the 1269 minimal scenario above. However, most of the privacy considerations 1270 are actually the same. 1272 The positioning phase in this scenario begins when the browser 1273 extension contacts the positioning server. The positioning server 1274 acts as an LG. 1276 The distribution phase actually occurs entirely within the Target 1277 host. This phase begins when the positioning server, now acting as 1278 LS, follows the LCP policy by providing location only to the Target. 1279 The next hop in distribution occurs when the browser extension (an 1280 entity under the control of the Target) passes an LO to the web page 1281 (an entity under the control of its author). In this phase, the 1282 browser extension acts as an LS, with the Target as the sole Rule 1283 Maker; the user interface for rule-making is effectively a protocol 1284 for conveying Rules, and the extension's API effectively defines a 1285 way to communicate LOs and an LO Format. The web site acts as an LR 1286 when the web page accepts the LO. 1288 The use phase encompasses the web site's use of the LO. In this 1289 context, the phrase "web site" encompasses not only the web page, but 1290 also the dedicated supporting logic behind it. Considering the 1291 entire web site as a recipient, rather than a single page, it becomes 1292 clear that sending the LO in an XMLHttpRequest to a back-end server 1293 is like passing it to a separate component of the LR (as opposed to 1294 retransmitting it to another entity). Thus, even in this case, where 1295 location-relevant information is obtained from a back-end server, the 1296 LR does not retain or retransmit location, so its behavior is 1297 "privacy-safe" -- it doesn't need to interpret the Rules in the LO. 1299 However, consider a variation on this scenario where the web page 1300 requests additional information (a map, for instance) from a third- 1301 party site. In this case, since location is being transmitted to a 1302 third party, the web site (either in the web page or in a back-end 1303 server) would need to verify that this transmission is allowed by the 1304 LO's Privacy Rules. Similarly, if the site wanted to log the user's 1305 location information, then it would need to examine the LO to 1306 determine how long this information can be retained. In such a case, 1307 if the LR needs to do something that is not allowed by the Rules, it 1308 may have to deny service to the user (hopefully providing a message 1309 with the reason). Nonetheless, if the Rules permit retention or 1310 retransmission (even if this retransmission is limited by access 1311 control rules), then the LR may do so to the extent the Rules allow. 1313 The following outline summarizes this scenario: 1315 o Positioning: Network-assisted, positioning server=LG 1317 o Rule installation: RM (=Target) gives permission to sites and sets 1318 LO Rules 1320 o Distribution hop 1: positioning server=LS --> Target, privacy via 1321 LCP policy 1323 o Distribution hop 2: Browser=LS --> Web site=LR, privacy via user 1324 confirmation 1326 o Use: Back-end server delivers location-relevant information 1327 without further retransmission, then deletes location; privacy via 1328 safe behavior 1330 o Key points: 1332 * Privacy in this scenario is provided by a combination of 1333 explicit user direction and Rules in an LO 1335 * Distribution can occur within a host, between mutually 1336 untrusting components 1338 * Some transmissions of location are actually internal to an LR 1340 * LRs that do things that might be constrained by Rules need to 1341 verify that these actions are allowed for a particular LO 1343 6.3. Emergency Calling 1345 Support for emergency calls by Voice-over-IP devices is a critical 1346 use case for location information about Internet hosts. The details 1347 of the Internet architecture for emergency calling are described in 1348 [22][23]. In this architecture, there are three critical steps in 1349 the placement of an emergency call, each involving location 1350 information: 1352 1. Determine the location of the caller 1353 2. Determine the proper Public Safety Answering Point (PSAP) for the 1354 caller's location 1356 3. Send a SIP INVITE message (including the caller's location) to 1357 the PSAP 1359 The first step in an emergency call is to determine the location of 1360 the caller. This step is the positioning phase of the location life- 1361 cycle. Location is determined by whatever means are available to the 1362 caller's device, or to the network, if this step is being done by a 1363 proxy. Whichever entity does the positioning (either the caller or a 1364 proxy) acts as an LS, preserving the privacy of location information 1365 by only including it in emergency calls. 1367 The second step in an emergency call encompasses location 1368 distribution and use. The entity that is routing the emergency call 1369 sends location though the LoST protocol [15] to a mapping server. In 1370 this role, the routing entity acts as an LS and the LoST server acts 1371 as an LR. The LO format within LoST does not allow Rules to be sent 1372 along with location, but because LoST is an application-specific 1373 protocol, the sending of location within a LoST message authorizes 1374 the LoST server to use the location to complete the protocol, namely 1375 to route the message as necessary through the LoST mapping 1376 architecture [24]. That is, the LoST server is authorized to 1377 complete the LoST protocol, but to do nothing else. 1379 The third step in an emergency call is again a combination of 1380 distribution and use. The caller (or another entity that inserts the 1381 caller's location) acts as an LS and the PSAP acts as an LR. In this 1382 specific example, the caller's location is transmitted either as a 1383 PIDF-LO object or as a reference that returns a PIDF-LO (or both); in 1384 the latter case, the reference should be appropriately protected so 1385 that only the PSAP has access. In any case, the receipt of an LO 1386 implies that the PSAP should obey the Rules in those LOs in order to 1387 preserve privacy. Depending on the regulatory environment, the PSAP 1388 may have the option to ignore those constraints in order to respond 1389 to an emergency, or it may be bound to respect these Rules (in spite 1390 of the emergency situation). 1392 The following outline summarizes this scenario: 1394 o Positioning: Any 1396 o Distribution/use hop 1: Target=LS --> LoST infrastructure (no 1397 Rules), privacy via authorization implicit in protocol 1399 o Distribution/use hop 2: Target=LS --> PSAP, privacy via Rules in 1400 LO 1402 o Use: PSAP uses location to deliver emergency services 1404 o Key points: 1406 * Privacy in this scenario is provided by a combination of 1407 explicit user direction, implicit authorization particular to a 1408 protocol, and Rules in an LO 1410 * LRs may be constrained to respect or ignore Privacy Rules by 1411 local regulation 1413 6.4. Combination of Services 1415 In modern Internet applications, users frequently receive information 1416 via one channel and broadcast it via another. In this sense, both 1417 users and channels (e.g., web services) become LSess. Here we 1418 consider a more complex example that illustrates this pattern across 1419 multiple logical hops. 1421 Suppose Alice (the Target) subscribes to a wireless ISP that 1422 determines her location using a network-based positioning technique 1423 (e.g., via the location of the base station serving the Target), and 1424 provides that information directly to a location-enhanced presence 1425 provider (which might use SIP, XMPP [25], or another protocol). The 1426 location-enhanced presence provider allows Alice to specify Rules for 1427 how this location is distributed: which friends should receive 1428 Alice's location and what Rules they should get with it. Alice uses 1429 a few other location-enhanced services as well, so she sends Rules 1430 that allow her location to be shared with those services, and allow 1431 those services to retain and retransmit her location. 1433 Bob is one of Alice's friends, and he receives her location via this 1434 location-enhanced presence service. Noting that she's at their 1435 favorite coffee shop, Bob wants to upload a photo of the two of them 1436 at the coffee shop to a photo-sharing site, along with an LO that 1437 marks the location. Bob checks the Rules in Alice's LO and verifies 1438 that the photo sharing site is one of the services that Alice 1439 authorized. Seeing that Alice has authorized him to give the LO to 1440 the photo-sharing site, he attaches it to the photo and uploads it. 1442 Once the geo-tagged photo is uploaded, the photo sharing site reads 1443 the Rules in the LO and verifies that the site is authorized to store 1444 the photo and to share it with others. Since Alice has allowed the 1445 site to retransmit and retain without any constraints, the site 1446 fulfills Bob's request to make the geo-tagged photo publicly 1447 accessible. 1449 Eve, another user of the photo sharing site, downloads the photo of 1450 Alice and Bob at the coffee shop and receives Alice's LO along with 1451 it. Eve posts the photo and location to her public page on a social 1452 networking site without checking the Rules, even though the LO 1453 doesn't allow Eve to send the location anywhere else. The social 1454 networking site, however, observes that no retransmission or 1455 retention are allowed (both of which it needs for a public posting), 1456 and rejects the upload. 1458 In terms of the location life-cycle, this scenario consists of a 1459 positioning step, followed by four distribution hops and use. 1460 Positioning is the simplest step: An LG in Alice's ISP monitors her 1461 location and transmits it to the presence service, maintaining 1462 privacy by only transmitting location to a single entity (to which 1463 Alice has delegated privacy responsibilities). 1465 The first distribution hop occurs when the presence server sends 1466 location to Bob. In this transaction, the presence server acts as an 1467 LS, Alice acts as an RM, and Bob acts as an LR. The privacy of this 1468 transaction is assured by the fact that Alice has installed Rules on 1469 the presence server that dictate who it may allow to access her 1470 location. The second distribution hop is when Bob uploads the LO to 1471 the photo-sharing site. Here Bob acts as an LS, preserving the 1472 privacy of location information by verifying that the Rules in the LO 1473 allow him to upload it. The third distribution hop is when the 1474 photo-sharing site sends the LO to Eve, likewise following the Rules 1475 -- but a different set of Rules than Bob, since an LO can specify 1476 different Rule sets for different LSes. 1478 Eve is the fourth LS in the chain, and fails to comply with Geopriv 1479 by not checking the Rules in the LO prior to uploading the LO to the 1480 social networking site. The site, however, is a responsible LR -- it 1481 checks the Rules in the LO, sees that they don't allow it to use the 1482 location as it needs to, and discards the LO. 1484 The following outline summarizes this scenario: 1486 o Positioning: Network-based, LG in network, privacy via exclusive 1487 relationship with presence service 1489 o Distribution/use hop 1: Presence server --> Bob, privacy via 1490 Alice's access control rules 1492 o Distribution/use hop 2: Bob --> photo sharing site, privacy via 1493 Rules for Bob in LO 1495 o Distribution/use hop 3: Photo sharing site --> Eve, privacy via 1496 Rules for site in LO 1498 o Distribution/use hop 4: Eve --> Social networking site, violates 1499 privacy by retransmitting 1501 o Use: Social networking site, privacy via checking Rules and 1502 discarding 1504 o Key points: 1506 * Privacy can be preserved through multiple hops 1508 * A LO can specify different Rules for different entities 1510 * An LS can still disobey the Rules, but even then, the 1511 architecture still works in some cases 1513 7. Glossary 1515 Various security-related terms not defined here are to be understood 1516 in the sense defined in RFC 4949 [26]. 1518 $ Access Control Rule 1520 A rule that describe which entities may receive location 1521 information and in what form. 1523 $ civic location 1525 The geographic position of an entity in terms of a postal address 1526 or civic landmark. Examples of such data are room number, street 1527 number, street name, city, ZIP code, county, state and country. 1529 $ Device 1531 The physical device whose location is tracked as a proxy for the 1532 location of a Target. 1534 $ geodetic location 1536 The geographic position of an entity in a particular coordinate 1537 system (for example, a latitude-longitude pair). 1539 $ Local Rule 1541 A Privacy Rules that directs a Location Server about how to treat 1542 a Target's location information. Local Rules are used internally 1543 by a Location Server to handle requests from Location Recipients. 1544 They are not distributed to Location Recipients. 1546 $ Location Generator (LG) 1548 Performs the role of initially determining or gathering the 1549 location of a Target. Location Generators may be any sort of 1550 software or hardware used to obtain a Target's location (examples 1551 include GPS chips and cellular networks). 1553 $ Location Information Server (LIS) 1555 An entity responsible for providing devices within an access 1556 network with information about their own locations. A Location 1557 Information Server uses knowledge of the access network and its 1558 physical topology to generate and distribute location information 1559 to devices. 1561 $ Location Object (LO) 1563 A data unit that conveys location information together with 1564 Privacy Rules within the Geopriv architecture. A Location Object 1565 may convey geodetic location data (latitiude/longitude/altitude), 1566 civic location data (street/city/state/etc.), or both. 1568 $ Location Recipient (LR) 1570 An ultimate end point entity to which a Location Object is 1571 distributed. Location Recipients request location information 1572 about a particular Target from a Location Server. If allowed by 1573 the appropriate Privacy Rules, a Location Recipient will receive 1574 Location Objects describing the Target's location from the 1575 Location Server. 1577 $ Location Server (LS) 1579 An entity that receives Location Objects from Location Generators, 1580 Privacy Rules from Rule Makers, and location requests from 1581 Location Recipients. A Location Server applies the appropriate 1582 Privacy Rules to a Location Object received from a Location 1583 Generator and may disclose the Location Object, in compliance with 1584 the Rules, to Location Recipients. 1586 Location Servers may not necessarily be "servers" in the 1587 colloquial sense of hosts in remote data centers servicing 1588 requests. Rather, a Location Server can be any software or 1589 hardware component that receives and distributes location 1590 information. Examples include a positioning server (with a 1591 location interface) in an access network, a presence server, or a 1592 Web browser or other software running on a Target's device. 1594 $ Privacy Rule 1596 A directive that regulates an entity's activities with respect to 1597 a Target's location information, including the collection, use, 1598 disclosure, and retention of the location information. Privacy 1599 Rules describe how location information may be used by an entity, 1600 the level of detail with which location information may be 1601 described to an entity, and the conditions under which location 1602 information may be disclosed to an entity. Privacy Rules are 1603 communicated from Rule Makers to Location Servers and conveyed in 1604 Location Objects throughout the Geopriv architecture. 1606 $ Rule 1608 See Privacy Rule. 1610 $ Rule Maker (RM) 1612 An individual or entity that is authorized to set Privacy Rules 1613 for a Target. In some cases a Rule Maker and a Target will be the 1614 same individual or entity, and in other cases they will be 1615 separate. For example, a parent may serve as the Rule Maker when 1616 the Target is his child. The Rule Maker is also not necessarily 1617 the owner of a Target device. For example, a corporation may own 1618 a device that it provides to an employee but permit the employee 1619 to serve as the Rule Maker and set her own Privacy Rules. Rule 1620 Makers provide the Privacy Rules associated with a Target to 1621 Location Servers. 1623 $ Forwarded Rule 1625 A Privacy Rule that travels inside a Location Object. Forwarded 1626 Rules direct Location Recipients about how to handle the location 1627 information they receive. Because the Forwarded Rules themselves 1628 may reveal potentially sensitive information about a Target, only 1629 the minimal subset of Forwarded Rules necessary for a Location 1630 Recipient to handle a Location Object is distributed to the 1631 Location Recipient. 1633 $ Target 1635 An individual or other entity whose location is sought in the 1636 Geopriv architecture. In many cases the Target will be the human 1637 user of a Device, or it may be an object such as a vehicle or 1638 shipping container to which a Device is attached. In some 1639 instances the Target will be the Device itself. The Target is the 1640 entity whose privacy Geopriv seeks to protect. 1642 $ Usage Rule 1644 A rule that describe what uses of location information are 1645 authorized. 1647 8. Acknowledgements 1649 Section 5 is largely based on the security investigations conducted 1650 as part of the Geopriv Layer-7 Location Configuration Protocol design 1651 team, which produced [9]. We would like to thank all the members of 1652 the design team. 1654 We would also like to thank Marc Linsner and Martin Thomson for their 1655 contributions regarding terminology and LCPs. 1657 9. IANA Considerations 1659 This document makes no request of IANA. 1661 10. References 1663 10.1. Normative References 1665 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1666 Levels", BCP 14, RFC 2119, March 1997. 1668 10.2. Informative References 1670 [2] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. 1671 Polk, "Geopriv Requirements", RFC 3693, February 2004. 1673 [3] Danley, M., Mulligan, D., Morris, J., and J. Peterson, "Threat 1674 Analysis of the Geopriv Protocol", RFC 3694, February 2004. 1676 [4] U.S. Department of Defense, "National Industrial Security 1677 Program Operating Manual", DoD 5220-22M, January 1995. 1679 [5] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 1680 Presence Information Data Format Location Object (PIDF-LO) 1681 Usage Clarification, Considerations, and Recommendations", 1682 RFC 5491, March 2009. 1684 [6] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk, 1685 J., and J. Rosenberg, "Common Policy: A Document Format for 1686 Expressing Privacy Preferences", RFC 4745, February 2007. 1688 [7] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., and 1689 J. Polk, "Geolocation Policy: A Document Format for Expressing 1690 Privacy Preferences for Location Information", 1691 draft-ietf-geopriv-policy-21 (work in progress), January 2010. 1693 [8] Rosenberg, J., "The Extensible Markup Language (XML) 1694 Configuration Access Protocol (XCAP)", RFC 4825, May 2007. 1696 [9] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location 1697 Configuration Protocol: Problem Statement and Requirements", 1698 RFC 5687, March 2010. 1700 [10] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host 1701 Configuration Protocol Option for Coordinate-based Location 1702 Configuration Information", RFC 3825, July 2004. 1704 [11] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 1705 and DHCPv6) Option for Civic Addresses Configuration 1706 Information", RFC 4776, November 2006. 1708 [12] Polk, J., "Dynamic Host Configuration Protocol (DHCP) IPv4 and 1709 IPv6 Option for a Location Uniform Resource Identifier (URI)", 1710 draft-ietf-geopriv-dhcp-lbyr-uri-option-08 (work in progress), 1711 July 2010. 1713 [13] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC 5985, 1714 September 2010. 1716 [14] Marshall, R., "Requirements for a Location-by-Reference 1717 Mechanism", RFC 5808, May 2010. 1719 [15] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, 1720 "LoST: A Location-to-Service Translation Protocol", RFC 5222, 1721 August 2008. 1723 [16] Kent, S. and K. Seo, "Security Architecture for the Internet 1724 Protocol", RFC 4301, December 2005. 1726 [17] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 1727 Protocol Version 1.2", RFC 5246, August 2008. 1729 [18] Peterson, J., "A Presence-based GEOPRIV Location Object 1730 Format", RFC 4119, December 2005. 1732 [19] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 1733 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- 1734 HTTP/1.1", RFC 2616, June 1999. 1736 [20] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1737 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1738 Session Initiation Protocol", RFC 3261, June 2002. 1740 [21] World Wide Web Consortium, "The XMLHttpRequest Object", W3C 1741 document http://www.w3.org/TR/XMLHttpRequest/, April 2008. 1743 [22] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, "Framework 1744 for Emergency Calling using Internet Multimedia", 1745 draft-ietf-ecrit-framework-11 (work in progress), July 2010. 1747 [23] Rosen, B. and J. Polk, "Best Current Practice for 1748 Communications Services in support of Emergency Calling", 1749 draft-ietf-ecrit-phonebcp-15 (work in progress), July 2010. 1751 [24] Schulzrinne, H., "Location-to-URL Mapping Architecture and 1752 Framework", draft-ietf-ecrit-mapping-arch-04 (work in 1753 progress), March 2009. 1755 [25] Saint-Andre, P., Ed., "Extensible Messaging and Presence 1756 Protocol (XMPP): Core", RFC 3920, October 2004. 1758 [26] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, 1759 August 2007. 1761 [27] Polk, J. and B. Rosen, "Location Conveyance for the Session 1762 Initiation Protocol", draft-ietf-sip-location-conveyance-13 1763 (work in progress), March 2009. 1765 URIs 1767 [28] 1769 Authors' Addresses 1771 Richard Barnes 1772 BBN Technologies 1773 9861 Broken Land Pkwy, Suite 400 1774 Columbia, MD 21046 1775 USA 1777 Phone: +1 410 290 6169 1778 Email: rbarnes@bbn.com 1779 Matt Lepinski 1780 BBN Technologies 1781 10 Moulton St 1782 Cambridge, MA 02138 1783 USA 1785 Phone: +1 617 873 5939 1786 Email: mlepinski@bbn.com 1788 Alissa Cooper 1789 Center for Democracy & Technology 1790 1634 I Street NW, Suite 1100 1791 Washington, DC 1792 USA 1794 Email: acooper@cdt.org 1796 John Morris 1797 Center for Democracy & Technology 1798 1634 I Street NW, Suite 1100 1799 Washington, DC 1800 USA 1802 Email: jmorris@cdt.org 1804 Hannes Tschofenig 1805 Nokia Siemens Networks 1806 Linnoitustie 6 1807 Espoo 02600 1808 Finland 1810 Phone: +358 (50) 4871445 1811 Email: Hannes.Tschofenig@gmx.net 1812 URI: http://www.tschofenig.priv.at 1813 Henning Schulzrinne 1814 Columbia University 1815 Department of Computer Science 1816 450 Computer Science Building 1817 New York, NY 10027 1818 US 1820 Phone: +1 212 939 7004 1821 Email: hgs@cs.columbia.edu 1822 URI: http://www.cs.columbia.edu