idnits 2.17.1 draft-ietf-geopriv-reqs-00.txt: 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 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 66 lines 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 == Line 398 has weird spacing: '...ided by the L...' -- 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 (June 2002) is 7979 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 3 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-00.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: Dec. 2002 June 2002 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 months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 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 services, 42 management of equipment in the field, and other location-dependent 43 services need geographic location information about a target (user, 44 resource or other entity). There is a need to securely gather and 45 transfer location information for location services, protecting the 46 privacy of the individuals involved. 48 This document describes the requirements for the geopriv Location 49 Object (used to transfer location data and perhaps some other 51 Cuellar, Morris, Mulligan Expires Dec 2002 1 52 information) and for further IETF protocols that use this Location 53 Object as an embedded protocol. We focus on authorization, integrity 54 and privacy requirements. 56 Table of Contents 58 1. Overview.......................................................2 59 2. Conventions used in this document..............................4 60 3. Usage Model....................................................4 61 3.1. Roles and attributes......................................4 62 3.2. Data......................................................8 63 3.3. Identification, Authentication, and Authorization.........9 64 3.3.1. Identifiers..........................................9 65 3.3.2. Authentication......................................10 66 3.3.3. Authorization.......................................10 67 3.4. Data Flows...............................................10 68 3.4.1. Relationship framework..............................12 69 3.4.2. Scenarios of Data Flow..............................12 70 3.5. Further explanations.....................................14 71 3.5.1. Location Data Types.................................14 72 3.5.2. Public Global Identities............................15 73 3.5.3. Authorization without Explicit Authentication.......15 74 4. Requirements..................................................17 75 4.1. Protocols................................................17 76 4.2. Policy based Location Data transfer......................17 77 4.3. Location Object, Location Field..........................18 78 4.4. Requests.................................................19 79 4.5. Identity Protection......................................19 80 4.6. Authentication Requirements..............................20 81 4.7. Actions to be secured....................................21 82 4.8. Non-Requirements.........................................21 83 5. Security Considerations.......................................21 84 6. Acknowledgements..............................................21 85 7. References....................................................22 86 8. Author's Addresses............................................22 87 9. Full Copyright Statement......................................22 89 1. Overview 91 Location-based services (applications that require geographic 92 location information as input) are becoming increasingly common. The 93 collection and transfer of location information about a particular 94 device and/or target can have privacy implications. 96 The ability to derive or compute a device's location, and access to 97 the derived or computed location, are key elements of the location- 98 based services privacy equation. Central to a target's privacy are 99 (a) the identity of entities that have access to raw location data, 101 Cuellar, Morris, Mulligan Expires Dec 2002 2 102 derive or compute location, and/or have access to derived or computed 103 location information, and (b) whether those entities can be trusted 104 to know and follow the target's (or better Rule Maker's) policy. 106 In this paper we assume that "location information" is a relatively 107 specific way of describing where a device is located and that the 108 location information is either (a) derived or computed from 109 information generally not available to the general public, or (b) 110 determined by a device that is not generally publicly addressable or 111 accessible. For example, location information could include 112 information calculated by triangulating on a wireless signal with 113 respect to cell phone towers, or longitude and latitude information 114 determined by a device with GPS (global positioning satellite) 115 capabilities. 117 Excluded from the discussion below is the determination of location 118 information wholly without the knowledge or consent of the target (or 119 the target's network or access service provider), based on generally 120 available information such as an IP or e-mail address. It is 121 important to note that information like IP address can enable someone 122 to roughly or in some instances precisely estimate a location. 123 Commercial services exist, for example, that offer to provide rough 124 location information based on IP address. Currently, this type of 125 location information is typically less accurate and has a coarser 126 granularity than the type of location information addressed in this 127 document. This less accurate type of location computation still 128 raises significant potential privacy and public policy concerns, but 129 such scenarios are generally outside the scope of this document. 131 For the purposes of this document, "policies" or "privacy rules" are 132 rules that regulate an entity's activities with respect to location 133 information, including, but not limited to, the collection, use, 134 disclosure, and retention of location information. These rules must 135 generally comply with fair information practices. For instance, see 136 the OECD Guidelines on the Protection of Privacy and Transporter 137 Flows of Personal Data at http://www.oecd.org. 139 The main principles guiding the requirements exposed in this paper 140 are: 142 1) Security of the protocol is of essential to guarantee the 143 correctness (integrity) and the confidentiality of the location 144 information. This includes authenticating the main entities of 145 the protocol and securing the exchanged messages. 147 2) A critical role is played by user-controlled policies, which 148 describe the permissions (or consent) given by the user. (In 149 this introductory section we use the word "user" informally; to 150 be more precise, instead of "user", we should say "Rule Maker" 151 but this term has not been introduced yet.) The policies specify 152 the necessary conditions that allow a Location Server to forward 153 (transformed or filtered) location information to a Location 154 Recipient and the conditions under which and purposes for which 156 Cuellar, Morris, Mulligan Expires Dec 2002 3 157 location information can be used. That is, using policies, the 158 user is able to specify which component or derived measure of the 159 information is to be released to whom and in which granularity or 160 accuracy. The exact form or expressiveness of policies is not 161 further discussed in this paper. 163 3) Whenever possible, the location information should not be linked 164 to the real identity of the user or a static identifier easily 165 linked back to the real identity of the user (e.g., the phone 166 number). Rather, the user is able to specify which local 167 identifier, pseudonym, or private identifier is to be linked to 168 the location information. 170 4) The user may want to hide the real identities of himself and his 171 partners not only to eavesdroppers but also to other entities 172 participating in the protocol. 174 Although complete anonymity may not be appropriate because of legal 175 constraints or because some location services may in fact need 176 explicit identifications, in most cases the location services only 177 need some type of authorization information and/or perhaps anonymous 178 identifiers of the entities in question. 180 2. Conventions used in this document 182 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 183 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 184 document are to be interpreted as described in [1]. 186 Note that the requirements discussed here are requirements on privacy 187 protocols for location services. Thus the requirements sometimes 188 refer only to the capabilities of these protocols. For example, 189 requiring that the protocol support integrity is not the same thing 190 as requiring that all protocol traffic be authenticated. In other 191 cases, the requirement may be that the user always obtains a notice 192 when his location data was not authenticated. This is clearly not 193 just a capability of the protocol. 195 3. Usage Model 197 The following usage model will be discussed more extensively in 198 another framework and scenarios document. We present here a summary 199 of the terminology of the usage model for convenience. 201 3.1. Roles and attributes 203 The entities of a geopriv application or scenario may be given 204 explicit roles: 206 Target: 207 The entity whose location is desired by the Location Seeker. 209 Cuellar, Morris, Mulligan Expires Dec 2002 4 210 In many cases the Target will be the human "user" of a Device 211 or an object such as a vehicle or shipping container to which 212 the device is attached. In some instances the target will be 213 the device itself. 215 Device: 216 The technical device the location of which is tracked as a 217 proxy for the location of a Target. A Device might, for 218 example, be a Global Positioning Satellite (GPS) receiver, a 219 laptop equipped with a wireless access device, or a 220 transmitter that emits a signal that can be tracked or 221 located. In some situations there may be no Device, in the 222 sense of this definition, but for instance a user is entering 223 the location information manually. 225 Rule Maker: 226 The individual or entity who has the authorization to set the 227 applicable privacy rules, collectively known also as the 228 policy. In some cases this is the user who is in possession 229 of the Device, but is some cases it is not. For example, 230 parents may control what happens to the location information 231 derived from their children's cell phones. The Rule Maker is 232 often, but not always, the "owner" of the Device used to track 233 location. For example, a company may own and provide a cell 234 phone to an employee but permit him/her to set the privacy 235 rules. Other proposed names are "Owner (of the privacy 236 rights)" or "policy maker" 238 Unintended Target: 239 A person or object tracked by proximity to the Target. This 240 special case most frequently occurs if the target is not a 241 person. For example, the Target may be a rental car equipped 242 with a GPS device, used to track car inventory. The rental 243 company may not care about the driver's location, but the 244 driver's privacy is implicitly affected. Working group 245 protocols may or may not protect or affect the privacy of 246 Unintended Targets, but the impact on Unintended Targets 247 should be acknowledged. 249 Data Transporter ("DT"): 250 An entity or sub-network that receives and forwards data 251 without processing or altering it. A Data Transporter could 252 theoretically be involved in almost any transmission between a 253 Device and a Location Processor, a Location Processor and a 254 second Location Processor, or a Location Processor and a 255 Location Seeker. Some location tracking scenarios may not 256 involve a Data Transporter. 258 Location Seeker ("LS") 259 An individual or entity who seeks to receive location data 260 about a Target. 262 Cuellar, Morris, Mulligan Expires Dec 2002 5 263 Computational Location Server ("CLServ") 264 A Device or entity that computes or processes raw data to 265 compute or derive location data, or processes location data to 266 transform or refine the data into new location data. The 267 actual computation of location information is beyond geopriv's 268 scope, the distribution of location information is not. 270 Location Storage ("LStor") 271 (. Location Server: Think of pure storage devices as disks. 272 They matter for privacy purposes!) 273 A Device or entity that stores raw or location data. The data 274 storage policy of LStor is crucial to privacy considerations, 275 because this policy may influence what location information 276 the Rule Maker will reveal. The different actors in a location 277 information request create intertwined privacy concerns. If 278 data about a requester is stored and correlated with data 279 about a Target, it may be possible to infer more information 280 from the aggregate than one or both entity's rules would 281 allow. Unlinkable identifiers provide the ideal solution to 282 this problem, but may be impossible in practice. Stored 283 identifiers SHOULD use the closest possible approximation to 284 unlinkable identifiers. LStor devices SHOULD follow the Rule 285 Maker's policies regarding permissible duration of data 286 storage, etc. 287 291 Rule Repository ("RR") 292 A repository that contains private (authenticated, but not 293 signed) or public (signed) policies, identifiers, and perhaps 294 also stores requests. 296 Roles of Location Information Requesters 298 An entity that seeks to access the location data is a Location Seeker 299 and may act in one or more of the following roles: as the Location 300 Sighter (Location Data Source), as a Location Server, or as an 301 Ultimate Location Recipient. 303 Location Sighter (LoSi), or Location Data Source 304 The original source of the sighting of a target in a given 305 transaction. 307 Location Server (LS), or Intermediate Location Recipient: 308 A Device or entity that provides access to raw data or 309 location data after processing or altering it or not. Some 310 location tracking scenarios may not involve a Location Server. 312 Cuellar, Morris, Mulligan Expires Dec 2002 6 313 Ultimate Location Recipient (ULR): 314 An individual or entity who receives location data about a 315 Target and does not transmit the location information or 316 information based on the Target's location (such as driving 317 directions to or from the target) to another party distinct 318 from the target or the Rule Maker. 320 A data transporter may be an 322 Initial Access Provider ("IAP"): 323 A data transporter that provides the initial network access or 324 other data communications services essential for the operation 325 of communications functions of the Device or computer 326 equipment in which the Device operates. Often, the IAP -- 327 which will be a wireless carrier, an Internet Service 328 Provider, or an internal corporate network -- will be 329 identical to the LoSi. Other cases may involve no IAP at all. 330 But in other instances the IAP's infrastructure may be 331 controlled by another party. In these cases the IAP could be 332 seen as a "dumb" LoSi, one that transmits geopriv data but 333 does not implement any part of the geopriv protocol. 335 The rules of the Target may be accessible to a Location Server in the 336 form of Private or Public Rules Repositories: 338 Public Policy Repository: 339 A repository where signed policies, identifiers, and perhaps 340 also requests are stored. 342 Private Policy Repository: 343 A repository of authenticated policies, identifiers, and 344 perhaps also requests are stored, for the private use of one 345 Location Server. 347 The following table shows the possible roles of the geopriv entities. 349 Cuellar, Morris, Mulligan Expires Dec 2002 7 350 +------------------+-----+------+--------+---------+----------+ 351 | role| IAP | ULR | Public | Private | Location | 352 |entity | | | RR | RR | Sighter | 353 +------------------+-----+------+--------+---------+----------+ 354 |Target | | | | | x | 355 +------------------+-----+------+--------+---------+----------+ 356 |Device | | | | | x | 357 +------------------+-----+------+--------+---------+----------+ 358 |Rule Maker | x | | | | x | 359 +------------------+-----+------+--------+---------+----------+ 360 |Unintended Target | | | | | | 361 +------------------+-----+------+--------+---------+----------+ 362 |Data Transporter | x | | | | x | 363 +------------------+-----+------+--------+---------+----------+ 364 |Location Seeker | x | x | | | | 365 +------------------+-----+------+--------+---------+----------+ 366 |Location Server | x | | | | x | 367 +------------------+-----+------+--------+---------+----------+ 368 |Rule Repository | | | x | x | | 369 +------------------+-----+------+--------+---------+----------+ 371 3.2. Data 373 The main data used by the protocol is the Location Object (LO). It 374 contains the sighting information (the identity/location pair) and 375 some other information to be determined, e.g., time information, some 376 types of policies, authenticators, etc. If no time information is 377 included, this implicitly means "at the current time" or "at a very 378 recent time". 380 Sighting: the location information for a target. This is the 381 main private data accessed by Location Servers and/or Ultimate 382 Location Recipients. Some variant of the sighting information 383 is included in the Location Object. Abstractly, it consists 384 of two separate data fields: 386 (Sighting-Identifier, Location) 388 Sighting-Identifier is the identifier assigned to a target or 389 device being sighted, and Location is the current position of 390 that target or device being sighted. 392 Not all entities have access to exactly the same piece of 393 sighting information. The sighting may be transformed to a 394 new sighting pair: 396 (Sighting-Identifier-1, Location-1) 398 before it is provided by the Location Data Source or the 399 Location Server to another Location Recipient. 401 Cuellar, Morris, Mulligan Expires Dec 2002 8 402 Policy: 403 A set of rules that regulate an entity's activities with 404 respect to location information, including the collection, 405 use, disclosure, and retention of location information. In 406 particular, the policy describes how location information may 407 be used by an entity and which transformed location 408 information may be released to which entities under which 409 conditions. Policies contain "rules" or "assertions". 410 Policies must be obeyed; they are not advisory. To make this 411 more explicit, the term "rules" is also used instead of 412 "policy". 414 Data attributes: 415 Filtered: 416 Location information that has been computationally modified. 418 3.3. Identification, Authentication, and Authorization 420 This subsection introduces some terms to be used later in the 421 Requirements Section. 423 3.3.1. Identifiers 425 The LO has a filed for identification of the target. Geopriv- 426 compliant systems MUST implement a means of asserting identities and 427 inserting and using the identifiers in the LO, but the LO needs not 428 use identifiers under all circumstances. 430 432 Using protocols should be able to handle LOs with identifiers, LOs 433 without identifiers, and LOs with pseudonyms. The identity of the 434 requester may be irrelevant in some cases, whereas the identity of 435 the Target may be irrelevant in others. In particular, geopriv does 436 not suggest that a LO with no identifier provides anonymity. 438 Entity-Identifier: The names used by the entities of the protocol 439 to identify, authenticate or authorize themselves to other 440 entities. Policies also use entity-identifiers to express 441 which Location Seekers may receive which transformed sighting 442 information. 444 The next type of identifier may not be used as an Entity-Identifier, 445 since it can be shared by several, perhaps many, different entities: 447 Role identifier 448 ("administrator", "member-of-club-A", etc.) The meaning of the 449 role may be context dependent. 450 Geopriv will probably does not support role identifiers in any 451 particular way. 453 Cuellar, Morris, Mulligan Expires Dec 2002 9 454 3.3.2. Authentication 456 People use the word authentication with different meanings. Some 457 people insist that authentication associates an entity with a more or 458 less well-known identity. This basically means that if A 459 authenticates another entity as being "B", then the label "B" has 460 also a meaning for many entities different from A. In this case, the 461 label "B" is called a publicly known identifier, and the 462 authentication is "explicit": 464 Explicit Authentication 465 The act of verifying a claimed static identity easily linked 466 back to the real identity of the user, in the form of a pre- 467 existing label from a predefined name space, as the sole 468 originator of a message (message authentication) or as the 469 end-point of a channel (entity authentication). 471 3.3.3. Authorization 473 Authorization 474 The act of determining if a particular right, such as access 475 to some resource, can be granted to the presenter of a 476 particular credential. 478 Depending on the type of credential, authorization may imply 479 Explicit Authentication or not. 481 3.4. Data Flows 483 Figure 1 presents the entities of a "typical" protocol setting, using 484 the Location Object and the data flows between those entities. Not 485 all steps discussed here necessarily occur in every scenario. The 486 data flows may be one-step message exchanges, or multi-step sub- 487 protocols and the actual transport of the Location Object may be done 488 via some other transport entities not included in the diagram. The 489 data flows to be considered by the geopriv WG, in the sense that WG 490 will assess their authentication, authorization and privacy 491 requirements, are the following. They are shown in Figure 1 by 492 normal arrows ("--->") 494 LI (Location Information): 495 the location data source sends the "full" location information 496 to the location server. Then the location server sends the 497 full or filtered location information to the Location 498 Recipient. The information may be filtered in the sense that 499 in general a less precise or a computed version of the 500 information is being delivered. 502 Pol (Policy): 503 The Rule Maker(or in particular, the target itself) sends a 504 Policy to the location server. 506 Cuellar, Morris, Mulligan Expires Dec 2002 10 507 PolInfo (Policy Information): 508 the server informs the Location Seeker which data type(s) of 509 filtered location information are available to him for a given 510 target. This mechanism must be able to be invoked by the 511 Location Seeker before he sends an LRequest. 513 LRequest (Location Information Request): 514 the Location Seeker requests location information for a 515 target, a given class of targets, or for targets with a 516 particular set of attributes. In this request, the Location 517 Seeker may select which location information data type it 518 prefers. The Location Seeker can also specify the need for 519 periodic location information updates. 521 +---------+ Locate +-----------+ 522 | Location|<************| Location | SPol +------------+ 523 | Data | LI | Server + |<*************| Public | 524 | Source |------------>| Private | * | Policy | 525 | + IAP | | Repository|<---\ * | Repository | 526 +---------+ +-----------+ | * +------------+ 527 ^ | | | * ^ 528 LRequest| |LI |PolInfo | * * SPol 529 | V V | * * 530 +----------+ +-----------+ | * * 531 | Target | | Location |<**+****/ +----------+ 532 | or |<***********>| Server + | | | | 533 |Rule Maker| Service | Private | | <-----------|Rule Maker| 534 +----------+ | Repository|<--/ Pol | | 535 ^ +-----------+ +----------+ 536 * ^ | | 537 * LRequest| |LI |PolInfo 538 * | V V 539 * +----------+ 540 * | Ultimate | 541 ******************>| Location | 542 Service | Recipient| 543 +----------+ 545 Figure 1: The Entities and Data Flows 547 The following Data Flows MAY be outside of the scope of the geopriv 548 WG, but should be mentioned for understandability. They are shown in 549 Figure 1 as while starred arrows ("***>"). 551 Service: (Service Information, Negotiation and Delivery): 552 The target (or the Rule Maker) and the client exchange 553 information about the service and negotiate it. The client 554 provides service delivery to the target and accounting or 555 billing data, as necessary. 557 Cuellar, Morris, Mulligan Expires Dec 2002 11 558 SPol (Signed Policy): 559 As an alternative to Pol, the Rule Maker may write a policy 560 and place it in the Open Repository. The entities access the 561 repository via SPol. 563 Locate: 564 Request to locate the target. When a Location Server receives 565 an LRequest for a target for which has no current location 566 information, the server may send this "Locate" request to the 567 Location Data Source. 569 3.4.1. Relationship framework 571 Location information can be used in very different environments. In 572 some cases the participants will have longstanding relationships 573 while in others participants may have discrete interactions. 575 The different relationships raise different concerns for the 576 implementation of privacy rules, including the need to communicate 577 privacy instructions. A public rule repository for example seems to 578 be superfluous in a trusted environment where more efficient methods 579 of addressing privacy issues likely exist. We propose the following 580 attributes as modifiers to a given data flow: 582 Trusted: 583 The data flow is governed by a contract that protects location 584 privacy. 586 Non-trusted: 587 The data flow is not governed by a contract that protects 588 location privacy. 590 3.4.2. Scenarios of Data Flow 592 In this subsection we introduce two short scenarios to illustrate how 593 these terms and attributes describe location information 594 transactions. 596 SCENARIO 1: GPS Device with Internal Computing Power: Closed System 598 In this example, the target wishes to know his/her location using 599 Global Positioning System (GPS) and the device is capable of 600 independently processing the raw data to determine its location. The 601 location is derived as follows: the device receives transmissions 602 from the GPS satellites, internally computes and displays location. 603 This is a closed system. For the purpose of this and subsequent 604 examples, it is assumed that the GPS satellite broadcasts some 605 signal, and has no information about the identity or whereabouts of 606 devices using the signal. 608 Cuellar, Morris, Mulligan Expires Dec 2002 12 609 GPS Satellite 610 | 611 | 612 | 613 | 614 V GPS Device 615 -------------------------------------------------- 616 / \ 617 | Data ----- Location ----- Location | 618 | Transporter Server Storage | 619 \ | / 620 -------------------------------------------|------ 621 | 622 ------------|------ 623 / V \ 624 / Target Location \ 625 | Seeker | 626 | | 627 \ Rule Maker / 628 \ / 629 ------------------- 631 In this scenario the GPS device is both the IAP and the LoSi. The 632 interaction occurs in a Trusted environment because it occurs in the 633 Rule Maker�s device. 635 SCENARIO 2: Cell Phone Roaming 637 In this example, a cell phone is used outside its home service area 638 (roaming). Also, the cell phone service provider (cell phone Corp 2) 639 outsourced the accounting of cell phone usage. The cell phone is not 640 GPS-enabled. Location is derived by the cell phone network in which 641 the target and device are roaming. When the target wishes to use the 642 cell phone, cell phone Corp 1 (IAP) provides the roaming service for 643 the target, which sends the raw data about usage (e.g., duration of 644 call, location � roaming network, etc.) to cell phone Corp 2, the 645 home service provider. Cell phone Corp 2 submits the raw data to the 646 accounting company which processes the raw data for the accounting 647 statements. Finally, the raw data is sent to a data warehouse where 648 the raw data is stored in a location server (e.g., computer server). 650 Cuellar, Morris, Mulligan Expires Dec 2002 13 651 Cell Phone Corp 1 Cell Phone Corp 2 652 ----------------- ----------------- 653 Sighting / \ Sighting / \ 654 Device --- | Data Transporter| --------- | Data Transporter | 655 \ / \ / 656 ----------------- / ----------------- 657 Target / | 658 / sighting| 659 / | 660 ----------- | 661 / V 662 ------------ / ---------- 663 / \ / / \ 664 / Location \ / | Location | 665 | Storage | Location Info | Storage | 666 | |<----------------- | | 667 | Location | | Location | 668 | Seeker | | Seeker | 669 \ / \ / 670 ------------- ---------- 672 Here cell phone corp 1 is the IAP and the LoSi. Cell phone corp 1 673 could be Non-trusted (the Rule Maker does not have a contract 674 protecting location information with corp 1 and there is no 675 contractual relationship with privacy provisions between corp 1 and 676 corp 2) or Trusted (contract with privacy protections between cell 677 phone corp 2 and corp 1). Cell phone corp 2 is Trusted. 679 3.5. Further explanations 681 684 3.5.1. Location Data Types 686 Two apparently different data types may contain the same information 687 if it is possible to transform one data type into the other and vice- 688 versa without information loss. 690 One location data type DT1 may contain more location information than 691 another DT2 in at least two different senses: 693 - DT1 may have the same dimensions as DT2 has, plus some extra 694 ones. (For instance, DT1 contains velocity, while DT2 does 695 not). 697 - DT1 may be more accurate than DT2. 699 Cuellar, Morris, Mulligan Expires Dec 2002 14 700 In general, if DT1 has more information than DT2, then there is one a 701 function that "translates correctly" from DT1 to DT2. There are 702 other types of transformations that introduce errors (obfuscation: 703 intentionally make the location values less accurate by adding 704 randomness). During a transformation, information can be lost, but 705 not gained. Of course, a transformation that merges information from 706 several sources clearly increases the information of each one. Thus 707 a transformation is a filtering of information. For instance there 708 are transformation functions from both data types "(latitude, 709 longitude, altitude)" and "(country, state, province, city)" to the 710 data types "(country, state)" and "time zone", but not vice-versa. 712 Notice that if the space regions determined by different location 713 values of DT2 do not overlap, then there is at most one 714 transformation from DT1 to DT2. If the space regions of DT2 overlap, 715 then usually there is some choice, which can be given by a (pseudo-) 716 random function. 718 If DT1 does not have more information than DT2, then there is no 719 function that "translates correctly" from DT1 to DT2. In other 720 words: there are many functions that translate from DT1 to DT2, but 721 all introduce some degree of error. We believe that this kind of 722 functions should be avoided. 724 3.5.2. Public Global Identities 726 If A has some information about a public global identifier "ID" and A 727 discloses this information to B, then B may associate this 728 information with the same entity as A did. In this way, B may 729 accumulate information about the entity labeled by "ID". 731 A public identity is a well-known label that identifies an entity for 732 a (rather large) group of entities. 734 A public identity may be the subscription identity at the home domain 735 (if applicable), a well-known identity (name, address or Tel Number), 736 etc. 738 An entity may regard the disclosure of his public identity (in 739 connection with some activity of him, his location or other 740 attribute) as a violation of his privacy right. 742 3.5.3. Authorization without Explicit Authentication 744 In order to remain anonymous, an entity may use private identifiers. 745 Private identifiers convey less information than public identities, 746 because they are meaningful to a smaller number of entities and in 747 use for a shorter duration. Thus if A discloses a private identifier 748 to B, B is less likely to associate this information with a known 749 individual or entity than if a public identifier was disclosed. 751 Cuellar, Morris, Mulligan Expires Dec 2002 15 752 Short-lived identifier 753 an identifier that is used only for one or a limited number of 754 "sessions". 756 Short-lived identifiers may be used to anonymously authenticate 757 entities in some settings. 759 In many situations, including pre-paid services, token-based or role- 760 based authorizations, unauthenticated key agreement, and purpose- 761 based identifiers, there is no need for explicit authentication. 763 Using weaker forms of authentication, the communication partner may 764 still want to make sure that he is communicating to the same entity 765 during the whole session, or that he is communicating with an 766 authorized entity. Thus message authentication codes are used, based 767 on "unauthenticated keys". 769 Authorization credentials may be used in the same way as 770 authentication credentials to secure a key agreement in the following 771 sense: one party is assured that no other party aside from the owner 772 of the authorization credentials (and possibly additional identified 773 trusted parties) may gain access to the agreed secret key. The 774 resulting keys are called authorized keys. Those keys may be used 775 for message authentication, without implying an explicit 776 authentication. 778 In real life this corresponds for instance to the following 779 situation: at a cloakroom a person deposits his coat and receives a 780 credential that he may use later to obtain back the coat. 782 One possible goal of the Rule Maker is to hide the identity of the 783 Location Recipient to the Location Server. Nevertheless, the 784 Location Server has to be sure that the Rule Maker has authorized the 785 Recipient to access the location. This is a case of authorization 786 without explicit authentication: the Location Server has to be sure 787 that the Location Recipient is a particular (i.e., authorized) 788 communication partner of the Rule Maker. 790 This may be done for instance as follows: consider a Location Seeker 791 that obtains a set of "traveller's cheques" from the Rule Maker. The 792 cheques will be used to "buy" location information from a Location 793 Service. Initially, the Location Seeker signs for a first time the 794 cheques with any "signature" that he wants to use. The Rule Maker, 795 through his own signature, authorizes the signature of the Location 796 Seeker. When presented to the Location Server, the cheques may be 797 countersigned so that the server is sure that the signer is the same 798 as the one who was authorized by the Rule Maker. This 799 countersignature does not only authenticate the Location Seeker to 800 the verifier, but also indirectly to the Rule Maker, when the cheque 801 is later presented to him. Incidentally, the Rule Maker may achieve 802 full information about who has accessed to his location information. 804 Cuellar, Morris, Mulligan Expires Dec 2002 16 805 To hide the real identity of the Rule Maker to the Location Server, 806 the following dual solution can be used. The Rule Maker buys (say, 807 using e-cash) a service from a Location Seeker (e.g., a navigation 808 service). During this transaction, the Location Seeker and the Rule 809 Maker agree on one or several pseudonyms and a set of "traveller's 810 cheques" that the target may use later to authenticate himself to the 811 server and thus indirectly also to the Location Seeker. 812 Since e-cash protocols may be also anonymous, this may be used to 813 hide simultaneously, 815 o the identity of the target from the Location Server, 816 o the identity of the Location Seeker from the Location 817 Server, 818 o the identity of the target from the Location Seeker. 820 But notice that the Location Data Source is in general not able to 821 localize the target based on some short-lived identifier. In this 822 scenario, the Location Data Source should be a Location Server, a 823 different one from the one from whom the identity of the target is to 824 be hidden. 826 4. Requirements 828 4.1. Protocols 830 Req. 1. The geopriv protocol MUST be an embedded protocol: it 831 defines a Location Object (LO), together with the security 832 mechanisms used to secure it. The security mechanisms are 833 of two types: on one hand the Location Object as such is 834 secured, using cryptographic checksums or encryption as 835 part of the Location Object itself, and on the other hand 836 security mechanisms may be provided by the embedding using 837 protocol that uses the Location Object. If 838 possible, security mechanisms on the Location Object itself 839 are to be preferred. 841 We refer to the embedded protocol also as the geopriv protocol and to 842 the combination of both the embedded protocol and the using 843 protocol as the combined protocol. 845 4.2. Policy based Location Data transfer 847 Req. 2. The decision of a Location Server to provide a Location 848 Seeker access to location information is based on Rule 849 Maker-defined privacy policies. 851 Req. 3. The Location Data Source may be unaware of the full 852 policies defined by the Rule Maker, but in that case it 853 will have to obey another set of "generic" policies, 854 consented to by the Rule Maker, to transfer Location Data 855 (raw or not) to another entity. 857 Cuellar, Morris, Mulligan Expires Dec 2002 17 858 Req. 4. An Ultimate Location Recipient does not need to be aware 859 of the full policies defined by the Rule Maker, but it will 860 obey a set of policies regarding the use and retention of 861 the location information. 863 Req. 5. The "generic" policies (as opposed to the policies 864 created by the Rule Maker) used by the Location Data 865 Source, by the Ultimate Location Recipients and by the 866 Location Server of some special scenarios MUST be made 867 explicit. 869 Req. 6. The combined protocol MAY specify a policy language. 870 This policy language MAY be an existing one, an adaptation 871 of an existing one or a new policy language. 873 If specified, the policy language MUST be strong enough to 874 express policies of the form: a group G of clients are 875 allowed to know a certain transformation A of the location 876 L of a target together with a given identifier I of the 877 target for a given purpose, for a given period of time. 879 If specified, the policy language MUST be strong enough to 880 express conditions on G and A as follows: 881 G, the group of clients SHOULD be characterized by the 882 possession of (identifiers, credentials) with a certain 883 syntactic property. 884 A, the transformation function MAY be specified by data 885 type of the expected filtered location information. 887 Within those constraints, the policy language SHOULD be as 888 simple as possible, or it SHOULD be an existing policy 889 language. 891 4.3. Location Object, Location Field 893 The Location Object has at least the following optional fields 894 (attributes): Identifier, Location, Location Data Type, Policy, 895 Request, and Version. The definition of the Location Object should 896 be flexible enough to accommodate new application-specific fields. 898 Req. 7. The embedded protocol MUST define one Location Object 899 (LO) -- both in syntax and semantics -- that must be 900 supported by all geopriv entities. 902 Some fields of the Location Object MAY be optional. This 903 means that an instance of a Location Object MAY contain the 904 fields or not. 906 Some fields of the Location Object MAY be opaque to the 907 embedded protocol. This means that the syntax and 908 semantics of these fields is not defined in the embedded 910 Cuellar, Morris, Mulligan Expires Dec 2002 18 911 protocol, but rather it is only clear in the using 912 protocol. Nevertheless the embedded protocol MUST know how 913 large the fields are. 915 Req. 8. The Location Object MUST contain one optional Identifier 916 Field. 918 Req. 9. The embedded protocol MUST define of at least one 919 Location Data Type supported by all geopriv implementations 920 and entities. 922 Req. 10. The Location Object MUST contain one optional Location 923 Field. An instance of a Location Object MAY contain zero, 924 one, or several Location Fields. (We also say in this case 925 that the LO contains several Locations.) Each Location 926 Field may contain one or more Location Representations. 928 932 When transmitting location information, (LI in Figure 1), the sender 933 and the receiver must agree on the data type of the location 934 information. The combined protocol may specify that the data type 935 information is part of the Location Object or that sender and 936 receiver have agreed on it before the actual data transfer. 938 Req. 11. The Location Object MUST contain one optional Location 939 Data Type Field. The Location Data Type Field may be used 940 to specify the type of a Location Field or Location 941 Representation, or to request a Location Field of this 942 particular type. 944 Req. 12. The Location Object MUST contain one optional Policy 945 Field. 947 Req. 13. The Location Object MUST contain a version number. 949 Req. 14. The protocol MUST be extensible, allowing the 950 definition of new attributes in the Location Object. 952 4.4. Requests 954 Req. 15. The Location Object MUST contain one optional Request 955 Field, encoding the type of remote request. Examples of 956 remote requests are: "send me the location information in a 957 given format", "send me a pseudonym to be used later", 958 "send me a pseudonym to be used later", "confirm the 959 purpose built key", etc. 961 4.5. Identity Protection 963 Cuellar, Morris, Mulligan Expires Dec 2002 19 964 Req. 16. The combined protocol MUST be able to hide the real 965 identity or linkable identifiers associated with the real 966 identity of the Rule Maker, the target, and the device from 967 the Ultimate Location Recipient. 969 This may be easily done using short-lived identifiers. 971 Req. 17. The combined protocol MUST be able to hide the real 972 identity of the Rule Maker to a Location Seeker, including 973 a Location Server. 975 Req. 18. The combined protocol MUST be able to hide the real 976 identity of the Location Recipient to the Location Server. 978 Thus here the target is not concerned about the Server identifying 979 him and knowing his location, but identifying his business partners, 980 and therefore his habits, etc. One reason for hiding the real 981 identities of the Location Recipients may be that this knowledge may 982 be used to infer the identity of the target. Or perhaps I have just 983 asked a certain organization (say, a political party or a night club) 984 to send me driving directions, but it could be embarrassing for me if 985 certain people find out that I have some relationship to that 986 organization. I do not want to let the Location Server know about 987 this. Even if my Server is trustworthy, it would be better if this 988 explicit information was never disclosed to anybody. Another reason 989 for not wanting the Server to know the real identity of the location 990 recipients is that the dossier telling who has obtained my location 991 information over a long period of time gives quite a lot of 992 information on my habits, movements, etc. Even if the location 993 service providers agree to respect the privacy of the user, are 994 compelled by laws or regulations to protect the privacy of the user, 995 and misbehavior or negligence of the Location Server can be ruled 996 out, there is still a chance that personal data may become available 997 to unauthorized persons through attacks from outsiders, unauthorized 998 access from insiders, or technical or human errors. 1000 Req. 19. When a Location Server accepts a policy from the Rule 1001 Maker, the target MUST prove to the combined protocol that 1002 he owns the claimed group or role identifier that should be 1003 passed to the Location Recipient. 1005 For instance, if a Target wants the role identifier "medical doctor" 1006 to be passed to a Location Recipient, the Target must prove the 1007 claims to be a medical doctor. 1010 4.6. Authentication Requirements 1012 Req. 20. The combined protocol MUST allow different 1013 authentication schemes. The combined protocol MUST 1014 guarantee that appropriate keys (shared or asymmetric) are 1016 Cuellar, Morris, Mulligan Expires Dec 2002 20 1017 generated and available to secure the Location Object 1018 within the embedded protocol. 1020 Req. 21. The combined protocol MUST allow authorization without 1021 explicit authentication. 1023 4.7. Actions to be secured 1025 Req. 22. The embedded protocol MUST be able to secure the 1026 Location Object for the following message flows (mutual 1027 end-point authentication, data object integrity, data 1028 object confidentiality, replay protection, in the absence 1029 of a time parameter): LI, Pol, LIF, LRequest, and PolInfo. 1031 Req. 23. The embedded protocol MUST specify a minimum mandatory 1032 to implement Location Object security including mandatory 1033 to implement crypto transforms. 1035 Req. 24. The embedding protocol MAY provide extra security for 1036 these flows (hop-by-hop or end-to-end). 1038 In full details, these requirements have many consequences: the 1039 communicating parties MUST have security relationships between them, 1040 allowing them to construct secure channels between them. This may 1041 imply that some scenarios should not be permitted in general. The 1042 Rule Maker MAY choose to use the security provided by the embedded or 1043 by the embedding protocol, or none. 1045 4.8. Non-Requirements 1047 Req. 25. The geopriv specification SHOULD NOT specify the 1048 bridging to non-IP networks (PSTN, etc). 1050 5. Security Considerations 1052 The purpose of the geopriv protocol is to allow a policy-controlled 1053 disclosure of location information for location services. Only the 1054 information carried within the Location Object is secured in a way 1055 compliant with the privacy and security policies of the target. This 1056 does not mean that geopriv secures the target against general traffic 1057 analysis attacks or other forms of privacy violations. 1059 The Location Server is assumed to be trustworthy. 1061 6. Acknowledgements 1063 We wish to thank the members of the IETF geopriv WG for their 1064 comments and suggestions. Detailed comments or text were provided by 1065 Aaron Burstein, Mehmet Ersue, Allison Mankin, Randall Gellens, and 1066 the participants of the geopriv interim meeting in San Diego. 1068 Cuellar, Morris, Mulligan Expires Dec 2002 21 1069 7. References 1071 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1072 Levels", BCP 14, RFC 2119, March 1997. 1074 8. Author's Addresses 1076 Jorge R Cuellar 1077 Siemens AG 1078 Corporate Technology 1079 CT IC 3 1080 81730 Munich Email: Jorge.Cuellar@mchp.siemens.de 1081 Germany 1083 John B. Morris, Jr. 1084 Director, Internet Standards, Technology & Policy Project 1085 Center for Democracy and Technology 1086 1634 I Street NW, Suite 1100 1087 Washington, DC 20006 Email: jmorris@cdt.org 1088 USA http://www.cdt.org 1090 Deirdre K. Mulligan 1091 Samuelson Law, Technology and Public Policy Clinic 1092 Boalt Hall School of Law 1093 University of California 1094 Berkeley, CA 94720-7 Email: dmulligan@law.berkeley.edu 1096 9. Full Copyright Statement 1098 Copyright (C) The Internet Society (date). All Rights Reserved. 1100 This document and translations of it may be copied and furnished to 1101 others, and derivative works that comment on or otherwise explain it 1102 or assist in its implementation may be prepared, copied, published 1103 and distributed, in whole or in part, without restriction of any 1104 kind, provided that the above copyright notice and this paragraph are 1105 included on all such copies and derivative works. However, this 1106 document itself may not be modified in any way, such as by removing 1107 the copyright notice or references to the Internet Society or other 1108 Internet organizations, except as needed for the purpose of 1109 developing Internet standards in which case the procedures for 1110 copyrights defined in the Internet Standards process must be 1111 followed, or as required to translate it into languages other than 1112 English. 1114 The limited permissions granted above are perpetual and will not be 1115 revoked by the Internet Society or its successors or assigns. 1117 This document and the information contained herein is provided on an 1118 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1120 Cuellar, Morris, Mulligan Expires Dec 2002 22 1121 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1122 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1123 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1124 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1126 Cuellar, Morris, Mulligan Expires Dec 2002 23