Location Configuration Extensions for Policy Management
draft-barnes-geopriv-policy-uri-00

Status of this Memo

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

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

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.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on April 10, 2010.

Copyright Notice

Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Abstract

Current location configuration protocols are capable of provisioning an Internet host with a location URI that refers to the host's location. However, these protocols lack a mechnism for the htarget host to inspect or set the privacy rules that are applied to the URIs they distribute. This document extends the current location configuration protocols to provide hosts with a reference to the rules that are applied to a URI, so that the host can view or set these rules.

Table of Contents

1.  Introduction
2.  Definitions
3.  Policy URIs
4.  Location Configuration Extensions
    4.1.  HELD
    4.2.  DHCP
5.  Examples
    5.1.  HELD
    5.2.  DHCP
    5.3.  Basic access control policy
    5.4.  The possession model
6.  Acknowledgements
7.  IANA Considerations
    7.1.  URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:held:policy
    7.2.  XML Schema Registration
    7.3.  DHCP LuriType Registration
8.  Security Considerations
9.  References
    9.1.  Normative References
    9.2.  Informative References
§  Author's Address

1.  Introduction

A critical step in enabling Internet hosts to access location-based services is to provision those hosts with information about their own location. This is accomplished via a Location Configuration Protocol (LCP) [7] (Tschofenig, H. and H. Schulzrinne, “GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and Requirements,” July 2009.), which allow a location provider (e.g., a local access network) to inform a host about its location.

There are two basic patterns for location configuration, namely configuration "by value" and "by reference" [8] (Marshall, R., “Requirements for a Location-by-Reference Mechanism,” November 2009.). Configuration by value provisions a host directly with its location, by providing it location information that is directly usable (e.g., coordinates or a civic address). Configuration by reference provides a host with a URI that references the host's location, i.e., one that can be dereferenced to obtain the location (by value) of the host.

In some cases, location by reference offers a few benefits over location by value. From a privacy perspective, the required dereference transaction provides a policy enforcement point, so that the opaque URI itself can be safely conveyed over untrusted media (e.g., SIP through untrusted proxies [9] (Peterson, J., Hardie, T., and J. Morris, “Implications of 'retransmission-allowed' for SIP Location Conveyance,” August 2009.)). If the target host is mobile, an application provider can use a single reference to obtain the location of the host multiple times, saving bandwidth to the host. For some configuration protocols, the location object referenced by a location URI provides a much more expressive syntax for location values than the configuration protocol itself (e.g., DHCP geodetic location [10] (Polk, J., Schnizlein, J., Linsner, M., Thomson, M., and B. Aboba, “Dynamic Host Configuration Protocol Options for Coordinate-based Location Configuration Information,” March 2010.) versus GML in a PIDF-LO [11] (Peterson, J., “A Presence-based GEOPRIV Location Object Format,” December 2005.)).

From a privacy perspective, however, current LCPs are limited in their flexibility, in that they do not provide the Target (the client in an LCP) with a way to inform the Location Server with policy for how his location information should be handled. This document addresses this gap by defining a simple mechanism for referring to and manipulating policy, and by extending current LCPs to carry policy references. Using the mechanisms defined in this document, a Location Server (acting as an LCP server) can inform a client as to which policy document controls a given location resource, and the LCP client (a Target and Rule Maker) can inspect this document and modify it as necessary.

The remainder of this document is structured as follows: After introducing a few relevant terms, we define policy URIs as a channel for referencing, inspecting, and updating policy documents. We then define extensions to HELD protocol and the DHCP option for location by reference to allow these protocols to cary policy URIs. Examples are given that demonstrate how policy URIs are carried in these protocols and how they can be used by clients.

2.  Definitions

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 RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [1].

3.  Policy URIs

A policy URI is an HTTP or HTTPS URI that a Rule Holder can use to inspect and install policy documents that tell a location server how it should protect a given location resource. A policy URI is always a reference to a common-policy document [2] (Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk, J., and J. Rosenberg, “Common Policy: A Document Format for Expressing Privacy Preferences,” February 2007.) (possibly including some extensions, e.g., for geolocation policy [3] (Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., and J. Polk, “Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information,” January 2010.)).

A server that is the authority for policy URIs MUST support GET, PUT, and DELETE requests to these URIs, in order to allow clients to inspect, replace, and delete policy documents. While the server MAY deny any particular request according to local policy, it SHOULD allow all requests (with any of the three methods) from the Target of the protected location resource. Clients MUST likewise support the three required request types.

A GET request to a policy URI is a request for the referenced policy information. In response to a GET request, the server MUST validate that the requestor is an authorized Rule Maker or Rule Holder according to local policy. If the request is valid, then the server MUST send an HTTP 200 response containing the full policy document referenced by the URI, in the common-policy format; these responses MUST have content-type 'application/auth-policy+xml'.

