Internet Engineering Task Force (IETF) R. Barnes Request for Comments: 7199 M. Thomson Category: Standards Track Mozilla ISSN: 2070-1721 J. Winterbottom Unaffiliated H. Tschofenig April 2014 Location Configuration Extensions for Policy Management
AbstractCurrent location configuration protocols are capable of provisioning an Internet host with a location URI that refers to the host's location. These protocols lack a mechanism for the target 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. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7199.
Copyright Notice Copyright (c) 2014 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. 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Policy URIs . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Policy URI Usage . . . . . . . . . . . . . . . . . . . . 5 3.2. Policy URI Allocation . . . . . . . . . . . . . . . . . . 6 3.3. Policy Defaults . . . . . . . . . . . . . . . . . . . . . 7 4. Location Configuration Extensions . . . . . . . . . . . . . . 8 4.1. HELD . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Client Processing . . . . . . . . . . . . . . . . . . . . 9 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Basic Access Control Policy . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6.1. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:held:policy . . . . . . . 12 6.2. XML Schema Registration . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7.1. Integrity and Confidentiality for Authorization Policy Data . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.2. Access Control for Authorization Policy . . . . . . . . . 13 7.3. Location URI Allocation . . . . . . . . . . . . . . . . . 15 7.4. Policy URI Handling . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . 17 Appendix A. Example Policy URI Generation Algorithm . . . . . . 18
RFC5687], which allows 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" [RFC5808]. 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 if suitable privacy policies have been provisioned, the opaque location URI can be safely conveyed over untrusted media. (If the location URI is not subject to privacy rules, then conveying the location URI may pose even greater risk than sending location by value [RFC5606].) 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 [RFC6225] versus Geography Markup Language (GML) in a Presence Information Data Format Location Object (PIDF-LO) [RFC4119]). From a privacy perspective, however, current LCPs are limited in their flexibility, in that they do not provide hosts (the clients 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, an LCP server (acting for the Location Server (LS) or Location Information Server (LIS)) can inform a host as to which policy document controls a given location resource, and the host (in its Rule Maker role) can inspect this document and modify it as necessary. In the following figure, adapted from RFC 5808, this document extends the Location Configuration Protocols (1) and defines a simple protocol for policy exchange (4).
+---------+---------+ Location +-----------+ | | | Dereference | Location | | LIS/LS +---------------+ Recipient | | | | Protocol | | +----+----+----+----+ (3) +-----+-----+ | | | | | | Policy| |Location |Location Exchange| |Configuration |Conveyance (4)| |Protocol |Protocol | |(1) |(2) | | | +------+----+----+----+ | | Rule | Target/ | | | Maker | Host +---------------------+ | | | +-----------+---------+ 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 an extension to the HELD protocol to allow it to carry policy URIs. Examples are given that demonstrate how policy URIs are carried in this protocol and how it can be used by clients. RFC2119]. RFC2616] or HTTPS [RFC2818] URI that identifies a policy resource that contains the authorization policy for a linked location resource. Access to the location resource is governed by the contents of the authorization policy. A policy URI identifies an HTTP resource that a Rule Maker can use to inspect and install policy documents that tell a Location Server how it should protect the associated location resource. A policy URI always identifies a resource that can be represented as a common- policy document [RFC4745] (possibly including some extensions; e.g., for geolocation policy [RFC6772]).
Note: RFC 3693 [RFC3693] identified the Rule Holder role as the one that stores policy information. In this document, the Location Server is also a Rule Holder. Section 7). A Location Server SHOULD allow all requests, but it MAY deny certain requests based on local policy. For instance, a Location Server might allow clients to inspect policy (GET), but not to update it (PUT). Or, a Location Server might require clients to authenticate using HTTP or Transport Layer Security (TLS) client authentication. Clients implementing this specification SHOULD support HTTP client authentication [RFC2617] and MAY support TLS client certificates. A GET request to a policy URI is a request for the referenced policy information. If the request is authorized, then the Location Server sends an HTTP 200 response containing the complete policy identified by the URI. A PUT request to a policy URI is a request to replace the current policy. The entity-body of a PUT request includes a complete policy document. When a Location Server receives a PUT request, it MUST validate the policy document included in the body of the request. If the request is valid and authorized, then the Location Server MUST replace the current policy with the policy provided in the request. A DELETE request to a policy URI is a request to delete the referenced policy document. If the request is authorized, then the Location Server MUST delete the policy referenced by the URI and disallow access to the location URIs it governs until a new policy document has been put in place via a PUT request. A policy URI is only valid while the corresponding location URI set is valid. A Location Server MUST NOT respond to any requests to a policy URI once the corresponding location URI set has expired. This expiry time is specified by the 'expires' attribute in the HELD locationResponse.
A location URI can thus become invalid in three ways: By the expiration of a validity interval in policy, by the removal of a policy document with a DELETE request, or by the expiry of the LCP-specified validity interval. The former two are temporary, since the policy URI can be used to update the policy. The latter one is permanent, since the expiry causes the policy URI to be invalidated as well. The Location Server MUST support policy documents in the common- policy format [RFC4745], as identified by the MIME media type of "application/auth-policy+xml". The common-policy format MUST be provided as the default format in response to GET requests that do not include specific "Accept" headers, but content negotiation MAY be used to allow for other formats. This usage of HTTP is generally compatible with the use of Extensible Markup Language (XML) Configuration Access Protocol (XCAP) [RFC4825] or Web Distributed Authoring and Versioning (WebDAV) [RFC4918] to manage policy documents, but this document does not define or require the use of these protocols. RFC6753] or requests from third parties [RFC6155]. Each location URI has either one policy URI or no policy URI. The initial policy that is referenced by a policy URI MUST be identical to the policy that would be applied in the absence of a policy URI. A client that does not support policy URIs can continue to use the location URI as they would have if no policy URI were provided. For HELD, the client assumes that the default policy grants any requester access to location information, as long as the request possesses the location URI. To ensure that the authorization policy is less permissive, a client updates the policy prior to distributing the location URI.
server may change its default policy to something more restrictive -- even the empty, default-deny policy -- since the client can specify something more permissive if desired. RFC5985] defines a "locationUriSet" element, which contains a set of one or more location URIs that reference the same resource and share a common access control policy. The schema in Figure 2 defines two extension elements for HELD: an empty "requestPolicyUri" element that is added to a location request to indicate that a Device desires that a policy URI be allocated and a "policyUri" element that is included in the location response. <?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:hp="urn:ietf:params:xml:ns:geopriv:held:policy" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:element name="requestPolicyUri"> <xs:complexType name="empty"/> </xs:element> <xs:element name="policyUri" type="xs:anyURI"/> </xs:schema> Figure 2: XML Schema for the Policy URI Extension The URI carried in a "policyUri" element refers to the common access control policy for location URIs in the location response. The URI MUST be a policy URI as described in Section 3. A policy URI MUST use the "http:" or "https:" scheme, and the Location Server MUST support the specified operations on the URI.
A HELD request MAY contain an explicit request for a policy URI. The presence of the "requestPolicyUri" element in a location request indicates that a policy URI is desired.
PUT /policy/357lp6f64prlbvhl5nk3b 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" xmlns:gp="urn:ietf:params:xml:ns:geolocation-policy" xmlns:lp="urn:ietf:params:xml:ns:basic-location-profiles"> <rule id="f3g44r1"> <conditions> <identity> <one id="sip:email@example.com"/> </identity> <validity> <until>2011-01-01T13:00:00.0Z</until> </validity> </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/357lp6f64prlbvhl5nk3b HTTP/1.1 Host: ls.example.com:9768 HTTP/1.1 200 OK
RFC3688]. URI: urn:ietf:params:xml:ns:geopriv:held:policy Registrant Contact: IETF, GEOPRIV working group, (firstname.lastname@example.org), Richard Barnes (email@example.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> <p>See <a href="http://www.rfc-editor.org/rfc/rfc7199.txt"> RFC 7199</a>.</p> </body> </html> END RFC3688]. URI: urn:ietf:params:xml:schema:geopriv:held:policy Registrant Contact: IETF, GEOPRIV working group (firstname.lastname@example.org), Richard Barnes (email@example.com) Schema: The XML for this schema can be found in Section 4.1.
RFC5985]). These measures ensure that a policy URI is conveyed to the client without modification or interception. In general, the requirements for TLS on policy transactions are the same as for the dereference transactions they set policy for [RFC6753]. To protect the integrity and confidentiality of policy data during management, the Location Server SHOULD provide policy URIs with the "https:" scheme and require the use of HTTP over TLS [RFC2818]. The cipher suites required by TLS [RFC5246] provide both integrity protection and confidentiality. If other means of protection are available, an "http:" URI MAY be used, but location servers SHOULD reject PUT and DELETE requests for policy URIs that use the "http:" URI scheme. RFC5808] and is subject to the same constraints: o Knowledge of a policy URI MUST be restricted to authorized Rule Makers. Confidentiality and integrity protections SHOULD be used when policy URIs are conveyed in a location configuration protocol and in the requests that are used to inspect, change, or delete the policy resource. Note that in some protocols (such as DHCP), these protections may arise from limiting the use of the protocol to the local network thus relying on lower-layer security
mechanisms. When neither application-layer nor network-layer security is provided, location servers MUST reject requests using the PUT and DELETE methods. o The Location Server MUST ensure that it is not practical for an attacker to guess a policy URI value, even if the attacker has requested many policy URIs from the Location Server over time. The policy URI MUST NOT be derived solely from information that might be public, including the Target identity or any location URI. The addition of 128 bits or more of random entropy is RECOMMENDED to make it infeasible for a third party to guess a policy URI. o Servers SHOULD apply rate limits in order to make brute-force guessing infeasible. If a server allocates location URIs that include N bits of entropy with a lifetime of T seconds, then the server should limit clients to (2^(N/2))/T queries per second. (The lifetime T of a location URI set is specified by the "expires" attribute in HELD.) One possible algorithm for generating appropriately unpredictable policy URIs for a location URI set is described in Appendix A. The goal of the above recommendation on rate limiting is to bound the probability that an attacker can guess a policy URI during its lifetime. If an attacker is limited to (2^(N/2))/T queries per second, then he will be able to make at most 2^(N/2) guesses over the lifetime of the URI. Assuming these guesses are distinct, the probability of the attacker guessing any given URI is (2^(N/2))/(2^N), so the probability of compromise over the T-second lifetime of the URI is at most 2^(-N/2). (Of course, if the attacker guesses the URI after the policy URI has expired, then there is no risk.) With N=128, the probability of compromise is 5.4e-20 under this rate-limiting scheme. Operators should choose values for N so that the corresponding risk of compromise presents an acceptable level of risk. If M distinct URIs are issued within the same namespace, then the probability of any of the M URIs being compromised is M*2^(N/2). The example algorithm for generating policy URIs (see Appendix A) places them in independent namespaces (i.e., below the corresponding location URIs), so this compounding does not occur. Note that the chosen entropy level will also affect how quickly legitimate clients can query a given URI, especially for very long- lived URIs. If the default lifetime T is greater than 2^(N/2), then clients will have to wait multiple seconds between queries. Operators should choose entropy and lifetime values that result in
acceptable high maximum query rates and acceptably low probability of compromise. For example, with 32 bits of entropy (much less than recommended above), the one-query-per-second policy URI lifetime is around 18 hours. RFC5808] for associated location URIs. Under this model, it might be possible to more widely distribute a location URI, relying on the authorization policy to constrain access to location information. To allow for wider distribution, authorization by access control lists places additional constraints on the construction of location URIs. If multiple Targets share a location URI, an unauthorized location recipient that acquires location URIs for the Targets can determine that the Targets are at the same location by comparing location URIs. With shared policy URIs, Targets are able to see and modify authorization policy for other Targets. To allow for the creation of Target-specific authorization policies that are adequately privacy protected, each location URI and policy URI that is issued to a different Target MUST be different from other location URIs and policy URIs. That is, two clients MUST NOT receive the same location URI or the same policy URI. In some deployments, it is not always apparent to an LCP server that two clients are different. In particular, where a middlebox [RFC3234] exists, two or more clients might appear as a single client. An example of a deployment scenario of this nature is described in [RFC5687]. An LCP server MUST create a different location URI and policy URI for every request, unless the requests can be reliably identified as being from the same client.
It should be noted that one of the benefits of the policy URI construct is that in most cases, there is not a policy URI to leave the client device to which it is provided. Without policy URIs, location URIs are subject to a default policy set unilaterally by the server, and location URIs must be conveyed to another entity in order to be useful. With policy URIs, location URIs can have more nuanced access controls, and the shared secret used to authenticate the client (i.e., the policy URI) can simply be stored on the client and used to set the access control policy on the location URI. So while policy URIs do use a default model of authorization by possession, they reduce the overall risk to location privacy posed by leakage of shared secret URIs.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [RFC4745] 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. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC 5985, September 2010. [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002. [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004. [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005. [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006. [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", RFC 4918, June 2007. [RFC5606] Peterson, J., Hardie, T., and J. Morris, "Implications of 'retransmission-allowed' for SIP Location Conveyance", RFC 5606, August 2009. [RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location Configuration Protocol: Problem Statement and Requirements", RFC 5687, March 2010. [RFC5808] Marshall, R., "Requirements for a Location-by-Reference Mechanism", RFC 5808, May 2010. [RFC6155] Winterbottom, J., Thomson, M., Tschofenig, H., and R. Barnes, "Use of Device Identity in HTTP-Enabled Location Delivery (HELD)", RFC 6155, March 2011. [RFC6225] Polk, J., Linsner, M., Thomson, M., and B. Aboba, "Dynamic Host Configuration Protocol Options for Coordinate-Based Location Configuration Information", RFC 6225, July 2011. [RFC6753] Winterbottom, J., Tschofenig, H., Schulzrinne, H., and M. Thomson, "A Location Dereference Protocol Using HTTP- Enabled Location Delivery (HELD)", RFC 6753, October 2012. [RFC6772] Schulzrinne, H., Tschofenig, H., Cuellar, J., Polk, J., Morris, J., and M. Thomson, "Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information", RFC 6772, January 2013.
RFC4648] to one of the location URIs, e.g., as a query parameter: "http://example.com/loc/ foo?policy=j3WTGUb3smxcZA6eKIqmqdV3ALE"