| GEOPRIV | J. Winterbottom |
| Internet-Draft | Commscope |
| Intended status: Standards Track | H. Tschofenig |
| Expires: October 31, 2012 | Nokia Siemens Networks |
| H. Schulzrinne | |
| Columbia University | |
| M. Thomson | |
| (Unaffiliated) | |
| May 2012 |
A Location Dereferencing Protocol Using HELD
This document describes how to use the Hypertext Transfer Protocol (HTTP) over Transport Layer Security (TLS) as a dereferencing protocol to resolve a reference to a Presence Information Data Format Location Object (PIDF-LO). The document assumes that a Location Recipient possesses a URI that can be used in conjunction with the HTTP-Enabled Location Delivery (HELD) protocol to request the location of the Target.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 31, 2012.
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) 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.
A location URI [RFC5808] identifies a resource that contains the location of an entity. This document specifies how a holder of an http: or https: location URI uses that URI to retrieve location information.
A location URI can be acquired using a location configuration protocol, such as HTTP-Enabled Location Delivery (HELD) [RFC5985] or the Dynamic Host Configuration Protocol (DHCP) location URI option [I-D.ietf-geopriv-dhcp-lbyr-uri-option].
A Location Recipient that dereferences a location URI acquires location information in the of a Presence Information Data Format - Location Object (PIDF-LO) document [RFC4119]. HELD parameters allow for specifying the type of location information, though some constraints are placed on allowable parameters.
Location URIs compatible with HELD dereferencing use the https: or http: scheme. HELD can be used by Location Recipients that are aware of the fact that the URI is a location URI. Mandatory support for an HTTP GET request ensures that the URI can be used even if it is not recognized as a location URI.
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 document uses key terminology from several sources:
This section describes how HELD can be used to dereference a location URI. This process can be applied when a Location Recipient is in possession of a location URI with a https: or http: URI scheme.
This document does not describe a specific authentication mechanism. This means that authorization policies are unable to specifically identify authorized Location Recipients.
A Location Recipient that wishes to dereference an https: or http: URI performs a HELD request on HTTP to the identified resource.
The Location Recipient establishes a connection to the LS, as described in [RFC2818].
TLS SHOULD be used. When TLS is used, the TLS ciphersuite TLS_NULL_WITH_NULL_NULL MUST NOT be used and the LS MUST be authenticated [RFC6125] to ensure that the correct server is contacted.
A Location Server MAY reject a request and request that a Location Recipient provide authentication credentials if authorization is dependent on the Location Recipient identity. Future specifications could define an authentication mechanism and a means by which Location Recipients are identified in authorization policies. This document provides definitions for neither item.
Use of HELD as a location dereference protocol is largely the same as its use as a location configuration protocol. Aside from the restrictions noted in this document, HELD semantics do not differ from those established in [RFC5985].
The HELD locationRequest is the only request permitted by this specification. Similarly, request parameters other than the following MUST NOT be accepted by the LS: responseTime, locationType (including the associated exact attribute).
Parameters and requests that do not have known behaviour for dereference requests MUST NOT be used. The LS MUST ignore any parameters that it does not understand unless it knows the parameters to be invalid. If parameters are understood by the LS and known to be 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 contains a locationType element that includes locationURI, this parameter is either ignored or rejected as appropriate, based on the associated exact attribute.
GET is the method assumed by generic HTTP user agents, therefore unless context identifies an https: URI as a HELD URI, such a user agent might simply send an HTTP GET. Rather than providing an HTTP 405 (Method Not Allowed) response indicating that POST is the only permitted method, a LIS MUST provide a HELD location response if it receives 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>
HTTP GET requests MUST be safe and idempotent [RFC2616] - that is, there are no side-effects of making the request and a repeated request has no more effect than a single request. Repeating a HELD request might result in a different location, but only as a result of a change in the state of the resource: the location of the Target.
Only the creation of a location URI as a result of receiving 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 cannot be produced in response to a request to a location URI.
A Location Recipient MAY infer from a response containing the HELD content type, application/held+xml, that a URI references a resource that supports HELD.
Content negotiation MAY be supported to produce a presence document in place of a HELD location response. Where the presence document would otherwise be included in a locationResponse document, it can be included in the body of the HTTP response directly by including an Accept header that includes application/pidf+xml.
This section discusses two extreme types of authorization models for dereferencing with HELD URIs, namely "Authorization by Possession" and "Authorization by Access Control". In the subsequent subsections we discuss the properties of these two models. Figure 2, from [RFC5808], shows the model applicable 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 +------------------------------+ | | +----------+
It is important to note that this document does not mandate a specific authorization model. It is possible to combine aspects of both models. However, no authentication framework is provided, which limits the policy options available when the "Authorization by Access Control" model is used.
For either authorization model, the overall process is similar. The following steps are followed, with minor alterations:
In this final step, the Location Server (LS) or LIS makes an authorization decision. How this decision is reached depends on the authorization model.
In this model, possession - or knowledge - of the location URI is used to control access to location information. A location URI is constructed such that it is hard to guess (see C8 of [RFC5808]) and the set of entities that it is disclosed to is limited. The only authentication required by the LS is evidence of possession of the URI. The LS is able to immediately authorize any request that indicates this URI.
Authorization by possession uses a very simple policy that does not typically require direct interaction with a Rule Maker; it is assumed that the Rule Maker is able to exert control over the distribution of the location URI. Therefore, the LIS can operate with limited policy input from a Rule Maker.
Limited disclosure is an important aspect of this authorization model. The location URI is a secret; therefore, ensuring that adversaries are not able to acquire this information is paramount. Encryption, such as might be offered by TLS [RFC5246] or S/MIME [RFC5751], protects the information from eavesdroppers.
Use of authorization by possession location URIs in a hop-by-hop protocol such as SIP [RFC3261] adds the possibility of on-path adversaries. Depending on the usage of the location URI for certain location based applications (e.g., emergency services, location based routing) specific treatment is important, as discussed in [RFC6442].
Using possession as a basis for authorization means that, once granted, authorization cannot be easily revoked. Cancellation of a location URI ensures that legitimate users are also affected; application of additional policy is theoretically possible, but could be technically infeasible. Expiration of location URIs limits the usable time for a location URI, requiring that an attacker continue to learn new location URIs to retain access to current location information.
A very simple policy is established at the time that a location URI is created. This policy specifies that the location URI expires after a certain time, which limits any inadvertent exposure of location information to adversaries. The expiration time of the location URI might be negotiated at the time of its creation, or it might be unilaterally set by the LIS.
Use of explicit access control provides a Rule Maker greater control over the behaviour of an LS. In contrast to authorization by possession, possession of this form of location URI does not imply authorization. Since an explicit policy is used to authorize access to location information, the location URI can be distributed to many potential Location Recipients.
Either before creation or dissemination of the location URI, the Rule Maker establishes an authorization policy with the LS. In reference to Figure 2, authorization policies might be established at creation (Step 1), and need to be established before the location URI is published (Step 2) to ensure that the policy grants access to the desired Location Recipients. 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 [I-D.ietf-geopriv-policy]. Additional constraints might be established by other means.
The LS enforces the authorization policy when a Location Recipient dereferences the URI. Explicit authorization policies allow a Rule Maker to specify how location information is provided to Location Recipients.
This document does not describe a specific authentication mechanism; therefore, the authorization by access control model is not an option. Instead, this document assumes the authorization by possession model.
Other policy mechanisms, such as those described in [I-D.ietf-geopriv-policy], can be applied for different Location Recipients if each recipient is given a different location URIs. Each location URI can be assigned different authorization policy. Selective disclosure used in this fashion can be used in place of identity-based authorization.
How policy is associated with a location URI is not defined by this document. [I-D.ietf-geopriv-policy-uri] describes one possible mechanism.
Use of identity-based authorization policy is not precluded. A Location Server MAY support an authentication mechanism that enables identity-based authorization policies to be used. Future specifications might define means of identifying recipients.
An example scenario envisioned by this document is shown in Figure 3. This diagram shows how a location dereference protocol fits with location configuration and conveyance. [RFC5808] contains more information on this scenario and others like it.
+-------------+
+------------+ | 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)------->| :
| . | | .
| `- + - - - - - - - - - - - - + -'
| | |
The example in Figure 4 shows the simplest form of dereferencing request using HELD to the location URI https://ls.example.com:49152/uri/w3g61nf5n66p0. The only way that this differs from the example in Section 10.1 of [RFC5985] is in the request URI and the source of the URI.
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 5 shows the response to the previous request listing both civic and geodetic location information of the Target's location. Again, this is identical to the response in Section 10.1 of [RFC5985] - unless policy specifies otherwise, the Location Recipient receives the same information as 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>
The following GET request is treated in an equivalent fashion. The LS treats this request as though it were a location request of the form shown in Figure 1. The same response might be provided.
GET /uri/w3g61nf5n66p0 HTTP/1.1
Host: ls.example.com:49152
Accept: application/held+xml
The following GET request uses content negotiation to indicate a preference for a presence document.
GET /uri/w3g61nf5n66p0 HTTP/1.1
Host: ls.example.com:49152
Accept: application/pidf+xml,application/held+xml;q=0.5
The response only differs from a normal HELD location response to a POST request in that the locationResponse element is omitted and the Content-Type header reflects the changed 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>
Privacy of location information is the most important security consideration for this document. Two measures in particular are used to protect privacy: TLS and authorization policies. TLS provides a means of ensuring confidentiality of location information through encryption and mutual authentication. An authorization policy allows a Rule Maker to explicitly control how location information is provided to Location Recipients.
The process by which a Rule Maker establishes an authorization policy is not covered by this document; several methods are possible, for instance: [I-D.ietf-geopriv-policy-uri], [RFC4825].
Use of TLS for the dereferencing of location URIs is strongly RECOMMENDED, as discussed in Section 3. Location Recipients MUST authenticate the host identity using the domain name included in the location URI, using the procedure described in Section 3.1 of [RFC2818]. Local policy determines what a Location Recipient does if authentication fails or cannot be attempted.
The authorization by possession model [pawn] further relies on TLS when transmitting the location URI to protect the secrecy of the URI. Possession of such a URI implies the same privacy considerations as possession of the PIDF-LO document that the URI references.
Location URIs MUST only be disclosed to authorized Location Recipients. The GEOPRIV architecture [RFC6280] identifies the Rule Maker role as being the entity that authorizes disclosure of this nature.
Protection of the location URI is necessary, since the policy attached to such a location URI permits any who have the URI to view it. This aspect of security is covered in more detail in the specification of location conveyance protocols, such as [RFC6442].
The LS MUST NOT provide any information about the Target except its location, unless policy from a Rule Maker allows otherwise. In particular, the requirements in [RFC5808] mandate this measure to protect the identity of the Target. To this end, an unlinked pseudonym MUST be provided in the entity attribute of the PIDF-LO document.
Further security considerations and requirements relating to the use of location URIs are described in [RFC5808].
This document makes no request of IANA.
[[IANA/RFC-EDITOR: Please remove this section before publication.]]
Thanks to Barbara Stark and Guy Caron for providing early comments. Thanks to Rohan Mahy for constructive comments on the scope and format of the document. Thanks to Ted Hardie for his strawman proposal that provided assistance with the security section of this document. Richard Barnes made helpful observations on the application of authorization policy. Bernard Aboba and Julian Reschke contributed constructive reviews.
The participants of the GEOPRIV interim meeting 2008 provided significant feedback on this document.
James Polk provided input on security in June 2008.
Martin Dawson was an original author of this document. Sadly, he passed away prior to its publication.
This section describes how use of HELD as a location dereference protocol complies with the GEOPRIV requirements described in [RFC3693].
Section 7.2 of [RFC3693] details the requirements of a "Using Protocol". These requirements are restated, followed by a statement of compliance:
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:
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:
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.
This section describes how HELD complies to the location reference requirements stipulated in [RFC5808]. Compliance of [RFC5985] to the Location Configuration Protocol is included.