idnits 2.17.1 draft-haddad-alien-privacy-terminology-01.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 on line 314. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 291. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 298. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 304. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 : ---------------------------------------------------------------------------- ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 26, 2006) is 6514 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'ANON' -- Possible downref: Non-RFC (?) normative reference: ref. 'ANON-PRIV' -- Possible downref: Non-RFC (?) normative reference: ref. 'FREEDOM' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO99' -- Possible downref: Non-RFC (?) normative reference: ref. 'PRIVNG' Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 12 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 Expires: December 28, 2006 E. Nordmark 5 Sun Microsystems 6 June 26, 2006 8 Privacy Aspects Terminology 9 draft-haddad-alien-privacy-terminology-01 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 28, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This memo introduces the terminology for the main privacy aspects. 43 The prime goal is to avoid situations where different interpretations 44 of 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. Location Privacy . . . . . . . . . . . . . . . . . . . . . . . 7 55 6. Overview of Different Privacy Aspects . . . . . . . . . . . . 8 56 6.1. Anonymity . . . . . . . . . . . . . . . . . . . . . . . . 8 57 6.2. Unlinkability . . . . . . . . . . . . . . . . . . . . . . 8 58 6.3. Unobservability . . . . . . . . . . . . . . . . . . . . . 9 59 6.4. Relation Between Anonymity and Unlinkability . . . . . . . 9 60 6.5. Pseudonymity . . . . . . . . . . . . . . . . . . . . . . . 9 61 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 62 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 64 Intellectual Property and Copyright Statements . . . . . . . . . . 12 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 with regard to the meanings of 73 privacy in some particular scenarios and to differentiate between 74 requirements related to each scenario, privacy aspects have to be 75 well defined before designing any solution. It is the intention of 76 this memo to introduce the terminology for the main aspects of 77 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 to 91 identify its target. Examples of IOI include a subject, event, 92 action (e.g., send, receive, move, etc), specific type of messages, 93 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 We refer to any prior information available to an attacker about a 101 specific target as background knowledge. 103 4. Privacy 105 Privacy is a fundamental human right. The most common definition of 106 privacy is the one by Alan Westin: "Pivacy is the claim of 107 individuals, groups and institutions to determine for themesleves, 108 when, how and to what extent information about them is communicated 109 to others". 111 Privacy is a general term that involves several different aspects. 112 These aspects enable features like hiding the node's address(es) 113 (e.g., MAC and/or IP), name(s) (e.g., DNS), and/or location(s), in 114 addition to hiding specific IOIs. One or more of these features can 115 be obtained during one particular session. 117 In wireless telecommunications, privacy addresses especially the 118 protection of the content as well as the context (e.g., time, 119 location, type of service, ...) of a communication event. 121 Consequently, neither the mobile node nor its system software shall 122 support the creation of user-related usage profiles. Such profiles 123 basically comprise of a correlation of time and location of the 124 node's use, as well as the type and details of the transaction 125 performed. 127 The main prvacy aspects are anonymity, unlinkability, 128 unobservability, and pseudonymity. Note that privacy can be achieved 129 by disconnectivity, i.e., not being connected to a network. 131 5. Location Privacy 133 Location privacy is the ability to prevent other parties from 134 learning one's current and/or past location. In order to get such 135 ability, the concerned (i.e., targeted) node must conceal any 136 relation between its location and the personal identifiable 137 information. 139 In our context, location privacy refers normally to the topological 140 location and not the geographic one. The latter is provided by other 141 means (e.g., GPS) than an IPv6 address. But it should be noted that 142 it may be possible sometimes to deduce the geographical location from 143 the topological one. 145 6. Overview of Different Privacy Aspects 147 As mentioned above, privacy is a general term, which refers to many 148 different aspects. In the following, we define the main privacy 149 aspects and describe the different relations between them. 151 6.1. Anonymity 153 Anonymity is the state of being not uniquely characterized, i.e., 154 identifiable, within a set of subjects (e.g., node, user) called the 155 anonymity set. The set of possible subjects depends on the knowledge 156 of the attacker and may vary overtime. Thus, anonymity is relative 157 with respect to the attacker and is very much context dependent. 159 In the security field, anonymity is a property of network security. 160 An entity "A" in a set has anonymity if no other entity can identify 161 "A", nor is there any link back to "A" that can be used, nor any way 162 to verify that any two anonymous act are performed by "A". 164 From a user perspective, anonymity ensures that a user may use a 165 resource or service without disclosing the user's identity. 167 In wireless networks, anonymity means that neither the mobile node 168 nor its system shall by default expose any information, that allows 169 any conclusions on the owner or current use of the node. 171 Consequently, in scenarios where a device and/or network identifiers 172 are used (e.g., MAC address, IP address), neither the communication 173 partner nor any outside attacker should be able to disclose any 174 possible link between the respective identifier and the user's 175 identity. 177 6.2. Unlinkability 179 Unlinkability of two or more IOIs means that from an attacker's 180 perspective, these IOIs are no more and no less related after his 181 observation than they are related concerning his background 182 knowledge. 184 For example, two messages (e.g., binding updates) are unlinkable for 185 an attacker if the a-posteriori probability describing his background 186 knowledge that these two messages are sent by the same sender and/or 187 received by the same recipient is the same as the probability imposed 188 by his a-priori knowledge. 190 From a user perspective, unlinkability ensures that a user may make 191 multiple uses of resources or services without other being able to 192 link these uses together. 194 6.3. Unobservability 196 Unobservability is the state of IOIs being indistinguishable from any 197 IOI. This means that messages are not discernable from e.g., random 198 noise. Consequently, unobservability deals with events instead of 199 subjects. 201 From a user perspective, unobservability ensures that a user may use 202 a resource or service without others, especially third parties, being 203 able to observe that the resource or service is being used. 205 6.4. Relation Between Anonymity and Unlinkability 207 In terms of unlinkability, anonymity can be defined as the 208 unlikability of an IOI and any identifier of a subject. 209 Consequently, unlinkability is a sufficient condition of anonymity 210 but is not a necessary condition. 212 6.5. Pseudonymity 214 Pseudonymity is a weaker property related to anonymity. It means 215 that one cannot identify an entity, but it may be possible to prove 216 that two pseudonyms acts were performed by the same entity. 218 From a user perspective, pseudonymity ensures that a user may use a 219 resource or service without disclosing its user identity, but can 220 still be accountable for that use. 222 Consequently, a pseudonym is an identifier for a party to a 223 transaction, which is not in the normal course of events, sufficient 224 to associate the transaction with a particular user. 226 Hence a transaction is pseudonymous in relation to a particular party 227 if the transaction data contains no direct identifier for that party, 228 and can only be related to them in the event that a very specific 229 piece of additional data is associated with it. 231 For more literature about the privacy terminology content, please 232 refer to [ANON], [ISO99], [PRIVNG], [FREEDOM] and [ANON-PRIV]. 234 7. Security Considerations 236 This document introduces terminology for different privacy aspects. 237 It does not raise any security issues. 239 8. References 241 [ANON] Pfitzman, A. and M. Hansen, "Anonymity, Unlinkability, 242 Unobservability, Pseudonymity, and Identity Management - A 243 consolidated Proposal for Terminology", Draft v0.28, 244 May 2006. 246 [ANON-PRIV] 247 Schmidt, M., "Subscriptionless Mobile Networking: 248 Anonymity and Privacy Aspects within Personal Area 249 Networks", IEEE WCNC, 2002. 251 [FREEDOM] Westin, A., "Privacy and Freedom", Atheneum Press, 252 NY, USA, 1967. 254 [ISO99] "ISO IS 15408", http://www.commoncriteria.org/ , 1997. 256 [PRIVNG] Escudero-Pascual, A., "Privacy in the Next Generation 257 Internet", December 2002. 259 [TERM] Bradner, S., "Key Words for Use in RFCs to Indicate 260 Requirement Levels", RFC 2119, BCP , March 1997. 262 Authors' Addresses 264 Wassim Haddad 265 Ericsson Research 266 Torshamnsgatan 23 267 SE-164 Stockholm 268 Sweden 270 Phone: +46 84044079 271 Email: Wassim.Haddad@ericsson.com 273 Erik Nordmark 274 Sun Microsystems 275 17 Network Circle 276 Menlo Park, CA 94025 277 USA 279 Phone: +1 650 786 2921 280 Email: Erik.Nordmark@sun.com 282 Intellectual Property Statement 284 The IETF takes no position regarding the validity or scope of any 285 Intellectual Property Rights or other rights that might be claimed to 286 pertain to the implementation or use of the technology described in 287 this document or the extent to which any license under such rights 288 might or might not be available; nor does it represent that it has 289 made any independent effort to identify any such rights. Information 290 on the procedures with respect to rights in RFC documents can be 291 found in BCP 78 and BCP 79. 293 Copies of IPR disclosures made to the IETF Secretariat and any 294 assurances of licenses to be made available, or the result of an 295 attempt made to obtain a general license or permission for the use of 296 such proprietary rights by implementers or users of this 297 specification can be obtained from the IETF on-line IPR repository at 298 http://www.ietf.org/ipr. 300 The IETF invites any interested party to bring to its attention any 301 copyrights, patents or patent applications, or other proprietary 302 rights that may cover technology that may be required to implement 303 this standard. Please address the information to the IETF at 304 ietf-ipr@ietf.org. 306 Disclaimer of Validity 308 This document and the information contained herein are provided on an 309 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 310 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 311 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 312 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 313 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 314 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 316 Copyright Statement 318 Copyright (C) The Internet Society (2006). This document is subject 319 to the rights, licenses and restrictions contained in BCP 78, and 320 except as set forth therein, the authors retain all their rights. 322 Acknowledgment 324 Funding for the RFC Editor function is currently provided by the 325 Internet Society.