idnits 2.17.1 draft-danley-geopriv-threat-analysis-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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 8 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 117 has weird spacing: '...threats to LI...' == Line 515 has weird spacing: '...ty, and give ...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 28, 2002) is 7850 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-04) exists of draft-ietf-geopriv-reqs-01 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GEOPRIV WG M. Danley 3 Internet-Draft D. Mulligan 4 Expires: April 28, 2003 UC Berkeley 5 J. Morris 6 CDT 7 J. Peterson 8 NeuStar 9 October 28, 2002 11 Threat Analysis of the GEOPRIV Protocol 12 draft-danley-geopriv-threat-analysis-00 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at http:// 30 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 This Internet-Draft will expire on April 28, 2003. 37 Copyright Notice 39 Copyright (C) The Internet Society (2002). All Rights Reserved. 41 Abstract 43 This document provides some analysis of threats against the GEOPRIV 44 protocol architecture. It focuses on protocol threats, threats that 45 result from the storage of data by entities in the architecture, and 46 threats posed by the abuse of informaion yielded by geopriv. Some 47 security properties that meet these threats are enumerated as a 48 reference for GEOPRIV requirements. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Habitat of the GEOPRIV Protocol . . . . . . . . . . . . . . 3 54 3. Motivations of Attackers of GEOPRIV . . . . . . . . . . . . 4 55 4. Representative Attacks on GEOPRIV . . . . . . . . . . . . . 5 56 4.1 Protocol Attacks . . . . . . . . . . . . . . . . . . . . . . 5 57 4.1.1 Eavesdropping and/or Interception . . . . . . . . . . . . . 5 58 4.1.2 Identity Spoofing . . . . . . . . . . . . . . . . . . . . . 6 59 4.1.3 Information Gathering . . . . . . . . . . . . . . . . . . . 7 60 4.1.4 Denial of Service . . . . . . . . . . . . . . . . . . . . . 8 61 4.2 Host Attacks . . . . . . . . . . . . . . . . . . . . . . . . 9 62 4.2.1 Data Stored at Servers . . . . . . . . . . . . . . . . . . . 9 63 4.2.2 Data Stored in Devices . . . . . . . . . . . . . . . . . . . 9 64 4.2.3 Data Stored with the Ultimate Location Recipient . . . . . . 10 65 4.2.4 Information Contained in Policies . . . . . . . . . . . . . 10 66 4.3 Usage Attacks . . . . . . . . . . . . . . . . . . . . . . . 11 67 4.3.1 Threats Posed by Overcollection . . . . . . . . . . . . . . 11 68 5. Countermeasures for Usage Violations . . . . . . . . . . . . 11 69 5.1 Fair Information Practices . . . . . . . . . . . . . . . . . 11 70 6. Security Properties of the GEOPRIV Protocol . . . . . . . . 13 71 6.1 Policies as Counter-Measures . . . . . . . . . . . . . . . . 13 72 6.1.1 Rule Maker Should Define Policies . . . . . . . . . . . . . 13 73 6.1.2 GEOPRIV Should Have Default Policies . . . . . . . . . . . . 13 74 6.1.3 Location Recipient Should Not Be Aware of All Policies . . . 14 75 6.1.4 Certain Policies Should Travel With the LO . . . . . . . . . 14 76 6.2 Protection of Identities . . . . . . . . . . . . . . . . . . 14 77 6.2.1 Short-Lived Identifiers May Protect Target's Identity . . . 15 78 6.2.2 Unlinked Pseudonyms May Protect the Location Recipients' 79 Identity . . . . . . . . . . . . . . . . . . . . . . . . . . 15 80 6.3 Security During Transmission of Data . . . . . . . . . . . . 15 81 6.3.1 Policies May Disallow a Certain Frequency of Requests . . . 15 82 6.3.2 Mutual End-Point Authentication . . . . . . . . . . . . . . 15 83 6.3.3 Data Object Integrity & Confidentiality . . . . . . . . . . 16 84 6.3.4 Replay Protection . . . . . . . . . . . . . . . . . . . . . 16 85 7. Security Considerations . . . . . . . . . . . . . . . . . . 16 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16 87 Informative References . . . . . . . . . . . . . . . . . . . 16 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16 89 Full Copyright Statement . . . . . . . . . . . . . . . . . . 18 91 1. Introduction 93 The proliferation of location-based services that integrate tracking 94 and navigation capabilities gives rise to significant privacy and 95 security concerns. Such services allow users to identify their own 96 location as well as determine the location of others. In certain 97 peer-to-peer exchanges, device identification takes place 98 automatically within a defined location perimeter, informing peer 99 devices of a given user's identity and availability. Additionally, 100 records of location exchanges can reveal significant information 101 about the habits, whereabouts, and associations of individual users. 103 The GEOPRIV requirements allow the Location Object (LO) to support a 104 wide variety of uses of Location Information (LI); the GEOPRIV object 105 itself is intended to be technology-neutral, allowing a wide variety 106 of devices to provide LI in the form of LO. GEOPRIV also requires 107 that many classes of Ultimate Location Recipients (ULRs) be capable 108 of requesting LI from a Target (in some cases directly and in others 109 through a Location Server). The GEOPRIV requirements account for 110 circumstances in which the Target has a contractual relationship with 111 the entities that transmit and receive LI and those in which no 112 contract exists. Requiring the GEOPRIV object to support any 113 technology, Target-ULR relationship, or underlying legal framework 114 governing LI, complicates the protection of privacy and the security 115 of LI. 117 This document analyzes threats to LI in transmission and storage. 118 The actions possible due to the compromises of LI through these 119 threats vary depending on the circumstances. A server selling 120 location information to potential marketers poses a distinct (and 121 lower) risk from an outside individual intercepting a Target's 122 present location to commit a physical attack. It is important that 123 these threats are considered as we work towards defining the LO. 125 Some of the threats discussed in this document may be outside of the 126 scope of the GEOPRIV charter, e.g., threats arising from failure to 127 meet contractual obligations. Nevertheless, a comprehensive 128 discussion of threats is necessary to identify desirable security 129 properties and counter-measures that will improve the security of the 130 LO, and thereby better protect LI. 132 2. Habitat of the GEOPRIV Protocol 134 The GEOPRIV architecture will be deployed in the open Internet - in a 135 security environment in which potential attackers can inspect packets 136 on the wire, spoof Internet addresses, and launch large-scale denial- 137 of-service attacks. In some architectures, portions of GEOPRIV 138 traffic (especially traffic between the Location Sighter and an 139 initial Location Server) may occur over managed networks that do not 140 interface with the public Internet. 142 The protocol itself assumes interaction between a number of logical 143 roles, many of which will commonly be implemented in distributed 144 network devices (for a full list of GEOPRIV roles and entities, see 145 [1]). The endpoints of the common GEOPRIV transactions are the 146 Location Sighter (the source of location information from the 147 perspective of the network) and the Ultimate Location Recipient (ULR) 148 (the destination of data), which can be viewed as a special case of a 149 Location Seeker. Both a Location Sighter and a Location Seeker may 150 have a relationship with a Location Server; the Location Sighter 151 publishes data to a Location Server (which may provide a grooming/ 152 filtration function for location information), and the Location 153 Seeker requests and receives information from the Location Server. 154 This provides two points where GEOPRIV information could require 155 protection across the wire. Policies can also be provisioned in the 156 Location Server by a Rule-Maker over the network; this provides 157 another point where the architecture requires security. 159 It is important to note that Location Sighters, and to a lesser 160 degree Location Seekers, may be implemented on low-cost devices for 161 which strong cryptographic security is currently prohibitively 162 expensive computationally. 164 3. Motivations of Attackers of GEOPRIV 166 The most obvious motivation for an attacker of GEOPRIV is to learn 167 the location of a subject who wishes to keep their position private, 168 or even for authorized Seekers to ascertain location information with 169 a greater degree of precision than the Rule-Maker desires. However, 170 there are several other potential motivations that are causes for 171 concern. Attackers might also wish to prevent a target's location 172 from being distributed, or to modify or corrupt location information 173 in order to misrepresent the location of the target, or to redirect 174 the target's location information to a third party that is not 175 authorized to know this information. Attackers may want to identify 176 the associates of a target, or learn the habit or routines of a 177 target. Attackers might want to learn the identity of all of the 178 parties that are in a certain location. Finally, some attackers may 179 simply want to halt the operation of the entire system through 180 denial-of-service attacks. 182 There is also a class of attackers who may be authorized as 183 legitimate participants in a GEOPRIV protocol exchange but who abuse 184 location information. This includes the distribution or accumulation 185 of location information outside the parameters of agreements between 186 the principals, possibly for commercial purposes or as an act of 187 unlawful surveillance. 189 4. Representative Attacks on GEOPRIV 191 4.1 Protocol Attacks 193 4.1.1 Eavesdropping and/or Interception 195 Imagine a location-based computer game, based on traditional hide- 196 and-seek, in which a centralized server provides hints as to the 197 location of the 'hider' to a set of 'seekers'. Seekers are given 198 access to very coarse location data, whereas a single referee is 199 given access to unfiltered and precise location information of the 200 hider. Each seeker has a wireless device (in the GEOPRIV 201 architecture, a Location Seeker) that feeds them coarse positioning 202 data from the Location Server. The hider carries a device (a 203 Location Sighter implemented by embedded GPS) that transmits location 204 information to the Location Server. 206 If one of the seekers wished to cheat by attacking the GEOPRIV 207 protocol, there are a number of ways they could mount such an attack 208 in order to learn the precise location of the hider. They might 209 eavesdrop on one of two network connections - either the connection 210 between the Location Sighter and the Location Server, or the 211 connection between the Location Server and the referee's Location 212 Seeker (which receives precise information). They might also attempt 213 to impersonate the referee to the Location Server, in order to 214 receive unfiltered Location Information. Alternatively, they could 215 impersonate the Location Server to the Location Sighter carried by 216 the hider, which would also give them access to precise location 217 information. Finally, the cheater could attempt to act as the Rule- 218 Maker, and to insert policies into the Location Server that would 219 enable the cheater's Location Seeker access to uncoarsened location 220 information. 222 From these threats, we can derive a need for several security 223 properties of the architecture. 225 o Confidentiality is required on both the connection between the 226 Location Sighter and the Location Server, as well as the 227 connection between the Location Server and any given Location 228 Seeker. 230 o Location Servers must be capable of authenticating and authorizing 231 Location Seekers to prevent impersonation. 233 o Similarly, Location Sighters must be capable of authenticating and 234 authorizing Location Servers in order to prevent impersonation. 236 o Finally, the Location Server must be able to authenticate Rule- 237 Makers, to make sure that unauthorized parties cannot change 238 rules. 240 4.1.2 Identity Spoofing 242 Consider a case in which the same boss employs two rivals. One goes 243 on a business trip to Cleveland. Both rivals carry devices that are 244 tracked by a Location Sighter (such as cell phones on which the cell 245 carrier can triangulate), and both rivals allow their boss access to 246 their (coarse) location information. The rival that remained home 247 wants to hack the GEOPRIV protocol to make it appear that the 248 traveling rival is actually goofing off in South Beach rather than 249 attending a dull technology conference in Cleveland. How would such 250 an attack be mounted? 252 The attacker might attempt to spoof network traffic from the Location 253 Sighter to the Location Server (especially if, through some other 254 means such as a denial-of-service attack, the Location Sighter became 255 unable to issue its own reports). The goal of the attacker may be to 256 provide falsified location information appropriate for someone in 257 Miami, or perhaps even to replay a genuine location object from a 258 previous visit of the rival to Miami. The attacker might also try to 259 spoof traffic from the Location Server to the boss' Location Seeker. 261 From these threats we can derive a need for several security 262 properties of the architecture. 264 o There is a need for the Location Server to authenticate Location 265 Sighters. 267 o Location Seekers must be capable of authenticating Location 268 Servers. 270 o Location information must be protected from replay attacks. 272 Identity spoofing may create additional threats when the protocol is 273 attacked. In many circumstances, the identity of the Location 274 Requester and the Location Recipient are the basis for controlling 275 whether LI is revealed and, if so, how that LI is filtered. If the 276 identity of those entities is compromised, privacy is threatened. 277 Anyone inside or outside the transaction that is capable of 278 impersonating an authorized entity can gain access to confidential 279 information, or initiate false transmissions in the authorized 280 entity's name. The ability to spoof the identity of the Location 281 Recipient, for example, would create the risk of an unauthorized 282 entity accessing both the identity and the location of the Target at 283 the moment the LO was sent. 285 4.1.3 Information Gathering 287 Eavesdropping and interception can also create traffic analysis 288 threats as the interceptor collects more data over time. Traffic 289 analysis threats generally create the risk that an eavesdropper will 290 be able to determine, from the very fact of the transmission, a 291 relationship between the various entities involved. If an employer 292 requests to send the location of an employee to a customer, an 293 eavesdropper could determine that three entities are somehow 294 interacting with one another. If eavesdropping continues over time, 295 each interaction would involve the employer, employee, and several 296 customers. Such a log of information would reveal that the employer 297 and employee frequently were associated with one another, and would 298 reveal which clients more frequently dealt with the pair. Thus, the 299 traffic analysis threat creates the risk of eavesdroppers determining 300 the Target's associates. 302 Traffic analysis might also allow an eavesdropper to ascertain the 303 identity or characteristics of targets in a particular location. By 304 observing transmissions between Location Sighters in a particular 305 location and Location Servers (perhaps by eavesdropping on a wireless 306 or wireline LAN scoped to the location in question), and then 307 possibly following the data to various Location Recipients, an 308 attacker may be able to learn the associates, including the employer, 309 of targets in that location, and perhaps to extrapolate further 310 identity information. 312 If the eavesdropper is able to intercept not only the LO, but the LI 313 itself, other threats are raised. Let's return to the above example 314 of the employer requesting an employee's location information. In 315 this instance, the interception of one such past transaction may 316 reveal the identities and/or locations of all three parties involved, 317 in addition to revealing the fact of their association. In 318 circumstances where there is a log of this data, however, analysis 319 could reveal any regular route that the employee may travel in 320 visiting customers, a general area that the employee works in, the 321 identities and location of the employee's entire customer base, and 322 information about how the entities relate. 324 Threats based on traffic analysis are difficult to meet with protocol 325 security measures, but they are important to note. 327 From these threats we can derive a need for several security 328 properties of the architecture. 330 o The Rule Maker must be able to define policies regarding the use 331 of their LI. 333 o The connection between the Location Sighter and Location Server, 334 as well as the connection between the Location Server and Location 335 Seeker must remain confidential. 337 o Location Servers and Location Sighters must be capable of 338 authenticating Location Seekers to prevent impersonation. 340 o Location Servers must be able to authenticate Rule Makers to 341 ensure that unauthorized entities cannot change rules. 343 4.1.4 Denial of Service 345 Parties who wish to deprive entire networks of GEOPRIV service, 346 rather than just targeting particular users, would probably focus 347 their efforts on the Location Server. Since in many scenarios the 348 Location Server plays the central role of managing access to location 349 information for many devices, it is in such architectures a natural 350 single point of failure. 352 The GEOPRIV protocol appears to have some opportunities for 353 amplification attacks. When the Location Sighter reports 354 information, the Location Server acts as an exploder, potentially 355 delivering this information to numerous targets. If the Location 356 Sighter were to provide very rapid updates of position (as many as 357 link speed could accommodate, especially in high-bandwidth wireless 358 environments), then were the Location Server to proxy information to 359 Seekers at a similar rate, this could become problematic when large 360 numbers of Seekers are tracking the same user. 362 Also note that most operations associated with the Location Server 363 probably require cryptographic authentication. Cryptographic 364 operations entail a computational expense on the part of the Location 365 Server. This could provide an attractive means for attackers to 366 flood the Location Server with dummied GEOPRIV information that is 367 spoofed to appear to come from a Location Sighter, Location Seeker, 368 or the Rule-Maker. Because the Location Server has to expend 369 resources to verify credentials presented by these GEOPRIV messages, 370 floods of GEOPRIV information could have greater impact than denial- 371 of-service attacks based on generic packet flooding. 373 4.2 Host Attacks 375 4.2.1 Data Stored at Servers 377 LI maintained at a server is subject to many potential risks. First, 378 there may be accidental misuse of LI by the server. Whether by 379 negligence, carelessness, or lack of knowledge, the server may 380 accidentally release LI to the wrong Location Recipients, or fail to 381 properly filter the LI that is sent out. Second, the server may 382 intentionally misuse LI. A server may decide to sell a "profile" it 383 has compiled of a Target or Location Seeker despite provisions to the 384 contrary in the Rule Maker's Policy. Alternatively, an individual 385 working for the server may, for personal gain, misuse access to the 386 server to obtain LI. Third, even with the most secure and trusted 387 server, there is the risk that someone outside the system will hack 388 into it in order to retrieve LI. Last, there is always the potential 389 that someone would use the legal system to subpoena an individual's 390 records from a Server. Such a process would likely result in the 391 revelation of the Target's location information without notice to the 392 Target or the Target's consent. 394 Data stored at the server may reveal the Target's present location if 395 the data is used or intercepted at or near the moment of 396 transmission. If a Target requests a map from their present location 397 to a nearby store, and the server sends that information to the wrong 398 Location Recipient, that Recipient could know the identity of the 399 Target, the Target's current location, and the location where the 400 Target might be headed. 402 Data stored at the Location Server can also create many of the 403 traffic analysis threats discussed in Section 4.1 above. If access 404 is gained not only to the fact of the LO transmission, but also to 405 the LI transmitted, anyone with access to that information can put 406 together a history of where that Target has been, for how long, and 407 with whom. 409 4.2.2 Data Stored in Devices 411 Because GEOPRIV is required to work with any given type of technology 412 or Device, it is difficult to determine the particular threat 413 potential of individual devices. For example, any device that 414 maintains a log of Location Requests sent, or LOs received, would 415 pose a similar threat to the information maintained at a Location 416 Server, discussed above. A court subpoena or warrant for an 417 individual's device could additionally reveal a similar log. 419 Additionally, depending on the device, there is always the potential 420 for data to be compromised in some way. For a Device with a screen, 421 there is always the potential that another individual will have the 422 opportunity to view the Device display without the user's knowledge. 423 A Device that provides verbal feedback (i.e. to give directions to 424 the blind) creates additional potential for LI to be compromised. If 425 the Target is sitting in a public place and requests directions from 426 the Target's home to another location, anyone who can see the Device 427 output may be able to determine the Target's identity, their 428 residence, and possibly the location to which they are headed. 430 In addition, if the device retained location information and the 431 Device were lost or stolen, someone other than the Policy Maker could 432 potentially access information regarding who LI was sent to and when, 433 as well as potentially the location of the Target during each 434 transaction. Such information could enable an entity to determine 435 significant private information based on who the owner of the Device 436 has associated with in the past, as well as each location where the 437 Target has been and for how long. 439 4.2.3 Data Stored with the Ultimate Location Recipient 441 The threats posed here are similar to those discussed above in 442 relation to Location Servers and Devices. The main purpose of 443 separating out threats posed by data stored at the ULR is to show 444 that, depending on the complexity of the transaction and the other 445 entities involved, data storage at various points in the transaction 446 can bring rise to the same types of privacy risks. 448 4.2.4 Information Contained in Policies 450 In many instances, the policies a Rule Maker creates will reveal 451 information either about the Rule Maker or the Target. A rule that 452 degrades all information sent out by approximately 25 miles might 453 tell an interceptor how to determine the Target's true location. A 454 policy that states, "Tell my boss what room I'm in when I'm in the 455 building, but when I'm outside the building between 9 a.m. and 5 456 p.m. tell him I'm in the building," would reveal a lot more 457 information than most employees would desire. Any boss who was the 458 Location Seeker who received LI that specified "in the building" 459 would then realize that the employee was elsewhere. 461 In addition, if an entity had access to a log of data at the Location 462 Server or at a Device, knowledge of the content of Policies would 463 enable a sort of "decoding" of the location information of the device 464 to something more accurate. Thus, my boss could not only tell where 465 I am at this minute, but could tell how many times over the last year 466 I had been outside the building between 9 a.m. and 5 p.m. 468 The policies themselves may also reveal information about the Target. 470 A rule such as the one above would clearly reveal the employment 471 relationship between the two individuals as well as the fact that the 472 employee was hiding something from the employer. 474 In combination with other information the location information may 475 enable the identification of the Target. 477 4.3 Usage Attacks 479 4.3.1 Threats Posed by Overcollection 481 Weak or absent default privacy rules would also compromise LI. 482 Without default policies for LOs, it is likely that a large number of 483 Devices would reveal LI by default. Privacy rules should control the 484 collection, use, disclosure, and retention of Location Information. 485 These rules must comply with fair information practices-these 486 practices are further discussed in Section 5.1. 488 While technically savvy Device users may create privacy rules to 489 protect their LI, many individuals will lack the skill or motivation 490 to do so. Thus, left to their own devices many individuals would 491 likely be left without privacy rules for their LI. This in turn 492 would leave these users' LI entirely vulnerable to various attacks. 493 Default rules are necessary to address this problem. 495 Without default rules, for example, a device might signal out to 496 anyone nearby at regular intervals, respond to anyone nearby who 497 queried it, or send signals out to unknown entities. 499 The lack of a default rule of "Do not re-distribute," would allow the 500 Location Server to pass the Target's location information on to 501 others. Lack of a default rule limiting the retention of LI could 502 increase the risk posed by inappropriate use and access to stored 503 data. 505 While defining default privacy rules is beyond the scope of this 506 document, default rules are necessary to limit the privacy risks 507 posed by the use of services and devices using LI. 509 5. Countermeasures for Usage Violations 511 5.1 Fair Information Practices 513 Principles of fair information practices require entities that handle 514 personal information to meet certain obligations with respect to its 515 collection, use, maintenance and security, and give individuals 516 whose personal information is collected certain due process-like 517 rights in the handling of their information. Fair information 518 practices are designed to prevent specific threats posed by the 519 collection of personal information about individuals. For this 520 reason, fair information practices are "countermeasures" that should 521 be reflected in technical systems that handle personal information 522 and the policies that govern their use. A brief discussion of fair 523 information practices may be beneficial in formulating requirements 524 for the LO. 526 There are seven main principles of fair information practices: 528 1. Openness: The existence of a record-keeping system for personal 529 information must be known, along with a description of the main 530 purpose and uses of the data. Thus any entity that collects LI 531 should inform individuals that this information is being 532 collected and inform them about what the LI is being used for. 533 Openness is designed to prevent the creation of secret systems. 535 2. Individual Participation: Individuals should have a right to view 536 all information collected about them, and to be able to correct 537 or remove data that is not timely, accurate, relevant, or 538 complete. The practice of individual participation acknowledges 539 that sometimes information that is collected may be inaccurate or 540 inappropriate. 542 3. Collection Limitation: Data should be collected by lawful and 543 fair means and should be collected, where appropriate, with the 544 knowledge or consent of the subject. Data collection should be 545 minimized to that which is necessary to support the transaction. 546 Placing limits on collection helps protect individuals from the 547 dangers of overcollection-both in terms of collecting too much 548 information, or of collecting information for too long of a time 549 period. 551 4. Data Quality: Personal data should be relevant to the purposes 552 for which it is collected and used; personal information should 553 be accurate, complete, and timely. The requirement of data 554 quality is designed to prevent particular kinds of harms that can 555 flow from the use (appropriate or inappropriate) of personal 556 information. 558 5. Finality: There should be limits to the use and disclosure of 559 personal data: data should be used only for purposes specified at 560 the time of collection; data should not be otherwise used or 561 disclosed without the consent of the data subject or other legal 562 authority. A consumer who provides LI to a business in order to 563 receive directions, for example, does not provide that 564 information for any other purpose. The business should then only 565 use that LI to provide directions, and not for other purposes. 567 6. Security: Personal Data should be protected by reasonable 568 security safeguards against such risks as loss, unauthorized 569 access, destruction, use, modification, or disclosure. While 570 some security measures may take place outside of the LO-i.e. 571 limiting employee access to Location Servers-other measures may 572 be done through the LO or LO applications. 574 7. Accountability: Record keepers should be accountable for 575 complying with fair information practices. It will typically be 576 easier for an individual to enforce these practices if they are 577 explicitly written-either in the policies written by the Rule 578 Maker, or in contracts between the individual and a trusted 579 entity. 581 6. Security Properties of the GEOPRIV Protocol 583 The countermeasures suggested below reflect the threats discussed in 584 this document. There is thus some overlap between the proposed 585 security properties listed below, and the requirements in [1]. 587 6.1 Policies as Counter-Measures 589 The sections below are designed to illustrate that in many instances 590 threats to LI can be limited through clear, unavoidable rules 591 determined by Rule Makers. 593 6.1.1 Rule Maker Should Define Policies 595 The Rule Maker for a given Device will generally be either the user 596 of, or owner of, the device. In certain circumstances, the Rule 597 Maker may be both of these entities. Depending on the device the 598 Rule Maker may or may not be the individual most closely aligned with 599 the Target. For instance a child carrying a cell phone may be the 600 Target, but the parent of that child would likely be the Rule Maker 601 for the Device. Giving the Rule Maker control is a potential 602 opportunity to buttress the consent component of the collection 603 limitation and finality principles discussed above. 605 6.1.2 GEOPRIV Should Have Default Policies 607 Because some Rule Makers may not be informed about the role Policies 608 play in the disclosure of their LI, GEOPRIV should include default 609 policies. The Rule Maker is, of course, always free to change his or 610 her policies to provide more or less protection. To protect privacy 611 and physical safety, default policies should, at a minimum, limit 612 disclosure and retention of LI.. 614 Default policies are also necessary for so-called "dumb" Location 615 Sighters (LoSi). If a LoSi is unable to determine the Policies set 616 by the Rule Maker before passing the LO on to a Location Seeker, it 617 is important that some default policies protect that LO in transit, 618 and ensure that the LO is only sent to authorized Location Seekers. 619 These default LoSi policies would help prevent many of the threats 620 discussed in this document. The Rule Maker should be able to 621 determine the content of these default policies at any time. 623 6.1.3 Location Recipient Should Not Be Aware of All Policies 625 An Ultimate Location Recipient should not be aware of the full 626 policies defined by the Rule Maker. The ULR will only need to be 627 aware of those Policies it must obey-i.e. those regarding its use 628 and retention of the LI. Other policies, such as those specifying 629 the accuracy or filtering of the LI, or rules that do not cover the 630 given interaction should not be revealed to the ULR. This 631 countermeasure is consistent with the minimization component of the 632 collection limitation principle and ensures that the Rule Maker 633 reveals only what he intends to. 635 6.1.4 Certain Policies Should Travel With the LO 637 Security of LI at the device level is a bit complicated, as the Rule 638 Maker has no real control over what is done with the LI once it 639 arrives at the Device of the Location Seeker. If certain Policies 640 travel with the LO, the Rule Maker can encourage ULR compliance with 641 its policies. Potentially, a Policy could travel with the LO 642 indicating when it was time to purge the data, preventing the 643 compilation of a "log" of the Target's LI on any Device involved in 644 the transmission of the LO. Allowing policies to travel with the LO 645 has the potential to limit the opportunity for traffic analysis 646 attacks. 648 6.2 Protection of Identities 650 Identities are an extremely important component of the LO. While, in 651 many instances, some form of identification of the Target, LS, and 652 ULR will be necessary for authentication, there are various methods 653 to separate these authentication "credentials" from the true identity 654 of these devices. These countermeasures are particularly useful in 655 that compromise of a log of LI, no matter where the source, is less 656 threatening to privacy when the Target's identity is stripped. 658 6.2.1 Short-Lived Identifiers May Protect Target's Identity 660 Short-Lived identifiers would allow the using protocol to hide the 661 true identity of the Rule Maker and the Target from Location Servers 662 or Location Recipients. These identifiers would still allow 663 authentication, ensuring that only appropriate Location Recipients 664 received the LO. At the same time, however, making these identifiers 665 short-lived helps prevent any association of a true identity of a 666 Target with particular habits and associates. 668 6.2.2 Unlinked Pseudonyms May Protect the Location Recipients' Identity 670 Unlinked pseudonyms would protect the identity of the Location 671 Recipients in much the same manner as short-lived identifiers would 672 protect the Target's identity. When using both, any record that a 673 Location Server had of a transaction would have two "credentials" 674 associated with a LI transmission-one linked to the Target and one 675 linked to the Location Recipient. These credentials would allow the 676 Location Server to authenticate the transmission without ever 677 acquiring knowledge of the true identities of the individuals 678 associated with each side of the transaction. 680 6.3 Security During Transmission of Data 682 The attacks describe in this document motivate the following security 683 properties for the connections between the Location Sighter and 684 Location Server, the Location Server and Rule-Maker, and the Location 685 Server and Location Seeker: 687 6.3.1 Policies May Disallow a Certain Frequency of Requests 689 The Rule Maker might be able to set a policy that disallows a certain 690 number of requests made within a specific period of time. This type 691 of arrangement would allow the Rule Maker to somewhat prevent the 692 ability to average randomly coarsened data. To an "untrusted" 693 Location Recipient, for example, to whom the Rule Maker only wants to 694 reveal LI that is coarsened to the level of a city, only one request 695 might be honored every 2 hours. This would prevent Location 696 Recipients from sending repeated requests to gain more accurate 697 presence information. 699 6.3.2 Mutual End-Point Authentication 701 Authentication is crucial to the security of LI during transmission. 702 The Location Server must be capable of authenticating Location 703 Seekers to prevent impersonation. Location Sighters must be capable 704 of authenticating Location Servers to ensure that raw location 705 information is not sent to improper entities. Additionally, Location 706 Servers must be able to authenticate Rule-Makers to ensure that 707 unauthorized entities cannot change Policies. 709 6.3.3 Data Object Integrity & Confidentiality 711 The LO must maintain integrity at all points of communication between 712 Location Servers and Location Seekers. Confidentiality is required 713 on both the connection between the Location Sighter and the Location 714 Server, as well as on the connection between the Location Server and 715 any given Location Seeker. 717 6.3.4 Replay Protection 719 Replay protection prevents an attacker from capturing a particular 720 picee of location information and replaying it at a later time in 721 order to convince ULRs of an erroneous location for the target. Both 722 Location Seekers and Location Servers, depending on their 723 capabilities, may need replay protection. 725 7. Security Considerations 727 This informational document characterizes potential security threats 728 targeting the GEOPRIV architecture. 730 8. IANA Considerations 732 This document introduces no additional considerations for IANA. 734 Informative References 736 [1] Cuellar, J., Morris, J. and D. Mulligan, "Geopriv requirements", 737 draft-ietf-geopriv-reqs-01 (work in progress), October 2002. 739 Authors' Addresses 741 Michelle Engelhardt Danley 742 Samuelson Law, Technology and Public Policy Clinic, Boalt Hall School of Law 743 University of California 744 Berkeley, CA 94720 745 USA 747 EMail: mre213@nyu.edu 748 Deirdre Mulligan 749 Samuelson Law, Technology and Public Policy Clinic, Boalt Hall School of Law 750 University of California 751 Berkeley, CA 94720 752 USA 754 EMail: dmulligan@law.berkeley.edu 756 John B. Morris, Jr. 757 Center for Democracy and Technology 758 1634 I Street NW 759 Suite 1100 760 Washington, DC 20006 761 USA 763 EMail: jmorris@cdt.org 764 URI: http://www.cdt.org 766 Jon Peterson 767 NeuStar, Inc. 768 1800 Sutter St 769 Suite 570 770 Concord, CA 94520 771 USA 773 Phone: +1 925/363-8720 774 EMail: jon.peterson@neustar.biz 775 URI: http://www.neustar.biz/ 777 Full Copyright Statement 779 Copyright (C) The Internet Society (2002). All Rights Reserved. 781 This document and translations of it may be copied and furnished to 782 others, and derivative works that comment on or otherwise explain it 783 or assist in its implementation may be prepared, copied, published 784 and distributed, in whole or in part, without restriction of any 785 kind, provided that the above copyright notice and this paragraph are 786 included on all such copies and derivative works. However, this 787 document itself may not be modified in any way, such as by removing 788 the copyright notice or references to the Internet Society or other 789 Internet organizations, except as needed for the purpose of 790 developing Internet standards in which case the procedures for 791 copyrights defined in the Internet Standards process must be 792 followed, or as required to translate it into languages other than 793 English. 795 The limited permissions granted above are perpetual and will not be 796 revoked by the Internet Society or its successors or assigns. 798 This document and the information contained herein is provided on an 799 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 800 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 801 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 802 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 803 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 805 Acknowledgement 807 Funding for the RFC Editor function is currently provided by the 808 Internet Society.