idnits 2.17.1 draft-ietf-geopriv-threat-analysis-01.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 6 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 523 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 (September 29, 2003) is 7508 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-03 Summary: 2 errors (**), 0 flaws (~~), 4 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: March 29, 2004 UC Berkeley 5 J. Morris 6 CDT 7 J. Peterson 8 NeuStar 9 September 29, 2003 11 Threat Analysis of the geopriv Protocol 12 draft-ietf-geopriv-threat-analysis-01 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 March 29, 2004. 37 Copyright Notice 39 Copyright (C) The Internet Society (2003). 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 information 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 Viewer . . . . . . . . . . . . . . . . 10 65 4.2.4 Information Contained in Rules . . . . . . . . . . . . . . . 10 66 4.3 Usage Attacks . . . . . . . . . . . . . . . . . . . . . . . 11 67 4.3.1 Threats Posed by Overcollection . . . . . . . . . . . . . . 11 68 5. Countermeasures for Usage Violations . . . . . . . . . . . . 12 69 5.1 Fair Information Practices . . . . . . . . . . . . . . . . . 12 70 6. Security Properties of the geopriv Protocol . . . . . . . . 13 71 6.1 Rules as Counter-Measures . . . . . . . . . . . . . . . . . 13 72 6.1.1 Rule Maker Should Define Rules . . . . . . . . . . . . . . . 13 73 6.1.2 Geopriv Should Have Default Rules . . . . . . . . . . . . . 14 74 6.1.3 Location Recipient Should Not Be Aware of All Rules . . . . 14 75 6.1.4 Certain Rules 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 Rules May Disallow a Certain Frequency of Requests . . . . . 15 82 6.3.2 Mutual End-Point Authentication . . . . . . . . . . . . . . 16 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 . . . . . . . . . . . . . . . . . . . . . 17 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 Viewers be capable of requesting LI from a 108 Location Server. The geopriv requirements account for circumstances 109 in which the Target has a contractual relationship with the entities 110 that transmit and receive LI and those in which no contract exists. 111 Requiring the geopriv object to support any technology, Target-Viewer 112 relationship, or underlying legal framework governing LI, complicates 113 the protection of privacy and the security of LI. 115 This document analyzes threats to LI in transmission and storage. 116 The possibility that the LI will be compromised by these threats 117 varies depending on the circumstances. A server selling location 118 information to potential marketers poses a distinctly lower risk than 119 an outside individual intercepting a Target's present location to 120 commit a physical attack. It is important that these threats are 121 considered as we work towards defining the LO. 123 Some of the threats discussed in this document may be outside of the 124 scope of the geopriv charter, e.g., threats arising from failure to 125 meet contractual obligations. Nevertheless, a comprehensive 126 discussion of threats is necessary to identify desirable security 127 properties and counter-measures that will improve the security of the 128 LO, and thereby better protect LI. 130 2. Habitat of the geopriv Protocol 132 The geopriv architecture will be deployed in the open Internet - in a 133 security environment in which potential attackers can inspect packets 134 on the wire, spoof Internet addresses, and launch large-scale denial- 135 of-service attacks. In some architectures, portions of geopriv 136 traffic (especially traffic between the Location Generator and an 137 initial Location Server) may occur over managed networks that do not 138 interface with the public Internet. 140 The protocol itself assumes interaction between a number of logical 141 roles, many of which will commonly be implemented in distributed 142 network devices (for a full list of geopriv roles and entities with 143 definitions, see [1]). The endpoints of the common geopriv 144 transactions are the Location Generator (the source of location 145 information from the perspective of the network) and the Location 146 Recipient. Both a Location Generator and a Location Recipient may 147 have a relationship with a Location Server; the Location Generator 148 publishes data to a Location Server (which may provide a grooming/ 149 filtration function for location information), and the Location 150 Recipient requests and/or receives information from the Location 151 Server. This provides two points where geopriv information could 152 require protection across the wire. Rules can also be passed over 153 the network from a Rule Holder to a Location Server; this provides 154 another point where the architecture requires security. 156 It is important to note that Location Generators and Location 157 Recipients may be implemented on low-cost devices for which strong 158 cryptographic security is currently prohibitively expensive 159 computationally. 161 3. Motivations of Attackers of geopriv 163 The most obvious motivation for an attacker of geopriv is to learn 164 the location of a subject who wishes to keep their position private, 165 or even for authorized Viewers to ascertain location information with 166 a greater degree of precision than the Rule Maker desires. However, 167 there are several other potential motivations that are causes for 168 concern. Attackers might also wish to prevent a Target's location 169 from being distributed, or to modify or corrupt location information 170 in order to misrepresent the location of the Target, or to redirect 171 the Target's location information to a third party that is not 172 authorized to know this information. Attackers may want to identify 173 the associates of a Target, or learn the habit or routines of a 174 Target. Attackers might want to learn the identity of all of the 175 parties that are in a certain location. Finally, some attackers may 176 simply want to halt the operation of an entire geopriv system through 177 denial-of-service attacks. 179 There is also a class of attackers who may be authorized as 180 legitimate participants in a geopriv protocol exchange but who abuse 181 location information. This includes the distribution or accumulation 182 of location information outside the parameters of agreements between 183 the principals, possibly for commercial purposes or as an act of 184 unlawful surveillance. 186 4. Representative Attacks on geopriv 188 4.1 Protocol Attacks 190 4.1.1 Eavesdropping and/or Interception 192 Imagine a location-based computer game, based on traditional hide- 193 and-seek, in which a centralized server provides hints as to the 194 location of the 'hider' to a set of 'seekers'. Seekers are given 195 access to very coarse location data, whereas a single referee is 196 given access to unfiltered and precise location information of the 197 hider. Each seeker has a wireless device (in the geopriv 198 architecture, a Location Recipient) that feeds them coarse 199 positioning data from the Location Server. The hider carries a 200 device (a Location Generator employing GPS) that transmits location 201 information to the Location Server. 203 If one of the seekers wished to cheat by attacking the geopriv 204 protocol, there are a number of ways they could mount such an attack 205 in order to learn the precise location of the hider. They might 206 eavesdrop on one of two network connections - either the connection 207 between the Location Generator and the Location Server, or the 208 connection between the Location Server and the referee's Location 209 Recipient (which receives precise information). They might also 210 attempt to impersonate the referee to the Location Server, in order 211 to receive unfiltered Location Information. Alternatively, they 212 could impersonate the Location Server to the Location Generator 213 carried by the hider, which would also give them access to precise 214 location information. Finally, the cheater could attempt to act as 215 the Rule Maker, and to provide Rules to the Location Server that 216 would enable the cheater's Location Recipient access to uncoarsened 217 location information. 219 From these threats, we can derive a need for several security 220 properties of the architecture. 222 o Confidentiality is required on both the connection between the 223 Location Generator and the Location Server, as well as the 224 connection between the Location Server and any given Location 225 Recipient. 227 o Location Servers must be capable of authenticating and authorizing 228 Location Recipients to prevent impersonation. 230 o Similarly, Location Generators must be capable of authenticating 231 and authorizing Location Servers in order to prevent 232 impersonation. 234 o Finally, the Location Server must be able to authenticate Rule 235 Makers, to make sure that unauthorized parties cannot change 236 rules. 238 4.1.2 Identity Spoofing 240 Consider a case in which the same boss employs two rivals. One goes 241 on a business trip to Cleveland. Both rivals carry devices that are 242 tracked by a Location Generator (such as cell phones which the cell 243 carrier can triangulate), and both rivals allow their boss access to 244 their (coarse) location information. The rival that remained home 245 wants to hack the geopriv protocol to make it appear that the 246 traveling rival is actually goofing off in South Beach rather than 247 attending a dull technology conference in Cleveland. How would such 248 an attack be mounted? 250 The attacker might attempt to spoof network traffic from the Location 251 Generator to the Location Server (especially if, through some other 252 means such as a denial-of-service attack, the Location Generator 253 became unable to issue its own reports). The goal of the attacker 254 may be to provide falsified location information appropriate for 255 someone in Miami, or perhaps even to replay a genuine location object 256 from a previous visit of the rival to Miami. The attacker might also 257 try to spoof traffic from the Location Server to the boss' Location 258 Recipient. 260 From these threats we can derive a need for several security 261 properties of the architecture. 263 o There is a need for the Location Server to authenticate Location 264 Generators. 266 o Location Recipients must be capable of authenticating Location 267 Servers. 269 o Location information must be protected from replay attacks. 271 Identity spoofing may create additional threats when the protocol is 272 attacked. In many circumstances, the identity of the Viewer is the 273 basis for controlling whether LI is revealed and, if so, how that LI 274 is filtered. If the identity of that entities is compromised, 275 privacy is threatened. Anyone inside or outside the transaction that 276 is capable of impersonating an authorized entity can gain access to 277 confidential information, or initiate false transmissions in the 278 authorized entity's name. The ability to spoof the identity of the 279 Location Recipient, for example, would create the risk of an 280 unauthorized entity accessing both the identity and the location of 281 the Target at the moment the LO was sent. 283 4.1.3 Information Gathering 285 Eavesdropping and interception can also create traffic analysis 286 threats as the interceptor collects more data over time. Traffic 287 analysis threats are leveraged by an eavesdropper w to determine, 288 from the very fact of a network transmission, the relationship 289 between the various entities involved. If an employer sends the 290 location of an employee to a customer, an eavesdropper could 291 determine that these three entities are somehow interacting with one 292 another. If eavesdropping continues over time, the collection of 293 interactions would involve the employer, employees, and all of their 294 customers. Such a log of information would reveal that the employer 295 and employee frequently were associated with one another, and would 296 reveal which clients more frequently dealt with the pair. Thus, the 297 traffic analysis threat creates the risk of eavesdroppers determining 298 the Target's associates. 300 Traffic analysis might also allow an eavesdropper to ascertain the 301 identity or characteristics of targets in a particular location. By 302 observing transmissions between Location Generators in a particular 303 location and Location Servers (perhaps by eavesdropping on a wireless 304 or wireline LAN scoped to the location in question), and then 305 possibly following the data to various Location Recipients, an 306 attacker may be able to learn the associates, including the employer, 307 of targets in that location, and perhaps to extrapolate further 308 identity information. 310 If the eavesdropper is able to intercept not only an encrypted LO, 311 but the plaintext LI itself, other threats are raised. Let's return 312 to the above example of the employer requesting an employee's 313 location information. In this instance, the interception of one such 314 past transaction may reveal the identities and/or locations of all 315 three parties involved, in addition to revealing the fact of their 316 association. In circumstances where there is a log of this data, 317 however, analysis could reveal any regular route that the employee 318 may travel in visiting customers, a general area that the employee 319 works in, the identities and location of the employee's entire 320 customer base, and information about how the entities relate. 322 Threats based on traffic analysis are difficult to meet with protocol 323 security measures, but they are important to note. 325 From these threats we can derive a need for several security 326 properties of the architecture. 328 o The Rule Maker must be able to define Rules regarding the use of 329 their LI. 331 o The connection between the Location Generator and Location Server, 332 as well as the connection between the Location Server and Location 333 Recipient must remain confidential. 335 o Location Servers must be capable of authenticating Location 336 Recipients to prevent impersonation. 338 o Location Servers must be able to authenticate Rule Makers to 339 ensure that unauthorized entities cannot change rules. 341 4.1.4 Denial of Service 343 Parties who wish to deprive entire networks of geopriv service, 344 rather than just targeting particular users, would probably focus 345 their efforts on the Location Server. Since in many scenarios the 346 Location Server plays the central role of managing access to location 347 information for many devices, it is in such architectures a natural 348 single point of failure. 350 The geopriv protocol appears to have some opportunities for 351 amplification attacks. When the Location Generator publishes 352 location information, the Location Server acts as an exploder, 353 potentially delivering this information to numerous targets. If the 354 Location Generator were to provide very rapid updates of position (as 355 many as link speed could accommodate, especially in high-bandwidth 356 wireless environments), then were the Location Server to proxy 357 information to Seekers at a similar rate, this could become 358 problematic when large numbers of Seekers are tracking the same user. 360 Also note that most operations associated with the Location Server 361 probably require cryptographic authentication. Cryptographic 362 operations entail a computational expense on the part of the Location 363 Server. This could provide an attractive means for attackers to 364 flood the Location Server with dummied geopriv information that is 365 spoofed to appear to come from a Location Generator, Location 366 Recipient, or the Rule Maker. Because the Location Server has to 367 expend resources to verify credentials presented by these geopriv 368 messages, floods of geopriv information could have greater impact 369 than denial-of-service attacks based on generic packet flooding. 371 From these threats we can derive a need for several security 372 properties of the architecture. 374 o Location Servers must use stateless authentication challenges and 375 similar measures to insure that authentication attempts will not 376 unnecessarily consume system resources. 378 o The Rule Maker must be able to provision policies that limit the 379 rate at which Location Information is sent to prevent 380 amplification attacks. 382 4.2 Host Attacks 384 4.2.1 Data Stored at Servers 386 LI maintained at a server is subject to many potential risks. First, 387 there may be accidental misuse of LI by the server. Whether by 388 negligence, carelessness, or lack of knowledge, the server may 389 accidentally release LI to the wrong Location Recipients, or fail to 390 properly filter the LI that is sent out. Second, the server may 391 intentionally misuse LI. A server may decide to sell a "profile" it 392 has compiled of a Target or Location Recipient despite provisions to 393 the contrary in the Rule Maker's Rule. Alternatively, an individual 394 working for the server may, for personal gain, misuse access to the 395 server to obtain LI. Third, even with the most secure and trusted 396 server, there is the risk that someone outside the system will hack 397 into it in order to retrieve LI. Last, there is always the potential 398 that someone would use the legal system to subpoena an individual's 399 records from a Server. Such a process would likely result in the 400 revelation of the Target's location information without notice to the 401 Target or the Target's consent. 403 Data stored at the server may reveal the Target's present location if 404 the data is used or intercepted at or near the moment of 405 transmission. If a Target requests a map from their present location 406 to a nearby store, and the Location Server sends that information to 407 the wrong Location Recipient, whose Viewer could know the identity of 408 the Target, the Target's current location, and the location where the 409 Target might be headed. 411 Data stored at the Location Server can also create many of the 412 traffic analysis threats discussed in Section 4.1 above. If access 413 is gained not only to the fact of the LO transmission, but also to 414 the LI transmitted, anyone with access to that information can put 415 together a history of where that Target has been, for how long, and 416 with whom. 418 4.2.2 Data Stored in Devices 420 Because geopriv is required to work with any given type of technology 421 or Device, it is difficult to determine the particular threat 422 potential of individual devices. For example, any device that 423 maintains a log of location requests sent, or LOs received, would 424 pose a similar threat to the information maintained at a Location 425 Server, discussed above. A court subpoena or warrant for an 426 individual's device could additionally reveal a similar log. 428 Additionally, depending on the device, there is always the potential 429 for data to be compromised in some way. For a Device with a screen, 430 there is always the potential that another individual will have the 431 opportunity to view the Device display without the user's knowledge. 432 A Device that provides verbal feedback (i.e. to give directions to 433 the blind) creates additional potential for LI to be compromised. If 434 the Target/Viewer is sitting in a public place and requests 435 directions from the Target's home to another location, anyone who can 436 see the Device output may be able to determine the Target's identity, 437 their residence, and possibly the location to which they are headed. 439 In addition, if the device retained location information and the 440 Device were lost or stolen, someone other than the Rule Maker could 441 potentially access information regarding who LI was sent to and when, 442 as well as potentially the location of the Target during each 443 transaction. Such information could enable an entity to determine 444 significant private information based on who the owner of the Device 445 has associated with in the past, as well as each location where the 446 Target has been and for how long. 448 4.2.3 Data Stored with the Viewer 450 The threats posed here are similar to those discussed above in 451 relation to Location Servers and Devices. The main purpose of 452 separating out threats posed by data stored at the Viewer is to show 453 that, depending on the complexity of the transaction and the other 454 entities involved, data storage at various points in the transaction 455 can bring rise to the same types of privacy risks. 457 4.2.4 Information Contained in Rules 459 In many instances, the Rules a Rule Maker creates will reveal 460 information either about the Rule Maker or the Target. A rule that 461 degrades all information sent out by approximately 25 miles might 462 tell an interceptor how to determine the Target's true location. A 463 Rule that states, "Tell my boss what room I'm in when I'm in the 464 building, but when I'm outside the building between 9 a.m. and 5 465 p.m. tell him I'm in the building," would reveal a lot more 466 information than most employees would desire. Any boss who was the 467 Location Recipient who received LI that specified "in the building" 468 would then realize that the employee was elsewhere. 470 In addition, if an entity had access to a log of data at the Location 471 Server or at a Device, knowledge of the content of Rules would enable 472 a sort of "decoding" of the location information of the device to 473 something more accurate. Thus, my boss could not only tell where I 474 am at this minute, but could tell how many times over the last year I 475 had been outside the building between 9 a.m. and 5 p.m. 477 The Rules themselves may also reveal information about the Target. A 478 rule such as the one above would clearly reveal the employment 479 relationship between the two individuals as well as the fact that the 480 employee was hiding something from the employer. 482 In combination with other information the location information may 483 enable the identification of the Target. 485 4.3 Usage Attacks 487 4.3.1 Threats Posed by Overcollection 489 Weak or absent default privacy rules would also compromise LI. 490 Without default Rules for LOs, it is likely that a large number of 491 Devices would reveal LI by default. Privacy rules should control the 492 collection, use, disclosure, and retention of Location Information. 493 These rules must comply with fair information practices-these 494 practices are further discussed in Section 5.1. 496 While technically savvy Device users may create privacy rules to 497 protect their LI, many individuals will lack the skill or motivation 498 to do so. Thus, left to their own devices many individuals would 499 likely be left without privacy rules for their LI. This in turn 500 would leave these users' LI entirely vulnerable to various attacks. 501 Default rules are necessary to address this problem. 503 Without default rules, for example, a device might signal out to 504 anyone nearby at regular intervals, respond to anyone nearby who 505 queried it, or send signals out to unknown entities. 507 The lack of a default rule of "Do not re-distribute," would allow the 508 Location Server to pass the Target's location information on to 509 others. Lack of a default rule limiting the retention of LI could 510 increase the risk posed by inappropriate use and access to stored 511 data. 513 While defining default privacy rules is beyond the scope of this 514 document, default rules are necessary to limit the privacy risks 515 posed by the use of services and devices using LI. 517 5. Countermeasures for Usage Violations 519 5.1 Fair Information Practices 521 Principles of fair information practices require entities that handle 522 personal information to meet certain obligations with respect to its 523 collection, use, maintenance and security, and give individuals 524 whose personal information is collected certain due process-like 525 rights in the handling of their information. Fair information 526 practices are designed to prevent specific threats posed by the 527 collection of personal information about individuals. For this 528 reason, fair information practices are "countermeasures" that should 529 be reflected in technical systems that handle personal information 530 and the Rules that govern their use. A brief discussion of fair 531 information practices may be beneficial in formulating requirements 532 for the LO. 534 There are seven main principles of fair information practices: 536 1. Openness: The existence of a record-keeping system for personal 537 information must be known, along with a description of the main 538 purpose and uses of the data. Thus any entity that collects LI 539 should inform individuals that this information is being 540 collected and inform them about what the LI is being used for. 541 Openness is designed to prevent the creation of secret systems. 543 2. Individual Participation: Individuals should have a right to view 544 all information collected about them, and to be able to correct 545 or remove data that is not timely, accurate, relevant, or 546 complete. The practice of individual participation acknowledges 547 that sometimes information that is collected may be inaccurate or 548 inappropriate. 550 3. Collection Limitation: Data should be collected by lawful and 551 fair means and should be collected, where appropriate, with the 552 knowledge or consent of the subject. Data collection should be 553 minimized to that which is necessary to support the transaction. 554 Placing limits on collection helps protect individuals from the 555 dangers of overcollection-both in terms of collecting too much 556 information, or of collecting information for too long of a time 557 period. 559 4. Data Quality: Personal data should be relevant to the purposes 560 for which it is collected and used; personal information should 561 be accurate, complete, and timely. The requirement of data 562 quality is designed to prevent particular kinds of harms that can 563 flow from the use (appropriate or inappropriate) of personal 564 information. 566 5. Finality: There should be limits to the use and disclosure of 567 personal data: data should be used only for purposes specified at 568 the time of collection; data should not be otherwise used or 569 disclosed without the consent of the data subject or other legal 570 authority. A consumer who provides LI to a business in order to 571 receive directions, for example, does not provide that 572 information for any other purpose. The business should then only 573 use that LI to provide directions, and not for other purposes. 575 6. Security: Personal Data should be protected by reasonable 576 security safeguards against such risks as loss, unauthorized 577 access, destruction, use, modification, or disclosure. While 578 some security measures may take place outside of the LO-i.e. 579 limiting employee access to Location Servers-other measures may 580 be done through the LO or LO applications. 582 7. Accountability: Record keepers should be accountable for 583 complying with fair information practices. It will typically be 584 easier for an individual to enforce these practices if they are 585 explicitly written-either in the Rules written by the Rule Maker, 586 or in contracts between the individual and a trusted entity. 588 6. Security Properties of the geopriv Protocol 590 The countermeasures suggested below reflect the threats discussed in 591 this document. There is thus some overlap between the proposed 592 security properties listed below, and the requirements in [1]. 594 6.1 Rules as Counter-Measures 596 The sections below are designed to illustrate that in many instances 597 threats to LI can be limited through clear, unavoidable rules 598 determined by Rule Makers. 600 6.1.1 Rule Maker Should Define Rules 602 The Rule Maker for a given Device will generally be either the user 603 of, or owner of, the Device. In certain circumstances, the Rule 604 Maker may be both of these entities. Depending on the device the 605 Rule Maker may or may not be the individual most closely aligned with 606 the Target. For instance a child carrying a cell phone may be the 607 Target, but the parent of that child would likely be the Rule Maker 608 for the Device. Giving the Rule Maker control is a potential 609 opportunity to buttress the consent component of the collection 610 limitation and finality principles discussed above. 612 6.1.2 Geopriv Should Have Default Rules 614 Because some Rule Makers may not be informed about the role Rules 615 play in the disclosure of their LI, geopriv should include default 616 Rules. The Rule Maker is, of course, always free to change his or 617 her Rules to provide more or less protection. To protect privacy and 618 physical safety, default Rules should, at a minimum, limit disclosure 619 and retention of LI. 621 Default Rules are also necessary for so-called "dumb" Location 622 Generators (LG). If a LG is unable to determine the Rules set by the 623 Rule Maker before publishing the LO on to a Location Server, it is 624 important that some default Rules protect that LO in transit, and 625 ensure that the LO is eventually only sent to authorized Location 626 Recipients. These default LG Rules would help prevent many of the 627 threats discussed in this document. The Rule Maker should be able to 628 determine the content of these default Rules at any time. 630 6.1.3 Location Recipient Should Not Be Aware of All Rules 632 An Viewer should not be aware of the full Rules defined by the Rule 633 Maker. The Viewer will only need to be aware of those Rules it must 634 obey-i.e. those regarding its use and retention of the LI. Other 635 Rules, such as those specifying the accuracy or filtering of the LI, 636 or rules that do not cover the given interaction should not be 637 revealed to the Viewer. This countermeasure is consistent with the 638 minimization component of the collection limitation principle and 639 ensures that the Rule Maker reveals only what he intends to. 641 6.1.4 Certain Rules Should Travel With the LO 643 Security of LI at the device level is a bit complicated, as the Rule 644 Maker has no real control over what is done with the LI once it 645 arrives at the Location Recipient. If certain Rules travel with the 646 LO, the Rule Maker can encourage Viewer compliance with its Rules. 647 Potentially, a Rule could travel with the LO indicating when it was 648 time to purge the data, preventing the compilation of a "log" of the 649 Target's LI on any Device involved in the transmission of the LO. 650 Allowing Rules to travel with the LO has the potential to limit the 651 opportunity for traffic analysis attacks. 653 6.2 Protection of Identities 655 Identities are an extremely important component of the LO. While, in 656 many instances, some form of identification of the Target, Rule 657 Maker, and Viewer will be necessary for authentication, there are 658 various methods to separate these authentication "credentials" from 659 the true identity of these devices. These countermeasures are 660 particularly useful in that compromise of a log of LI, no matter 661 where the source, is less threatening to privacy when the Target's 662 identity is stripped. 664 6.2.1 Short-Lived Identifiers May Protect Target's Identity 666 Short-Lived identifiers would allow the using protocol to hide the 667 true identity of the Rule Maker and the Target from Location Servers 668 or Location Recipients. These identifiers would still allow 669 authentication, ensuring that only appropriate Location Recipients 670 received the LO. At the same time, however, making these identifiers 671 short-lived helps prevent any association of a true identity of a 672 Target with particular habits and associates. 674 6.2.2 Unlinked Pseudonyms May Protect the Location Recipients' Identity 676 Unlinked pseudonyms would protect the identity of the Location 677 Recipients in much the same manner as short-lived identifiers would 678 protect the Target's identity. When using both, any record that a 679 Location Server had of a transaction would have two "credentials" 680 associated with a LI transmission: one linked to the Target and one 681 linked to the Location Recipient. These credentials would allow the 682 Location Server to authenticate the transmission without ever 683 acquiring knowledge of the true identities of the individuals 684 associated with each side of the transaction. 686 6.3 Security During Transmission of Data 688 The attacks described in this document motivate the following 689 security properties for the connections between the Location 690 Generator and Location Server, the Location Server and Rule Maker, 691 and the Location Server and Location Recipient: 693 6.3.1 Rules May Disallow a Certain Frequency of Requests 695 The Rule Maker might be able to set a Rule that disallows a certain 696 number of requests made within a specific period of time. This type 697 of arrangement would allow the Rule Maker to somewhat prevent 698 attackers from detecting patterns in randomly coarsened data. To an 699 "untrusted" Location Recipient, for example, to whom the Rule Maker 700 only wants to reveal LI that is coarsened to the level of a city, 701 only one request might be honored every 2 hours. This would prevent 702 Location Recipients from sending repeated requests to gain more 703 accurate presence information. 705 Similarly, thresholds on notifications of location information can 706 help to combat amplification attacks. 708 6.3.2 Mutual End-Point Authentication 710 Authentication is crucial to the security of LI during transmission. 711 The Location Server must be capable of authenticating Location 712 Recipients to prevent impersonation. Location Generators must be 713 capable of authenticating Location Servers to ensure that raw 714 location information is not sent to improper entities. Additionally, 715 Location Servers must be able to authenticate Rule Makers to ensure 716 that unauthorized entities cannot change Rules. 718 6.3.3 Data Object Integrity & Confidentiality 720 The LO must maintain integrity at all points of communication between 721 Location Servers and Location Recipients. Confidentiality is 722 required on both the connection between the Location Generator and 723 the Location Server, as well as on the connection between the 724 Location Server and any given Location Recipient. Confidentiality of 725 Rules sent over the network to the Location Server is of comparable 726 importance. 728 6.3.4 Replay Protection 730 Replay protection prevents an attacker from capturing a particular 731 piece of location information and replaying it at a later time in 732 order to convince Viewers of an erroneous location for the target. 733 Both Location Recipients and Location Servers, depending on their 734 capabilities, may need replay protection. 736 7. Security Considerations 738 This informational document characterizes potential security threats 739 targeting the geopriv architecture. 741 8. IANA Considerations 743 This document introduces no additional considerations for IANA. 745 Informative References 747 [1] Cuellar, J., Morris, J., Mulligan, D., Peterson, J. and J. Polk, 748 "Geopriv requirements", draft-ietf-geopriv-reqs-03 (work in 749 progress), March 2003. 751 Authors' Addresses 753 Michelle Engelhardt Danley 754 Samuelson Law, Technology and Public Rule Clinic, Boalt Hall School of Law 755 University of California 756 Berkeley, CA 94720 757 USA 759 EMail: mre213@nyu.edu 761 Deirdre Mulligan 762 Samuelson Law, Technology and Public Rule Clinic, Boalt Hall School of Law 763 University of California 764 Berkeley, CA 94720 765 USA 767 EMail: dmulligan@law.berkeley.edu 769 John B. Morris, Jr. 770 Center for Democracy and Technology 771 1634 I Street NW 772 Suite 1100 773 Washington, DC 20006 774 USA 776 EMail: jmorris@cdt.org 777 URI: http://www.cdt.org 779 Jon Peterson 780 NeuStar, Inc. 781 1800 Sutter St 782 Suite 570 783 Concord, CA 94520 784 USA 786 Phone: +1 925/363-8720 787 EMail: jon.peterson@neustar.biz 788 URI: http://www.neustar.biz/ 790 Full Copyright Statement 792 Copyright (C) The Internet Society (2003). All Rights Reserved. 794 This document and translations of it may be copied and furnished to 795 others, and derivative works that comment on or otherwise explain it 796 or assist in its implementation may be prepared, copied, published 797 and distributed, in whole or in part, without restriction of any 798 kind, provided that the above copyright notice and this paragraph are 799 included on all such copies and derivative works. However, this 800 document itself may not be modified in any way, such as by removing 801 the copyright notice or references to the Internet Society or other 802 Internet organizations, except as needed for the purpose of 803 developing Internet standards in which case the procedures for 804 copyrights defined in the Internet Standards process must be 805 followed, or as required to translate it into languages other than 806 English. 808 The limited permissions granted above are perpetual and will not be 809 revoked by the Internet Society or its successors or assigns. 811 This document and the information contained herein is provided on an 812 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 813 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 814 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 815 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 816 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 818 Acknowledgement 820 Funding for the RFC Editor function is currently provided by the 821 Internet Society.