A PUT request to a policy URI is a request to replace the current policy. The entity-body of a PUT requests MUST be a common-policy document; it must have content-type 'application/auth-policy+xml'. When a server receives a PUT request, it MUST validate the policy document included in the body of the request, and it MUST validate that the requestor is an authorized Rule Maker or Rule Holder according to local policy. If the request is valid, then the server MUST replace the current policy document referenced by the URI with the policy document provided in the request.

A DELETE request to a policy URI is a request to delete the referenced policy document and terminate access to the protected resource. In response to a DELETE request, the server MUST validate that the requestor is an authorized Rule Maker or Rule Holder according to local policy. If the request is valid, then the server MUST delete the policy document referenced by the URI and disallow any further access to the location resource it governs.

It should be noted that this usage of HTTP is generally compatible with the use of XCAP or WebDAV to manage policy documents, but this document does not define or require the use of these protocols.

4.  Location Configuration Extensions

Location configuration protocols can provision hosts with location URIs that refer to the host's location. If the target host is to control policy on these URIs, it needs a way to access the policy that the server will use to guide its interactions. This section defines extensions to LCPs to carry policy URIs that the target can use to control access to location resources.

4.1.  HELD

The HELD protocol [4] (Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, “HTTP Enabled Location Delivery (HELD),” August 2009.) provides <locationUriSet> elements, which contain a set of one or more location URIs that reference the same resource and share a common access control policy. The schema in Figure Figure 1 defines an extended <locationUriSet> object with a new optional attribute "policy"

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

  <xs:import namespace="http://www.w3.org/XML/1998/namespace" />

  <xs:complexType name="returnLocationTypeWithPolicy">
    <xs:complexContent>
      <xs:restriction base="held:returnLocationType">
        <xs:attribute name="policy" type="xs:anyURI" use="optional"/>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>

  <xs:element name="locationUriSet"
              type="hp:returnLocationTypeWithPolicy"/>

</xs:schema>

The URI carried in a "policy" attribute refers to the common access control policy for the location URIs in the <locationUriSet>. The URI MUST be a policy URI as described in Section Section 3 (Policy URIs): It MUST be an HTTP or HTTPS URI, and the server MUST support the specified operations on the URI.

4.2.  DHCP

The DHCP location by reference option [5] (Polk, J., “Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6 Option for a Location Uniform Resource Identifier (URI),” March 2010.) provides location URIs in sub-options called LuriElements. This document defines a new LuriElement type for policy URIs

LuriType=X

Policy-URI - This is a policy URI that refers to the access control policy for the location URI in the preceding LuriElement.

[NOTE TO IANA/RFC-EDITOR: Please replace X above with the assigned LuriType value]

Each Policy-URI LuriElement MUST immediately follow a sub-option that carries a location URI, for example, a sub-option with LuriType 1. The URI carried in a Policy-URI LuriElement refers to the access control policy for the location URI in the sub-option that precedes it. The URI MUST be a policy URI as described in Section Section 3 (Policy URIs): It MUST be an HTTP or HTTPS URI, and the server MUST support the specified operations on the URI.

5.  Examples

In this section, we provide some brief illustrations of how policy URIs are delivered to target hosts and used by those hosts to manage policy

5.1.  HELD

A HELD response providing a single <locationUriSet>, containing two URIs under a common policy, would have the following form:

<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
  <locationUriSet
      xmlns="urn:ietf:params:xml:ns:geopriv:held:policy"
      expires="2006-01-01T13:00:00.0Z"
      policy="https://ls.example.com:9768/policy/357yc6s64ceyoiuy5ax3o">
    <locationURI>
      https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
    </locationURI>
    <locationURI>
      sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com:
    </locationURI>
  </locationUriSet>
</locationResponse>

5.2.  DHCP

A DHCP option providing a single location URI along with a single policy URI would have the following form:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          option-code          |              111              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   1   |   0   |       1       |      49       |     'h'       |
    +---------------+---------------+---------------+---------------|
    |      't'      |      't'      |      'p'      |     's'       |
    +---------------+---------------+---------------+---------------|
    |      ':'      |      '/'      |      '/'      |     'l'       |
    +---------------+---------------+---------------+---------------|
    |      's'      |      '.'      |              ...              |
    +---------------+---------------+---------------+---------------|
    |       3       |      56       |      'h'            't'       |
    +---------------+---------------+---------------+---------------|
    |      't'      |      'p'      |      's'      |     ':'       |
    +---------------+---------------+---------------+---------------|
    |      '/'      |      '/'      |              ...              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.3.  Basic access control policy

Consider a user that gets the policy URI <https://ls.example.com/>, as in the above LCP example. The first thing this allows the user to do is inspect the default policy that the LS has assigned to this URI:

