idnits 2.17.1 draft-cuellar-geopriv-reqs-02.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 9 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. ** There are 25 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 381 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 (May 2002) is 8016 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: 4 errors (**), 0 flaws (~~), 4 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-cuellar-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: Nov. 2002 May 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 Nov 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 60 2. Conventions used in this document..............................4 62 3. Usage Model....................................................4 63 3.1. Roles and attributes......................................4 64 3.2. Data......................................................7 65 3.3. Identification, Authentication, and Authorization.........8 66 3.4. Data Flows................................................9 67 3.4.1. Relationship framework..............................11 68 3.4.2. Scenarios of Data Flow..............................11 69 3.5. Further explanations.....................................13 70 3.5.1. Location Data Types.................................13 71 3.5.2. Public Global Identities............................14 72 3.5.3. Authorization without Explicit Authentication.......14 74 4. Requirements..................................................16 75 4.1. Protocols................................................16 76 4.2. Policy based Location Data transfer......................16 77 4.3. Location Object, Location Data...........................17 78 4.4. Policies.................................................17 79 4.5. Identity Protection......................................18 80 4.6. Authentication Requirements..............................18 81 4.7. Actions to be secured....................................19 83 5. Security Considerations.......................................19 84 6. References....................................................19 85 7. Author's Addresses............................................20 86 8. Full Copyright Statement......................................20 88 1. Overview 90 Location-based services (applications that require geographic 91 location information as input) are becoming increasingly common. The 92 collection and transfer of location information about a particular 93 device and/or target can have privacy implications. 95 The ability to derive or compute a device's location, and access to 96 the derived or computed location, are key elements of the location- 97 based services privacy equation. Central to a target's privacy are 98 (a) the identity of entities that have access to raw location data, 99 derive or compute location, and/or have access to derived or computed 100 location information, and (b) whether those entities can be trusted 101 to know and follow the target's (or better rule-maker's) policy. 103 Cuellar, Morris, Mulligan Expires Nov 2002 2 104 In this paper we assume that "location information" is a relatively 105 specific way of describing where a device is located and that the 106 location information is either (a) derived or computed from 107 information generally not available to the general public, or (b) 108 determined by a device that is not generally publicly addressable or 109 accessible. For example, location information could include 110 information calculated by triangulating on a wireless signal with 111 respect to cell phone towers, or longitude and latitude information 112 determined by a device with GPS (global positioning satellite) 113 capabilities. 115 Excluded from the discussion below is the determination of location 116 information wholly without the knowledge or consent of the target (or 117 the target's network or access service provider), based on generally 118 available information such as an IP or e-mail address. It is 119 important to note that information like IP address can enable someone 120 to roughly or in some instances precisely estimate a location. 121 Commercial services exist, for example, that offer to provide rough 122 location information based on IP address. Currently, this type of 123 location information is typically less accurate and has a coarser 124 granularity than the type of location information addressed in this 125 document. This less accurate type of location computation still 126 raises significant potential privacy and public policy concerns, but 127 such scenarios are generally outside the scope of this document. 129 For the purposes of this document, "policies" or "privacy rules" are 130 rules that regulate an entity's activities with respect to location 131 information, including, but not limited to, the collection, use, 132 disclosure, and retention of location information. These rules must 133 generally comply with fair information practices. For example, see 134 the OECD (Organization for Economic Co-operation and Development) 135 Guidelines on the Protection of Privacy and Transporter Flows of 136 Personal Data at 137 http://www1.oecd.org/dsti/sti/it/secur/prod/PRIVEN.HTM. The 138 application of these rules is described briefly in the scenarios. 139 However, they must be fully explored in a separate document prior to 140 creating location privacy technologies. 142 The main principles guiding the requirements exposed in this paper 143 are: 145 1) Security of the protocol is of utmost importance to guarantee the 146 correctness (integrity) and the confidentiality of the location 147 information. This includes authenticating the main entities of 148 the protocol and securing the exchanged messages. 150 2) A most important role is played by user-controlled policies, 151 which describe the permissions (or consent) given by the user. 152 The policies specify the necessary conditions that allow a 153 Location Server to forward (transformed or filtered) location 154 information to a Location Recipient and the conditions under 155 which and purposes for which location information can be used. 156 That is, using policies, the user is able to specify which 158 Cuellar, Morris, Mulligan Expires Nov 2002 3 159 component or derived measure of the information is to be released 160 to whom and in which granularity or accuracy. The exact form or 161 expressiveness of policies is not further discussed in this 162 paper. 164 3) Whenever possible, the location information should not be linked 165 to the real identity of the user or a static identifier easily 166 linked back to the real identity of the user (ie. phone number). 167 Rather, the user is able to specify which local identifier, 168 pseudonym, or private identifier is to be linked to the location 169 information. 171 4) The user may want to hide the real identities of himself and his 172 partners not only to eavesdroppers but also to other entities 173 participating in the protocol. 175 Although complete anonymity may not be appropriate because of legal 176 constraints or because some location services may in fact need 177 explicit identifications, in most cases the location services only 178 need some type of authorization information and/or perhaps anonymous 179 identifiers of the entities in question. 181 2. Conventions used in this document 183 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 184 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 185 document are to be interpreted as described in [1]. 187 Note that the requirements discussed here are requirements on privacy 188 protocols for location services. Thus the requirements sometimes 189 refer only to the capabilities of these protocols. For example, 190 requiring that the protocol support integrity is not the same thing 191 as requiring that all protocol traffic be authenticated. In other 192 cases, the requirement may be that the user always obtains a notice 193 when his location data was not authenticated. This is clearly not 194 just a capability of the protocol. 196 3. Usage Model 198 The following usage model will be discussed more extensively in 199 another framework and scenarios document. We present here a summary 200 of the terminology of the usage model for convenience. 202 3.1. Roles and attributes 204 The entities of a geopriv application or scenario may be given 205 explicit roles: 207 Target: 208 The entity whose location is desired by the Location Seeker. 209 In many cases the Target will be the human "user" of a Device 211 Cuellar, Morris, Mulligan Expires Nov 2002 4 212 or an object such as a vehicle or shipping container to which 213 the device is attached. In some instances the target will be 214 the device itself. 216 Device: 217 The technical device the location of which is tracked as a 218 proxy for the location of a Target. A Device might, for 219 example, be a Global Positioning Satellite (GPS) receiver, a 220 laptop equipped with a wireless access device, or a 221 transmitter that emits a signal that can be tracked or 222 located. In some situations there may be no Device, in the 223 sense of this definition, but for instance a user is entering 224 the location information manually. 226 Rule-Maker: 227 The individual or entity who has the authorization to set the 228 applicable privacy rules, collectively known also as the 229 policy. In some cases this is the user who is in possession 230 of the Device, but is some cases it is not. For example, 231 parents may control what happens to the location information 232 derived from their children's cell phones. The Rule-Maker is 233 often, but not always, the "owner" of the Device used to track 234 location. For example, a company may own and provide a cell 235 phone to an employee but permit him/her to set the privacy 236 rules. Other proposed names are "Owner (of the privacy 237 rights)" or "policy maker" 239 Unintended Target: 240 A person or object tracked by proximity to the Target. This 241 special case most frequently occurs if the target is not a 242 person. For example, the Target may be a rental car equipped 243 with a GPS device, used to track car inventory. The rental 244 company may not care about the driver's location, but the 245 driver's privacy is implicitly affected. Working group 246 protocols may or may not protect or affect the privacy of 247 Unintended Targets, but the impact on Unintended Targets 248 should be acknowledged. 250 Data Transporter (�DT�): 251 An entity or networking that receives and forwards data 252 without processing or altering it. A Data Transporter could 253 theoretically be involved in almost any transmission between a 254 Device and a Location Processor, a Location Processor and a 255 second Location Processor, or a Location Processor and a 256 Location Seeker. Some location tracking scenarios may not 257 involve a Data Transporter. 259 Location Seeker (�LS�) 260 An individual or entity who seeks to receive location data 261 about a Target. 263 Cuellar, Morris, Mulligan Expires Nov 2002 5 264 Computational Location Server (�CLServ�) 265 A Device or entity that computes or processes raw data to 266 compute or derive location data, or processes location data to 267 transform or refine the data into new location data. 268 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. 275 Rule Repository (�RR�) 276 A repository that contains private or public policies, 277 identifiers, and perhaps also requests are stored. 279 Attributes 281 An entity that who seeks to access the location data is a Location 282 Seeker and may act in one or more of the following roles: as the 283 Location Sighter (Location Data Source), as a Location Server, or as 284 an Ultimate Location Recipient. 286 Location Sighter (LoSi), or Location Data Source 287 The original source of the sighting of a target in a given 288 transaction. 290 Location Server (LS), or Intermediate Location Recipient: 291 A Device or entity that provides access to raw data or 292 location data after processing or altering it or not. Some 293 location tracking scenarios may not involve a Location Server. 295 Ultimate Location Recipient (ULR): 296 An individual or entity who receives location data about a 297 Target and does not transmit the location information or 298 information based on the Target's location (such as driving 299 directions to or from the target) to another party distinct 300 from the target or the Rule-Maker. 302 A data transporter may be an 304 Initial Access Provider (�IAP�): 305 A data transporter that provides the initial network access or 306 other data communications services essential for the operation 307 of communications functions of the Device or computer 308 equipment in which the Device operates. Most commonly, an IAP 309 will be a wireless carrier, an Internet Service Provider, or 310 an internal corporate network, used by the Target and the 311 Target's Device and over which location services are provided 312 or utilized. In many cases the IAP is the location sighter. 313 In some instances the IAP�s infrastructure may be owned and 315 Cuellar, Morris, Mulligan Expires Nov 2002 6 316 controlled by another party who should be identified. Some 317 location tracking scenarios may not involve any IAP. 319 The rules of the Target may be accessible to a Location Server in the 320 form of Private or Public Rules Repositories: 322 Public Policy Repository: 323 A repository where signed policies, identifiers, and perhaps 324 also requests are stored. 326 Private Policy Repository: 327 A repository of authenticated policies, identifiers, and 328 perhaps also requests are stored, for the private use of one 329 Location Server. 331 +------------------+-----+------+--------+---------+----------+ 332 | | IAP | ULR | Public | Private | Location | 333 | | | | RR | RR | Sighter | 334 +------------------+-----+------+--------+---------+----------+ 335 |Target | | | | | x | 336 +------------------+-----+------+--------+---------+----------+ 337 |Device | | | | | x | 338 +------------------+-----+------+--------+---------+----------+ 339 |Rule Maker | x | | | | x | 340 +------------------+-----+------+--------+---------+----------+ 341 |Unintended Target | | | | | | 342 +------------------+-----+------+--------+---------+----------+ 343 |Data Transporter | x | | | | x | 344 +------------------+-----+------+--------+---------+----------+ 345 |Location Seeker | x | x | | | | 346 +------------------+-----+------+--------+---------+----------+ 347 |Location Server | x | | | | x | 348 +------------------+-----+------+--------+---------+----------+ 349 |Rule Repository | | | x | x | | 350 +------------------+-----+------+--------+---------+----------+ 352 3.2. Data 354 The main data used by the protocol is the Location Object. It 355 contains the "sighting" information (the pair identity and location) 356 and some other information to be determined, e.g. time information, 357 some types of policies, authenticators, etc. (If no time information 358 is included, this implicitly means "at the current time" or "at a 359 very recent time".) 361 Sighting: the location information for a target. This is the main 362 private data accessed by Location Servers and/or Ultimate 363 Location Recipients. This sighting information is probably 365 Cuellar, Morris, Mulligan Expires Nov 2002 7 366 included in the Location Object. Abstractly, it consists of 367 two separate data fields: 369 (Sighting-Identifier, Location) 371 Sighting-Identifier is the identifier assigned to a device 372 being sighted, and Location is the current position of a 373 device being sighted. 375 Not all entities have access to exactly the same piece of 376 sighting information. The sighting may be transformed to a 377 new sighting pair: 379 (Sighting-Identifier-1, Location-1) 381 before it is provided by the Location Data Source or the 382 Location Server to another Location Recipient. 384 Policy: 385 A set of rules that regulate an entity's activities with 386 respect to location information, including the collection, 387 use, disclosure, and retention of location information. In 388 particular, the policy describes how location information may 389 be used by an entity and which transformed location 390 information may be released to which entities under which 391 conditions. Policies contain "rules" or "assertions". 392 Policies must be obeyed; they are not of advisory character. 393 To make this more explicit, the term "rules" is also used 394 instead of "policy". 396 Data attributes: 397 Filtered: 398 Location information that has been computationally modified. 400 3.3. Identification, Authentication, and Authorization 402 This subsection introduces some terms to be used later in the 403 Requirements Section. 405 Entity-Identifier: The names used by the entities of the protocol 406 to identify, authenticate or authorize themselves to other 407 entities. Policies also use entity-identifiers to express 408 which Location Seekers may receive which transformed sighting 409 information. 411 The next type of identifier may not be used as an Entity-Identifier, 412 since it can be shared by several, perhaps many, different entities: 414 Role identifier 415 ("administrator", "member-of-club-A", etc.) The meaning of the 416 role may be context dependent. 418 Cuellar, Morris, Mulligan Expires Nov 2002 8 419 People use the word authentication with different meanings. Some 420 people insist that authentication associates an entity with a more or 421 less well-known identity. This basically means that if A 422 authenticates another entity as being "B", then the label "B" has 423 also a meaning for many entities different from A. In this case, the 424 label "B" is called a publicly known identifier, and the 425 authentication is "explicit": 427 Explicit Authentication 428 The act of verifying a claimed static identity easily linked 429 back to the real identity of the user, in the form of a pre- 430 existing label from a predefined name space, as the sole 431 originator of a message (message authentication) or as the 432 end-point of a channel (entity authentication). 434 Authorization 435 The act of determining if a particular right, such as access 436 to some resource, can be granted to the presenter of a 437 particular credential. 439 Depending on the type of credential, authorization may imply 440 Explicit Authentication or not. 442 3.4. Data Flows 444 Figure 1 presents the entities of a "typical" protocol setting, using 445 the Location Object and the data flows between those entities. Not 446 all steps discussed here necessarily occur in every scenario. The 447 data flows may be one-step message exchanges, or multi-step sub- 448 protocols and the actual transport of the Location Object may be done 449 via some other transport entities not included in the diagram. The 450 data flows to be considered by the geopriv WG, in the sense that WG 451 will assess their authentication, authorization and privacy 452 requirements, are the following. They are shown in Figure 1 by 453 normal arrows ("--->") 455 LI (Location Information): 456 the location data source sends the "full", raw location 457 information to the location server. 459 FLI (Filtered Location Information): 460 The location server sends filtered location information to the 461 Location Recipient. The information is filtered in the sense 462 that in general not the original information is being 463 delivered, but for instance a less precise version of the 464 information. 466 There is no technical reason for distinguishing Location Information 467 from Filtered Location Information; it is just a way of insisting 468 that the information sent by the location server is (or could be) 469 different from the information he has received. 471 Cuellar, Morris, Mulligan Expires Nov 2002 9 472 Pol (Policy): 473 The Rule-Maker(or in particular, the target itself) sends a 474 Policy to the location server. 476 PolInfo (Policy Information): 477 the server informs the Location Seeker which data type(s) of 478 filtered location information are available to him for a given 479 target. This mechanism must be able to be invoked by the 480 Location Seeker before he sends an LRequest. 482 LRequest (Location Information Request): 483 the Location Seeker requests location information for a 484 target, a given class of targets, or for targets with a 485 particular set of attributes. In this request, the Location 486 Seeker may select which location information data type it 487 prefers. The Location Seeker can also specify the need for 488 periodic location information updates. 490 +---------+ Locate +-----------+ 491 | Location|<************| Location | SPol +------------+ 492 | Data | LI | Server + |<*************| Public | 493 | Source |------------>| Private | * | Policy | 494 | + IAP | | Repository|<---\ * | Repository | 495 +---------+ +-----------+ | * +------------+ 496 ^ | | | * ^ 497 LRequest| |FLI |PolInfo | * * SPol 498 | V V | * * 499 +----------+ +-----------+ | * * 500 | Target | | Location |<**+****/ +----------+ 501 | or |<***********>| Server + | | | | 502 |Rule-Maker| Service | Private | | <-----------|Rule-Maker| 503 +----------+ | Repository|<--/ Pol | | 504 ^ +-----------+ +----------+ 505 * ^ | | 506 * LRequest| |FLI |PolInfo 507 * | V V 508 * +----------+ 509 * | Ultimate | 510 ******************>| Location | 511 Service | Recipient| 512 +----------+ 514 Figure 1: The Entities and Data Flows 516 The following Data Flows MAY be outside of the scope of the geopriv 517 WG, but should be mentioned for understandability. They are shown in 518 Figure 1 as while starred arrows ("***>"). 520 Cuellar, Morris, Mulligan Expires Nov 2002 10 521 Service: (Service Information, Negotiation and Delivery): 522 The target (or the Rule-Maker) and the client exchange 523 information about the service and negotiate it. The client 524 provides service delivery to the target and accounting or 525 billing date, as necessary. 527 SPol (Signed Policy): 528 As an alternative to Pol, the Rule-Maker may write a policy 529 and place it in the Open Repository. The entities access the 530 repository via SPol. 532 Locate: 533 Request to locate the target. When a Location Server receives 534 an LRequest for a target for which has no current location 535 information, the server may send this "Locate" request to the 536 Location Data Source. 538 3.4.1. Relationship framework 540 Location information can be used in very different environments. In 541 some cases the participants will have longstanding relationships 542 while in others participants may have discrete interactions. 544 The different relationships raise different concerns for the 545 implementation of privacy rules, including the need to communicate 546 privacy instructions. It is important that the Geopriv specification 547 acknowledge the varied relationships between parties to location 548 exchanges and set out a privacy framework suitable for each. A public 549 rule repository for example seems to be superfluous in a trusted 550 environment where more efficient methods of addressing privacy issues 551 likely exist. We propose the following attributes as modifiers to a 552 given data flow: 554 Trusted: 555 The data flow is governed by a contract that protects location 556 privacy. 558 Non-trusted: 559 The data flow is not governed by a contract that protects 560 location privacy. 562 3.4.2. Scenarios of Data Flow 564 In this subsection we introduce two short scenarios to illustrate how 565 these terms and attributes describe location information 566 transactions. 568 SCENARIO 1: GPS Device with Internal Computing Power: Closed System 570 In this example, the target wishes to know his/her location using 571 Global Positioning System (GPS) and the device is capable of 572 independently processing the raw data to determine its location. The 574 Cuellar, Morris, Mulligan Expires Nov 2002 11 575 location is derived as follows: the device receives transmissions 576 from the GPS satellites, internally computes and displays location. 577 This is a closed system. For the purpose of this and subsequent 578 examples, it is assumed that the GPS satellite broadcasts 579 information, and has no capacity to record the identity or 580 whereabouts of devices using the signal. 582 GPS Satellite 583 | 584 | 585 | 586 | 587 V GPS Device 588 -------------------------------------------------- 589 / \ 590 | Data ----- Location ----- Location | 591 | Transporter Server Storage | 592 \ | / 593 -------------------------------------------|------ 594 | 595 ------------|------ 596 / V \ 597 / Target Location \ 598 | Seeker | 599 | | 600 \ Rule-Maker / 601 \ / 602 ------------------- 604 In this scenario the GPS device is both the IAP and the LoSi. The 605 interaction occurs in a Trusted environment because it occurs in the 606 rulemaker�s device. 608 SCENARIO 2: Cell Phone Roaming: Cell Phone Company Outsourced 609 Billing and IT 611 In this example, a cell phone is used outside its home service area 612 (roaming). Also, the cell phone service provider (cell phone Corp 2) 613 outsourced the billing of cell phone usage. The cell phone is not 614 GPS-enabled. Location is derived by the cell phone network in which 615 the target and device are roaming. When the target wishes to use the 616 cell phone, cell phone Corp 1 (IAP) provides the roaming service for 617 the target, which sends the raw data about usage (e.g. duration of 618 call, location � roaming network, etc.) to cell phone Corp 2, the 619 home service provider. Cell phone Corp 2 submits the raw data to the 620 billing company which processes the raw data for the billing 621 statements. Finally, the raw data is sent to a data warehouse where 622 the raw data is stored in a location server (e.g. computer server). 624 Cuellar, Morris, Mulligan Expires Nov 2002 12 625 Cell Phone Corp 1 Cell Phone Corp 2 626 ----------------- ----------------- 627 Sighting / \ Sighting / \ 628 Device --- | Data Transporter| --------- | Data Transporter | 629 \ / \ / 630 ----------------- / ----------------- 631 Target / | 632 / sighting| 633 / | 634 ----------- | 635 / V 636 ------------ / ---------- 637 / \ / / \ 638 / Location \ / | Location | 639 | Storage | Location Info | Storage | 640 | |<----------------- | | 641 | Location | | Location | 642 | Seeker | | Seeker | 643 \ / \ / 644 ------------- ---------- 646 Here cell phone corp 1 is the IAP and the LoSi. Cell phone corp 1 647 could be Non-trusted (the rulemaker does not have a contract 648 protecting location information with corp 1 and there is no 649 contractual relationship with privacy provisions between corp 1 and 650 corp 2) or Trusted (contract with privacy protections between cell 651 phone corp 2 and corp 1). Cell phone corp 2 is Trusted. 653 3.5. Further explanations 655 662 3.5.1. Location Data Types 664 Two apparently different data types may contain the same information 665 if it is possible to transform one data type into the other and vice- 666 versa without information loss. 668 One location data type DT1 may contain more location information than 669 another DT2 in at least two different senses: 671 - DT1 may have the same dimensions as DT2 has, plus some extra 672 ones. (For instance, DT1 contains velocity, while DT2 does 673 not). 675 Cuellar, Morris, Mulligan Expires Nov 2002 13 676 - DT1 may be more accurate than DT2. 678 In general, if DT1 has more information than DT2, then there is one a 679 function that "translates correctly" from DT1 to DT2. There are 680 other types of transformations that introduce errors (obfuscation: 681 intentionally make the location values less accurate by adding 682 randomness). During a transformation, information can be lost, but 683 not gained. Of course, a transformation that merges information from 684 several sources clearly increases the information of each one. Thus 685 a transformation is a filtering of information. For instance there 686 are transformation functions from both data types "(latitude, 687 longitude, altitude)" and "(country, state, province, city)" to the 688 data types "(country, state)" and "time zone", but not vice-versa. 690 Notice that if the space regions determined by different location 691 values of DT2 do not overlap, then there is at most one 692 transformation from DT1 to DT2. If the space regions of DT2 overlap, 693 then usually there is some choice, which can be given by a (pseudo-) 694 random function. 696 If DT1 does not have more information than DT2, then there is no 697 function that "translates correctly" from DT1 to DT2. In other 698 words: there are many functions that translate from DT1 to DT2, but 699 all introduce some degree of error. We believe that this kind of 700 functions should be avoided. 702 3.5.2. Public Global Identities 704 If A has some information about a public global identifier "ID" and A 705 discloses this information to B, then B may associate this 706 information with the same entity as A did. In this way, B may 707 accumulate information about the entity labeled by "ID". 709 A public identity is a well-known label that identifies an entity for 710 a (rather large) group of entities. 712 A public identity may be the subscription identity at the home domain 713 (if applicable), a well-known identity (name, address or Tel Number), 714 etc. 716 An entity may regard the disclosure of his public identity (in 717 connection with some activity of him, his location or other 718 attribute) as a violation of his privacy right. 720 3.5.3. Authorization without Explicit Authentication 722 In order to remain anonymous, an entity may use private identifiers. 723 Private identifiers convey less information than public identities, 724 because they are meaningful to a smaller number of entities and in 725 use for a shorter duration. Thus if A discloses a private identifier 727 Cuellar, Morris, Mulligan Expires Nov 2002 14 728 to B, B is less likely to associate this information with a known 729 individual or entity than if a public identifier was disclosed. 731 Short-lived identifier 732 an identifier that is used only for one or a limited number of 733 "sessions". 735 Short-lived identifiers may be used to anonymously authenticate 736 entities in some settings. 738 In many situations, including pre-paid services, token-based or role- 739 based authorizations, unauthenticated key agreement, and purpose- 740 based identifiers, there is no need for explicit authentication. 742 Using weaker forms of authentication, the communication partner may 743 still want to make sure that he is communicating to the same entity 744 during the whole session, or that he is communicating with an 745 authorized entity. Thus message authentication codes are used, based 746 on "unauthenticated keys". 748 Authorization credentials may be used in the same way as 749 authentication credentials to secure a key agreement in the following 750 sense: one party is assured that no other party aside from the owner 751 of the authorization credentials (and possibly additional identified 752 trusted parties) may gain access to the agreed secret key. The 753 resulting keys are called authorized keys. Those keys may be used 754 for message authentication, without implying an explicit 755 authentication. 757 In real life this corresponds for instance to the following 758 situation: at a cloakroom a person deposits his coat and receives a 759 credential that he may use later to obtain back the coat. 761 One possible goal of the Rule-Maker is to hide the identity of the 762 Location Recipient to the Location Server. Nevertheless, the 763 Location Server has to be sure that the Rule-Maker has authorized the 764 Recipient to access the location. This is a case of authorization 765 without explicit authentication: the Location Server has to be sure 766 that the Location Recipient is a particular (i.e., authorized) 767 communication partner of the Rule-Maker. 769 This may be done for instance as follows: consider a Location Seeker 770 that obtains a set of "traveller's cheques" from the Rule-Maker. The 771 cheques will be used to "buy" location information from a Location 772 Service. Initially, the Location Seeker signs for a first time the 773 cheques with any "signature" that he wants to use. The Rule-Maker, 774 through his own signature, authorizes the signature of the Location 775 Seeker. When presented to the Location Server, the cheques may be 776 countersigned so that the server is sure that the signer is the same 777 as the one who was authorized by the Rule-Maker. This 778 countersignature does not only authenticate the Location Seeker to 779 the verifier, but also indirectly to the Rule-Maker, when the cheque 781 Cuellar, Morris, Mulligan Expires Nov 2002 15 782 is later presented to him. Incidentally, the Rule-Maker may achieve 783 full information about who has accessed to his location information. 785 To hide the real identity of the Rule-Maker to the Location Server, 786 the following dual solution can be used. The Rule-Maker buys (say, 787 using e-cash) a service from a Location Seeker (e.g. a navigation 788 service). During this transaction, the Location Seeker and the Rule- 789 Maker agree on one or several pseudonyms and a set of "traveller's 790 cheques" that the target may use later to authenticate himself to the 791 server and thus indirectly also to the Location Seeker. 792 Since e-cash protocols may be also anonymous, this may be used to 793 hide simultaneously, 795 o the identity of the target from the Location Server, 796 o the identity of the Location Seeker from the Location 797 Server, 798 o the identity of the target from the Location Seeker. 800 But notice that the Location Data Source is in general not able to 801 localize the target based on some short-lived identifier. In this 802 scenario, the Location Data Source should be a Location Server, a 803 different one from the one from whom the identity of the target is to 804 be hidden. 806 4. Requirements 808 4.1. Protocols 810 Req. 1. The geopriv protocol MUST be an embedded protocol: it 811 defines a Location Object, together with the security 812 mechanisms used to secure it. The security mechanisms are 813 of two types: on one hand the Location Object as such is 814 secured, using cryptographic checksums or encryption as 815 part of the Location Object itself, and on the other hand 816 security mechanisms may be provided by the embedding 817 transport protocol that uses the Location Object. If 818 possible, security mechanisms on the Location Object itself 819 are to be preferred. 821 We refer to the embedded protocol also as the geopriv protocol and to 822 the combination of both the embedded protocol and the transport 823 protocol as the combined protocol. 825 4.2. Policy based Location Data transfer 827 Req. 2. The decision of a Location Server to provide a Location 828 Seeker access to location information is based on user- 829 defined privacy policies. 831 Req. 3. The Location Data Source may be unaware of the full 832 policies defined by the Rule-Maker, but in that case it 834 Cuellar, Morris, Mulligan Expires Nov 2002 16 835 will have to obey another set of "generic" policies, 836 consented to by the Rule-Maker, to transfer Location Data 837 (raw or not) to another entity. 839 Req. 4. An Ultimate Location Recipient does not need to be aware 840 of the full policies defined by the Rule-Maker, but it will 841 obey a set of policies regarding the use and retention of 842 the location information. 844 4.3. Location Object, Location Data 846 Req. 5. The embedded protocol MUST define one Location Object 847 (both in syntax and semantics) that must be supported by 848 all geopriv entities. Some fields of the Location Object 849 MAY be opaque to the embedded protocol. 851 Req. 6. The Location Object MAY define at least one Location 852 Data Type (both syntax and semantics) that must be 853 supported by all geopriv entities, or the Location Data 854 field(s) of the Location Object MAY be opaque. The 855 Location Object MAY define at least one Location Data Type 857 When transmitting location information, (LI and FLI in Figure 1), the 858 sender and the receiver must agree on the data type of the location 859 information. The combined protocol may specify that the data type 860 information is part of the Location Object or that sender and 861 receiver have agreed on it before the actual data transfer. Thus 863 Req. 7. The Location Object MAY contain a field for the data 864 type of the Location Data. This field MAY also be opaque. 866 4.4. Policies 868 Req. 8. The Location Object MAY contain a field for policies 869 that may be passed to the location server or may be stored 870 in a public (open) repository. 872 Req. 9. The Location Object MAY contain a field for identifiers 873 that may be passed to the location server or may be stored 874 in a public (open) repository. 876 Req. 10. The Location Object MAY contain a field for requests 877 from the clients. 879 Req. 11. The combined protocol MAY specify a policy language. 880 This policy language MAY be an existing one, an adaptation 881 of an existing one or a new policy language. 883 If specified, the policy language MUST be strong enough to 884 express policies of the form: a group G of clients are 885 allowed to know a certain transformation A of the location 887 Cuellar, Morris, Mulligan Expires Nov 2002 17 888 L of a target together with a given identifier I of the 889 target for a given purpose, for a given period of time. 891 If specified, the policy language MUST be strong enough to 892 express conditions on G and A as follows: 893 G, the group of clients SHOULD be characterized by the 894 possession of (identifiers, credentials) with a certain 895 syntactic property. 896 A, the transformation function MAY be specified by data 897 type of the expected filtered location information. 899 Within those constraints, the policy language SHOULD be as 900 simple as possible, or it SHOULD be an existing policy 901 language. 903 4.5. Identity Protection 905 Req. 12. When a location server accepts a policy that uses a 906 role identifier, the Rule-Maker MUST prove the ownership of 907 the claimed role identifier. This is a property of the 908 combined protocol. 910 Req. 13. The combined protocol MUST be able to hide the real 911 identity and static identifiers association with the real 912 identity of the Rule-Maker, the target, and the device from 913 the Ultimate Location Recipient. 915 This may be easily done using short-lived or role identifiers. 917 Req. 14. The combined protocol MUST be able to hide the real 918 identity of the Location Recipient to the Location Server. 920 925 Req. 15. The combined protocol MUST be able to hide the real 926 identity of the Rule-Maker to a Location Seeker, including 927 a Location Server. 929 4.6. Authentication Requirements 931 Req. 16. The combined protocol MUST allow different 932 authentication schemes. The combined protocol MUST 933 guarantee that appropriate keys (shared or asymmetric) are 934 generated and available to secure the Location Object 935 within the embedded protocol. 937 Req. 17. The combined protocol MUST allow authorization without 938 explicit authentication. 940 Cuellar, Morris, Mulligan Expires Nov 2002 18 941 4.7. Actions to be secured 943 Req. 18. The embedded protocol MUST be able to secure the 944 Location Object for the following message flows (mutual 945 end-point authentication, data object integrity, data 946 object confidentiality, replay protection, in the absence 947 of a time parameter): LI, Pol, LIF, LRequest, and PolInfo. 949 Req. 19. The embedded protocol MUST specify a minimum mandatory 950 to implement Location Object security including mandatory 951 to implement crypto transforms. 953 Req. 20. The embedding protocol MAY provide extra security for 954 these flows (hop-by-hop or end-to-end). 956 In full details, these requirements have many consequences: the 957 communicating parties MUST have security relationships between them, 958 allowing them to construct secure channels between them. This may 959 imply that some scenarios should not be permitted in general. The 960 Rule-Maker MAY choose to use the security provided by the embedded or 961 by the embedding protocol, or none. 963 Req. 21. When a Location Server accepts a policy from the Rule- 964 Maker, the target MUST prove to the combined protocol that 965 he owns the claimed group or role identifier that should be 966 passed to the Location Recipient. 968 (For instance, if a Target wants the role identifier "medical doctor" 969 to be passed to a Location Recipient, the Target must prove the 970 claims to be a medical doctor.) 972 Req. 22. The "generic" policies (as opposed to the policies 973 created by the Rule-Maker) used by the Location Data 974 Source, by the Ultimate Location Recipients and by the 975 Location Server of some special scenarios to be discussed 976 yet MUST be made explicit. 978 5. Security Considerations 980 The purpose of the geopriv protocol is to allow a policy-controlled 981 disclosure of location information for location services. Only the 982 information carried within the Location Object is secured in a way 983 compliant with the privacy and security policies of the target. This 984 does not mean that geopriv secures the target against general traffic 985 analysis attacks or other forms of privacy violations. 987 The Location Server is assumed to be trustworthy. 989 6. References 991 Cuellar, Morris, Mulligan Expires Nov 2002 19 993 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 994 Levels", BCP 14, RFC 2119, March 1997. 996 7. Author's Addresses 998 Jorge R Cuellar 999 Siemens AG 1000 Corporate Technology 1001 CT IC 3 1002 81730 Munich Email: Jorge.Cuellar@mchp.siemens.de 1003 Germany 1005 John B. Morris, Jr. 1006 Director, Internet Standards, Technology & Policy Project 1007 Center for Democracy and Technology 1008 1634 I Street NW, Suite 1100 1009 Washington, DC 20006 Email: jmorris@cdt.org 1010 USA http://www.cdt.org 1012 Deirdre K. Mulligan 1013 Samuelson Law, Technology and Public Policy Clinic 1014 Boalt Hall School of Law 1015 University of California 1016 Berkeley, CA 94720-7 Email: dmulligan@law.berkeley.edu 1018 8. Full Copyright Statement 1020 Copyright (C) The Internet Society (date). All Rights Reserved. 1022 This document and translations of it may be copied and furnished to 1023 others, and derivative works that comment on or otherwise explain it 1024 or assist in its implementation may be prepared, copied, published 1025 and distributed, in whole or in part, without restriction of any 1026 kind, provided that the above copyright notice and this paragraph are 1027 included on all such copies and derivative works. However, this 1028 document itself may not be modified in any way, such as by removing 1029 the copyright notice or references to the Internet Society or other 1030 Internet organizations, except as needed for the purpose of 1031 developing Internet standards in which case the procedures for 1032 copyrights defined in the Internet Standards process must be 1033 followed, or as required to translate it into languages other than 1034 English. 1036 The limited permissions granted above are perpetual and will not be 1037 revoked by the Internet Society or its successors or assigns. 1039 This document and the information contained herein is provided on an 1040 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1041 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1042 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1043 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1044 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1046 Cuellar, Morris, Mulligan Expires Nov 2002 20