A Privacy-Preserving Policy Transformation for Location

Abstract

Obscuring location effectively is difficult. Falsehood offers a simpler, more effective method of location privacy protection. A mechanism is defined whereby a rule maker can request that a location server lie about location.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on December 31, 2011.

Copyright Notice

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Conventions used in this document
• 3. Location Information Absolute Replacement
• 3.1. Interaction with Other Transformations
• 3.2. Example
• 4. XML Schema
• 5. Acknowledgements
• 6. IANA Considerations
• 6.1. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:liar
• 6.2. XML Schema Registration for Location Information Absolute Replacement Schema
• 6.3. Location Transformation Token Registration
• 7. Security Considerations
• 8. References
• Author's Address

1. Introduction

Obscuring location has applications for protecting privacy, as described in [I-D.ietf-geopriv-policy].

Effectively protecting privacy through obscuring location information is difficult. Given an obscured location and enough supplementary information, a location recipient can recover a great deal of information about the known location despite obfuscation being used. This supplementary information might include data on geographic features and their characteristics, past behavior of the target or aggregated data.

Solving the difficult obscuring problem might be possible, but the effort required to try is significant. A more expedient solution to the overall problem is to provide a way for a rule maker to select the location that is reported to location recipients.

This privacy solution presents a trade-off. While finer control is thereby given to rule makers over the location information that is shared, it also presents a greater burden on the rule maker developing policy rules.

An extension to the <provide-location> element defined in [I-D.ietf-geopriv-policy] is described.

This policy extension is most useful where an automated system generates location information. In systems where the rule maker already is presented with an opportunity to alter location information, such as where the rule maker role is assumed by the entity generating (e.g. [RFC5985]) or publishing (e.g. [RFC3903]) location, such a mechanism is redundant.

2. Conventions used in this document

Familiarity with the terminology outlined in [I-D.ietf-geopriv-arch] is helpful.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

3. Location Information Absolute Replacement

The location information absolute replacement (liar) element is a transformation element that is included in the provide-location element of a policy document. When a liar element is included, the profile attribute MUST be set to replacement-transformation.

The liar element can contain any form of location information that is valid for the location-info element in a PIDF-LO [RFC4119] (see also [RFC5491]).

In order to apply the transformation, replace the content of any selected location-info element in the presence document with the content of the liar element in the policy document. Content is copied verbatim.

3.1. Interaction with Other Transformations

The common policy [RFC4745] framework permits the application of policy rules in any order. Precedence is used to determine which transformation is finally applied.

When combining multiple provide-location transformations, the location information absolute replacement transformation is assigned the highest available precedence.

3.2. Example

  <ruleset
      xmlns="urn:ietf:params:xml:ns:common-policy"
      xmlns:gp="urn:ietf:params:xml:ns:geolocation-policy"
      xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
      xmlns:liar="urn:ietf:params:xml:ns:pidf:geopriv:liar">
    <rule id="drinking">
      <conditions>
	<identity>
	  <one id="sip:wife@example.com"/>
	</identity>
	<gp:location-condition>
	  <gp:location profile="civic-condition"
		       label="My Happy Place">
	    <ca:civicAddress>
	      <ca:NAM>The Pub</ca:NAM>
	    </ca:civicAddress>
	  </gp:location>
	</gp:location-condition>
      </conditions>
      <actions/>
      <transformations>
	<gp:provide-location profile="replacement-transformation">
	  <liar:liar>
	    <ca:civicAddress>
	      <ca:NAM>Work</ca:NAM>
	    </ca:civicAddress>
	  </liar:liar>
	</gp:provide-location>
      </transformations>
    </rule>
  </ruleset>

4. XML Schema

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:geopriv:liar"
	   xmlns:liar="urn:ietf:params:xml:ns:geopriv:liar"
	   xmlns:xs="http://www.w3.org/2001/XMLSchema"
	   elementFormDefault="qualified"
	   attributeFormDefault="unqualified">

  <xs:element name="liar" type="liar:liarType"/>
  <xs:complexType name="liarType">
    <xs:complexContent>
      <xs:restriction base="xs:anyType">
	<xs:sequence>
	  <!-- The content model is equivalent to that of
	       <location-info> in RFC 4119: very permissive -->
	  <xs:any namespace="##any" processContents="lax"
		  minOccurs="0" maxOccurs="unbounded"/>
	</xs:sequence>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>

</xs:schema>

5. Acknowledgements

Richard Barnes provided input on the original idea.

6. IANA Considerations

This section registers an XML schema for the location information absolute replacement element, the corresponding namespace and replacement-transformation token.

6.1. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:liar

      BEGIN
	<?xml version="1.0"?>
	<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
	  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
	<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
	  <head>
	    <title>Location Information Absolute Replacement</title>
	  </head>
	  <body>
	    <h1>Namespace</h1>
	    <h2>urn:ietf:params:xml:ns:geopriv:liar</h2>
[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
    with the RFC number for this specification.]]
	    <p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
	  </body>
	</html>
      END
      

This section registers a new XML namespace, urn:ietf:params:xml:ns:geopriv:liar, as per the guidelines in [RFC3688].

• URI: urn:ietf:params:xml:ns:geopriv:liar
• Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com).
• XML:

6.2. XML Schema Registration for Location Information Absolute Replacement Schema

This section registers an XML schema as per the guidelines in [RFC3688].

URI:

urn:ietf:params:xml:schema:geopriv:liar

Registrant Contact:

IETF, GEOPRIV working group, (geopriv@ietf.org), Martin Thomson (martin.thomson@commscope.com).

Schema:

The XML for this schema can be found in Section 4 of this document.

6.3. Location Transformation Token Registration

The token replacement-transformation is registered in the Geolocation Policy Location Profile Registry, as defined in [I-D.ietf-geopriv-policy]. This token is used for the provide-location element as described in Section 3.

7. Security Considerations

Policy documents include privacy-sensitive information. The additional capabilities added by this document do not change this fact, but expand the possibilities for embarassment if policy documents are revealed.

8. References

Author's Address