RFC 7199
Location Configuration Extensions for Policy Management
RFC 7199: Location Configuration Extensions for Policy Management ✨
Okay bestie, this is RFC 7199 🎀 It's a Standards Track document from April 2014 (ISSN 2070-1721), written by R. Barnes, M. Thomson (from Mozilla), J. Winterbottom (who's Unaffiliated, so independent 🌈), and H. Tschofenig. Its title block has no Obsoletes or Updates lines, so it doesn't replace or change any other RFC. Iconic. 💅
Abstract
Location configuration protocols can already hand a host a location URI that points to where the host is. The problem is that they give the target host no way to look at or change the privacy rules applied to those URIs 🙈 This document fixes that by giving hosts a reference to the rules attached to a URI, so they can view or set them. It's giving control. 💜
Status of This Memo
This is an Internet Standards Track document. 🦋
It's a product of the Internet Engineering Task Force (IETF), and it reflects the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 5741.
You can find the current status, any errata, and how to send feedback 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) as they stood on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes. 🌸
Table of Contents
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 . . . . . . 181. Introduction 🧚
Okay so the first step for letting hosts use location-based services is giving them info about their own location 📍 That's what a Location Configuration Protocol (LCP) [RFC5687] does. It lets a location provider, like a local access network, tell a host where it is. 💖
There are two basic patterns for location configuration, "by value" and "by reference" [RFC5808]. Configuration by value hands the host its location directly, as info it can use right away, like coordinates or a civic address. Configuration by reference gives the host a URI that points at its location. You have to dereference that URI to get the location by value. 🦋
Location by reference has some perks over location by value in certain cases. Privacy-wise, the dereference step is a policy enforcement point. So if suitable privacy policies have been set up, the opaque location URI can be safely sent over untrusted media. (If the location URI isn't covered by privacy rules, sending it could be even riskier than sending location by value [RFC5606].) If the target host is mobile, an application provider can reuse one reference to get the host's location many times, which saves the host bandwidth. For some configuration protocols, the location object a URI points to has a much more expressive syntax for location values than the configuration protocol does itself. For example, compare DHCP geodetic location [RFC6225] with Geography Markup Language (GML) in a Presence Information Data Format Location Object (PIDF-LO) [RFC4119]. 🌈
Privacy-wise, though, current LCPs aren't very flexible. They don't give hosts (the clients in an LCP) a way to tell the Location Server how their location information should be handled. This document fills that gap 🫶 It defines a simple mechanism for referring to and changing policy, and it extends current LCPs so they can carry policy references. With the mechanisms in this document, an LCP server (acting for the Location Server (LS) or Location Information Server (LIS)) can tell a host which policy document controls a given location resource. The host, in its Rule Maker role, can then look at that document and change it as needed. 👑
Here's the 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 rest of the document goes like this 💅 First we cover a few key terms, then we define policy URIs as a channel for referencing, inspecting, and updating policy documents. After that we define a HELD protocol extension so HELD can carry policy URIs. Examples show how policy URIs travel in this protocol and how clients can use them. ✨
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 [RFC2119]. (These are the official BCP 14 words, so they're the ones to watch for 👀)
3. Policy URIs 🔐
A policy URI is an HTTP [RFC2616] or HTTPS [RFC2818] URI. It identifies a policy resource that holds the authorization policy for a linked location resource. Access to the location resource is controlled by what's in that authorization policy. It's giving gatekeeper. 🚪
A policy URI identifies an HTTP resource. A Rule Maker can use it to inspect and install policy documents, which tell a Location Server how to protect the associated location resource. A policy URI always identifies a resource that can be represented as a common-policy document [RFC4745], and that resource may include some extensions too, like the ones for geolocation policy [RFC6772]. 💜
Note: RFC 3693 [RFC3693] named the Rule Holder role as the one that stores policy information. In this document, the Location Server is also a Rule Holder. 🌸
3.1. Policy URI Usage 🎀
Okay so a Location Server that's the authority for policy URIs MUST support GET, PUT, and DELETE requests to these URIs, so clients can inspect, replace, and delete policy documents 💅. Clients just pick whichever of the three methods they need for the job 🦋.
Knowing the policy URI counts as adequate evidence of authorization, bestie. A policy URI basically works as a shared secret between the client and the server (see Section 7) 🔐. A Location Server SHOULD allow all requests, but it MAY deny certain ones based on local policy. For example, a server might let clients peek at policy (GET) but not change it (PUT). Or it might require clients to authenticate using HTTP or Transport Layer Security (TLS) client authentication. Clients implementing this spec SHOULD support HTTP client authentication [RFC2617] and MAY support TLS client certificates 🌸.
A GET to a policy URI is a request for the policy info it points to. If the request is authorized, the Location Server sends back an HTTP 200 response containing the complete policy identified by the URI ✨.
A PUT to a policy URI is a request to replace the current policy 🔄. The entity-body of a PUT includes a complete policy document. When a Location Server gets a PUT, it MUST validate the policy document in the body of the request. If the request is valid and authorized, the Location Server MUST replace the current policy with the one provided in the request 💖.
A DELETE to a policy URI is a request to delete the referenced policy document 🗑️. If the request is authorized, 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. Literally a total lockdown until someone uploads a fresh one 🙈.
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 become invalid in three ways: when a validity interval in policy expires, when a policy document is removed with a DELETE request, or when the LCP-specified validity interval expires. The first two are temporary, since the policy URI can still be used to update the policy. The last one is permanent, since the expiry also invalidates the policy URI 💀.
The Location Server MUST support policy documents in the common-policy format [RFC4745], identified by the MIME media type of "application/auth-policy+xml" 📜. The common-policy format MUST be the default format in response to GET requests that don't include specific "Accept" headers, but content negotiation MAY be used to allow other formats 🌈.
This usage of HTTP is generally compatible with the Extensible Markup Language (XML) Configuration Access Protocol (XCAP) [RFC4825] or Web Distributed Authoring and Versioning (WebDAV) [RFC4918] for managing policy documents. But this document doesn't define or require either of those protocols 🧚.
3.2. Policy URI Allocation 🍓
A Location Server creates a policy URI for a specific location resource at the moment that resource is created. So the policy URI is born at the same time as the location URI it controls 👶. The URI of the policy resource MUST be different from the location URI.
A policy URI is handed out in response to location configuration requests. A policy URI MUST NOT be provided to an entity that isn't authorized to view or set policy 🙅. This document doesn't describe how policy might reach entities other than for location configuration, for example in responses to dereferencing requests [RFC6753] or requests from third parties [RFC6155].
Each location URI has either one policy URI or no policy URI. The initial policy 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 doesn't support policy URIs can keep using the location URI the way it would if no policy URI had been provided 🫶.
For HELD, the client assumes the default policy grants any requester access to location information, as long as the request has the location URI. To make the authorization policy less permissive, a client updates the policy before distributing the location URI 🔒.
A Location Server chooses whether or not to provide a policy URI based on local policy. A HELD-specific extension also lets a requester specifically ask for one 🎯.
A policy URI is effectively a shared secret between the Location Server and its clients. Knowing a policy URI is all you need to perform any operation the policy allows 😭. So a policy URI should be constructed so that it's hard to predict, and confidentiality protected when it's transmitted (see Section 7). To avoid reusing these shared secrets, the Location Server MUST generate a new policy URI whenever it generates a new location URI set 🔁.
3.3. Policy Defaults 🌷
Client implementors should keep in mind that setting no policy (never performing an HTTP request to a policy URI) is very different from setting an empty policy (performing a PUT with the empty policy). By "the empty policy," we mean a policy containing no rules, which would be represented by the following policy document 🫧:
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
</ruleset>Figure 1: The Empty Policy
If no policy is set, the client tacitly accepts whatever policy the server applies to location URIs, including a policy that provides location to anyone who makes a dereference request 👀. If the empty policy is set, the opposite is true: the client directs the server to never provide access to location. (That's because there are no rules to allow access, and the policy language is default-deny 🚫.)
So implementors should consider carefully how to handle the case where the user provides no privacy policy input 🤔. On the one hand, an implementation might treat this case as if the user had no privacy preferences and, therefore, set no policy. On the other hand, another implementation might decide that if a user provides no positive authorization, then the empty policy should be installed.
The same reasoning could also be applied to servers, with the caveat that servers don't know whether a given HELD client supports the use of policy URIs. A client that doesn't understand policy URIs won't be able to set its own policy, so the server must choose a default that's open enough that clients will find it useful 🛠️. On the other hand, once a client indicates that it understands policy URIs (by including a "requestPolicyUri" element in its HELD request), the 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 it wants 🌟.
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 going to control policy on these URIs, it needs a way to access the policy the Location Server uses to guide how it serves location URIs. This section defines extensions to LCPs that carry policy URIs, so the target can use them to control access to location resources 💜.
4.1. HELD 💅
The HELD protocol [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's added to a location request to indicate that a Device wants a policy URI allocated, and a "policyUri" element that's 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 the 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 🙋.
4.2. Client Processing 🦋
It's possible this document will be updated to allow policy URIs that use protocols other than the HTTP-based protocol described above 🔮. To make sure they fail safely when handed such a URI, clients implementing this specification MUST verify that a policy URI received from HELD uses either the "http:" or "https:" scheme. If the URI doesn't match those schemes, the client MUST discard the URI and behave as if no policy URI was provided 🚨.
5. Examples 🎀
In this section, we share some brief illustrations of how policy URIs get delivered to target hosts and then used by those hosts to manage policy 🌈.
A HELD request that explicitly requests the creation of a policy URI looks like this 📨:
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationType exact="true">locationURI</locationType>
<requestPolicyUri
xmlns="urn:ietf:params:xml:ns:geopriv:held:policy"/>
</locationRequest>A HELD response that provides a single "locationUriSet", containing two URIs under a common policy, would look like this 💌:
<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationUriSet expires="2011-01-01T13:00:00.0Z">
<locationURI>
https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
</locationURI>
<locationURI>
sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com:
</locationURI>
</locationUriSet>
<policyUri xmlns="urn:ietf:params:xml:ns:geopriv:held:policy">
https://ls.example.com:9768/policy/357lp6f64prlbvhl5nk3b
</policyUri>
</locationResponse>5.1. Basic Access Control Policy ✨
okay so bestie, picture a client that gets the policy URI <https://ls.example.com:9768/policy/357lp6f64prlbvhl5nk3b>, same as in the LCP example from before 🎀. The first thing that URI lets the client do is peek at the default policy the Location Server (LS) already attached to it 👀
GET /policy/357lp6f64prlbvhl5nk3b 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"
xmlns:gp="urn:ietf:params:xml:ns:geolocation-policy">
<rule id="AA56ia9">
<conditions>
<validity>
<until>2011-01-01T13:00:00.0Z</until>
</validity>
</conditions>
<actions/>
<transformations>
<gp:provide-location/>
<gp:set-retransmission-allowed>
false
</gp:set-retransmission-allowed>
<gp:set-retention-expiry>0</gp:set-retention-expiry>
</transformations>
</rule>
</ruleset>ngl this default is giving "anyone can see me" 💅 It lets any requester grab location info, as long as they know the location URI. If the user is like "nah, I only want my bestie to see me, and only at city level" 🙅♀️, then the client can install this policy on the Location Server:
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:friend@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 OKAnd then, after using the URI for a while, the user decides they're done and wants to permanently kill it 💀 That's where the DELETE comes in:
DELETE /policy/357lp6f64prlbvhl5nk3b HTTP/1.1
Host: ls.example.com:9768
HTTP/1.1 200 OK6. IANA Considerations 🦋
This document needs a few IANA registrations, all detailed below 🌸
6.1. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:held:policy
This section registers a brand new XML namespace, urn:ietf:params:xml:ns:geopriv:held:policy, following the guidelines in [RFC3688] 🧚
URI: urn:ietf:params:xml:ns:geopriv:held:policy
Registrant Contact: IETF, GEOPRIV working group,
(geopriv@ietf.org), Richard Barnes (rlb@ipv.sx).
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>
END6.2. XML Schema Registration
This section registers an XML schema, also following the guidelines in [RFC3688] 💖
URI: urn:ietf:params:xml:schema:geopriv:held:policy
Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org),
Richard Barnes (rlb@ipv.sx)
Schema: The XML for this schema can be found in Section 4.1.7. Security Considerations 💀
okay this section is SERIOUS, so pay attention 🥺 There are two main kinds of risk with access control policy management. The first is unauthorized grants, or denials of access to the protected resource, caused by messing with the policy management process. The second is leaking the policy information itself 😱
Protecting the management process from being messed with comes down to two big requirements. First, the policy URI has to reach the client faithfully and confidentially. Second, the policy document has to reach the Location Server faithfully and confidentially too. On top of that, the mechanism has to make sure only authorized entities can get or change policy 🔐
7.1. Integrity and Confidentiality for Authorization Policy Data
Each LCP handles integrity and confidentiality its own way (see [RFC5985]). These measures make sure a policy URI gets to the client without being changed or intercepted 🫶
Generally speaking, the TLS requirements for policy transactions are the same as the ones 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] give you both integrity protection and confidentiality ✨ If other means of protection are available, an "http:" URI MAY be used. Even so, location servers SHOULD reject PUT and DELETE requests for policy URIs that use the "http:" URI scheme 🙅♀️
7.2. Access Control for Authorization Policy
Access control for the policy resource is based on knowing its URI 🗝️ The URI of a policy resource works under the same constraints as a possession model location URI [RFC5808], and it's subject to those same constraints too:
- 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 used to inspect, change, or delete the policy resource. Note that in some protocols (such as DHCP), these protections may come from limiting the protocol to the local network, which means 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.
- 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 🎲
- 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))/Tqueries 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 whole point of the rate-limiting advice is to bound the chance that an attacker guesses a policy URI during its lifetime. If an attacker is limited to (2^(N/2))/T queries per second, then they can make at most 2^(N/2) guesses over the lifetime of the URI. Assuming those guesses are all distinct, the probability of 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 it has expired, there's no risk at all 🙃) 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 matching risk of compromise is an acceptable level of risk 📊
If M distinct URIs are issued within the same namespace, then the probability of any one of those M URIs being compromised is M*2^(N/2). The example algorithm for generating policy URIs (see Appendix A) puts them in independent namespaces (that is, below the corresponding location URIs), so this compounding doesn't happen 🙌
Also, the chosen entropy level affects 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 give acceptably high maximum query rates and an 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 ⏰
7.3. Location URI Allocation
A policy URI enables the authorization by access control lists model [RFC5808] for associated location URIs. Under this model, it might be possible to distribute a location URI more widely, and rely on the authorization policy to constrain access to location information 🦋
To allow for wider distribution, authorization by access control lists puts extra constraints on how location URIs get built 🧱
If multiple Targets share a location URI, an unauthorized location recipient who collects location URIs for those Targets can tell that they're in the same place just by comparing them. With shared policy URIs, Targets can see and change the authorization policy for other Targets. Not ideal, bestie 😭
So, to allow for Target-specific authorization policies that are properly privacy protected, each location URI and policy URI issued to a different Target MUST be different from every other location URI and policy URI. That is, two clients MUST NOT receive the same location URI or the same policy URI 🔒
In some deployments, it isn't always obvious to an LCP server that two clients are actually different. In particular, where a middlebox [RFC3234] exists, two or more clients might look like a single client. An example of a deployment scenario like this 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 coming from the same client 💜
7.4. Policy URI Handling 🔐
okay so servers can totally choose to put access controls on policy URIs 💅 but by default? literally any holder of a policy URI is authorized to access and modify the policy document it points to, which means they also get to control access to the location resources tied to it 😭 policy URIs work like shared secrets, so clients SHOULD protect them the way they'd protect passwords 🫶 bestie, policy URIs SHOULD NOT be sent to other hosts or stored in plaintext. guard that thing 🔒
it's worth noting that one of the best parts of the policy URI setup is that most of the time, the policy URI never even leaves the client device it was given to 🦋 without policy URIs, location URIs get a default policy the server sets all on its own, and they have to be passed to someone else before they're useful at all 🙃 with policy URIs, location URIs can have way more nuanced access controls, and the shared secret used to authenticate the client (i.e., the policy URI) can just live on the client and be used to set the access control policy on the location URI ✨ so yeah, policy URIs still use a default model of authorization by possession, but they lower the overall risk to location privacy when shared secret URIs leak 🌸
8. Acknowledgements 🙏
thanks to Mary Barnes and Alissa Cooper for giving critical commentary and input on the ideas in this document 💖 also, a big thank you to Ted Hardie and Adam Roach for helping clarify how policy URIs, policy documents, and location resources all relate to each other 🧚 and thanks to Stephen Farrell for a super helpful chat about security and privacy challenges 💜
9. References ✨
9.1. Normative References
[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.9.2. Informative References
[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.Appendix A. Example Policy URI Generation Algorithm 🧩
okay so here's one possible algorithm for generating appropriately unpredictable policy URIs for a location URI set 🎀
- Choose parameters:
- A cryptographic hash function
H, e.g., SHA256 - A number
Nof bits of entropy to add, such thatNis no more than the length of the output of the hash function
- A cryptographic hash function
- On allocation of a location URI, generate a policy URI in the following way:
- Generate a random value
NONCEat leastN/8bytes long - Compute
hash = H( Location-URI-Set || NONCE )using some cryptographic hash functionHand some serialization of the location URI set (e.g., the XML from a HELD response) - Form the policy URI by appending the base64url-encoded form of the hash [RFC4648] to one of the location URIs, e.g., as a query parameter:
"http://example.com/loc/foo?policy=j3WTGUb3smxcZA6eKIqmqdV3ALE"
- Generate a random value
Authors' Addresses 📮
Richard Barnes
Mozilla
331 E. Evelyn Ave.
Mountain View, CA 94041
US
EMail: rlb@ipv.sx
Martin Thomson
Mozilla
Suite 300
331 E Evelyn Street
Mountain View, CA 94041
US
EMail: martin.thomson@gmail.com
James Winterbottom
Unaffiliated
AU
EMail: a.james.winterbottom@gmail.com
Hannes Tschofenig
Hall in Tirol 6060
Austria
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at📦 where this page comes from
- ietf: rfc7199 2014-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms