idnits 2.17.1 draft-haddad-alien-privacy-terminology-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 342. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 353. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 360. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 366. 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 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 (June 25, 2008) is 5777 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 7 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: December 27, 2008 Sun Microsystems 6 June 25, 2008 8 Privacy Aspects Terminology 9 draft-haddad-alien-privacy-terminology-04 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 27, 2008. 36 Abstract 38 This memo introduces terminology for the main privacy aspects. The 39 prime goal is to avoid situations where different interpretations of 40 the same key privacy aspects result in different requirements when 41 designing specific solutions, thus leading to an unnecessary 42 confusion. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 2. Conventions used in this document . . . . . . . . . . . . . . 4 48 3. General Terminology . . . . . . . . . . . . . . . . . . . . . 5 49 4. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 50 5. Overview of Different Privacy Aspects . . . . . . . . . . . . 7 51 5.1. Anonymity . . . . . . . . . . . . . . . . . . . . . . . . 7 52 5.2. Unlinkability . . . . . . . . . . . . . . . . . . . . . . 7 53 5.3. Relation Between Anonymity and Unlinkability . . . . . . . 8 54 5.4. Undetectability and Unobservability . . . . . . . . . . . 8 55 5.5. Pseudonymity . . . . . . . . . . . . . . . . . . . . . . . 9 56 5.6. Location Privacy . . . . . . . . . . . . . . . . . . . . . 9 57 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 58 7. Informative References . . . . . . . . . . . . . . . . . . . . 11 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 60 Intellectual Property and Copyright Statements . . . . . . . . . . 13 62 1. Introduction 64 Privacy is becoming a key requirement to allow deployment of specific 65 internet services. However, privacy has many aspects, which differ 66 in scope, properties and limitations. 68 To avoid any possible confusion in ongoing and future works with 69 regard to the meanings of privacy in some particular scenarios, and 70 to differentiate between requirements related to each scenario, 71 privacy aspects have to be well defined before designing any 72 solution. It is the intention of this memo to introduce terminology 73 for the main aspects of privacy. 75 2. Conventions used in this document 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in [TERM]. 81 3. General Terminology 83 Item of Interest (IOI) 85 An Item of Interest (IOI) represents what an attacker is trying to 86 discover, learn, trace and possibly link to other IOI(s), in order 87 to identify its target. Examples of IOI include a subject, event, 88 action (e.g., send, receive, move, etc), specific type of 89 messages, etc. 91 Knowledge 93 In the field of privacy, knowledge refers to the information 94 available to an attacker about its target. In terms of IOI, 95 knowledge can be described by the probability of one or more IOIs. 96 Consequently, more knowledge means more accurate probabilities. 97 We refer to any prior information available to an attacker about a 98 specific target as background knowledge. 100 Pseudonym 102 A pseudonym is an identifier of a subject (e.g., user) to a 103 particular transaction, which is different than any of the user's 104 real names. This means that in the normal course of events, a 105 pseudonym is not sufficient to associate the transaction to a 106 particular subject. 108 Digital Pseudonym 110 A digital pseudonym is a unique identifier (at least with very 111 high probability) suitable to be used to authenticate the holder's 112 IOIs relatively to his/her digital pseudonym, e.g., to 113 authenticate his/her messages sent. 114 Another utility example is to set up an online account with an 115 organization without revealing personal information, e.g., a 116 public key. 117 Note that using digital pseudonyms, accountability can be realized 118 with respect to pseudonyms. 120 4. Privacy 122 Privacy is a fundamental human right. The most common definition of 123 privacy is the one by Alan Westin: "Privacy is the claim of 124 individuals, groups and institutions to determine for themselves, 125 when, how and to what extent information about them is communicated 126 to others". 128 Privacy is a general term that involves several different aspects. 129 These aspects enable features like hiding the node's address(es) 130 (e.g., MAC and/or IP), name(s) (e.g., DNS), and/or location(s), in 131 addition to hiding specific IOIs. One or more of these features can 132 be obtained during one particular session. 134 In wireless telecommunications, privacy addresses especially the 135 protection of the content as well as the context (e.g., time, 136 location, type of service, ...) of a communication event. 138 Consequently, neither the mobile node nor its system software shall 139 support the creation of user-related usage profiles. Such profiles 140 basically comprise of a correlation of time and location of the 141 node's use, as well as the type and details of the transaction 142 performed. 144 The main prvacy aspects are anonymity, unlinkability, 145 undetectability, unobservability, and pseudonymity. Note that one 146 way to achieve privacy is by disconnectivity, i.e., not being 147 connected to a network. 149 5. Overview of Different Privacy Aspects 151 As mentioned above, privacy is a general term, which refers to many 152 different aspects. In the following, we define the main privacy 153 aspects and describe the different relations between them. 155 5.1. Anonymity 157 Anonymity is the state of being not identifiable within a set of 158 subjects (e.g., node, user) called anonymity set. The sender(s) 159 anonymity set(s) can be the same as the recipient(s) anonymity set(s) 160 or they can overlap or simply be disjoint. But it should be noted 161 that a set of possible subjects depends only on the knowledge of the 162 attacker and may vary overtime. However, as the attacker's knowledge 163 is expected to only increase in most applications, this means that 164 the anonymity set can only decrease. Consequently, anonymity is the 165 stronger, the larger the respective anonymity set is. Following the 166 above description, it becomes clear that the anonymity concept is 167 very much context dependent. 169 In the security field, anonymity is a property of network security. 170 An entity "A" in a set has anonymity if no other entity can identify 171 "A", nor is there any link back to "A" that can be used, nor any way 172 to verify that any two anonymous act are performed by "A". 174 From a user perspective, anonymity ensures that a user may use a 175 resource or service without disclosing the user's identity. 177 In wireless networks, anonymity means that neither the mobile node 178 nor its system shall by default expose any information that allows 179 any conclusions on the owner or current use of the node. 181 Consequently, in scenarios where a device and/or network identifiers 182 are used (e.g., MAC address, IP address), neither the communication 183 partner nor any outside attacker should be able to disclose any 184 possible link between the respective identifier and the user's 185 identity. 187 5.2. Unlinkability 189 Unlinkability of two or more IOIs means that from an attacker's 190 perspective, these IOIs are no more and no less related after his 191 observation than they are related with regards to his background 192 knowledge. 194 For example, two messages (e.g., binding updates) are unlinkable for 195 an attacker if the a-posteriori probability describing his background 196 knowledge that these two messages are sent by the same sender and/or 197 received by the same recipient is the same as the probability imposed 198 by his a-priori knowledge (i.e., by observing the system). 200 From a user perspective, unlinkability ensures that a user may make 201 multiple uses of resources or services without other being able to 202 link these uses together. 204 5.3. Relation Between Anonymity and Unlinkability 206 In terms of unlinkability, anonymity can be defined as the 207 unlinkability of an IOI and any subject. For example, a sender 208 anonymity means that a particular message is not linkable to any 209 sender and that to a particular sender, no message is linkable. The 210 same is true for recipient anonymity. 212 If we consider as an example, that the subject is a pseudonym, this 213 means that the anonymity of a particular IOI can be defined as the 214 unlinkability of the IOI to any pseudonym and an anonymous pseudonym 215 is not linkable to any IOI. 217 A weaker property than the sender's anonymity and the recipient's 218 anonymity is the "relationship anonymity" where two or more 219 pseudonyms are unlinkable. This means that for senders and 220 recipients, it is not possible to trace who is communicating with 221 whom, though it may possible to trace who is the sender, or who is 222 the recipient. In other words, sender's pseudonyms and recipient's 223 pseudonyms are unlinkable. 225 5.4. Undetectability and Unobservability 227 As described above, the anonymity and unlinkability states protect 228 the relationship between an IOI and a subject(s) or other IOI(s). 229 This means that in scenarios where anonymity and/or unlinkability are 230 required, senders and recipients can still exchange unprotected 231 IOI(s). 233 In contrast to anonymity and unlinkability, the undetectability of 234 IOIs is the state that whether they exist or not is 235 indistinguishable. In other words, undetectability protects IOIs 236 from being exposed. That is, the message transmission is not 237 discernable from a random noise. In addition, unlinkability does not 238 mention any relationship between "could-be" IOIs and subjects causing 239 them. Consequently, undetectability of an IOI cannot be achieved if 240 the IOI is related to a subject(s). 242 On the other side, unobservability can be defined as the 243 undetectability by unrelated subjects together with anonymity (even 244 if an IOIs can be detected). 246 From a user perspective, unobservability ensures that a user may use 247 a resource or service without others, especially third parties, being 248 able to observe that the resource or service is being used. 250 5.5. Pseudonymity 252 Pseudonymity is a weaker property related to anonymity as it means 253 that one cannot identify an entity, but it may be possible to prove 254 that two pseudonyms acts were performed by the same entity. 256 When digital pseudonyms are used, pseudonymity ensures that a user 257 may use a resource or service without disclosing its user identity, 258 but can still be accountable for that use. 260 For more literature about the privacy terminology content, please 261 refer to [ANON], [ISO99], [PRIVNG], [FREEDOM] and [ANONP]. 263 5.6. Location Privacy 265 Location privacy is the ability to prevent other parties from 266 learning one's current and/or past location. In order to get such 267 ability, the concerned (i.e., targeted) node must conceal any 268 relation between its location and the personal identifiable 269 information. 271 In other words, when the location is considered an IOI, then location 272 privacy means the unlinkability between a node's identity and its 273 location. 275 In our context, location privacy refers normally to the topological 276 location and not the geographic one. The latter is provided by other 277 means (e.g., GPS) than an IPv6 address. But it should be noted that 278 it may be possible sometimes to deduce the geographical location from 279 the topological one. 281 6. Security Considerations 283 This document introduces terminology for different privacy aspects. 284 It does not raise any security issues. 286 7. Informative References 288 [ANON] Pfitzman, A. and M. Hansen, "Anonymity, Unlinkability, 289 Unobservability, Pseudonymity, and Identity Management - A 290 consolidated Proposal for Terminology", Draft v0.29, 291 July 2007. 293 [ANONP] Schmidt, M., "Subscriptionless Mobile Networking: 294 Anonymity and Privacy Aspects within Personal Area 295 Networks", IEEE WCNC, 2002. 297 [FREEDOM] Westin, A., "Privacy and Freedom", Atheneum Press, 298 NY, USA, 1967. 300 [ISO99] "ISO IS 15408", http://www.commoncriteria.org/ , 1997. 302 [PRIVNG] Escudero-Pascual, A., "Privacy in the Next Generation 303 Internet", December 2002. 305 [TERM] Bradner, S., "Key Words for Use in RFCs to Indicate 306 Requirement Levels", RFC 2119, BCP , March 1997. 308 Authors' Addresses 310 Wassim Haddad 311 Qualcomm 312 500 Somerset Corporate Blvd 313 Bridgewater, NJ 08807 314 USA 316 Phone: +1 908 9385027 317 Email: whaddad@qualcomm.com 319 Erik Nordmark 320 Sun Microsystems 321 17 Network Circle 322 Menlo Park, CA 94025 323 USA 325 Phone: +1 650 786 2921 326 Email: Erik.Nordmark@sun.com 328 Full Copyright Statement 330 Copyright (C) The IETF Trust (2008). 332 This document is subject to the rights, licenses and restrictions 333 contained in BCP 78, and except as set forth therein, the authors 334 retain all their rights. 336 This document and the information contained herein are provided on an 337 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 338 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 339 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 340 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 341 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 342 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 344 Intellectual Property 346 The IETF takes no position regarding the validity or scope of any 347 Intellectual Property Rights or other rights that might be claimed to 348 pertain to the implementation or use of the technology described in 349 this document or the extent to which any license under such rights 350 might or might not be available; nor does it represent that it has 351 made any independent effort to identify any such rights. Information 352 on the procedures with respect to rights in RFC documents can be 353 found in BCP 78 and BCP 79. 355 Copies of IPR disclosures made to the IETF Secretariat and any 356 assurances of licenses to be made available, or the result of an 357 attempt made to obtain a general license or permission for the use of 358 such proprietary rights by implementers or users of this 359 specification can be obtained from the IETF on-line IPR repository at 360 http://www.ietf.org/ipr. 362 The IETF invites any interested party to bring to its attention any 363 copyrights, patents or patent applications, or other proprietary 364 rights that may cover technology that may be required to implement 365 this standard. Please address the information to the IETF at 366 ietf-ipr@ietf.org.