idnits 2.17.00 (12 Aug 2021) /tmp/idnits54283/draft-haddad-alien-privacy-terminology-06.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 (November 11, 2010) is 4202 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 Ericsson 4 Intended status: Informational E. Nordmark 5 Expires: May 15, 2011 Oracle 6 November 11, 2010 8 Privacy Aspects Terminology 9 draft-haddad-alien-privacy-terminology-06 11 Abstract 13 This memo introduces terminology for the main privacy aspects. The 14 prime goal is to avoid situations where different interpretations of 15 the same key privacy aspects result in different requirements when 16 designing specific solutions, thus leading to an unnecessary 17 confusion. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on May 15, 2011. 36 Copyright Notice 38 Copyright (c) 2010 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Conventions used in this document . . . . . . . . . . . . . . 4 55 3. General Terminology . . . . . . . . . . . . . . . . . . . . . 5 56 4. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 5. Overview of Different Privacy Aspects . . . . . . . . . . . . 7 58 5.1. Anonymity . . . . . . . . . . . . . . . . . . . . . . . . 7 59 5.2. Unlinkability . . . . . . . . . . . . . . . . . . . . . . 7 60 5.3. Relation Between Anonymity and Unlinkability . . . . . . . 8 61 5.4. Undetectability and Unobservability . . . . . . . . . . . 8 62 5.5. Pseudonymity . . . . . . . . . . . . . . . . . . . . . . . 9 63 5.6. Location Privacy . . . . . . . . . . . . . . . . . . . . . 9 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 65 7. Informative References . . . . . . . . . . . . . . . . . . . . 11 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 68 1. Introduction 70 Privacy is becoming a key requirement to allow deployment of specific 71 internet services. However, privacy has many aspects, which differ 72 in scope, properties and limitations. 74 To avoid any possible confusion in ongoing and future works with 75 regard to the meanings of privacy in some particular scenarios, and 76 to differentiate between requirements related to each scenario, 77 privacy aspects have to be well defined before designing any 78 solution. It is the intention of this memo to introduce terminology 79 for the main aspects of privacy. 81 2. Conventions used in this document 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in [TERM]. 87 3. General Terminology 89 Item of Interest (IOI) 91 An Item of Interest (IOI) represents what an attacker is trying to 92 discover, learn, trace and possibly link to other IOI(s), in order 93 to identify its target. Examples of IOI include a subject, event, 94 action (e.g., send, receive, move, etc), specific type of 95 messages, etc. 97 Knowledge 99 In the field of privacy, knowledge refers to the information 100 available to an attacker about its target. In terms of IOI, 101 knowledge can be described by the probability of one or more IOIs. 102 Consequently, more knowledge means more accurate probabilities. 103 We refer to any prior information available to an attacker about a 104 specific target as background knowledge. 106 Pseudonym 108 A pseudonym is an identifier of a subject (e.g., user) to a 109 particular transaction, which is different than any of the user's 110 real names. This means that in the normal course of events, a 111 pseudonym is not sufficient to associate the transaction to a 112 particular subject. 114 Digital Pseudonym 116 A digital pseudonym is a unique identifier (at least with very 117 high probability) suitable to be used to authenticate the holder's 118 IOIs relatively to his/her digital pseudonym, e.g., to 119 authenticate his/her messages sent. 120 Another utility example is to set up an online account with an 121 organization without revealing personal information, e.g., a 122 public key. 123 Note that using digital pseudonyms, accountability can be realized 124 with respect to pseudonyms. 126 4. Privacy 128 Privacy is a fundamental human right. The most common definition of 129 privacy is the one by Alan Westin: "Privacy is the claim of 130 individuals, groups and institutions to determine for themselves, 131 when, how and to what extent information about them is communicated 132 to others". 134 Privacy is a general term that involves several different aspects. 135 These aspects enable features like hiding the node's address(es) 136 (e.g., MAC and/or IP), name(s) (e.g., DNS), and/or location(s), in 137 addition to hiding specific IOIs. One or more of these features can 138 be obtained during one particular session. 140 In wireless telecommunications, privacy addresses especially the 141 protection of the content as well as the context (e.g., time, 142 location, type of service, ...) of a communication event. 144 Consequently, neither the mobile node nor its system software shall 145 support the creation of user-related usage profiles. Such profiles 146 basically comprise of a correlation of time and location of the 147 node's use, as well as the type and details of the transaction 148 performed. 150 The main prvacy aspects are anonymity, unlinkability, 151 undetectability, unobservability, and pseudonymity. Note that one 152 way to achieve privacy is by disconnectivity, i.e., not being 153 connected to a network. 155 5. Overview of Different Privacy Aspects 157 As mentioned above, privacy is a general term, which refers to many 158 different aspects. In the following, we define the main privacy 159 aspects and describe the different relations between them. 161 5.1. Anonymity 163 Anonymity is the state of being not identifiable within a set of 164 subjects (e.g., node, user) called anonymity set. The sender(s) 165 anonymity set(s) can be the same as the recipient(s) anonymity set(s) 166 or they can overlap or simply be disjoint. But it should be noted 167 that a set of possible subjects depends only on the knowledge of the 168 attacker and may vary overtime. However, as the attacker's knowledge 169 is expected to only increase in most applications, this means that 170 the anonymity set can only decrease. Consequently, anonymity is the 171 stronger, the larger the respective anonymity set is. Following the 172 above description, it becomes clear that the anonymity concept is 173 very much context dependent. 175 In the security field, anonymity is a property of network security. 176 An entity "A" in a set has anonymity if no other entity can identify 177 "A", nor is there any link back to "A" that can be used, nor any way 178 to verify that any two anonymous act are performed by "A". 180 From a user perspective, anonymity ensures that a user may use a 181 resource or service without disclosing the user's identity. 183 In wireless networks, anonymity means that neither the mobile node 184 nor its system shall by default expose any information that allows 185 any conclusions on the owner or current use of the node. 187 Consequently, in scenarios where a device and/or network identifiers 188 are used (e.g., MAC address, IP address), neither the communication 189 partner nor any outside attacker should be able to disclose any 190 possible link between the respective identifier and the user's 191 identity. 193 5.2. Unlinkability 195 Unlinkability of two or more IOIs means that from an attacker's 196 perspective, these IOIs are no more and no less related after his 197 observation than they are related with regards to his background 198 knowledge. 200 For example, two messages (e.g., binding updates) are unlinkable for 201 an attacker if the a-posteriori probability describing his background 202 knowledge that these two messages are sent by the same sender and/or 203 received by the same recipient is the same as the probability imposed 204 by his a-priori knowledge (i.e., by observing the system). 206 From a user perspective, unlinkability ensures that a user may make 207 multiple uses of resources or services without other being able to 208 link these uses together. 210 5.3. Relation Between Anonymity and Unlinkability 212 In terms of unlinkability, anonymity can be defined as the 213 unlinkability of an IOI and any subject. For example, a sender 214 anonymity means that a particular message is not linkable to any 215 sender and that to a particular sender, no message is linkable. The 216 same is true for recipient anonymity. 218 If we consider as an example, that the subject is a pseudonym, this 219 means that the anonymity of a particular IOI can be defined as the 220 unlinkability of the IOI to any pseudonym and an anonymous pseudonym 221 is not linkable to any IOI. 223 A weaker property than the sender's anonymity and the recipient's 224 anonymity is the "relationship anonymity" where two or more 225 pseudonyms are unlinkable. This means that for senders and 226 recipients, it is not possible to trace who is communicating with 227 whom, though it may possible to trace who is the sender, or who is 228 the recipient. In other words, sender's pseudonyms and recipient's 229 pseudonyms are unlinkable. 231 5.4. Undetectability and Unobservability 233 As described above, the anonymity and unlinkability states protect 234 the relationship between an IOI and a subject(s) or other IOI(s). 235 This means that in scenarios where anonymity and/or unlinkability are 236 required, senders and recipients can still exchange unprotected 237 IOI(s). 239 In contrast to anonymity and unlinkability, the undetectability of 240 IOIs is the state that whether they exist or not is 241 indistinguishable. In other words, undetectability protects IOIs 242 from being exposed. That is, the message transmission is not 243 discernable from a random noise. In addition, unlinkability does not 244 mention any relationship between "could-be" IOIs and subjects causing 245 them. Consequently, undetectability of an IOI cannot be achieved if 246 the IOI is related to a subject(s). 248 On the other side, unobservability can be defined as the 249 undetectability by unrelated subjects together with anonymity (even 250 if an IOIs can be detected). 252 From a user perspective, unobservability ensures that a user may use 253 a resource or service without others, especially third parties, being 254 able to observe that the resource or service is being used. 256 5.5. Pseudonymity 258 Pseudonymity is a weaker property related to anonymity as it means 259 that one cannot identify an entity, but it may be possible to prove 260 that two pseudonyms acts were performed by the same entity. 262 When digital pseudonyms are used, pseudonymity ensures that a user 263 may use a resource or service without disclosing its user identity, 264 but can still be accountable for that use. 266 For more literature about the privacy terminology content, please 267 refer to [ANON], [ISO99], [PRIVNG], [FREEDOM] and [ANONP]. 269 5.6. Location Privacy 271 Location privacy is the ability to prevent other parties from 272 learning one's current and/or past location. In order to get such 273 ability, the concerned (i.e., targeted) node must conceal any 274 relation between its location and the personal identifiable 275 information. 277 In other words, when the location is considered an IOI, then location 278 privacy means the unlinkability between a node's identity and its 279 location. 281 In our context, location privacy refers normally to the topological 282 location and not the geographic one. The latter is provided by other 283 means (e.g., GPS) than an IPv6 address. But it should be noted that 284 it may be possible sometimes to deduce the geographical location from 285 the topological one. 287 6. Security Considerations 289 This document introduces terminology for different privacy aspects. 290 It does not raise any security issues. 292 7. Informative References 294 [ANON] Pfitzman, A. and M. Hansen, "Anonymity, Unlinkability, 295 Unobservability, Pseudonymity, and Identity Management - A 296 consolidated Proposal for Terminology", Draft v0.31, 297 February 2008. 299 [ANONP] Schmidt, M., "Subscriptionless Mobile Networking: 300 Anonymity and Privacy Aspects within Personal Area 301 Networks", IEEE WCNC, 2002. 303 [FREEDOM] Westin, A., "Privacy and Freedom", Atheneum Press, 304 NY, USA, 1967. 306 [ISO99] "ISO IS 15408", http://www.commoncriteria.org/ , 1997. 308 [PRIVNG] Escudero-Pascual, A., "Privacy in the Next Generation 309 Internet", December 2002. 311 [TERM] Bradner, S., "Key Words for Use in RFCs to Indicate 312 Requirement Levels", RFC 2119, BCP , March 1997. 314 Authors' Addresses 316 Wassim Haddad 317 Ericsson 318 300 Holger Way 319 San Jose, CA 95134 320 USA 322 Phone: +1 646 2562030 323 Email: Wassim.Haddad@ericsson.com 325 Erik Nordmark 326 Oracle 327 17 Network Circle 328 Menlo Park, CA 94025 329 USA 331 Phone: +1 650 786 2921 332 Email: Erik.Nordmark@oracle.com