RFC 6753
A Location Dereference Protocol Using HTTP-Enabled Location Delivery (HELD)
A Location Dereference Protocol Using HTTP-Enabled Location Delivery (HELD) 💖
Okay bestie, this is RFC 6753 🎀 It's an IETF Standards Track document from October 2012, with ISSN 2070-1721. The authors are J. Winterbottom from Commscope, H. Tschofenig from Nokia Siemens Networks, H. Schulzrinne from Columbia University, and M. Thomson from Microsoft. Its header doesn't list any RFCs it obsoletes or updates. 🌸
Abstract ✨
So basically this doc explains how to use HTTP over TLS (Hypertext Transfer Protocol over Transport Layer Security) as a dereference protocol 🦋 The goal is to resolve a reference to a PIDF-LO (Presence Information Data Format Location Object). It assumes a Location Recipient already has a URI that works with HELD (HTTP-Enabled Location Delivery) to ask for the location of the Target. Main character energy 👑
Status of This Memo 💅
This is an Internet Standards Track document.
This doc is a product of the IETF (Internet Engineering Task Force) 🌈 It represents the consensus of the IETF community, it got public review, and the IESG (Internet Engineering Steering Group) approved it for publication. If you want more info on Internet Standards, check out Section 2 of RFC 5741.
For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6753.
Copyright Notice 🧚
Copyright (c) 2012 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 in effect on the publication date. Please actually read these, because they spell out your rights and restrictions for this document 🙈 Code Components pulled out of this document have to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License.
Table of Contents 🍓
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. HELD Dereference Protocol . . . . . . . . . . . . . . . . . . 4
3.1. HELD Usage Profile . . . . . . . . . . . . . . . . . . . . 4
3.2. HTTP GET Behavior . . . . . . . . . . . . . . . . . . . . 5
4. Authorization Models . . . . . . . . . . . . . . . . . . . . . 6
4.1. Authorization by Possession . . . . . . . . . . . . . . . 7
4.2. Authorization via Access Control . . . . . . . . . . . . . 8
4.3. Access Control with HELD Dereference . . . . . . . . . . . 9
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. GEOPRIV Using Protocol Compliance . . . . . . . . . . 18
Appendix B. Compliance to Location Reference Requirements . . . . 21
B.1. Requirements for a Location Configuration Protocol . . . . 21
B.2. Requirements for a Location Dereference Protocol . . . . . 231. Introduction ✨
Okay so a location URI [RFC5808] is a resource that holds the location of an entity 📍 This doc says how someone holding an "http:" or "https:" location URI uses it to get location info, either with a subset of HELD or with a plain HTTP GET request. 🦋
You can get a location URI from a location configuration protocol, like HELD [RFC5985] or the DHCP location URI option [DHCP-URI-OPT]. 💖
A Location Recipient that dereferences a location URI gets location info as a PIDF-LO document [RFC4119]. HELD parameters let you say what kind of location info you want, but there are some limits on which parameters are allowed. 🌸
Location URIs that work with HELD dereferencing use the "https:" or "http:" scheme. A Location Recipient can use HELD if it knows the URI is a location URI. Mandatory support for an HTTP GET request means the URI still works even when the recipient doesn't recognize it as a location URI. Iconic design, honestly 🫶
2. Terminology 🎀
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
This doc pulls its key terms from a few different places 📚
- The GEOPRIV reference model terms are defined in [RFC6280].
- The term "Location Information Server (LIS)", from [RFC5687], is a node in the access network that gives location info to an endpoint. A LIS provides location URIs. 🌈
- The term "Location Server (LS)", from [RFC6280], is the role that answers a location dereference request. A Location Server might be the same entity as the LIS, but the model in [RFC5808] allows for separate, though related, entities. 💅
- The term "location URI" is coined in [RFC5808]. ✨
3. HELD Dereference Protocol 🧚
This section explains how HELD can dereference a location URI 💜 This works when a Location Recipient has a location URI with an "https:" or "http:" URI scheme.
This doc doesn't describe a specific authentication mechanism. That means authorization policies can't specifically identify authorized Location Recipients. 🙈
A Location Recipient that wants to dereference an "https:" or "http:" URI sends a HELD request over HTTP to the identified resource. 🦋
Note: In many cases, an "http:" URI does not provide sufficient security for location URIs. Without the security that TLS provides, the Rule Maker has no control over who gets location info, and the Location Recipient has no assurance that the info is correct. 💀
The Location Recipient sets up a connection to the LS, as described in [RFC2818].
The scheme of a location URI decides whether TLS gets used for a given dereference transaction. Location Servers MUST be configured to issue only HTTPS URIs and respond only to HTTPS dereference requests, unless some other mechanism provides confidentiality and integrity protection. For example, the server might only accept requests from clients on a trusted network or over an IPsec-protected channel. When TLS is used, the TLS ciphersuite TLS_NULL_WITH_NULL_NULL MUST NOT be used, and the LS MUST be authenticated [RFC6125] so the correct server gets contacted. 🔥
A Location Server MAY reject a request and ask the Location Recipient for authentication credentials if authorization depends on the Location Recipient's identity. Future specs could define an authentication mechanism and a way to identify Location Recipients in authorization policies. This document doesn't define either one. 👑
3.1. HELD Usage Profile 💖
Using HELD as a location dereference protocol is pretty much the same as using it as a location configuration protocol 🌸 Apart from the restrictions in this document, HELD semantics don't differ from the ones in [RFC5985].
The HELD locationRequest is the only request this spec allows. Similarly, request parameters other than the following MUST NOT be accepted by the LS: responseTime and locationType (including the associated exact attribute).
Parameters and requests with no known behavior for dereference requests MUST NOT be used. The LS MUST ignore any parameters it doesn't understand, unless it knows those parameters are invalid. If the LS understands a parameter and knows it's invalid, the LS MAY generate a HELD error response. For instance, those defined in [RFC6155] are always invalid and can be rejected. 🙈
The LS MUST NOT generate location URIs or provide a locationUriSet in response to a dereference request. If the location request has a locationType element that includes locationURI, that parameter is either ignored or rejected, depending on the associated exact attribute. 🫶
3.2. HTTP GET Behavior 🦋
GET is the method generic HTTP user agents assume, so unless context marks an "https:" URI as a HELD URI, such a user agent might just send an HTTP GET. ✨ Instead of replying with an HTTP 405 (Method Not Allowed) response saying POST is the only permitted method, a LIS MUST provide a HELD location response when it gets an HTTP GET request. 🌈
An HTTP GET request to a HELD URI produces a HELD response as if the following HELD request had been sent using HTTP POST:
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationType exact="false">
geodetic civic
</locationType>
</locationRequest>Figure 1: GET Request Equivalent Location Request 🎀
HTTP GET requests MUST be safe and idempotent [RFC2616]. That means making the request has no side effects, and a repeated request has no more effect than a single one. Repeating a HELD request might give a different location, but only if the state of the resource changed, meaning the location of the Target. 🧚
Only creating a location URI as a result of a request causes a HELD request to have side effects. A request to a location URI can be both safe and idempotent, since a location URI can't be produced in response to a request to a location URI. A Location Recipient MAY infer from a response with the HELD content type "application/held+xml" that a URI references a resource supporting HELD. 💜
Content negotiation MAY be supported to produce a presence document in place of a HELD location response. When the presence document would otherwise go inside a locationResponse document, it can go directly in the body of the HTTP response instead, as long as the request includes an "Accept" header with "application/pidf+xml". 💅
4. Authorization Models ✨
okay so this section is all about the two extreme authorization models for dereferencing HELD URIs: "Authorization by Possession" and "Authorization by Access Control" 🔐 we'll go through what makes each one tick in the subsections. Figure 2 (taken from [RFC5808]) shows the model that applies to location configuration, conveyance, and dereference 💅
+---------+--------+ Location +-----------+
| | | Dereference | Location |
| LIS - LS +---------------+ Recipient |
| | | Protocol | |
+----+----+--------+ (3) +-----+-----+
| `. |
| Policy `. |
Location | Exchange `. |
Configuration | (*) | |
Protocol | +----+----+ |
(1) | | Rule | Location |
| | Maker | Conveyance |
+-----+----+ +---------+ Protocol |
| | (2) |
| Target +------------------------------+
| |
+----------+
Figure 2: Communication ModelImportant tea: this document does not mandate a specific authorization model 🫶 you're allowed to mix bits of both models together. BUT no authentication framework is provided, which limits the policy options you have when the "Authorization by Access Control" model is in play 🥺
For either model, the overall process is pretty much the same, with minor tweaks. Here's the flow:
- The Target grabs a location URI from the LIS. This uses a location configuration protocol (LCP), like HELD or DHCP.
- The Target then passes the location URI along to a third party, the Location Recipient (for example, using SIP as described in [RFC6442]). This is step (2) in Figure 2.
- The Location Recipient then has to dereference the location URI to get the Location Object (3). An
https:orhttp:URI gets dereferenced the way this document describes; other URI schemes might be dereferenced using another method 🧚
In that last step, the Location Server (LS) or LIS makes an authorization decision. How that decision gets reached depends on which authorization model you're using 👑
4.1. Authorization by Possession
In this model, possession -- or knowledge -- of the location URI is what controls access to location information 🗝️ A location URI might be built so it's hard to guess (see C8 of [RFC5808]), and the set of entities it gets disclosed to can be limited. The only authentication the LS would need is evidence that you have the URI. The LS could immediately authorize any request that shows this URI 💖
Authorization by possession doesn't need direct interaction with a Rule Maker. It's assumed the Rule Maker can control how the location URI gets distributed. So the LIS can run with limited policy input from a Rule Maker 🌸
Limited disclosure is a big deal in this model 😭 The location URI is a secret, so keeping adversaries from getting their hands on it is literally the top priority. Encryption, such as what TLS [RFC5246] or S/MIME [RFC5751] can offer, protects the information from eavesdroppers 🔒
Heads up: using authorization by possession location URIs in a hop-by-hop protocol such as SIP [RFC3261] adds the possibility of on-path adversaries 👀 Depending on how the location URI is used for certain location-based applications (e.g., emergency services and location-based routing), specific treatment is important, as discussed in [RFC6442].
Here's the tricky part: once possession has been granted, authorization can't be easily revoked 💀 Cancelling a location URI means legitimate users get affected too. Applying additional policy is theoretically possible, but it could be technically infeasible. Expiration of location URIs limits how long a URI is usable, which means an attacker would have to keep learning new location URIs to keep access to current location information ⏳
A very simple policy might be set when the location URI is created. This policy says the location URI expires after a certain time, which limits any accidental exposure of location information to adversaries 🫧 The expiration time might be negotiated at creation, or the LIS might just set it unilaterally.
4.2. Authorization via Access Control
Explicit access control gives a Rule Maker way more control over how an LS behaves 🎀 Unlike authorization by possession, having this form of location URI does NOT imply authorization. Since an explicit policy is what authorizes access to location information, the location URI can be distributed to lots of potential Location Recipients 🦋
Before the location URI is created or disseminated, the Rule Maker sets up an authorization policy with the LS. Looking at Figure 2, authorization policies might be established at creation (Step 1), and they need to be established before the location URI is published (Step 2) so the policy actually grants access to the Location Recipients you want 💅 Depending on the mechanism used, it might also be possible to change authorization policies at any time.
A possible format for these authorization policies is available with GEOPRIV Common Policy [RFC4745] and Geolocation Policy [GEOPRIV-POLICY]. Additional constraints might be set up by other means ✨
The LS enforces the authorization policy whenever a Location Recipient dereferences the URI. Explicit authorization policies let a Rule Maker decide exactly how location information gets provided to Location Recipients 👑
4.3. Access Control with HELD Dereference
This document doesn't describe a specific authentication mechanism, so the authorization by access control model is NOT an option here 🙈 Instead, this document assumes the authorization by possession model.
Other policy mechanisms, like the ones described in [GEOPRIV-POLICY], can be applied for different Location Recipients as long as each recipient gets a different location URI. Each location URI can have its own authorization policy. Selective disclosure used this way can stand in for identity-based authorization 🧚
How policy gets associated with a location URI isn't defined by this document. [GEOPRIV-POLICY-URI] describes one possible mechanism 🌈
Using an identity-based authorization policy is not precluded. A Location Server MAY support an authentication mechanism that lets identity-based authorization policies be used 🫶 Future specifications might define ways of identifying recipients.
Note: policy frameworks like [RFC4745] degrade in a way that protects privacy if features aren't supported 🥹 If a policy has a rule that depends on the identity of a recipient, and the protocol doesn't (or can't) provide an assertion identity of the recipient, the rule has no effect, and the policy defaults to providing less information 💜
5. Examples 🎀
okay so this is the scenario this whole doc is vibing with, and Figure 3 shows it 🧚 It's how a location dereference protocol fits in with location configuration and conveyance. [RFC5808] has way more on this one and others like it, so go check it if you're curious 💅
+-------------+
+------------+ | Location | +-----------+
| End Device | | Information | | Location |
| (Target) | | Server | | Recipient |
+-----+------+ +------+------+ +-----+-----+
| | |
.- + - - - - - - - - - - - - + -. |
: | locationRequest | : |
. |----(for location URI)-->| . |
: | | : Location |
. | locationResponse | . Configuration |
: |<-----(location URI)-----| : |
. | | . |
`- + - - - - - - - - - - - - + -' |
| | |
| Location Conveyance |
|~ ~ ~ ~ ~ ~ ~ ~ ~ ~(location URI)~ ~ ~ ~ ~ ~ ~ ~ ~>|
| | |
| .- + - - - - - - - - - - - - + -.
| : | locationRequest | :
| . |<------(for civic)-------| .
| Dereferencing : | | :
| . | locationResponse | .
| : |--------(PIDF-LO)------->| :
| . | | .
| `- + - - - - - - - - - - - - + -'
| | |Figure 3: Example of Dereference Protocol Exchange
Figure 4 is the simplest version of a dereferencing request using HELD, aimed at the location URI "https://ls.example.com:49152/uri/w3g61nf5n66p0" ✨ The only differences from the example in Section 10.1 of [RFC5985] are the request URI and where that URI came from.
POST /uri/w3g61nf5n66p0 HTTP/1.1
Host: ls.example.com:49152
Content-Type: application/held+xml
Content-Length: 87
<?xml version="1.0"?>
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"/>Figure 4: Minimal Dereferencing Request
Figure 5 is the response to that last request, and it's giving both civic and geodetic location info for the Target 🌸 Again, it's identical to the Section 10.1 response in [RFC5985]. Unless policy says otherwise, the Location Recipient gets the same info as the Device. Main character energy for the Device 👑
HTTP/1.1 200 OK
Server: Example LIS
Date: Mon, 10 Jan 2011 03:42:29 GMT
Expires: Tue, 11 Jan 2011 03:42:29 GMT
Cache-control: private
Content-Type: application/held+xml
Content-Length: 676
<?xml version="1.0"?>
<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="pres:3650n87934c@ls.example.com">
<tuple id="b650sf789nd">
<status>
<geopriv xmlns="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basic-policy">
<location-info>
<Point xmlns="http://www.opengis.net/gml"
srsName="urn:ogc:def:crs:EPSG::4326">
<pos>-34.407 150.88001</pos>
</Point>
</location-info>
<usage-rules>
<gbp:retransmission-allowed>
false</gbp:retransmission-allowed>
<gbp:retention-expiry>
2011-01-11T03:42:29+00:00</gbp:retention-expiry>
</usage-rules>
<method>Wiremap</method>
</geopriv>
</status>
<timestamp>2006-01-10T03:42:28+00:00</timestamp>
</tuple>
</presence>
</locationResponse>Figure 5: Response with Location Information
The GET request below gets treated the same way 💖 The LS handles it like a location request of the form shown in Figure 1, so it might even hand back the same response.
GET /uri/w3g61nf5n66p0 HTTP/1.1
Host: ls.example.com:49152
Accept: application/held+xmlFigure 6: GET Request
This GET request uses content negotiation to say it prefers a presence document 🦋
GET /uri/w3g61nf5n66p0 HTTP/1.1
Host: ls.example.com:49152
Accept: application/pidf+xml,application/held+xml;q=0.5Figure 7: GET Request with Content Negotiation
The response here is basically a normal HELD location response to a POST request, with two differences: the "locationResponse" element is left out, and the "Content-Type" header shows the new content 🍓
HTTP/1.1 200 OK
Server: Example LIS
Date: Mon, 10 Jan 2011 03:42:29 GMT
Expires: Tue, 11 Jan 2011 03:42:29 GMT
Cache-control: private
Content-Type: application/pidf+xml
Content-Length: 591
<?xml version="1.0"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="pres:3650n87934c@ls.example.com">
<!-- PIDF contents are identical to the previous example -->
</presence>Figure 8: GET Response with PIDF-LO
6. Security Considerations 🔒
okay this section is SERIOUS bestie 😭 Privacy of location info is the most important security thing in this whole doc. There are two main tools for protecting it: TLS and authorization policies. TLS keeps location info confidential through encryption and mutual authentication. An authorization policy lets a Rule Maker explicitly control how location info gets handed out to Location Recipients.
How a Rule Maker sets up an authorization policy isn't covered here. There are a few ways to do it, for example [GEOPRIV-POLICY-URI] and [RFC4825] 🌈
TLS MUST be used for dereferencing location URIs unless confidentiality and integrity are provided by some other mechanism, as discussed in Section 3. Location Recipients MUST authenticate the host identity using the domain name in the location URI, following the procedure in Section 3.1 of [RFC2818]. What a Location Recipient does when authentication fails or can't be attempted is up to local policy 🫶
The authorization by possession model (Section 4.1) also leans on TLS when the location URI is sent, so the URI's secrecy stays protected. Having the URI means you have the same privacy concerns as having the PIDF-LO document it points to 🙈
Location URIs MUST only be disclosed to authorized Location Recipients. The GEOPRIV architecture [RFC6280] says the Rule Maker is the one who authorizes disclosing the URI 👑
Protecting the location URI really matters, because the policy on a location URI lets anyone holding the URI view the location info it's attached to 💀 The location conveyance protocols, like [RFC6442], go into more detail on this.
According to the requirements in [RFC5808], the LS MUST NOT provide any information about the Target except its location, unless a Rule Maker's policy allows otherwise. So the Location Server MUST only provide an unlinked pseudonym in the "entity" attribute of the PIDF-LO document, unless the Rule Maker's policy allows identity disclosure ✨
More security considerations and requirements for using location URIs are in [RFC5808] 🦋
7. Acknowledgements 💜
Thanks to Barbara Stark and Guy Caron for early comments 🎀 Thanks to Rohan Mahy for helpful comments on the scope and format of the document. Thanks to Ted Hardie for his strawman proposal, which helped with the security section. Richard Barnes made useful observations about applying authorization policy. Bernard Aboba and Julian Reschke did constructive reviews.
The participants of the GEOPRIV interim meeting 2008 gave a ton of great feedback on this document 🌸
James Polk gave input on security in June 2008 🧚
Martin Dawson was an original author of this document. Sadly, he passed away before it was published. He's a real one and we miss him 🕊️
8. References 📚
8.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.
- [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
- [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.
- [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations", RFC 5491, March 2009.
- [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC 5985, September 2010.
- [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, March 2011.
8.2. Informative References 📚✨
okay so bestie, these are the informative references, the reading list that backs up the spec without being required to implement it 🤓💅 Here's the whole list, every single entry:
[DHCP-URI-OPT]Polk, J., "Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6 Option for a Location Uniform Resource Identifier (URI)", Work in Progress, May 2012. 🌸[GEOPRIV-POLICY]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", Work in Progress, August 2012. 🦋[GEOPRIV-POLICY-URI]Barnes, R., Thomson, M., Winterbottom, J., and H. Tschofenig, "Location Configuration Extensions for Policy Management", Work in Progress, November 2011. 🧚[RFC3261]Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. 📞[RFC3693]Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 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. 🎀[RFC4825]Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", RFC 4825, May 2007. 🌈[RFC5246]Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. 🔐[RFC5687]Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location Configuration Protocol: Problem Statement and Requirements", RFC 5687, March 2010. ⭐[RFC5751]Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 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. 🪪[RFC6280]Barnes, R., Lepinski, M., Cooper, A., Morris, J., Tschofenig, H., and H. Schulzrinne, "An Architecture for Location and Location Privacy in Internet Applications", BCP 160, RFC 6280, July 2011. 🏰[RFC6442]Polk, J., Rosen, B., and J. Peterson, "Location Conveyance for the Session Initiation Protocol", RFC 6442, December 2011. 🛰️
Appendix A. GEOPRIV Using Protocol Compliance 🛡️💖
okay this appendix is the compliance checklist, aka "does HELD actually follow the GEOPRIV rules?" spoiler: mostly yes, with a couple of honest "not me…" moments 💅 It's a big one, so let's go.
This section describes how use of HELD as a location dereference protocol complies with the GEOPRIV requirements described in [RFC3693].
Req. 1. (Location Object generalities): This requirement relates to the PIDF-LO [RFC4119] document, which is used by HELD. These requirements are addressed by [RFC4119] and [RFC5491]. 🧁
Req. 2. (Location Object fields): This requirement relates to the PIDF-LO [RFC4119] document, which is used by HELD. These requirements are addressed by [RFC4119] and [RFC5491]. 🫧
Req. 3. (Location Data Types): This requirement relates to the PIDF-LO [RFC4119] document, which is used by HELD. These requirements are addressed by [RFC4119] and [RFC5491]. 🌷
Section 7.2 of [RFC3693] details the requirements of a "Using Protocol". These requirements are restated, followed by a statement of compliance. 📝
Req. 4. "The using protocol has to obey the privacy and security instructions coded in the Location Object and in the corresponding Rules regarding the transmission and storage of the LO".
Compliant: This specification describes the use of HTTP over TLS for carrying the PIDF-LO from the LS to the Location Recipient. The sending and receiving parties are expected to comply with the instructions carried inside the object. 🔒
Though discouraged, using unsecured http: URIs is permitted. Using unsecured HTTP is likely to result in non-compliance with this requirement. 🙈
Req. 5. "The using protocol will typically facilitate that the keys associated with the credentials are transported to the respective parties, that is, key establishment is the responsibility of the using protocol".
Compliant: This document specifies that authentication of the LS uses the established public key infrastructure used by HTTP over TLS [RFC2818]. Authentication of Location Recipients is based on distribution of a secret (the location URI) using a conveyance protocol (for instance, [RFC6442]), allowances are made for later work to define alternative methods. 🗝️
Req. 6. "(Single Message Transfer) In particular, for tracking of small target devices, the design should allow a single message/packet transmission of location as a complete transaction".
Not Compliant: The XML encoding specified in [RFC4119] is not suited to single packet transfers. Use of compressed content encoding [RFC2616] might allow this condition to be met. 💀
Section 7.3 of [RFC3693] details the requirements of a "Rule based Location Data Transfer". These requirements are restated where they are applicable to this document. 📜
Req. 7. "(LS Rules) The decision of a Location Server to provide a Location Recipient access to Location Information MUST be based on Rule Maker-defined Privacy Rules".
Compliant: This document describes two alternative methods by which a Rule Maker is able to control access to location information. Rule Maker policy is enforced by the LS when a location URI is dereferenced. However, this document does not describe how a location URI is created or how a Rule Maker associates policy with a location URI. These are covered by other specifications. 👑
Req. 8. (LG Rules) Not Applicable: This relationship between LS and the source of its information (be that Location Generator (LG) or LIS) is out of the scope of this document. 🍃
Req. 9. "(Viewer Rules) A Viewer does not need to be aware of the full Rules defined by the Rule Maker (because a Viewer SHOULD NOT retransmit Location Information), and thus a Viewer SHOULD receive only the subset of Privacy Rules necessary for the Viewer to handle the LO in compliance with the full Privacy Rules (such as, instruction on the time period for which the LO can be retained)".
Compliant: The Rule Maker might define (via mechanisms outside the scope of this document) which policy rules are disclosed to other entities. For instance, if [RFC4745] is used to convey authorization policies from Rule Maker to LS, this is possible using the parameters specified in [GEOPRIV-POLICY].
In order to comply with these rules, a Location Recipient MUST NOT redistribute a location URI without express permission. Depending on the access control model, the location URI might be secret (see Section 3.3 of [RFC5808]). 🤫
Req. 10. (Full Rule language) Not Applicable: Note, however, that GEOPRIV has defined a rule language capable of expressing a wide range of privacy rules (see [RFC4745] and [GEOPRIV-POLICY]. 🌈
Req. 11. (Limited Rule language) Not Applicable: This requirement applies to (and is addressed by) PIDF-LO [RFC4119]. 🫶
Section 7.4 of [RFC3693] details the requirements of "Location Object Privacy and Security". These requirements are restated where they are applicable to this document. 🕵️♀️
Req. 12. (Identity Protection) Compliant: Identity protection of the Target is provided as long as both of the following conditions are true:
- (a) the location URI is not associated with the identity of the Target in any context, and
- (b) the PIDF-LO does not contain information about the identity of the Target.
For instance, this requirement is complied with if the protocol that conveys the location URI does not link the identity of the Target to the location URI and the LS doesn't include meaningful identification information in the PIDF-LO document. Section 6 recommends that an unlinked pseudonym is used by the LS. 🎭
Req. 13. (Credential Requirements) Compliant: The primary security mechanism specified in this document is Transport Layer Security. TLS offers the ability to use different types of credentials, including symmetric, asymmetric, or a combination of them. 🔑
Req. 14. (Security Features) Compliant: GEOPRIV defines a few security requirements for the protection of Location Objects such as mutual endpoint authentication, data object integrity, data object confidentiality, and replay protection. The ability to use Transport Layer Security fulfills most of these requirements. Authentication of Location Recipients in this document relies on proof of a shared secret -- the location URI. This does not preclude the addition of more robust authentication procedures. 🛡️✨
Req. 15. (Minimal Crypto) Compliant: The mandatory-to-implement ciphersuite is provided in the TLS layer security specification [RFC5246]. 💎
Appendix B. Compliance to Location Reference Requirements 🦋
last one! this appendix is about how HELD lines up with the location-by-reference requirements from [RFC5808] 🎀 and it also drops a really important note about what HELD does and doesn't mean 👀
This section describes how HELD complies to the location reference requirements stipulated in [RFC5808]. Compliance of [RFC5985] to the Location Configuration Protocol is included.
Note: Use of HELD as a location dereference protocol does not necessarily imply that HELD is the corresponding LCP. This document is still applicable to HTTP location URIs that are acquired by other means. 💅🌸
B.1. Requirements for a Location Configuration Protocol 🗺️✨
okay so this is the checklist for what a location configuration protocol has to do, bestie 💅 and then it tells us how HELD does on each one 👀
- C1. "Location URI support: The location configuration protocol MUST support a location reference in URI form"
- Compliant: HELD only provides location references in URI form. 🎀
- C2. "Location URI expiration: When a location URI has a limited validity interval, its lifetime MUST be indicated"
- Compliant: HELD indicates the expiry time of location URIs using the "expires" attribute. [GEOPRIV-POLICY-URI] provides a way to control expiration of a location URI. ⏰
- C3. "Location URI cancellation: The location configuration protocol MUST support the ability to request a cancellation of a specific location URI"
- Compliant with Extension: [GEOPRIV-POLICY-URI] describes how a location URI can be canceled through the application of policy. Without extensions, HELD does not provide a method for canceling location URIs. 🙈
- C4. "Location Information Masking: The location URI MUST ensure, by default, through randomization and uniqueness, that the location URI does not contain location information specific components"
- Compliant: The HELD specification [RFC5985] explicitly references this requirement in providing guidance on the format of the location URI. 🫶
- C5. "Target Identity Protection: The location URI MUST NOT contain information that identifies the Target (e.g., user or device)"
- Compliant: The HELD specification [RFC5985] provides specific guidance on the anonymity of the Target with regards to the generation of location URIs. Section 6 expands on this guidance. 🦋
- C6. "Reuse indicator: There SHOULD be a way to allow a Target to control whether a location URI can be resolved once only, or multiple times"
- Not Compliant: Specific extensions to the protocol or authorization policy formats are needed to alter the default behavior, which allows unlimited resolution of the location URI. 😭
- C7. "Selective disclosure: The location configuration protocol MUST provide a mechanism that allows the Rule Maker to control what information is being disclosed about the Target"
- Compliant with Extension: Use of policy mechanisms and [GEOPRIV-POLICY-URI] enable this capability. Note that this document recommends that only location information be provided. 🌸
- C8. "Location URI Not guessable: As a default, the location configuration protocol MUST return location URIs that are random and unique throughout the indicated lifetime. A location URI with 128-bits of randomness is RECOMMENDED"
- Compliant: HELD specifies that location URIs conform to this requirement. The amount of randomness is not specifically identified since it depends on a number of factors that change over time, such as the number of valid location URIs, the validity period of those URIs, and the rate that guesses can be made. 🔐
- C9. "Location URI Options: In the case of user-provided authorization policies, where anonymous or non-guessable location URIs are not warranted, the location configuration protocol MAY support a variety of optional location URI conventions, as requested by a Target to a location configuration server, (e.g., embedded location information within the location URI)"
- Not Compliant: HELD does not support Device-specified location URI forms. 🙅♀️
B.2. Requirements for a Location Dereference Protocol 🔍💖
now the dereference side, which is the bit where the Location Recipient actually goes and gets the location 🧚
- D1. "Location URI support: The location dereference protocol MUST support a location reference in URI form"
- Compliant: HELD only provides location references in URI form. 🎀
- D2. "Authentication: The location dereference protocol MUST include mechanisms to authenticate both the client and the server"
- Partially Compliant: TLS provides means for mutual authentication. This document only specifies the required mechanism for server authentication. Client authentication is not precluded. 🤝
- D3. "Dereferenced Location Form: The value returned by the dereference protocol MUST contain a well-formed PIDF-LO document"
- Compliant: HELD requires that Location Objects are in the form of a PIDF-LO that complies with [RFC5491]. 📍
- D4. "Location URI Repeated Use: The location dereference protocol MUST support the ability for the same location URI to be resolved more than once, based on dereference server configuration"
- Compliant: A Location Recipient may access and use a location URI as many times as desired until URI expiration results in the URI being invalidated. Authorization policies might include rules that modify this behavior. 🔁
- D5. "The location dereference protocol MUST support confidentiality protection of messages sent between the Location Recipient and the location server"
- Compliant: This document strongly recommends the use of TLS for confidentiality, and HELD mandates its implementation. Unsecured HTTP is permitted: the associated risks are described in Section 3. 🔒
ngl the TLS stuff is the main vibe here 😭 TLS for confidentiality is strongly recommended, and HELD mandates it, but unsecured HTTP is still allowed, so read Section 3 for the risks 💀
Authors' Addresses 🌈
James Winterbottom
Commscope
Andrew Building (39)
Wollongong University Campus
Northfields Avenue
Wollongong, NSW 2522
AU
Phone: +61 242 212938
EMail: james.winterbottom@commscope.com
Hannes Tschofenig
Nokia Siemens Networks
Linnoitustie 6
Espoo 02600
Finland
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
USA
Phone: +1 212 939 7042
EMail: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu
Martin Thomson
Microsoft
3210 Porter Drive
Palo Alto, CA 94304
USA
Phone: +1 650-353-1925
EMail: martin.thomson@skype.net📦 where this page comes from
- ietf: rfc6753 2012-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms