idnits 2.17.1 draft-ietf-geopriv-reqs-02.txt: -(579): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 4 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (Jan 2003) is 7773 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'Bra00' -- Possible downref: Non-RFC (?) normative reference: ref. 'Cha85' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO99' -- Possible downref: Non-RFC (?) normative reference: ref. 'OECD' -- Possible downref: Non-RFC (?) normative reference: ref. 'Pfi01' Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft J. Cuellar 3 Document: draft-ietf-geopriv-reqs-02.txt Siemens AG 5 John B. Morris, Jr. 6 Center for Democracy and Technology 8 D. Mulligan 9 Samuelson Law, Technology, and Public Policy Clinic 11 Expires in six months Jan 2003 13 Geopriv requirements 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as 28 reference material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Copyright Notice 37 Copyright (C) The Internet Society (2001). All Rights Reserved. 39 Abstract 41 Location-based services, navigation applications, emergency 42 services, management of equipment in the field, and other location- 43 dependent services need geographic location information about a 44 Target (such as a user, resource or other entity). There is a need 45 to securely gather and transfer location information for location 46 services, while at the same time protecting the privacy of the 47 individuals involved. 49 Cuellar, Morris, Mulligan 1 50 This document focuses on the authorization, integrity and privacy 51 requirements for such location-dependent services. Specifically, it 52 describes the requirements for the geopriv Location Object (used to 53 securely transfer location data and other privacy-enabling 54 information) and for the protocols that use this Location Object. 56 Table of Contents 58 1. Overview........................................................3 59 2. Conventions used in this document...............................4 60 3. Terminology.....................................................4 61 3.1. Foundational Definitions...................................4 62 3.1.1. Location Information (LI) and Sighting................4 63 3.1.2. The Location Object...................................6 64 3.1.3. Location Object vs. Using Protocol....................6 65 3.1.4. Trusted vs. Non-trusted Data Flows....................6 66 3.2. Geopriv Entities and Functions.............................7 67 3.2.1. Primary Geopriv Entities..............................7 68 3.2.2. Secondary Geopriv Entities............................8 69 3.2.3. Geopriv Data Storage Functions........................9 70 3.3. Privacy Policies and Rules.................................9 71 3.4. Identifiers, Authentication and Authorization.............10 72 4. Scenarios and Explanatory Discussion...........................11 73 4.1. Scenarios of Data Flow....................................11 74 5. Requirements...................................................14 75 5.1. Location Object...........................................15 76 5.2. The Using Protocol........................................16 77 5.3. Policy based Location Data Transfer.......................17 78 5.4. Location Object Privacy and Security......................18 79 5.5. Identity Protection.......................................18 80 5.6. Authentication Requirements...............................18 81 5.7. Actions to be secured.....................................18 82 5.8. Non-Requirements..........................................19 83 6. Security Considerations........................................19 84 6.1. Traffic Analysis..........................................19 85 6.2. Securing the Privacy Policies.............................19 86 6.3. Emergency Case............................................20 87 6.4. Identities and Anonymity..................................20 88 6.5. Unintended Target.........................................21 89 7. Acknowledgements...............................................21 90 8. References.....................................................21 91 9. Protocol and LO Issues for later Consideration.................22 92 9.1. Multiple Locations in one LO..............................22 93 9.2. Translation Fields........................................22 94 9.3. Specifying Desired Accuracy in a Request..................22 95 9.4. Truth Flag................................................22 97 Cuellar, Morris, Mulligan 2 98 9.5. Timing Information Format.................................22 99 9.6. The Name Space of Identifiers.............................22 100 10. Author's Addresses............................................23 101 11. Full Copyright Statement......................................23 103 1. Overview 105 Location-based services (applications that require geographic 106 location information as input) are becoming increasingly common. 107 The collection and transfer of location information about a 108 particular Device and/or Target can have important privacy 109 implications. A key goal of the protocols described in this 110 document is to facilitate the protection of privacy pursuant to 111 privacy policies set by the "user" (or, more precisely in the 112 terminology of this document defined in Section 3 below, the "Rule 113 Maker"). 115 The ability to derive or compute a Device's location, and access to 116 the derived or computed location, are key elements of the location- 117 based services privacy equation. Central to a Target's privacy are 118 (a) the identity of entities that have access to raw location data, 119 derive or compute location, and/or have access to derived or 120 computed location information, and (b) whether those entities can be 121 trusted to know and follow the privacy policy of the user. 123 The main principles guiding the requirements described in this 124 document are: 126 1) Security of the transmission of Location Object is essential to 127 guarantee the integrity and confidentiality of the location 128 information. This includes authenticating the sender and 129 receiver of the Location Object, and securing the Location Object 130 itself. 132 2) A critical role is played by user-controlled policies, which 133 describe the restrictions imposed or permissions given by the 134 "user" (or, as defined below, the "Rule Maker"). The policies 135 specify the necessary conditions that allow a Location Server to 136 forward Location Information to a Location Recipient, and the 137 conditions under which and purposes for which the Location 138 Information can be used. 140 3) The Location Object should be able to carry a limited but core 141 set of privacy policies. The exact form or expressiveness of 142 policies in the core set or in the full set is not further 143 discussed in this paper, but is discussed more extensively in a 144 separate document. 146 4) Whenever appropriate, the location information should not be 147 linked to the real identity of the user or a static identifier 148 easily linked back to the real identity of the user (e.g., the 149 phone number). Rather, the user should be able to specify which 151 Cuellar, Morris, Mulligan 3 152 local identifier, unlinked pseudonym, or private identifier is to 153 be bound to the location information. 155 5) The user may want to hide the real identities of himself and his 156 partners not only to eavesdroppers but also to other entities 157 participating in the protocol. 159 Although complete anonymity may not be appropriate for some 160 applications because of legal constraints or because some location 161 services may in fact need explicit identifications, in most cases 162 the location services only need some type of authorization 163 information and/or perhaps anonymous identifiers of the entities in 164 question. 166 2. Conventions used in this document 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 170 this document are to be interpreted as described in [RFC2119]. 172 Note that the requirements discussed here are requirements on the 173 generic Location Object and on the using protocols for location 174 services. Thus the requirements discussed in this document mostly 175 refer to the capabilities that are mandatory-to-implement. For 176 example, requiring that implementations support integrity is not the 177 same thing as requiring that all protocol traffic be authenticated. 178 In other cases, the requirement may be that the user always obtains 179 a notice when his location data was not authenticated. This practice 180 is mandatory-to-use, not just to implement. 182 3. Terminology 184 The terminology and definitions detailed below include both (1) 185 terms used in the requirements section of this document, and (2) 186 terms that provide additional detail about the usage model 187 envisioned for the geopriv Location Object. These latter terms will 188 be utilized in a separate scenarios document. 190 3.1. Foundational Definitions 192 3.1.1. Location Information (LI) and Sighting 194 The focus of the geopriv working group is on information about a 195 Target's location that is NOT based on generally or publicly 196 available sources, but instead on private information provided or 197 created by a Target, a Target's Device, or a Target's network or 198 service provider: 200 Location Information (LI): 201 A relatively specific way of describing where a Device is 202 located and that is (a) derived or computed from information 203 generally not available to the general public (such as 205 Cuellar, Morris, Mulligan 4 206 information mainly available to a network or service 207 provider), (b) determined by a Device that may be not 208 generally publicly addressable or accessible, or (c) input or 209 otherwise provided by a Target. 211 As examples, LI could include (a) information calculated by 212 triangulating on a wireless signal with respect to cell phone 213 towers, (b) longitude and latitude information determined by a 214 Device with GPS (global positioning satellite) capabilities, or (c) 215 information manually entered into a cell phone or laptop by a Target 216 in response to a query. 218 Excluded from this definition is the determination of location 219 information wholly without the knowledge or consent of the Target 220 (or the Target's network or access service provider), based on 221 generally available information such as an IP or e-mail address. In 222 some cases information like IP address can enable someone to 223 estimate (at least roughly) a location. Commercial services exist 224 that offer to provide rough location information based on IP 225 address. Currently, this type of location information is typically 226 less accurate and has a coarser granularity than the type of 227 location information addressed in this document. Although this type 228 of location computation still raises significant potential privacy 229 and public policy concerns, such scenarios are generally outside the 230 scope of this document. 232 Within any given location-based transaction, the INITIAL 233 determination of location (and thus the initial creation of Location 234 Information) is termed a Sighting: 236 Sighting: 237 The initial determination of location based on non-public 238 information (as discussed in the definition of Location 239 Information), and the initial creation of Location 240 Information. 242 Some variant of the sighting information is included in the Location 243 Object. Abstractly, it consists of two separate data fields: 245 (Identifier, Location) 247 where Identifier is the identifier assigned to a Target being 248 sighted, and Location is the current position of that Target being 249 sighted. Not all entities may have access to exactly the same piece 250 of sighting information. A sighting may be transformed to a new 251 sighting pair: 253 (Identifier-1, Location-1) 255 before it is provided by a Location Sighter or Location Server to 256 another Location Recipient (for instance, another Location Server). 258 Cuellar, Morris, Mulligan 5 259 In this case, Identifier-1 may be Pseudonym, and Location-1 may have 260 less accuracy or granularity than the original value. 262 3.1.2. The Location Object 264 A main goal of the geopriv working group is to define a Location 265 Object (LO), to be used to convey both Location Information and 266 basic privacy-protecting instructions: 268 Location Object (LO): This data contains the Location Information 269 of the Target, and other fields including an identity or 270 pseudonym of the Target, time information, core privacy 271 policies, authenticators, etc. Most of the fields are 272 optional, including the Location Information itself. 274 Nothing is said about the semantics of a missing field. For 275 instance, a partially filled object MAY be understood implicitly as 276 the request to complete it. Or, if no time information is included, 277 this MAY implicitly mean "at the current time" or "at a very recent 278 time", but it could be interpreted in a different way, depending on 279 the context. 281 3.1.3. Location Object vs. Using Protocol 283 The "using protocol" is the protocol that uses (creates, reads or 284 modifies) the Location Object. A protocol that just transports the 285 LO as a string of bits, without looking at them (like an IP storage 286 protocol could do), is not a using protocol, but only a transport 287 protocol. Nevertheless, the entity or protocol that caused the 288 transport protocol to move the LO is responsible of the correct 289 distribution, protection, usage, retention, and storage of the LO. 291 The security and privacy enhancing mechanisms used to protect the LO 292 are of two types: First, the Location Object definition MUST 293 include (optional) fields or mechanisms used to secure the LO as 294 such. The LO MAY be secured, for example, using cryptographic 295 checksums or encryption as part of the LO itself. Second, the using 296 protocol may also provide security mechanisms to securely transport 297 the Location Object. 299 The security mechanisms of the Location Object itself are to be 300 preferred. 302 3.1.4. Trusted vs. Non-trusted Data Flows 304 Location information can be used in very different environments. In 305 some cases the participants will have longstanding relationships, 306 while in others participants may have discrete interactions with no 307 prior contractual or other contact. 309 The different relationships raise different concerns for the 310 implementation of privacy rules, including the need to communicate 312 Cuellar, Morris, Mulligan 6 313 privacy policies. A public Rule Repository, for example, may be 314 unnecessary in a trusted environment where more efficient methods of 315 addressing privacy issues exist. The following terms distinguish 316 between the two basic types of data flows: 318 Trusted Data Flow: 319 A data flow that is governed by a pre-existing contractual 320 relationship that addresses location privacy. 322 Non-trusted Data Flow: 323 The data flow is not governed by a pre-existing contractual 324 relationship that addresses location privacy. 326 3.2. Geopriv Entities and Functions 328 The entities of a geopriv application or transaction may be given 329 explicit roles: 331 3.2.1. Primary Geopriv Entities 333 Certain entities and roles are involved in most (and in some cases 334 all) geopriv transactions: 336 Target: 337 The entity whose location is desired by the Location Seeker. 338 In many cases the Target will be the human "user" of a Device 339 or an object such as a vehicle or shipping container to which 340 the Device is attached. In some instances the Target will be 341 the Device itself. 343 Device: 344 The technical device the location of which is tracked as a 345 proxy for the location of a Target. A Device might, for 346 example, be a cell phone, a Global Positioning Satellite (GPS) 347 receiver, a laptop equipped with a wireless access Device, or 348 a transmitter that emits a signal that can be tracked or 349 located. In some situations, such as when a Target manually 350 inputs location information (perhaps with a web browser), the 351 Target is effectively performing the function of a Device. 353 Rule Maker: 354 The individual or entity that has the authorization to set the 355 applicable privacy policies and rules. In many cases this 356 will be the owner of the Device, and in other cases this may 357 be the user who is in possession of the Device. For example, 358 parents may control what happens to the location information 359 derived from a child's cell phone. A company, in contrast, may 360 own and provide a cell phone to an employee but permit the 361 employee to set the privacy rules. 363 Cuellar, Morris, Mulligan 7 364 Location Seeker (LSeek): 365 An individual or entity who seeks to receive location data 366 about a Target. 368 A Location Seeker may act in one or more of the following more 369 specialized roles: as the Location Sighter, a Location Server, or as 370 an Ultimate Location Recipient: 372 Location Sighter (LoSi), or Location Data-Source 373 The original source of the sighting of a Target in a given 374 transaction. 376 Location Server (LServ), or Intermediate Location Recipient: 377 A Device or entity that provides access to Location 378 Information (possibly after processing or altering it) in 379 accordance with the privacy policies of the Rule Maker. Some 380 location tracking scenarios may involve a Target, Device, or 381 Device user performing the function of a Location Server. 383 Ultimate Location Recipient (ULR): 384 An individual or entity who receives location data about a 385 Target and does not transmit the location information or 386 information based on the Target's location (such as driving 387 directions to or from the Target) to any party OTHER than the 388 Target or the Rule Maker. 390 3.2.2. Secondary Geopriv Entities 392 Certain entities and functions are present or involved in only a 393 subset of geopriv transactions: 395 Data Transporter: 396 An entity or network that receives and forwards data without 397 processing or altering it. A Data Transporter could 398 theoretically be involved in almost any transmission between a 399 Device and a Location Server, a Location Server and a second 400 Location Server, or a Location Server and an Ultimate Location 401 Recipient. Some location tracking scenarios may not involve a 402 Data Transporter. 404 Initial Access Provider (IAP): 405 The entity that provides the initial network access or other 406 data communications services essential for the operation of 407 communications functions of the Device or computer equipment 408 in which the Device operates. Often, the IAP -- which will be 409 a wireless carrier, an Internet Service Provider, or an 410 internal corporate network -- will be identical to the LoSi. 411 In other cases the IAP has a "dumb" LoSi, one that transmits 412 geopriv data but does not implement or use any part of the 413 geopriv Location Object. Other cases may involve no IAP at 414 all or the IAP is only a Data Transporter. 416 Cuellar, Morris, Mulligan 8 417 3.2.3. Geopriv Data Storage Functions 419 Within the geopriv framework, certain data may be stored in various 420 functional entities: 422 Rule (or Policy) Storage 423 A storage used to store privacy-protecting policies, and 424 perhaps identifiers, credentials or keys. A Private Rule 425 Storage could be operated by a Device, a Location Server, or a 426 third party service provider. 428 How policies are authenticated and otherwise protected is outside of 429 the scope of this document, but see the remarks in Section 6 430 (Privacy Considerations). 432 Location Storage: 433 A Device or entity that stores raw or processed Location 434 Information for any period of time longer than the duration 435 necessary to complete an immediate transaction regarding the 436 LI. 438 The existence and data storage practices of Location Storage is 439 crucial to privacy considerations, because this may influence what 440 Location Information could eventually be revealed (through later 441 distribution, technical breach, or legal processes). 443 3.3. Privacy Policies and Rules 445 Privacy Policies are rules that regulate an entity's activities with 446 respect to location and other information, including, but not 447 limited to, the collection, use, disclosure, and retention of 448 location information. Such rules are generally based on fair 449 information practices, as detailed in (for example) the OECD 450 Guidelines on the Protection of Privacy and Transporter Flows of 451 Personal Data [OECD]. 453 Privacy Policy or Privacy Rule: 454 A rule or set of rules that regulate an entity's activities 455 with respect to location information, including the 456 collection, use, disclosure, and retention of location 457 information. In particular, the policy describes how location 458 information may be used by an entity and which transformed 459 location information may be released to which entities under 460 which conditions. Policies must be obeyed; they are not 461 advisory. 463 A full set of Privacy Rules will likely include both rules that have 464 only one possible technical meaning, and rules that will be affected 465 by a locality's prevailing laws and customs. For example, a 466 distribution rule of the form "my location can only be disclosed to 467 the owner of such credentials and in such accuracy" has clear-cut 468 implications for the protocol that uses the LO. But other rules, 470 Cuellar, Morris, Mulligan 9 471 like retention or usage policies, may have unclear technical 472 consequences for the protocol or for the involved entities. For 473 example, the precise scope of a retention rule stating "you may not 474 store my location for more than 2 days" may in part turn on local 475 laws or customs. 477 3.4. Identifiers, Authentication and Authorization 479 Anonymity is the property of being not identifiable (within a set of 480 subjects). Anonymity serves as the base case for privacy: without 481 the ability to remain anonymous, individuals cannot control their 482 own privacy. Unlinkability ensures that a user may make multiple 483 uses of resources or services without others being able to link 484 these uses together. Unlinkability requires that entities are 485 unable to determine whether the same user caused certain specific 486 operations in the system. [ISO99] A pseudonym is simply a bit 487 string which is unique as ID and is suitable to be used for end- 488 point authentication. 490 Unlinked Pseudonym: 491 A pseudonym where the linking between the pseudonym and its 492 holder is, at least initially, not known to anybody with the 493 possible exception of the holder himself or a trusted server 494 of the user. See [Pfi01] (there the term is called Initially 495 Unlinked Pseudonym) 497 The word authentication is used in different meanings. Some require 498 that authentication associates an entity with a more or less well- 499 known identity. This basically means that if A authenticates 500 another entity B as being "id-B", then the label "id-B" is a well- 501 known, or at least a linkable identity of the entity. In this case, 502 the label "id-B" is called a publicly known identifier, and the 503 authentication is "explicit": 505 Explicit Authentication: 506 The act of verifying a claimed identity as the sole originator 507 of a message (message authentication) or as the end-point of a 508 channel (entity authentication). Moreover, this identity is 509 easily linked back to the real identity of the entity in 510 question, for instance being a pre-existing static label from 511 a predefined name space (telephone number, name, etc.). 513 Authorization 514 The act of determining if a particular right, such as access 515 to some resource, can be granted to the presenter of a 516 particular credential. 518 Depending on the type of credential, authorization may imply 519 Explicit Authentication or not. 521 Cuellar, Morris, Mulligan 10 522 4. Scenarios and Explanatory Discussion 524 4.1. Scenarios of Data Flow 526 In this subsection we introduce short scenarios to illustrate how 527 these terms and attributes describe location information 528 transactions. 530 SCENARIO 1: GPS Device with Internal Computing Power: Closed System 532 In this example, the Target wishes to know his/her location using 533 Global Positioning System (GPS) and the Device is capable of 534 independently processing the raw data to determine its location. 535 The location is derived as follows: the Device receives 536 transmissions from the GPS satellites, internally computes and 537 displays location. This is a closed system. For the purpose of this 538 and subsequent examples, it is assumed that the GPS satellite 539 broadcasts some signal, and has no information about the identity or 540 whereabouts of Devices using the signal. 542 GPS Satellite 543 | 544 | 545 | 546 | 547 V GPS Device 548 -------------------------------------------------- 549 / \ 550 | Data ----- Location ----- Location | 551 | Transporter Server Storage | 552 \ | / 553 -------------------------------------------|------ 554 | 555 ------------|------ 556 / V \ 557 / Target Location \ 558 | Seeker | 559 | | 560 \ Rule Maker / 561 \ / 562 ------------------- 564 In this scenario the GPS Device is both the IAP and the LoSi. The 565 interaction occurs in a Trusted environment because it occurs in the 566 Rule Maker�s Device. 568 SCENARIO 2: Cell Phone Roaming 570 In this example, a cell phone is used outside its home service area 571 (roaming). Also, the cell phone service provider (cell phone Corp 2) 573 Cuellar, Morris, Mulligan 11 574 outsourced the accounting of cell phone usage. The cell phone is not 575 GPS-enabled. Location is derived by the cell phone network in which 576 the Target and Device are roaming. When the Target wishes to use 577 the cell phone, cell phone Corp 1 (IAP) provides the roaming service 578 for the Target, which sends the raw data about usage (e.g., duration 579 of call, location � roaming network, etc.) to cell phone Corp 2, the 580 home service provider. Cell phone Corp 2 submits the raw data to 581 the accounting company, which processes the raw data for the 582 accounting statements. Finally, the raw data is sent to a data 583 warehouse where the raw data is stored in a Location Server (e.g., 584 computer server). 586 Cell Phone Corp 1 Cell Phone Corp 2 587 ----------------- ----------------- 588 Sighting / \ Sighting / \ 589 Device ----- | Data Transporter | --------- | Data Transporter | 590 Target \ / \ / 591 ----------------- / ----------------- 592 / | 593 / sighting| 594 / | 595 ----------- | 596 / V 597 ------------ / ---------- 598 / \ / / \ 599 / Location \ / | Location | 600 | Storage | Location Info | Storage | 601 | |<----------------- | | 602 | Location | | Location | 603 | Seeker | | Seeker | 604 \ / \ / 605 ------------- ---------- 607 Here cell phone corp 1 is the IAP and the LoSi. Cell phone corp 1 608 could be Non-trusted (the Rule Maker does not have a contract 609 protecting location information with corp 1 and there is no 610 contractual relationship with privacy provisions between corp 1 and 611 corp 2) or Trusted (contract with privacy protections between cell 612 phone corp 2 and corp 1). Cell phone corp 2 is Trusted. 614 SCENARIO 3: Mobile Communities and Location-Based Services 616 The figure below shows a common scenario, where a user wants to find 617 his friends or colleagues or wants to share his position with them 618 or with a Location-Based Service Provider. Some of the messages use 619 a Location Object to carry for instance: identities or pseudonyms, 620 credentials and proof-of-possession of them, Policies and Location 621 Data Information, including Data Types and Accuracy. They are shown 622 in the figure by normal arrows ("--->"). Other messages do not use 624 Cuellar, Morris, Mulligan 12 625 the Location Object and are outside of the scope of the geopriv WG, 626 but should be mentioned for understandability. They are shown in 627 the figure as starred arrows ("***>"). 629 +---------+ +------------+ 630 | Location| | Public | 631 | Data |<** | Policy | 632 | Source | * | Repository | 633 | + IAP | * +------------+ 634 +---------+\ * * * 635 ^ \ *5 3a* * 636 * \ * * * 637 * \ ** * 638 * \ * * *3a 639 5a * \* * * 640 * * \ * * 641 * * \ * * 642 * * \6 * * 643 +----------+ * \ * V 644 | Target | * \->+-----------+ 645 | +----------+ 3 | Location | 646 +-| Rule |--------------------->| Server + | 647 | Maker | | Private | 648 +----------+<********************>| Repository| 649 ^ 1 +-----------+ 650 | ^ | 651 | 4| |7 652 | | V 653 | +----------+ 654 | | Ultimate | 655 +---------------------------->| Location | 656 2 | Recipient| 657 +----------+ 659 Figure 1: The Entities and Data Flows 661 1: Registration: 662 The Rule Maker registers himself and the Target with the 663 Location Server. This registration process is outside of the 664 scope of our discussion, but probably the Rule Maker has to 665 prove that he indeed is the owner of the privacy rights of the 666 Target (the Target is usually a Device owned by the Rule 667 Maker). The Rule Maker and the Location Server agree, as part 668 of the Registration Process, which keys or credentials and 669 proof-of-possession of the corresponding secrets they will use 670 to authenticate each other, and in particular, to authenticate 671 or sign the policies, or how they will agree on them or renew 672 those keys or credentials. 674 Cuellar, Morris, Mulligan 13 675 2: End-to-End Negotiation: 676 The Rule Maker and the Location Seeker exchange information 677 about the service (if any) and negotiate it. They also 678 negotiate the pseudonyms that they will use later on and the 679 credentials or keys that the Ultimate Location Recipient will 680 use to prove his authorization to the Location Server. This 681 End-to-End Negotiation may contain several messages and may 682 use or not the Location Object. 684 3: Policy Transfer: 685 The Rule Maker sends a Policy to the Location Server. This 686 Policy may be a field in a Location Object or not. 688 3a:Signed Policy: 689 As an alternative to the Policy Transfer, the Rule Maker may 690 write a policy and place it in the Open Repository. The 691 entities access the repository to read the signed policies. 693 4: Location Information Request: 694 The Location Seeker requests location information for a 695 Target. In this request, the Location Seeker may select which 696 location information data type it prefers. One way of 697 requesting Location Information MAY be sending a partially 698 filled Location Object, including only the identities of the 699 Target and Location Recipient and the desired Data Type and 700 accuracy, and providing proof of possession of the required 701 credentials. But whether the using protocol understands this 702 partially filled object as a request, this MAY depend on the 703 using protocol or on the context. The Location Seeker could 704 also specify the need for periodic location information 705 updates, but this is probably out of the scope of geopriv. 707 5: Locate: 708 When a Location Server receives an Location Information 709 Request for a Target for which has no current location 710 information, the server may send ask the Location Sighter to 711 locate the Target. 713 6: Location Information: 714 The Location Sighter sends the "full" location information to 715 the Location Server. This Location Information may be 716 embedded in a Location Object or not. 718 7: Filtered Location Information: 719 Then the Location Server sends the location information to the 720 Location Recipient. The information may be filtered in the 721 sense that in general a less precise or a computed version of 722 the information is being delivered. 724 5. Requirements 726 Cuellar, Morris, Mulligan 14 727 5.1. Location Object 729 Req. 1. (Location Object generalities) 731 1.1) Geopriv MUST define one Location Object (LO) -- both in 732 syntax and semantics -- that must be supported by all geopriv 733 entities. 735 1.2) Some fields of the Location Object MAY be optional. This 736 means that an instance of a Location Object MAY contain the 737 fields or not. 739 1.3) Some fields of the Location Object MAY be defined as 740 "extensions". This means that the syntax or semantics of these 741 fields is not fully defined in the basic Location Object 742 definition, but their use may be private to one or more using 743 protocols. 745 1.4) The Location Object MUST be extensible, allowing the 746 definition of new attributes or fields. 748 1.5) The object MUST be suitable for requesting and receiving a 749 location. 751 1.6) The object MUST permit (but not require) the policy to be 752 enforced by a third party. 754 1.7) The object MUST be usable in a variety of protocols, such as 755 HTTP and SIP, as well as local APIs. 757 1.8) The object MUST be usable in a secure manner even by 758 applications on constrained devices. 760 Req. 2. (Location Object fields) The Location Object definition 761 MUST support the following Fields (but not all LOs must use all 762 fields) 764 2.1) Target Identifier 766 2.2) Location Recipient Identity 768 This identity may be a multicast or group identity, used to 769 include the Location Object in multicast-based using protocols. 771 2.3) Location Recipient Credential 773 2.4) Location Recipient Proof-of-Possession of the Credential 775 2.5) Location Field. 777 Cuellar, Morris, Mulligan 15 778 Each Location Field may contain one or more Location 779 Representations, which can be also in different formats. 781 2.6) Location Data Type 783 When transmitting the Location Object, the sender and the 784 receiver must agree on the data type of the location information. 785 The using protocol may specify that the data type information is 786 part of the Location Object or that sender and receiver have 787 agreed on it before the actual data transfer. 789 2.7) Motion and direction vectors 791 2.8) Timing information: 792 (a) When was the LI accurate? (sighting time) 793 (b) Until when considered current? TTL (Time-to-live) (This is 794 different than a privacy rule setting a limit on data retention) 796 2.9) Policy Field: this field MAY be a referral to an applicable 797 policy (for instance, an URI to a full policy), or it MAY contain 798 a Limited Policy (see Req. 9), or both. 800 2.10) Security-headers and -trailers (for instance encryption 801 information, hashes, or signatures) (see Req. 13). 803 2.11) Version number 805 Req. 3. (Location Data Types) 807 3.1) The Location Object MUST define at least one Location Data 808 Type to be supported by all geopriv receivers (entities that 809 receive LOs). 811 3.2) The Location Object SHOULD define two Location Data Types: 812 one for latitude / longitude / altitude coordinates and one for 813 civil locations (City, Street, Number) supported by all geopriv 814 receivers (entities that receive LOs). 816 3.3) The latitude / longitude / altitude Data Type SHOULD also 817 support a delta format in addition to an absolute one, used for 818 the purpose of reducing the size of the packages or the security 819 and confidentiality needs. 821 3.4) The Location Object definition SHOULD agree on further 822 Location Data Types supported by some geopriv entities and 823 defined by other organizations. 825 5.2. The Using Protocol 827 Req. 4. The using protocol has to obey the privacy and security 828 instructions coded in the Location Object and in the 830 Cuellar, Morris, Mulligan 16 831 corresponding Policy Rules regarding the transmission and storage 832 of the LO. 834 Req. 5. The using protocol will typically facilitate that the keys 835 associated with the credentials are transported to the respective 836 parties, that is, key agreement is responsibility of the using 837 protocol. 839 Req. 6. (Single Message Transfer) In particular for tracking of 840 small target devices, the design should allow a single 841 message/packet transmission of location as a complete 842 transaction. 844 Other requirements on the using protocol are out of the scope of 845 this document. See also Section 9 (Protocol and LO Issues for later 846 Consideration) 848 5.3. Policy based Location Data Transfer 850 Req. 7. (LServ Policies) The decision of a Location Server to 851 provide a Location Seeker access to Location Information MUST be 852 based on Rule Maker-defined Privacy Policies. 854 It is outside of our scope how Privacy Policies are managed, how a 855 Location Server has access to the Privacy Policies, and if he is or 856 not aware of the full set of rules desired by the Rule-Maker. Note 857 that it might be that some rules contain private information not 858 intended for untrusted parties. 860 Req. 8. (LoSi Policies) Even if a Location Sighter is unaware of 861 and lacks access to the full Privacy Policies defined by the Rule 862 Maker, the Location Sighter MUST transmit Location Information in 863 compliance with instructions set by the Rule Maker. Such 864 compliance MAY be accomplished by the Location Sighter 865 transmitting LI only to a URI designated by the Rule Maker. 867 Req. 9. (ULR Policies) An Ultimate Location Recipient does not need 868 to be aware of the full policies defined by the Rule Maker 869 (because an ULR SHOULD NOT retransmit Location Information), and 870 thus an ULR SHOULD receive only the subset of Privacy Policies 871 necessary for the ULR to handle the LI in compliance with the 872 full Privacy Policies (such as, for example, an instruction on 873 the time period for which then LI can be retained). 875 Req. 10. (Full Policy language) Geopriv MAY specify a policy 876 language capable of expressing a wide range of privacy rules 877 concerning location information. This policy language MAY be an 878 existing one, an adaptation of an existing one or a new policy 879 language, and it SHOULD be as simple as possible. 881 Req. 11. (Limited Policy language) Geopriv MUST specify a limited 882 policy language capable of expressing a limited set of privacy 884 Cuellar, Morris, Mulligan 17 885 rules concerning location information. This policy language MAY 886 be an existing one, an adaptation of an existing one or a new 887 policy language. The Location Object MUST include sufficient 888 fields and data to express the limited set of privacy rules. 890 5.4. Location Object Privacy and Security 892 5.5. Identity Protection 894 Req. 12. (Identity Protection) The Location Object MUST support use 895 of Unlinked Pseudonyms in the corresponding identification fields 896 of Rule Maker, Target, Device, and Location Recipient. Since 897 Unlinked Pseudonyms are simply bit strings that are not linked 898 initially to a well-known identity, this requirement boils down 899 to saying that the name space for Identifiers used in the LO has 900 to be large enough to contain many unused strings. 902 5.6. Authentication Requirements 904 Req. 13. (Credential Requirements) The using protocol and the 905 Location Object SHOULD allow the use of different credentials 906 types, including privacy-enhancing credentials (like for instance 907 the ones described in [Bra00] or [Cha85]). 909 5.7. Actions to be secured 911 Req. 14. (Security Features) The Location Object MUST support 912 fields suitable for protecting the Object to provide the 913 following security features: 915 14.1) Mutual end-point authentication: the using protocol is 916 able to authenticate both parties in a Location Object 917 transmission, 919 14.2) Data object integrity: the LO is secured from 920 modification by unauthorized entities during transmission and 921 during storage, 923 14.3) Data object confidentiality: the LO is secured from 924 eavesdropping (unauthorized reading) during transmission and 925 during storage, and 927 14.4) Replay protection: an old LO may not be replayed by an 928 adversary or by the same entity that used the LO itself (except 929 perhaps during a small window of time that is configurable or 930 accepted by the Rule Maker). 932 Req. 15. (Minimal Crypto) 934 15.1) Geopriv MUST specify a minimum mandatory to implement 935 Location Object security including mandatory to implement crypto 937 Cuellar, Morris, Mulligan 18 938 algorithms, for digital signature algorithms and encryption 939 algorithms. 941 15.2) It MAY also define further mandatory to implement 942 Location Object security mechanisms for message authentication 943 codes (MACs) or other purposes. 945 15.3) The protocol SHOULD allow a bypass if authentication 946 fails in an emergency call. 948 The issue addressed in the last point is that an emergency call in 949 some very unfavorable situations my not be completed if the minimal 950 authentication fails. This is probably not what the user would like 951 to see. The user may prefer an unauthenticated call to an 952 unauthenticated emergency server than no call completion at all, 953 even at the risk that he is talking to an attacker or that his 954 information is not secured. 956 5.8. Non-Requirements 958 Non-Req. 1. (Bridging to non-IP networks) The geopriv specification 959 SHOULD NOT specify the bridging to non-IP networks (PSTN, etc). 961 6. Security Considerations 963 The purpose of the geopriv Location Object and the requirements on 964 the using protocol are to allow a policy-controlled disclosure of 965 location information for location services. 967 6.1. Traffic Analysis 969 The information carried within the Location Object is secured in a 970 way compliant with the privacy and security policies of the Rule 971 Maker, but other information, carried in other objects or headers 972 are in general not secured in the same way. This means that geopriv 973 does not as a general matter secure the Target against general 974 traffic analysis attacks or other forms of privacy violations. 976 6.2. Securing the Privacy Policies 978 The Privacy Policies of the Rule Maker regarding the location of the 979 Target may be accessible to a Location Server in a Private Storage 980 or in a Public Repository, or they may be carried by the Location 981 Object, or they may be presented by the Location Seeker as 982 capabilities or tokens. Each of this types of policy has to be 983 secured it�s own particular way. 985 The rules in a Private Storage are typically authenticated using a 986 MAC (Message Authentication Code) or a signature, depending on the 987 type of keys used. The rules in a Public Repository (one that in 989 Cuellar, Morris, Mulligan 19 990 principle may be accessed directly by several entities, for instance 991 several Location Servers) are typically digitally signed. A Policy 992 Field in a LO is secured as part of the LO itself. A Geopriv Token 993 (a token or ticket issued by the Rule Maker to a Location Seeker, 994 expressing the explicit consent of the Rule Maker to access his 995 location information) is authenticated or signed. 997 6.3. Emergency Case 999 One way of implementing the authentication bypass for emergency 1000 calls, mentioned in Req 14.3) is to let the user have the choice of 1001 writing a policy that says: 1002 - "If the emergency server does not authenticate itself, 1003 nevertheless send the location", or 1004 - "If the emergency server does not authenticate itself, let the 1005 call fail". 1007 In the case where the authentication of the emergency call fails 1008 because the user may not authenticate itself, the question arises: 1009 whose policy to use? It is reasonable to use a default one: this 1010 location information can only be sent to an emergency center. 1012 Another situation, which should be studied in more detail is: what 1013 to do if not only the user fails to authenticate itself, but also 1014 the emergency center is not authenticable? It is reasonable to send 1015 the Location Information anyway, but are there in this case any 1016 security threats that must be considered? 1018 6.4. Identities and Anonymity 1020 The use of Unlinked Pseudonyms is necessary to obtain anonymity. 1022 The purpose of the use of Unlinked Pseudonyms is the following: the 1023 using protocol should be able to hide the real identity of the Rule 1024 Maker, the Target, and the Device, the and to Location Servers or 1025 Location Recipients. Also, the using protocol SHOULD be able to 1026 hide the real identity of the Location Recipient to the Location 1027 Server. 1029 In this last case, the Target is not concerned about the Server 1030 identifying him and knowing his location, but identifying his 1031 business partners, and therefore his habits, etc. Reasons for 1032 hiding the real identities of the Location Recipients include (a) 1033 that this knowledge may be used to infer the identity of the Target, 1034 (b) that knowledge of the identity of the Location Recipient may 1035 embarrass the Target or breach confidential information, and (c) 1036 that the dossier telling who has obtained a Target's location 1037 information over a long period of time can give information on 1038 habits, movements, etc. Even if the location service providers 1039 agree to respect the privacy of the user, are compelled by laws or 1040 regulations to protect the privacy of the user, and misbehavior or 1042 Cuellar, Morris, Mulligan 20 1043 negligence of the Location Server can be ruled out, there is still 1044 risk that personal data may become available to unauthorized persons 1045 through attacks from outsiders, unauthorized access from insiders, 1046 technical or human errors, or legal processes. 1048 In some occasions a Location Server has to know who is supplying 1049 policies for a particular Target, but in other situations it could 1050 be enough to know that the supplier of the policies is authorized to 1051 do so. Those considerations are outside of our scope. 1053 6.5. Unintended Target 1055 An Unintended Target is a person or object tracked by proximity to 1056 the Target. This special case most frequently occurs if the Target 1057 is not a person. For example, the Target may be a rental car 1058 equipped with a GPS Device, used to track car inventory. The rental 1059 company may not care about the driver's location, but the driver's 1060 privacy is implicitly affected. 1062 Geopriv may or may not protect or affect the privacy of Unintended 1063 Targets, but the impact on Unintended Targets should be 1064 acknowledged. 1066 7. Acknowledgements 1068 We wish to thank the members of the IETF geopriv WG for their 1069 comments and suggestions. Aaron Burstein, Mehmet Ersue, Allison 1070 Mankin, Randall Gellens, Jon Peterson, and the participants of the 1071 geopriv meetings in San Diego and Yokohama provided detailed 1072 comments or text. 1074 8. References 1076 [Bra00] Stefan A.: Rethinking Public Key Infrastructures and Digital 1077 Certificates : Building in Privacy, MIT Press; ISBN: 1078 0262024918; 1st edition, August, 2000 1080 [Cha85] Chaum, David: Security without Identification, Card 1081 Computers to make Big Brother Obsolete. Original Verion 1082 appeared in: Communications of the ACM, vol. 28 no. 10, 1083 October 1985 pp. 1030-1044. Revised version available at 1084 http://www.chaum.com/articles/ 1086 [ISO99] ISO99: ISO IS 15408, 1999, http://www.commoncriteria.org/. 1088 [OECD] OECD Guidelines on the Protection of Privacy and Transborder 1089 Flows of Personal Data, http://www.oecd.org. 1091 [Pfi01] Pfitzmann, Andreas; K�hntopp, Marit: Anonymity, 1092 Unobservability, and Pseudonymity - A Proposal for 1093 Terminology; in: H Federrath (Ed.): Designing Privacy 1095 Cuellar, Morris, Mulligan 21 1096 Enhancing Technologies; Proc. Workshop on Design Issues in 1097 Anonymity and Unobservability; LNCS 2009; 2001; 1-9. Newer 1098 versions available at http://www.koehntopp.de/marit/pub/anon 1100 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1101 Requirement Levels", BCP 14, RFC 2119, March 1997. 1103 9. Protocol and LO Issues for later Consideration 1105 It seems important to mention some issues on the Location Object or 1106 on the protocol, which have emerged during the discussion of earlier 1107 versions of this document. 1109 9.1. Multiple Locations in one LO 1111 The possibility of inclusion of multiple locations is discussed in 1112 another draft, draft-morris-geopriv-location-object-issues-00.txt. 1114 An instance of a Location Object could contain zero, one, or several 1115 Location Fields, perhaps in different formats. Several Location 1116 Fields would be used to report the same sighting in different 1117 formats, or multiple sightings at different times, or multiple 1118 sensor locations for the same device, or other purposes. 1120 9.2. Translation Fields 1122 It is possible to include fields to indicate that one of the 1123 locations is a translation of another. If this is done, it is also 1124 possible to have a field to identify the translator, as identity and 1125 method. 1127 9.3. Specifying Desired Accuracy in a Request 1129 If the LO is used to request location information (leaving some 1130 fields empty), it is not clear how to specify the requested 1131 accuracy. Are the data types "country/state/city" and 1132 "country/state" different data types or the same data type with 1133 different "accuracy" or "granularity"? 1135 9.4. Truth Flag 1137 Geopriv should not provide an attribute in object saying "I'm not 1138 telling you the whole truth." 1140 9.5. Timing Information Format 1142 The format of timing information is out of the scope of this 1143 document. 1145 9.6. The Name Space of Identifiers 1147 Cuellar, Morris, Mulligan 22 1148 Who defines the Identities: may the using protocol define the 1149 Identifiers or must the using protocol use and authenticate 1150 Pseudonyms proposed by the policies, chosen independently of the 1151 using protocol? Of course, if the using protocol has an appropriate 1152 namespace, containing many unused names that may be used as 1153 pseudonyms and may be replaced by new ones regularly, then the 1154 Location Object may be able to use the name space. For this purpose, 1155 the user would probably have to write his policies using this name 1156 space. Note that it is necessary to change the used pseudonyms 1157 regularly, because identifying the user behind an unlinked pseudonym 1158 can be very simple. 1160 There are several advantages of letting the using protocol to define 1161 the name space: 1162 o the embedded authentication would be easier, as the using protocol 1163 has often already the credentials for the authentication identity 1164 in place and the "embedded" authentication would be independent on 1165 the form of Identifiers, 1166 o the size of the names would be fixed. 1168 On the other hand, the benefits of the policy choosing the 1169 identifiers are: 1170 o the user has a control of his anonymity, and 1171 o the interworking of multiple systems with Location object across 1172 protocol boundaries is facilitated. 1174 10. Author's Addresses 1176 Jorge R Cuellar 1177 Siemens AG 1178 Corporate Technology 1179 CT IC 3 1180 81730 Munich Email: Jorge.Cuellar@mchp.siemens.de 1181 Germany 1183 John B. Morris, Jr. 1184 Director, Internet Standards, Technology & Policy Project 1185 Center for Democracy and Technology 1186 1634 I Street NW, Suite 1100 1187 Washington, DC 20006 Email: jmorris@cdt.org 1188 USA http://www.cdt.org 1190 Deirdre K. Mulligan 1191 Samuelson Law, Technology and Public Policy Clinic 1192 Boalt Hall School of Law 1193 University of California 1194 Berkeley, CA 94720-7 Email: dmulligan@law.berkeley.edu 1196 11. Full Copyright Statement 1198 Copyright (C) The Internet Society (date). All Rights Reserved. 1200 Cuellar, Morris, Mulligan 23 1201 This document and translations of it may be copied and furnished to 1202 others, and derivative works that comment on or otherwise explain it 1203 or assist in its implementation may be prepared, copied, published 1204 and distributed, in whole or in part, without restriction of any 1205 kind, provided that the above copyright notice and this paragraph 1206 are included on all such copies and derivative works. However, this 1207 document itself may not be modified in any way, such as by removing 1208 the copyright notice or references to the Internet Society or other 1209 Internet organizations, except as needed for the purpose of 1210 developing Internet standards in which case the procedures for 1211 copyrights defined in the Internet Standards process must be 1212 followed, or as required to translate it into languages other than 1213 English. 1215 The limited permissions granted above are perpetual and will not be 1216 revoked by the Internet Society or its successors or assigns. 1218 This document and the information contained herein is provided on an 1219 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1220 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1221 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1222 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1223 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1225 Cuellar, Morris, Mulligan 24