idnits 2.17.1 draft-haddad-alien-privacy-terminology-03.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 346. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 357. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 364. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 370. 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 (October 28, 2007) is 6017 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 Ericsson Research 4 Intended status: Informational E. Nordmark 5 Expires: April 30, 2008 Sun Microsystems 6 October 28, 2007 8 Privacy Aspects Terminology 9 draft-haddad-alien-privacy-terminology-03 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 April 30, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This memo introduces terminology for the main privacy aspects. The 43 prime goal is to avoid situations where different interpretations of 44 the same key privacy aspects result in different requirements when 45 designing specific solutions, thus leading to an unnecessary 46 confusion. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Conventions used in this document . . . . . . . . . . . . . . 4 52 3. General Terminology . . . . . . . . . . . . . . . . . . . . . 5 53 4. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 54 5. Overview of Different Privacy Aspects . . . . . . . . . . . . 7 55 5.1. Anonymity . . . . . . . . . . . . . . . . . . . . . . . . 7 56 5.2. Unlinkability . . . . . . . . . . . . . . . . . . . . . . 7 57 5.3. Relation Between Anonymity and Unlinkability . . . . . . . 8 58 5.4. Undetectability and Unobservability . . . . . . . . . . . 8 59 5.5. Pseudonymity . . . . . . . . . . . . . . . . . . . . . . . 9 60 5.6. Location Privacy . . . . . . . . . . . . . . . . . . . . . 9 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 62 7. Informative References . . . . . . . . . . . . . . . . . . . . 11 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 64 Intellectual Property and Copyright Statements . . . . . . . . . . 13 66 1. Introduction 68 Privacy is becoming a key requirement to allow deployment of specific 69 internet services. However, privacy has many aspects, which differ 70 in scope, properties and limitations. 72 To avoid any possible confusion in ongoing and future works with 73 regard to the meanings of privacy in some particular scenarios, and 74 to differentiate between requirements related to each scenario, 75 privacy aspects have to be well defined before designing any 76 solution. It is the intention of this memo to introduce terminology 77 for the main aspects of privacy. 79 2. Conventions used in this document 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in [TERM]. 85 3. General Terminology 87 Item of Interest (IOI) 89 An Item of Interest (IOI) represents what an attacker is trying to 90 discover, learn, trace and possibly link to other IOI(s), in order 91 to identify its target. Examples of IOI include a subject, event, 92 action (e.g., send, receive, move, etc), specific type of 93 messages, etc. 95 Knowledge 97 In the field of privacy, knowledge refers to the information 98 available to an attacker about its target. In terms of IOI, 99 knowledge can be described by the probability of one or more IOIs. 100 Consequently, more knowledge means more accurate probabilities. 101 We refer to any prior information available to an attacker about a 102 specific target as background knowledge. 104 Pseudonym 106 A pseudonym is an identifier of a subject (e.g., user) to a 107 particular transaction, which is different than any of the user's 108 real names. This means that in the normal course of events, a 109 pseudonym is not sufficient to associate the transaction to a 110 particular subject. 112 Digital Pseudonym 114 A digital pseudonym is a unique identifier (at least with very 115 high probability) suitable to be used to authenticate the holder's 116 IOIs relatively to his/her digital pseudonym, e.g., to 117 authenticate his/her messages sent. 118 Another utility example is to set up an online account with an 119 organization without revealing personal information, e.g., a 120 public key. 121 Note that using digital pseudonyms, accountability can be realized 122 with respect to pseudonyms. 124 4. Privacy 126 Privacy is a fundamental human right. The most common definition of 127 privacy is the one by Alan Westin: "Privacy is the claim of 128 individuals, groups and institutions to determine for themselves, 129 when, how and to what extent information about them is communicated 130 to others". 132 Privacy is a general term that involves several different aspects. 133 These aspects enable features like hiding the node's address(es) 134 (e.g., MAC and/or IP), name(s) (e.g., DNS), and/or location(s), in 135 addition to hiding specific IOIs. One or more of these features can 136 be obtained during one particular session. 138 In wireless telecommunications, privacy addresses especially the 139 protection of the content as well as the context (e.g., time, 140 location, type of service, ...) of a communication event. 142 Consequently, neither the mobile node nor its system software shall 143 support the creation of user-related usage profiles. Such profiles 144 basically comprise of a correlation of time and location of the 145 node's use, as well as the type and details of the transaction 146 performed. 148 The main prvacy aspects are anonymity, unlinkability, 149 undetectability, unobservability, and pseudonymity. Note that one 150 way to achieve privacy is by disconnectivity, i.e., not being 151 connected to a network. 153 5. Overview of Different Privacy Aspects 155 As mentioned above, privacy is a general term, which refers to many 156 different aspects. In the following, we define the main privacy 157 aspects and describe the different relations between them. 159 5.1. Anonymity 161 Anonymity is the state of being not identifiable within a set of 162 subjects (e.g., node, user) called anonymity set. The sender(s) 163 anonymity set(s) can be the same as the recipient(s) anonymity set(s) 164 or they can overlap or simply be disjoint. But it should be noted 165 that a set of possible subjects depends only on the knowledge of the 166 attacker and may vary overtime. However, as the attacker's knowledge 167 is expected to only increase in most applications, this means that 168 the anonymity set can only decrease. Consequently, anonymity is the 169 stronger, the larger the respective anonymity set is. Following the 170 above description, it becomes clear that the anonymity concept is 171 very much context dependent. 173 In the security field, anonymity is a property of network security. 174 An entity "A" in a set has anonymity if no other entity can identify 175 "A", nor is there any link back to "A" that can be used, nor any way 176 to verify that any two anonymous act are performed by "A". 178 From a user perspective, anonymity ensures that a user may use a 179 resource or service without disclosing the user's identity. 181 In wireless networks, anonymity means that neither the mobile node 182 nor its system shall by default expose any information that allows 183 any conclusions on the owner or current use of the node. 185 Consequently, in scenarios where a device and/or network identifiers 186 are used (e.g., MAC address, IP address), neither the communication 187 partner nor any outside attacker should be able to disclose any 188 possible link between the respective identifier and the user's 189 identity. 191 5.2. Unlinkability 193 Unlinkability of two or more IOIs means that from an attacker's 194 perspective, these IOIs are no more and no less related after his 195 observation than they are related with regards to his background 196 knowledge. 198 For example, two messages (e.g., binding updates) are unlinkable for 199 an attacker if the a-posteriori probability describing his background 200 knowledge that these two messages are sent by the same sender and/or 201 received by the same recipient is the same as the probability imposed 202 by his a-priori knowledge (i.e., by observing the system). 204 From a user perspective, unlinkability ensures that a user may make 205 multiple uses of resources or services without other being able to 206 link these uses together. 208 5.3. Relation Between Anonymity and Unlinkability 210 In terms of unlinkability, anonymity can be defined as the 211 unlinkability of an IOI and any subject. For example, a sender 212 anonymity means that a particular message is not linkable to any 213 sender and that to a particular sender, no message is linkable. The 214 same is true for recipient anonymity. 216 If we consider as an example, that the subject is a pseudonym, this 217 means that the anonymity of a particular IOI can be defined as the 218 unlinkability of the IOI to any pseudonym and an anonymous pseudonym 219 is not linkable to any IOI. 221 A weaker property than the sender's anonymity and the recipient's 222 anonymity is the "relationship anonymity" where two or more 223 pseudonyms are unlinkable. This means that for senders and 224 recipients, it is not possible to trace who is communicating with 225 whom, though it may possible to trace who is the sender, or who is 226 the recipient. In other words, sender's pseudonyms and recipient's 227 pseudonyms are unlinkable. 229 5.4. Undetectability and Unobservability 231 As described above, the anonymity and unlinkability states protect 232 the relationship between an IOI and a subject(s) or other IOI(s). 233 This means that in scenarios where anonymity and/or unlinkability are 234 required, senders and recipients can still exchange unprotected 235 IOI(s). 237 In contrast to anonymity and unlinkability, the undetectability of 238 IOIs is the state that whether they exist or not is 239 indistinguishable. In other words, undetectability protects IOIs 240 from being exposed. That is, the message transmission is not 241 discernable from a random noise. In addition, unlinkability does not 242 mention any relationship between "could-be" IOIs and subjects causing 243 them. Consequently, undetectability of an IOI cannot be achieved if 244 the IOI is related to a subject(s). 246 On the other side, unobservability can be defined as the 247 undetectability by unrelated subjects together with anonymity (even 248 if an IOIs can be detected). 250 From a user perspective, unobservability ensures that a user may use 251 a resource or service without others, especially third parties, being 252 able to observe that the resource or service is being used. 254 5.5. Pseudonymity 256 Pseudonymity is a weaker property related to anonymity as it means 257 that one cannot identify an entity, but it may be possible to prove 258 that two pseudonyms acts were performed by the same entity. 260 When digital pseudonyms are used, pseudonymity ensures that a user 261 may use a resource or service without disclosing its user identity, 262 but can still be accountable for that use. 264 For more literature about the privacy terminology content, please 265 refer to [ANON], [ISO99], [PRIVNG], [FREEDOM] and [ANONP]. 267 5.6. Location Privacy 269 Location privacy is the ability to prevent other parties from 270 learning one's current and/or past location. In order to get such 271 ability, the concerned (i.e., targeted) node must conceal any 272 relation between its location and the personal identifiable 273 information. 275 In other words, when the location is considered an IOI, then location 276 privacy means the unlinkability between a node's identity and its 277 location. 279 In our context, location privacy refers normally to the topological 280 location and not the geographic one. The latter is provided by other 281 means (e.g., GPS) than an IPv6 address. But it should be noted that 282 it may be possible sometimes to deduce the geographical location from 283 the topological one. 285 6. Security Considerations 287 This document introduces terminology for different privacy aspects. 288 It does not raise any security issues. 290 7. Informative References 292 [ANON] Pfitzman, A. and M. Hansen, "Anonymity, Unlinkability, 293 Unobservability, Pseudonymity, and Identity Management - A 294 consolidated Proposal for Terminology", Draft v0.29, 295 July 2007. 297 [ANONP] Schmidt, M., "Subscriptionless Mobile Networking: 298 Anonymity and Privacy Aspects within Personal Area 299 Networks", IEEE WCNC, 2002. 301 [FREEDOM] Westin, A., "Privacy and Freedom", Atheneum Press, 302 NY, USA, 1967. 304 [ISO99] "ISO IS 15408", http://www.commoncriteria.org/ , 1997. 306 [PRIVNG] Escudero-Pascual, A., "Privacy in the Next Generation 307 Internet", December 2002. 309 [TERM] Bradner, S., "Key Words for Use in RFCs to Indicate 310 Requirement Levels", RFC 2119, BCP , March 1997. 312 Authors' Addresses 314 Wassim Haddad 315 Ericsson Research 316 Torshamnsgatan 23 317 SE-164 Stockholm 318 Sweden 320 Phone: +46 84044079 321 Email: Wassim.Haddad@ericsson.com 323 Erik Nordmark 324 Sun Microsystems 325 17 Network Circle 326 Menlo Park, CA 94025 327 USA 329 Phone: +1 650 786 2921 330 Email: Erik.Nordmark@sun.com 332 Full Copyright Statement 334 Copyright (C) The IETF Trust (2007). 336 This document is subject to the rights, licenses and restrictions 337 contained in BCP 78, and except as set forth therein, the authors 338 retain all their rights. 340 This document and the information contained herein are provided on an 341 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 342 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 343 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 344 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 345 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 346 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 348 Intellectual Property 350 The IETF takes no position regarding the validity or scope of any 351 Intellectual Property Rights or other rights that might be claimed to 352 pertain to the implementation or use of the technology described in 353 this document or the extent to which any license under such rights 354 might or might not be available; nor does it represent that it has 355 made any independent effort to identify any such rights. Information 356 on the procedures with respect to rights in RFC documents can be 357 found in BCP 78 and BCP 79. 359 Copies of IPR disclosures made to the IETF Secretariat and any 360 assurances of licenses to be made available, or the result of an 361 attempt made to obtain a general license or permission for the use of 362 such proprietary rights by implementers or users of this 363 specification can be obtained from the IETF on-line IPR repository at 364 http://www.ietf.org/ipr. 366 The IETF invites any interested party to bring to its attention any 367 copyrights, patents or patent applications, or other proprietary 368 rights that may cover technology that may be required to implement 369 this standard. Please address the information to the IETF at 370 ietf-ipr@ietf.org. 372 Acknowledgment 374 Funding for the RFC Editor function is provided by the IETF 375 Administrative Support Activity (IASA).