GEOPRIV R. Barnes Internet-Draft BBN Technologies Intended status: Informational October 7, 2009 Expires: April 10, 2010 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 Barnes Expires April 10, 2010 [Page 1] Internet-Draft LCP Policy URIs October 2009 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Policy URIs . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Location Configuration Extensions . . . . . . . . . . . . . . 5 4.1. HELD . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. HELD . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.2. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.3. Basic access control policy . . . . . . . . . . . . . . . 7 5.4. The possession model . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7.1. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:held:policy . . . . . . . . 10 7.2. XML Schema Registration . . . . . . . . . . . . . . . . . 10 7.3. DHCP LuriType Registration . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Barnes Expires April 10, 2010 [Page 2] Internet-Draft LCP Policy URIs October 2009 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], 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]. 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]). 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] versus GML in a PIDF-LO [11]). 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. Barnes Expires April 10, 2010 [Page 3] Internet-Draft LCP Policy URIs October 2009 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 [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] (possibly including some extensions, e.g., for geolocation policy [3]). 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. Barnes Expires April 10, 2010 [Page 4] Internet-Draft LCP Policy URIs October 2009 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] provides 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 object with a new optional attribute "policy" Figure 1 Barnes Expires April 10, 2010 [Page 5] Internet-Draft LCP Policy URIs October 2009 The URI carried in a "policy" attribute refers to the common access control policy for the location URIs in the . The URI MUST be a policy URI as described in Section Section 3: 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] 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: 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 , containing two URIs under a common policy, would have the following form: Barnes Expires April 10, 2010 [Page 6] Internet-Draft LCP Policy URIs October 2009 https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com: 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 , 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: Barnes Expires April 10, 2010 [Page 7] Internet-Draft LCP Policy URIs October 2009 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 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: Barnes Expires April 10, 2010 [Page 8] Internet-Draft LCP Policy URIs October 2009 PUT /policy/357yc6s64ceyoiuy5ax3o HTTP/1.1 Host: ls.example.com:9768 Content-type: application/auth-policy+xml Content-length: 462 city 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. Barnes Expires April 10, 2010 [Page 9] Internet-Draft LCP Policy URIs October 2009 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]. 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 HELD Policy URI Extension

Namespace for HELD Policy URI Extension

urn:ietf:params:xml:ns:geopriv:held:policy

[NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number for this specification.]

See RFCXXXX

END 7.2. XML Schema Registration This section registers an XML schema as per the guidelines in [6]. 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. Barnes Expires April 10, 2010 [Page 10] Internet-Draft LCP Policy URIs October 2009 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. Barnes Expires April 10, 2010 [Page 11] Internet-Draft LCP Policy URIs October 2009 9. References 9.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk, J., and J. Rosenberg, "Common Policy: A Document Format for Expressing Privacy Preferences", RFC 4745, February 2007. [3] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., and J. Polk, "Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information", draft-ietf-geopriv-policy-21 (work in progress), July 2009. [4] Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, "HTTP Enabled Location Delivery (HELD)", draft-ietf-geopriv-http-location-delivery-16 (work in progress), August 2009. [5] Polk, J., "Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6 Option for a Location Uniform Resource Identifier (URI)", draft-ietf-geopriv-dhcp-lbyr-uri-option-06 (work in progress), September 2009. [6] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. 9.2. Informative References [7] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and Requirements", draft-ietf-geopriv-l7-lcp-ps-10 (work in progress), July 2009. [8] Marshall, R., "Requirements for a Location-by-Reference Mechanism", draft-ietf-geopriv-lbyr-requirements-08 (work in progress), September 2009. [9] Peterson, J., Hardie, T., and J. Morris, "Implications of 'retransmission-allowed' for SIP Location Conveyance", RFC 5606, August 2009. [10] Polk, J., Schnizlein, J., Linsner, M., and B. Aboba, "Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information", draft-ietf-geopriv-rfc3825bis-01 (work in progress), July 2009. Barnes Expires April 10, 2010 [Page 12] Internet-Draft LCP Policy URIs October 2009 [11] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005. Author's Address Richard Barnes BBN Technologies 9861 Broken Land Parkway Columbia, MD 21046 US Phone: +1 410 290 6169 Email: rbarnes@bbn.com Barnes Expires April 10, 2010 [Page 13]