GET /policy/357yc6s64ceyoiuy5ax3o HTTP/1.1
Host: ls.example.com:9768


HTTP/1.1 200 OK
Content-type: application/auth-policy+xml
Content-length: 388

<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
  <rule id="f3g44r1">
    <conditions>
      <identity>
        <many domain="example.com">
          <except id="sip:alice@example.com"/>
          <except id="sip:bob@example.com"/>
        </many>
      </identity>
    </conditions>
    <actions/>
    <transformations/>
  </rule>
</ruleset>

This policy allows all users in the domain "example.com" to access the bound location URI, except for users "alice" and "bob". If the user disagrees with this policy, and prefers for example, to only provide location to one friend, at a city level of granularity, then he can install this policy on the LS:

PUT /policy/357yc6s64ceyoiuy5ax3o HTTP/1.1
Host: ls.example.com:9768
Content-type: application/auth-policy+xml
Content-length: 462

<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
  <rule id="f3g44r1">
    <conditions>
      <identity>
        <one id="sip:friend@example.com"/>
      </identity>
    </conditions>
    <actions/>
    <transformations>
      <gp:provide-location
          profile="civic-transformation">
        <lp:provide-civic>city</lp:provide-civic>
      </gp:provide-location>
    </transformations>
  </rule>
</ruleset>


HTTP/1.1 200 OK

Finally, after using the URI for a period, the user wishes to permanently invalidate the URI.

DELETE /policy/357yc6s64ceyoiuy5ax3o HTTP/1.1
Host: ls.example.com:9768


HTTP/1.1 200 OK

5.4.  The possession model

6.  Acknowledgements

Thanks to James Winterbottom, Martin Thomson, Hannes Tschofenig, and Mary Barnes for providing critical commentary on the ideas described in this document.

7.  IANA Considerations

This document requires several IANA registrations, detailed below.

7.1.  URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:held:policy

This section registers a new XML namespace, "urn:ietf:params:xml:ns:geopriv:held", per the guidelines in [6] (Mealling, M., “The IETF XML Registry,” January 2004.).

      URI: urn:ietf:params:xml:ns:geopriv:held:policy
      Registrant Contact: IETF, GEOPRIV working group,
      (geopriv@ietf.org), Richard Barnes (rbarnes@bbn.com).
      XML:

         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>HELD Policy URI Extension</title>
             </head>
             <body>
               <h1>Namespace for HELD Policy URI Extension</h1>
               <h2>urn:ietf:params:xml:ns:geopriv:held:policy</h2>
       [NOTE TO IANA/RFC-EDITOR: Please replace XXXX
       with the RFC number for this specification.]
               <p>See RFCXXXX</p>
             </body>
           </html>
         END

7.2.  XML Schema Registration

This section registers an XML schema as per the guidelines in [6] (Mealling, M., “The IETF XML Registry,” January 2004.).

URI:

urn:ietf:params:xml:schema:geopriv:held

Registrant Contact:

IETF, GEOPRIV working group (geopriv@ietf.org), Richard Barnes (rbarnes@bbn.com)

Schema:

The XML for this schema can be found in Section Section 4.1 (HELD).

7.3.  DHCP LuriType Registration

IANA is requested to add a value to the LuriTypes registry, as follows:

   +------------+----------------------------------------+-----------+
   |  LuriType  |   Name                                 | Reference |
   +------------+----------------------------------------+-----------+
   |     X*     |   Policy-URI                           | RFC XXXX**|
   +------------+----------------------------------------+-----------+

    * X is to be replaced with the assigned value
   ** RFC XXXX is to be replaced with this document's RFC-Editor RFC
      number.

8.  Security Considerations

There are two main classes of risks associated with access control policy management: The risk of unauthorized disclosure of the protected resource via manipulation of the policy management process, and the risk of disclosure of policy information itself.

Protecting the policy management process from manipulation entails two primary requirements: First, the policy URI has to be faithfully transmitted to the client, and second, the policy document has to be faithfully transmitted to the location server. The first requirement is met by the integrity properties of the underlying LCP. To meet the second requirement, the LCP server SHOULD provide HTTPS policy URIs and the policy server SHOULD support cipher suites that provide integrity protection.

Authorization policy at the policy server also plays a central role in the protection of both location information and user policy information. In order to prevent the unauthorized disclosure of location information and policyinformation, the policy server MUST authenticate all requests to policy URIs and verify that the requestor is an authorized Rule Maker for the protected location resource. In the particular case where the target itself is an authorized Rule Maker and the target is identified to the LS by its IP address, the server MAY use IP return routability as an authentication mechanism.

Finally, policy information must be protected from observation by unauthorized entities en route between the client and the policy server. This protection is provided by the use of HTTPS with appropriate cipher suites.

9.  References

9.1. Normative References

9.2. Informative References

Author's Address