idnits 2.17.1 draft-haddad-alien-privacy-terminology-00.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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 329. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 308. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 318. ** 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. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == 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 (October 2005) is 6767 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) == Missing Reference: 'TERM' is mentioned on line 80, but not defined == Missing Reference: 'PRIVNG' is mentioned on line 240, but not defined == Missing Reference: 'FREEDOM' is mentioned on line 240, but not defined == Unused Reference: 'ANONPRIV' is defined on line 254, but no explicit reference was found in the text == Unused Reference: 'Freedom' is defined on line 258, but no explicit reference was found in the text == Unused Reference: 'LOPRIPEC' is defined on line 263, but no explicit reference was found in the text == Unused Reference: 'PRIV-NG' is defined on line 267, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ANON' -- Possible downref: Non-RFC (?) normative reference: ref. 'ANONPRIV' -- Possible downref: Non-RFC (?) normative reference: ref. 'Freedom' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO99' -- Possible downref: Non-RFC (?) normative reference: ref. 'LOPRIPEC' -- Possible downref: Non-RFC (?) normative reference: ref. 'PRIV-NG' Summary: 6 errors (**), 0 flaws (~~), 11 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Wassim Haddad 2 Privacy Ericsson Research 3 Internet Draft Erik Nordmark 4 Expires March 2006 Sun Microsystems 5 October 2005 7 Privacy Terminology 8 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 This memo introduces the terminology for the main privacy 36 aspects. The prime goal is to avoid situations where different 37 interpretations of the same key privacy aspects result in 38 different requirements when designing specific solutions, thus 39 leading to an unnecessary confusion. 41 Table of Contents 43 1. Introduction.................................................2 44 2. Conventions used in this document............................2 45 3. General Terminology..........................................3 46 4. Privacy......................................................3 47 5. Location Privacy.............................................4 48 6. Privacy Aspects..............................................4 49 6.1. Anonymity..................................................4 50 6.2. Unlinkability..............................................5 51 6.3. Unobservability............................................5 52 6.3. Relation between Anonymity and Unlinkability...............6 53 6.5. Pseudonymity...............................................6 54 7. Security Considerations......................................6 55 8. References...................................................7 56 9. Authors'Addresses............................................7 57 Intellectual Property Statement.................................8 58 Disclaimer of Validity..........................................8 59 Copyright Statement.............................................8 61 1. Introduction 63 Privacy is becoming a key requirement to allow deployment of 64 specific internet services. However, privacy has many aspects, 65 which differ in scope, properties and limitations. 67 To avoid any possible confusion with regard to the meanings of 68 privacy in some particular scenarios and to differentiate 69 between requirements related to each scenario, privacy aspects 70 have to be well defined before designing any solution. It is 71 the intention of this memo to introduce the terminology for the 72 main aspects of privacy. 74 2. Conventions used in this document 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 77 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 78 "OPTIONAL" in this document are to be interpreted as described 79 in [TERM]. 81 3. General Terminology 83 Item of Interest (IOI) 85 An Item of Interest (IOI) represents what an attacker is 86 trying to discover, learn, trace and possibly link to other 87 IOI(s), in order to identify its target. 88 Examples of IOI include a subject, event, action (e.g., 89 send, receive, move, etc), specific type of messages,... 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 96 IOIs. 97 We refer to any prior information available to an attacker 98 about a specific target as background knowledge. 100 4. Privacy 102 Privacy is a fundamental human right. The most common 103 definition of privacy is the one by Alan Westin: "Pivacy is 104 the claim of individuals, groups and institutions to determine 105 for themesleves, when, how and to what extent information about 106 them is communicated to others". 108 Privacy is a general term that involves several different 109 aspects. These aspects enable features like hiding the node's 110 address(es) (e.g., MAC and/or IP), name(s) (e.g., DNS), and/or 111 location(s), in addition to hiding specific IOIs. One or more 112 of these features can be obtained during one particular 113 session. 115 In wireless telecommunications, privacy addresses especially 116 the protection of the content as well as the context (e.g., 117 time, location, type of service, ...) of a communication event. 119 Consequently, neither the mobile node nor its system software 120 shall support the creation of user-related usage profiles. Such 121 profiles basically comprise of a correlation of time and 122 location of the node's use, as well as the type and details of 123 the transaction performed. 125 The main privacy aspects are the anonymity, unlinkability, 126 unobservability and pseudonymity. Note that privacy can even be 127 achieved by disconnectivity, i.e., not being connected to a 128 network. 130 5. Location Privacy 132 Location privacy is the ability to prevent other parties from 133 learning one's current and/or past location. In order to get 134 such ability, the concerned (i.e., targeted :) node must 135 conceal any relation between its location and the personal 136 identifiable information. 138 In our context, location privacy refers normally to the 139 topological location and not the geographic one. The latter is 140 provided by other means (e.g., GPS) than an IPv6 address. But 141 it should be noted that it may be possible sometimes to deduce 142 the geographical location from the topological one. 144 6. Privacy Aspects 146 As mentioned above, privacy is a general term, which refers to 147 many different aspects. In the following, we define the main 148 privacy aspects and describe the different relations between 149 them. 151 6.1. Anonymity 153 Anonymity is the state of being not uniquely characterized, 154 i.e., identifiable, within a set of subjects (e.g., node, 155 user) called the anonymity set. The set of possible subjects 156 depends on the knowledge of the attacker and may vary over 157 time. Thus, anonymity is relative with respect to the attacker 158 and is very much context dependent. 160 In the security field, anonymity is a property of network 161 security. An entity "A" in a set has anonymity if no other 162 entity can identify "A", nor is there any link back to "A" 163 that can be used, nor any way to verify that any two anonymous 164 act are performed by "A". 166 From a user perspective, anonymity ensures that a user may use 167 a resource or service without disclosing the user's identity. 169 In wireless networks, anonymity means that neither the mobile 170 node nor its system shall by default expose any information, 171 that allows any conclusions on the owner or current use of the 172 node. 174 Consequently, in scenarios where a device and/or network 175 identifiers are used (e.g., MAC address, IP address), neither 176 the communication partner nor any outside attacker should be 177 able to disclose any possible link between the respective 178 identifier and the user's identity. 180 6.2. Unlinkability 182 Unlinkability of two or more IOIs means that from an 183 attacker's perspective, these IOIs are no more and no less 184 related after his observation than they are related 185 concerning his background knowledge. 187 For example, two messages (e.g., binding updates) are 188 unlinkable for an attacker if the a-posteriori probability 189 describing his background knowledge that these two messages 190 are sent by the same sender and/or received by the same 191 recipient is the same as the probability imposed by his 192 a-priori knowledge. 194 From a user perspective, unlinkability ensures that a user 195 may make multiple uses of resources or services without 196 other being able to link these uses together. 198 6.3. Unobservability 200 Unobservability is the state of IOIs being indistinguishable 201 from any IOI. This means that messages are not discernable 202 from e.g., random noise. Consequently, unobservability deals 203 with events instead of subjects. 205 From a user perspective, unobservability ensures that a user 206 may use a resource or service without others, especially 207 third parties, being able to observe that the resource or 208 service is being used. 210 6.4. Relation between Anonymity and Unlinkability 212 In terms of unlinkability, anonymity can be defined as the 213 unlikability of an IOI and any identifier of a subject. 214 Consequently, unlinkability is a sufficient condition of 215 anonymity but is not a necessary condition. 217 6.5. Pseudonymity 219 Pseudonymity is a weaker property related to anonymity. It 220 means that one cannot identify an entity, but it may be 221 possible to prove that two pseudonyms acts were performed by 222 the same entity. 224 From a user perspective, pseudonymity ensures that a user 225 may use a resource or service without disclosing its user 226 identity, but can still be accountable for that use. 228 Consequently, a pseudonym is an identifier for a party to a 229 transaction, which is not in the normal course of events, 230 sufficient to associate the transaction with a particular 231 user. 233 Hence a transaction is pseudonymous in relation to a 234 particular party if the transaction data contains no direct 235 identifier for that party, and can only be related to them in 236 the event that a very specific piece of additional data is 237 associated with it. 239 For more literature about the privacy terminology content, 240 please refer to [ANON], [ISO99], [PRIVNG], [FREEDOM] and 241 [ANON-PRIV]�. 243 7. Security Considerations 245 This document presents only terminology. There are no security 246 issues in this document. 248 8. References 250 [ANON] A. Pfitzmann et al. "Anonymity, Unobservability, 251 Pseudonymity, and Identity Management - A Proposal 252 for Terminology", Draft v0.23, Aout, 2005. 254 [ANONPRIV] M. Schmidt, "Subscriptionless Mobile Networking: 255 Anonymity and Privacy Aspects within Personal Area 256 Networks", IEEE WCNC 2002. 258 [Freedom] A.F. Westin, "Privacy and Freedom", Atheneum Press, 259 New York, USA, 1967. 261 [ISO99] ISO IS 15408, 1999, http://www.commoncriteria.org/ 263 [LOPRIPEC] A. Beresfold, F. Stajano, "Location Privacy in 264 Pervasive Computing", IEEE Pervasive Computing, 265 2(1):46-55, 2003 IEEE. 267 [PRIV-NG] A. Escudero-Pascual, "Privacy in the Next Generation 268 Internet", December 2002. 270 9. Authors' Addresses 272 Wassim Haddad 273 Ericsson Research 274 8400, Decarie Blvd 275 Town of Mount Royal 276 Quebec H4P 2N2 277 Canada 279 Phone: +1 514 345 7900 280 E-Mail: Wassim.Haddad@ericsson.com 282 Erik Nordmark 283 Sun Microsystems, Inc 284 17 Network Circle 285 Moutain View, CA 286 USA 287 Phone: +1 650 786 2921 288 Fax: +1 650 786 5896 289 E-Mail: Erik.Nordmark@sun.com 291 Intellectual Property Statement 293 The IETF takes no position regarding the validity or scope of 294 any Intellectual Property Rights or other rights that might be 295 claimed to pertain to the implementation or use of the 296 technology described in this document or the extent to which any 297 license under such rights might or might not be available; nor 298 does it represent that it has made any independent effort to 299 identify any such rights. Information on the IETF's procedures 300 with respect to rights in IETF Documents can be found in BCP 78 301 and BCP 79. 303 Copies of IPR disclosures made to the IETF Secretariat and any 304 assurances of licenses to be made available, or the result of an 305 attempt made to obtain a general license or permission for the 306 use of such proprietary rights by implementers or users of this 307 specification can be obtained from the IETF on-line IPR 308 repository at http://www.ietf.org/ipr. 310 The IETF invites any interested party to bring to its attention 311 any copyrights, patents or patent applications, or other 312 proprietary rights that may cover technology that may be 313 required to implement this standard. Please address the 314 information to the IETF at ietf-ipr@ietf.org. 315 The IETF has been notified of intellectual property rights 316 claimed in regard to some or all of the specification contained 317 in this document. For more information consult the online list 318 of claimed rights. 320 Disclaimer of Validity 322 This document and the information contained herein are provided 323 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 324 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 325 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 326 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY 327 THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 328 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 329 FOR A PARTICULAR PURPOSE. 331 Copyright Statement 333 Copyright (C) The Internet Society (2005). This document is 334 subject to the rights, licenses and restrictions contained in 335 BCP 78, and except as set forth therein, the authors retain all 336 their rights.