idnits 2.17.1 draft-thomson-geopriv-lying-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 29, 2011) is 4683 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-27) exists of draft-ietf-geopriv-policy-23 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GEOPRIV M. Thomson 3 Internet-Draft Commscope 4 Intended status: Informational June 29, 2011 5 Expires: December 31, 2011 7 A Privacy-Preserving Policy Transformation for Location 8 draft-thomson-geopriv-lying-00.txt 10 Abstract 12 Obscuring location effectively is difficult. Falsehood offers a 13 simpler, more effective method of location privacy protection. A 14 mechanism is defined whereby a rule maker can request that a location 15 server lie about location. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on December 31, 2011. 34 Copyright Notice 36 Copyright (c) 2011 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Conventions used in this document . . . . . . . . . . . . . . . 3 53 3. Location Information Absolute Replacement . . . . . . . . . . . 3 54 3.1. Interaction with Other Transformations . . . . . . . . . . 4 55 3.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 58 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 59 6.1. URN Sub-Namespace Registration for 60 urn:ietf:params:xml:ns:geopriv:liar . . . . . . . . . . . . 6 61 6.2. XML Schema Registration for Location Information 62 Absolute Replacement Schema . . . . . . . . . . . . . . . . 7 63 6.3. Location Transformation Token Registration . . . . . . . . 7 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 65 8. Informative References . . . . . . . . . . . . . . . . . . . . 8 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 1. Introduction 70 Obscuring location has applications for protecting privacy, as 71 described in [I-D.ietf-geopriv-policy]. 73 Effectively protecting privacy through obscuring location information 74 is difficult. Given an obscured location and enough supplementary 75 information, a location recipient can recover a great deal of 76 information about the known location despite obfuscation being used. 77 This supplementary information might include data on geographic 78 features and their characteristics, past behavior of the target or 79 aggregated data. 81 Solving the difficult obscuring problem might be possible, but the 82 effort required to try is significant. A more expedient solution to 83 the overall problem is to provide a way for a rule maker to select 84 the location that is reported to location recipients. 86 This privacy solution presents a trade-off. While finer control is 87 thereby given to rule makers over the location information that is 88 shared, it also presents a greater burden on the rule maker 89 developing policy rules. 91 An extension to the element defined in 92 [I-D.ietf-geopriv-policy] is described. 94 This policy extension is most useful where an automated system 95 generates location information. In systems where the rule maker 96 already is presented with an opportunity to alter location 97 information, such as where the rule maker role is assumed by the 98 entity generating (e.g. [RFC5985]) or publishing (e.g. [RFC3903]) 99 location, such a mechanism is redundant. 101 2. Conventions used in this document 103 Familiarity with the terminology outlined in [I-D.ietf-geopriv-arch] 104 is helpful. 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 3. Location Information Absolute Replacement 112 The location information absolute replacement ("liar") element is a 113 transformation element that is included in the "provide-location" 114 element of a policy document. When a "liar" element is included, the 115 "profile" attribute MUST be set to "replacement-transformation". 117 The "liar" element can contain any form of location information that 118 is valid for the "location-info" element in a PIDF-LO [RFC4119] (see 119 also [RFC5491]). 121 In order to apply the transformation, replace the content of any 122 selected "location-info" element in the presence document with the 123 content of the "liar" element in the policy document. Content is 124 copied verbatim. 126 3.1. Interaction with Other Transformations 128 The common policy [RFC4745] framework permits the application of 129 policy rules in any order. Precedence is used to determine which 130 transformation is finally applied. 132 When combining multiple "provide-location" transformations, the 133 location information absolute replacement transformation is assigned 134 the highest available precedence. 136 3.2. Example 138 143 144 145 146 147 148 149 151 152 The Pub 153 154 155 156 157 158 159 160 161 162 Work 163 164 165 166 167 168 170 4. XML Schema 172 173 179 180 181 182 183 184 186 188 189 190 191 193 195 5. Acknowledgements 197 Richard Barnes provided input on the original idea. 199 6. IANA Considerations 201 This section registers an XML schema for the location information 202 absolute replacement element, the corresponding namespace and 203 "replacement-transformation" token. 205 6.1. URN Sub-Namespace Registration for 206 urn:ietf:params:xml:ns:geopriv:liar 208 This section registers a new XML namespace, 209 "urn:ietf:params:xml:ns:geopriv:liar", as per the guidelines in 210 [RFC3688]. 212 URI: urn:ietf:params:xml:ns:geopriv:liar 214 Registrant Contact: IETF, GEOPRIV working group, 215 (geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com). 217 XML: 219 BEGIN 220 221 223 224 225 Location Information Absolute Replacement 226 227 228

Namespace

229

urn:ietf:params:xml:ns:geopriv:liar

230 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 231 with the RFC number for this specification.]] 232

See RFCXXXX.

233 234 235 END 237 6.2. XML Schema Registration for Location Information Absolute 238 Replacement Schema 240 This section registers an XML schema as per the guidelines in 241 [RFC3688]. 243 URI: urn:ietf:params:xml:schema:geopriv:liar 245 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 246 Martin Thomson (martin.thomson@commscope.com). 248 Schema: The XML for this schema can be found in Section 4 of this 249 document. 251 6.3. Location Transformation Token Registration 253 The token "replacement-transformation" is registered in the 254 Geolocation Policy Location Profile Registry, as defined in 255 [I-D.ietf-geopriv-policy]. This token is used for the 256 "provide-location" element as described in Section 3. 258 7. Security Considerations 260 Policy documents include privacy-sensitive information. The 261 additional capabilities added by this document do not change this 262 fact, but expand the possibilities for embarassment if policy 263 documents are revealed. 265 8. Informative References 267 [I-D.ietf-geopriv-arch] 268 Barnes, R., Lepinski, M., Cooper, A., Morris, J., 269 Tschofenig, H., and H. Schulzrinne, "An Architecture for 270 Location and Location Privacy in Internet Applications", 271 draft-ietf-geopriv-arch-03 (work in progress), 272 October 2010. 274 [I-D.ietf-geopriv-policy] 275 Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., 276 and J. Polk, "Geolocation Policy: A Document Format for 277 Expressing Privacy Preferences for Location Information", 278 draft-ietf-geopriv-policy-23 (work in progress), 279 March 2011. 281 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 282 Requirement Levels", BCP 14, RFC 2119, March 1997. 284 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 285 January 2004. 287 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension 288 for Event State Publication", RFC 3903, October 2004. 290 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 291 Format", RFC 4119, December 2005. 293 [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., 294 Polk, J., and J. Rosenberg, "Common Policy: A Document 295 Format for Expressing Privacy Preferences", RFC 4745, 296 February 2007. 298 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 299 Presence Information Data Format Location Object (PIDF-LO) 300 Usage Clarification, Considerations, and Recommendations", 301 RFC 5491, March 2009. 303 [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", 304 RFC 5985, September 2010. 306 Author's Address 308 Martin Thomson 309 Commscope 310 Andrew Building (39) 311 Wollongong University Campus 312 Northfields Avenue 313 Wollongong, NSW 2522 314 AU 316 Phone: +61 2 4221 2915 317 Email: martin.thomson@commscope.com