idnits 2.17.1 draft-haddad-alien-privacy-terminology-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (December 26, 2008) is 5599 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Haddad 3 Internet-Draft Qualcomm 4 Intended status: Informational E. Nordmark 5 Expires: June 29, 2009 Sun Microsystems 6 December 26, 2008 8 Privacy Aspects Terminology 9 draft-haddad-alien-privacy-terminology-05 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on June 29, 2009. 34 Copyright Notice 36 Copyright (c) 2008 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. 46 Abstract 48 This memo introduces terminology for the main privacy aspects. The 49 prime goal is to avoid situations where different interpretations of 50 the same key privacy aspects result in different requirements when 51 designing specific solutions, thus leading to an unnecessary 52 confusion. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Conventions used in this document . . . . . . . . . . . . . . 4 58 3. General Terminology . . . . . . . . . . . . . . . . . . . . . 5 59 4. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 5. Overview of Different Privacy Aspects . . . . . . . . . . . . 7 61 5.1. Anonymity . . . . . . . . . . . . . . . . . . . . . . . . 7 62 5.2. Unlinkability . . . . . . . . . . . . . . . . . . . . . . 7 63 5.3. Relation Between Anonymity and Unlinkability . . . . . . . 8 64 5.4. Undetectability and Unobservability . . . . . . . . . . . 8 65 5.5. Pseudonymity . . . . . . . . . . . . . . . . . . . . . . . 9 66 5.6. Location Privacy . . . . . . . . . . . . . . . . . . . . . 9 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 68 7. Informative References . . . . . . . . . . . . . . . . . . . . 11 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 71 1. Introduction 73 Privacy is becoming a key requirement to allow deployment of specific 74 internet services. However, privacy has many aspects, which differ 75 in scope, properties and limitations. 77 To avoid any possible confusion in ongoing and future works with 78 regard to the meanings of privacy in some particular scenarios, and 79 to differentiate between requirements related to each scenario, 80 privacy aspects have to be well defined before designing any 81 solution. It is the intention of this memo to introduce terminology 82 for the main aspects of privacy. 84 2. Conventions used in this document 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in [TERM]. 90 3. General Terminology 92 Item of Interest (IOI) 94 An Item of Interest (IOI) represents what an attacker is trying to 95 discover, learn, trace and possibly link to other IOI(s), in order 96 to identify its target. Examples of IOI include a subject, event, 97 action (e.g., send, receive, move, etc), specific type of 98 messages, etc. 100 Knowledge 102 In the field of privacy, knowledge refers to the information 103 available to an attacker about its target. In terms of IOI, 104 knowledge can be described by the probability of one or more IOIs. 105 Consequently, more knowledge means more accurate probabilities. 106 We refer to any prior information available to an attacker about a 107 specific target as background knowledge. 109 Pseudonym 111 A pseudonym is an identifier of a subject (e.g., user) to a 112 particular transaction, which is different than any of the user's 113 real names. This means that in the normal course of events, a 114 pseudonym is not sufficient to associate the transaction to a 115 particular subject. 117 Digital Pseudonym 119 A digital pseudonym is a unique identifier (at least with very 120 high probability) suitable to be used to authenticate the holder's 121 IOIs relatively to his/her digital pseudonym, e.g., to 122 authenticate his/her messages sent. 123 Another utility example is to set up an online account with an 124 organization without revealing personal information, e.g., a 125 public key. 126 Note that using digital pseudonyms, accountability can be realized 127 with respect to pseudonyms. 129 4. Privacy 131 Privacy is a fundamental human right. The most common definition of 132 privacy is the one by Alan Westin: "Privacy is the claim of 133 individuals, groups and institutions to determine for themselves, 134 when, how and to what extent information about them is communicated 135 to others". 137 Privacy is a general term that involves several different aspects. 138 These aspects enable features like hiding the node's address(es) 139 (e.g., MAC and/or IP), name(s) (e.g., DNS), and/or location(s), in 140 addition to hiding specific IOIs. One or more of these features can 141 be obtained during one particular session. 143 In wireless telecommunications, privacy addresses especially the 144 protection of the content as well as the context (e.g., time, 145 location, type of service, ...) of a communication event. 147 Consequently, neither the mobile node nor its system software shall 148 support the creation of user-related usage profiles. Such profiles 149 basically comprise of a correlation of time and location of the 150 node's use, as well as the type and details of the transaction 151 performed. 153 The main prvacy aspects are anonymity, unlinkability, 154 undetectability, unobservability, and pseudonymity. Note that one 155 way to achieve privacy is by disconnectivity, i.e., not being 156 connected to a network. 158 5. Overview of Different Privacy Aspects 160 As mentioned above, privacy is a general term, which refers to many 161 different aspects. In the following, we define the main privacy 162 aspects and describe the different relations between them. 164 5.1. Anonymity 166 Anonymity is the state of being not identifiable within a set of 167 subjects (e.g., node, user) called anonymity set. The sender(s) 168 anonymity set(s) can be the same as the recipient(s) anonymity set(s) 169 or they can overlap or simply be disjoint. But it should be noted 170 that a set of possible subjects depends only on the knowledge of the 171 attacker and may vary overtime. However, as the attacker's knowledge 172 is expected to only increase in most applications, this means that 173 the anonymity set can only decrease. Consequently, anonymity is the 174 stronger, the larger the respective anonymity set is. Following the 175 above description, it becomes clear that the anonymity concept is 176 very much context dependent. 178 In the security field, anonymity is a property of network security. 179 An entity "A" in a set has anonymity if no other entity can identify 180 "A", nor is there any link back to "A" that can be used, nor any way 181 to verify that any two anonymous act are performed by "A". 183 From a user perspective, anonymity ensures that a user may use a 184 resource or service without disclosing the user's identity. 186 In wireless networks, anonymity means that neither the mobile node 187 nor its system shall by default expose any information that allows 188 any conclusions on the owner or current use of the node. 190 Consequently, in scenarios where a device and/or network identifiers 191 are used (e.g., MAC address, IP address), neither the communication 192 partner nor any outside attacker should be able to disclose any 193 possible link between the respective identifier and the user's 194 identity. 196 5.2. Unlinkability 198 Unlinkability of two or more IOIs means that from an attacker's 199 perspective, these IOIs are no more and no less related after his 200 observation than they are related with regards to his background 201 knowledge. 203 For example, two messages (e.g., binding updates) are unlinkable for 204 an attacker if the a-posteriori probability describing his background 205 knowledge that these two messages are sent by the same sender and/or 206 received by the same recipient is the same as the probability imposed 207 by his a-priori knowledge (i.e., by observing the system). 209 From a user perspective, unlinkability ensures that a user may make 210 multiple uses of resources or services without other being able to 211 link these uses together. 213 5.3. Relation Between Anonymity and Unlinkability 215 In terms of unlinkability, anonymity can be defined as the 216 unlinkability of an IOI and any subject. For example, a sender 217 anonymity means that a particular message is not linkable to any 218 sender and that to a particular sender, no message is linkable. The 219 same is true for recipient anonymity. 221 If we consider as an example, that the subject is a pseudonym, this 222 means that the anonymity of a particular IOI can be defined as the 223 unlinkability of the IOI to any pseudonym and an anonymous pseudonym 224 is not linkable to any IOI. 226 A weaker property than the sender's anonymity and the recipient's 227 anonymity is the "relationship anonymity" where two or more 228 pseudonyms are unlinkable. This means that for senders and 229 recipients, it is not possible to trace who is communicating with 230 whom, though it may possible to trace who is the sender, or who is 231 the recipient. In other words, sender's pseudonyms and recipient's 232 pseudonyms are unlinkable. 234 5.4. Undetectability and Unobservability 236 As described above, the anonymity and unlinkability states protect 237 the relationship between an IOI and a subject(s) or other IOI(s). 238 This means that in scenarios where anonymity and/or unlinkability are 239 required, senders and recipients can still exchange unprotected 240 IOI(s). 242 In contrast to anonymity and unlinkability, the undetectability of 243 IOIs is the state that whether they exist or not is 244 indistinguishable. In other words, undetectability protects IOIs 245 from being exposed. That is, the message transmission is not 246 discernable from a random noise. In addition, unlinkability does not 247 mention any relationship between "could-be" IOIs and subjects causing 248 them. Consequently, undetectability of an IOI cannot be achieved if 249 the IOI is related to a subject(s). 251 On the other side, unobservability can be defined as the 252 undetectability by unrelated subjects together with anonymity (even 253 if an IOIs can be detected). 255 From a user perspective, unobservability ensures that a user may use 256 a resource or service without others, especially third parties, being 257 able to observe that the resource or service is being used. 259 5.5. Pseudonymity 261 Pseudonymity is a weaker property related to anonymity as it means 262 that one cannot identify an entity, but it may be possible to prove 263 that two pseudonyms acts were performed by the same entity. 265 When digital pseudonyms are used, pseudonymity ensures that a user 266 may use a resource or service without disclosing its user identity, 267 but can still be accountable for that use. 269 For more literature about the privacy terminology content, please 270 refer to [ANON], [ISO99], [PRIVNG], [FREEDOM] and [ANONP]. 272 5.6. Location Privacy 274 Location privacy is the ability to prevent other parties from 275 learning one's current and/or past location. In order to get such 276 ability, the concerned (i.e., targeted) node must conceal any 277 relation between its location and the personal identifiable 278 information. 280 In other words, when the location is considered an IOI, then location 281 privacy means the unlinkability between a node's identity and its 282 location. 284 In our context, location privacy refers normally to the topological 285 location and not the geographic one. The latter is provided by other 286 means (e.g., GPS) than an IPv6 address. But it should be noted that 287 it may be possible sometimes to deduce the geographical location from 288 the topological one. 290 6. Security Considerations 292 This document introduces terminology for different privacy aspects. 293 It does not raise any security issues. 295 7. Informative References 297 [ANON] Pfitzman, A. and M. Hansen, "Anonymity, Unlinkability, 298 Unobservability, Pseudonymity, and Identity Management - A 299 consolidated Proposal for Terminology", Draft v0.31, 300 February 2008. 302 [ANONP] Schmidt, M., "Subscriptionless Mobile Networking: 303 Anonymity and Privacy Aspects within Personal Area 304 Networks", IEEE WCNC, 2002. 306 [FREEDOM] Westin, A., "Privacy and Freedom", Atheneum Press, 307 NY, USA, 1967. 309 [ISO99] "ISO IS 15408", http://www.commoncriteria.org/ , 1997. 311 [PRIVNG] Escudero-Pascual, A., "Privacy in the Next Generation 312 Internet", December 2002. 314 [TERM] Bradner, S., "Key Words for Use in RFCs to Indicate 315 Requirement Levels", RFC 2119, BCP , March 1997. 317 Authors' Addresses 319 Wassim Haddad 320 Qualcomm 321 500 Somerset Corporate Blvd 322 Bridgewater, NJ 08807 323 USA 325 Phone: +1 908 9385027 326 Email: whaddad@qualcomm.com 328 Erik Nordmark 329 Sun Microsystems 330 17 Network Circle 331 Menlo Park, CA 94025 332 USA 334 Phone: +1 650 786 2921 335 Email: Erik.Nordmark@sun.com