< draft-ietf-geopriv-deref-protocol-04.txt   draft-ietf-geopriv-deref-protocol-05.txt >
GEOPRIV J. Winterbottom GEOPRIV J. Winterbottom
Internet-Draft Commscope Internet-Draft Commscope
Intended status: Standards Track H. Tschofenig Intended status: Standards Track H. Tschofenig
Expires: May 3, 2012 Nokia Siemens Networks Expires: November 9, 2012 Nokia Siemens Networks
H. Schulzrinne H. Schulzrinne
Columbia University Columbia University
M. Thomson M. Thomson
M. Dawson (Unaffiliated)
Commscope May 8, 2012
October 31, 2011
A Location Dereferencing Protocol Using HELD A Location Dereferencing Protocol Using HELD
draft-ietf-geopriv-deref-protocol-04 draft-ietf-geopriv-deref-protocol-05
Abstract Abstract
This document describes how to use the Hypertext Transfer Protocol This document describes how to use the Hypertext Transfer Protocol
(HTTP) over Transport Layer Security (TLS) as a dereferencing (HTTP) over Transport Layer Security (TLS) as a dereferencing
protocol to resolve a reference to a Presence Information Data Format protocol to resolve a reference to a Presence Information Data Format
Location Object (PIDF-LO). The document assumes that a Location Location Object (PIDF-LO). The document assumes that a Location
Recipient possesses a URI that can be used in conjunction with the Recipient possesses a URI that can be used in conjunction with the
HTTP-Enabled Location Delivery (HELD) protocol to request the HTTP-Enabled Location Delivery (HELD) protocol to request the
location of the Target. location of the Target.
skipping to change at page 1, line 42 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 3, 2012. This Internet-Draft will expire on November 9, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Authorization Models . . . . . . . . . . . . . . . . . . . . . 5 3. HELD Dereference Protocol . . . . . . . . . . . . . . . . . . 4
3.1. Authorization by Possession . . . . . . . . . . . . . . . 6 3.1. HELD Usage Profile . . . . . . . . . . . . . . . . . . . . 4
3.2. Authorization via Access Control . . . . . . . . . . . . . 7 3.2. HTTP GET Behavior . . . . . . . . . . . . . . . . . . . . 5
3.3. Access Control with HELD Deference . . . . . . . . . . . . 7 4. Authorization Models . . . . . . . . . . . . . . . . . . . . . 6
4. HELD Dereference Protocol . . . . . . . . . . . . . . . . . . 8 4.1. Authorization by Possession . . . . . . . . . . . . . . . 7
4.1. HELD Usage Profile . . . . . . . . . . . . . . . . . . . . 9 4.2. Authorization via Access Control . . . . . . . . . . . . . 8
4.2. HTTP GET Behavior . . . . . . . . . . . . . . . . . . . . 9 4.3. Access Control with HELD Deference . . . . . . . . . . . . 8
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
9.2. Informative references . . . . . . . . . . . . . . . . . . 15 9.2. Informative references . . . . . . . . . . . . . . . . . . 15
Appendix A. GEOPRIV Using Protocol Compliance . . . . . . . . . . 17 Appendix A. GEOPRIV Using Protocol Compliance . . . . . . . . . . 16
Appendix B. Compliance to Location Reference Requirements . . . . 20 Appendix B. Compliance to Location Reference Requirements . . . . 19
B.1. Requirements for a Location Configuration Protocol . . . . 20 B.1. Requirements for a Location Configuration Protocol . . . . 20
B.2. Requirements for a Location Dereference Protocol . . . . . 22 B.2. Requirements for a Location Dereference Protocol . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
Provision of location information by reference [RFC5808] involves the A location URI [RFC5808] identifies a resource that contains the
creation of a resource that is identified by a "location URI". A location of an entity. This document specifies how a holder of an
"location URI" is a URI [RFC3986] that identifies a resource "http:" or "https:" location URI uses that URI to retrieve location
containing the location of an entity. A location URI can be acquired information.
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 URI does not
intrinsically include location information, instead the URI is
"dereferenced" by a Location Recipient to acquire location
information. This document specifies how a holder of an "http:" or
"https:" location URI uses that URI to retrieve location information.
HELD defines a use of HTTP that enables location configuration - the
process where a Device acquires location information about itself. A
part of location configuration is the provision of a location URI.
However, HELD does not describe how such a URI is used; this document
provides that definition.
This document defines how HELD is used by a Location Recipient to
dereference a location URI and acquire location information. The
result of this process is a location object in the form of a Presence
Information Data Format - Location Object (PIDF-LO) document
[RFC4119]. A constrained set of HELD features are defined such that
it is suitable for use as a location dereference protocol [RFC5808].
Use as a location dereference protocol requires use of the Transport
Layer Security (TLS) binding for HTTP [RFC2818] in order to provide
confidentiality, authentication and protection from modification.
Use of HELD as a dereferencing protocol has the advantage that the
Location Recipient can indicate the type of location information it
would like to receive. This functionality is already available with
the HELD base specification, described in [RFC5985]. Furthermore,
the HELD response from the LIS towards the Location Recipient not
only provides the PIDF-LO but also encapsulates supplementary
information, such as error messages, back to the Location Recipient.
Location URIs created for use 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.
An example scenario envisioned by this document is shown in Figure 1. A location URI can be acquired using a location configuration
This diagram shows how a location dereference protocol fits with protocol, such as HTTP-Enabled Location Delivery (HELD) [RFC5985] or
location configuration and conveyance. [RFC5808] contains more the Dynamic Host Configuration Protocol (DHCP) location URI option
information on this scenario and others like it. [I-D.ietf-geopriv-dhcp-lbyr-uri-option].
+-------------+ A Location Recipient that dereferences a location URI acquires
+------------+ | Location | +-----------+ location information in the of a Presence Information Data Format -
| End Device | | Information | | Location | Location Object (PIDF-LO) document [RFC4119]. HELD parameters allow
| (Target) | | Server | | Recipient | for specifying the type of location information, though some
+-----+------+ +------+------+ +-----+-----+ constraints are placed on allowable parameters.
| | |
.- + - - - - - - - - - - - - + -. |
: | locationRequest | : |
. |----(for location URI)-->| . |
: | | : Location |
. | locationResponse | . Configuration |
: |<-----(location URI)-----| : |
. | | . |
`- + - - - - - - - - - - - - + -' |
| | |
| Location Conveyance |
|~ ~ ~ ~ ~ ~ ~ ~ ~ ~(location URI)~ ~ ~ ~ ~ ~ ~ ~ ~>|
| | |
| .- + - - - - - - - - - - - - + -.
| : | locationRequest | :
| . |<------(for civic)-------| .
| Dereferencing : | | :
| . | locationResponse | .
| : |--------(PIDF-LO)------->| :
| . | | .
| `- + - - - - - - - - - - - - + -'
| | |
Figure 1: Example of Dereference Protocol Exchange 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.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
This document uses key terminology from several sources: This document uses key terminology from several sources:
o terms for the GEOPRIV reference model defined in o terms for the GEOPRIV reference model defined in [RFC6280];
[I-D.ietf-geopriv-arch];
o the term Location Information Server (LIS), from [RFC5687], is a o the term Location Information Server (LIS), from [RFC5687], is a
node in the access network that provides location information to node in the access network that provides location information to
an end point; a LIS provides location URIs; an end point; a LIS provides location URIs;
o the term Location Server (LS), from [I-D.ietf-geopriv-arch], is o the term Location Server (LS), from [RFC6280], is used to identify
used to identify the role that responds to a location dereference the role that responds to a location dereference request; this
request; this might be the same entity as the LIS, but the model might be the same entity as the LIS, but the model in [RFC5808]
in [RFC5808] allows for the existence of separate - but related - allows for the existence of separate - but related - entities; and
entities; and
o the term location URI is coined in [RFC5808]. o the term location URI is coined in [RFC5808].
3. Authorization Models 3. HELD Dereference Protocol
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.
Note: In many cases, an "http:" URI does not provide sufficient
security for location URIs. The absence of the security
mechanisms provided by TLS means that the Rule Maker has no
control over who receives location information and the Location
Recipient has no assurance that the information is correct.
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.
3.1. HELD Usage Profile
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.
3.2. HTTP GET Behavior
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>
Figure 1: GET Request Equivalent Location Request
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".
4. Authorization Models
This section discusses two extreme types of authorization models for This section discusses two extreme types of authorization models for
dereferencing with HELD URIs, namely "Authorization by Possession" dereferencing with HELD URIs, namely "Authorization by Possession"
and "Authorization by Access Control". In the subsequent subsections and "Authorization by Access Control". In the subsequent subsections
we discuss the properties of these two models. Figure 2, from we discuss the properties of these two models. Figure 2, from
[RFC5808], shows the model applicable to location configuration, [RFC5808], shows the model applicable to location configuration,
conveyance and dereference. conveyance and dereference.
+---------+--------+ Location +-----------+ +---------+--------+ Location +-----------+
| | | Dereference | Location | | | | Dereference | Location |
skipping to change at page 6, line 10 skipping to change at page 7, line 7
Control" model is used. Control" model is used.
For either authorization model, the overall process is similar. The For either authorization model, the overall process is similar. The
following steps are followed, with minor alterations: following steps are followed, with minor alterations:
1. The Target acquires a location URI from the LIS. This uses a 1. The Target acquires a location URI from the LIS. This uses a
location configuration protocol (LCP), such as HELD or DHCP. location configuration protocol (LCP), such as HELD or DHCP.
2. The Target then conveys the location URI to a third party, the 2. The Target then conveys the location URI to a third party, the
Location Recipient (for example using SIP as described in Location Recipient (for example using SIP as described in
[I-D.ietf-sipcore-location-conveyance]). This step is shown in [RFC6442]). This step is shown in (2) of Figure 2.
(2) of Figure 2.
3. The Location Recipient then needs to dereference the location URI 3. The Location Recipient then needs to dereference the location URI
in order to obtain the Location Object (3). An "https:" or in order to obtain the Location Object (3). An "https:" or
"http:" URI is dereferenced as described in this document; other "http:" URI is dereferenced as described in this document; other
URI schemes might be dereferenced using another method. URI schemes might be dereferenced using another method.
In this final step, the Location Server (LS) or LIS makes an In this final step, the Location Server (LS) or LIS makes an
authorization decision. How this decision is reached depends on the authorization decision. How this decision is reached depends on the
authorization model. authorization model.
3.1. Authorization by Possession 4.1. Authorization by Possession
In this model, possession - or knowledge - of the location URI is In this model, possession - or knowledge - of the location URI is
used to control access to location information. A location URI is used to control access to location information. A location URI is
constructed such that it is hard to guess (see C9 of [RFC5808]) and 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 the set of entities that it is disclosed to is limited. The only
authentication required by the LS is evidence of possession of the authentication required by the LS is evidence of possession of the
URI. The LS is able to immediately authorize any request that URI. The LS is able to immediately authorize any request that
indicates this URI. indicates this URI.
Authorization by possession uses a very simple policy that does not Authorization by possession uses a very simple policy that does not
typically require direct interaction with a Rule Maker; it is assumed typically require direct interaction with a Rule Maker; it is assumed
that the Rule Maker is able to exert control over the distribution of that the Rule Maker is able to exert control over the distribution of
the location URI. Therefore, the LIS can operate with limited policy the location URI. Therefore, the LIS can operate with limited policy
input from a Rule Maker. input from a Rule Maker.
skipping to change at page 6, line 48 skipping to change at page 7, line 44
Limited disclosure is an important aspect of this authorization Limited disclosure is an important aspect of this authorization
model. The location URI is a secret; therefore, ensuring that model. The location URI is a secret; therefore, ensuring that
adversaries are not able to acquire this information is paramount. adversaries are not able to acquire this information is paramount.
Encryption, such as might be offered by TLS [RFC5246] or S/MIME Encryption, such as might be offered by TLS [RFC5246] or S/MIME
[RFC5751], protects the information from eavesdroppers. [RFC5751], protects the information from eavesdroppers.
Use of authorization by possession location URIs in a hop-by-hop Use of authorization by possession location URIs in a hop-by-hop
protocol such as SIP [RFC3261] adds the possibility of on-path protocol such as SIP [RFC3261] adds the possibility of on-path
adversaries. Depending on the usage of the location URI for certain adversaries. Depending on the usage of the location URI for certain
location based applications (e.g., emergency services, location based location based applications (e.g., emergency services, location based
routing) specific treatment is important, as discussed in routing) specific treatment is important, as discussed in [RFC6442].
[I-D.ietf-sipcore-location-conveyance].
Using possession as a basis for authorization means that, once Using possession as a basis for authorization means that, once
granted, authorization cannot be easily revoked. Cancellation of a granted, authorization cannot be easily revoked. Cancellation of a
location URI ensures that legitimate users are also affected; location URI ensures that legitimate users are also affected;
application of additional policy is theoretically possible, but could application of additional policy is theoretically possible, but could
be technically infeasible. Therefore, other measures are provided to be technically infeasible. Expiration of location URIs limits the
prevent an adversary from gaining access to location information usable time for a location URI, requiring that an attacker continue
indefinitely. to learn new location URIs to retain access to current location
information.
A very simple policy is established at the time that the location URI A very simple policy is established at the time that a location URI
is created. This policy specifies that the location URI expires is created. This policy specifies that the location URI expires
after a certain time, which limits any inadvertent exposure of after a certain time, which limits any inadvertent exposure of
location information to adversaries. The expiration time of the location information to adversaries. The expiration time of the
location URI might be negotiated at the time of its creation, or it location URI might be negotiated at the time of its creation, or it
might be unilaterally set by the LIS. might be unilaterally set by the LIS.
3.2. Authorization via Access Control 4.2. Authorization via Access Control
Use of explicit access control provides a Rule Maker greater control Use of explicit access control provides a Rule Maker greater control
over the behaviour of an LS. In contrast to authorization by over the behaviour of an LS. In contrast to authorization by
possession, possession of a this form of location URI does not imply possession, possession of this form of location URI does not imply
authorization. Since an explicit policy is used to authorize access authorization. Since an explicit policy is used to authorize access
to location information, the location URI can be distributed to many to location information, the location URI can be distributed to many
potential Location Recipients. potential Location Recipients.
Either before creation or dissemination of the location URI, the Rule Either before creation or dissemination of the location URI, the Rule
Maker establishes an authorization policy with the LS. In reference Maker establishes an authorization policy with the LS. In reference
to Figure 2, authorization policies might be established at creation to Figure 2, authorization policies might be established at creation
(Step 1), and need to be established before the location URI is (Step 1), and need to be established before the location URI is
published (Step 2) to ensure that the policy grants access to the published (Step 2) to ensure that the policy grants access to the
desired Location Recipients. Depending on the mechanism used, it desired Location Recipients. Depending on the mechanism used, it
skipping to change at page 7, line 44 skipping to change at page 8, line 40
A possible format for these authorization policies is available with A possible format for these authorization policies is available with
GEOPRIV Common Policy [RFC4745] and Geolocation Policy GEOPRIV Common Policy [RFC4745] and Geolocation Policy
[I-D.ietf-geopriv-policy]. Additional constraints might be [I-D.ietf-geopriv-policy]. Additional constraints might be
established by other means. established by other means.
The LS enforces the authorization policy when a Location Recipient The LS enforces the authorization policy when a Location Recipient
dereferences the URI. Explicit authorization policies allow a Rule dereferences the URI. Explicit authorization policies allow a Rule
Maker to specify how location information is provided to Location Maker to specify how location information is provided to Location
Recipients. Recipients.
3.3. Access Control with HELD Deference 4.3. Access Control with HELD Deference
This document does not describe a specific authentication mechanism.
This means that authorization policies are unable to specifically
identify authorized Location Recipients.
In order to control access to location information based on the This document does not describe a specific authentication mechanism;
identity of the Location Recipient, use of authorization by therefore, the authorization by access control model is not an
possession is employed. By controlling which Location Recipients option. Instead, this document assumes the authorization by
receive location URIs, access to location information is controlled. possession model.
Other policy mechanisms, such as those described in Other policy mechanisms, such as those described in
[I-D.ietf-geopriv-policy], can be applied to different Location [I-D.ietf-geopriv-policy], can be applied for different Location
Recipients if multiple location URIs are used. Location Recipients Recipients if each recipient is given a different location URIs.
that receive a particular location URI are granted location Each location URI can be assigned different authorization policy.
information based on the authorization policy associated with that Selective disclosure used in this fashion can be used in place of
URI. identity-based authorization.
Providing that knowledge of a location URI is limited, policy
appropriate to the Location Recipients that receive the location URI
can be assigned. 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 How policy is associated with a location URI is not defined by this
document. [I-D.ietf-geopriv-policy-uri] describes one possible document. [I-D.ietf-geopriv-policy-uri] describes one possible
mechanism. mechanism.
Authentication of Location Recipients and use of identity-based Use of identity-based authorization policy is not precluded. A
authorization policy is not precluded. A Location Server MAY support Location Server MAY support an authentication mechanism that enables
an authentication mechanism that enables identity-based authorization identity-based authorization policies to be used. Future
policies to be used. Future specifications might define means of specifications might define means of identifying recipients.
identifying recipients.
Note: Policy frameworks like [RFC4745] degrade in a way that Note: Policy frameworks like [RFC4745] degrade in a way that
protects privacy if features are not supported. If a policy protects privacy if features are not supported. If a policy
specifies a rule that is conditional on the identity of a specifies a rule that is conditional on the identity of a
recipient and the protocol does not (or cannot) provide an recipient and the protocol does not (or cannot) provide an
assertion identity of the recipient, the rule has no effect and assertion identity of the recipient, the rule has no effect and
the policy defaults to providing less information. the policy defaults to providing less information.
4. HELD Dereference Protocol 5. Examples
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.
A Location Recipient that wishes to dereference an "https:" or
"http:" URI performs a HELD request on HTTP to the identified
resource.
Note: In many cases, an "http:" URI does not provide sufficient
security for location URIs. The absence of the security
mechanisms provided by TLS means that the Rule Maker has no
control over who receives location information and the Location
Recipient has no assurance that the information is correct.
The Location Recipient establishes a connection to the LS, as
described in [RFC2818]. The TLS ciphersuite TLS_NULL_WITH_NULL_NULL
MUST NOT be used. The LS MUST be authenticated 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.
4.1. HELD Usage Profile
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.
4.2. HTTP GET Behavior
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>
Figure 3: GET Request Equivalent Location Request
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 An example scenario envisioned by this document is shown in Figure 3.
content type, "application/held+xml", that a URI references a This diagram shows how a location dereference protocol fits with
resource that supports HELD. location configuration and conveyance. [RFC5808] contains more
information on this scenario and others like it.
Content negotiation MAY be supported to produce a presence document +-------------+
in place of a HELD location response. Where the presence document +------------+ | Location | +-----------+
would otherwise be included in a "locationResponse" document, it can | End Device | | Information | | Location |
be included in the body of the HTTP response directly by including an | (Target) | | Server | | Recipient |
"Accept" header that includes "application/pidf+xml". +-----+------+ +------+------+ +-----+-----+
| | |
.- + - - - - - - - - - - - - + -. |
: | locationRequest | : |
. |----(for location URI)-->| . |
: | | : Location |
. | locationResponse | . Configuration |
: |<-----(location URI)-----| : |
. | | . |
`- + - - - - - - - - - - - - + -' |
| | |
| Location Conveyance |
|~ ~ ~ ~ ~ ~ ~ ~ ~ ~(location URI)~ ~ ~ ~ ~ ~ ~ ~ ~>|
| | |
| .- + - - - - - - - - - - - - + -.
| : | locationRequest | :
| . |<------(for civic)-------| .
| Dereferencing : | | :
| . | locationResponse | .
| : |--------(PIDF-LO)------->| :
| . | | .
| `- + - - - - - - - - - - - - + -'
| | |
5. Examples Figure 3: Example of Dereference Protocol Exchange
The example in Figure 4 shows the simplest form of dereferencing The example in Figure 4 shows the simplest form of dereferencing
request using HELD to the location URI request using HELD to the location URI
"https://ls.example.com:49152/uri/w3g61nf5n66p0". The only way that "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 this differs from the example in Section 10.1 of [RFC5985] is in the
request URI and the source of the URI. request URI and the source of the URI.
POST /uri/w3g61nf5n66p0 HTTP/1.1 POST /uri/w3g61nf5n66p0 HTTP/1.1
Host: ls.example.com:49152 Host: ls.example.com:49152
Content-Type: application/held+xml Content-Type: application/held+xml
skipping to change at page 12, line 45 skipping to change at page 12, line 7
</status> </status>
<timestamp>2006-01-10T03:42:28+00:00</timestamp> <timestamp>2006-01-10T03:42:28+00:00</timestamp>
</tuple> </tuple>
</presence> </presence>
</locationResponse> </locationResponse>
Figure 5: Response with Location Information Figure 5: Response with Location Information
The following GET request is treated in an equivalent fashion. The The following GET request is treated in an equivalent fashion. The
LS treats this request as though it were a location request of the LS treats this request as though it were a location request of the
form shown in Figure 3. The same response might be provided. form shown in Figure 1. The same response might be provided.
GET /uri/w3g61nf5n66p0 HTTP/1.1 GET /uri/w3g61nf5n66p0 HTTP/1.1
Host: ls.example.com:49152 Host: ls.example.com:49152
Accept: application/held+xml Accept: application/held+xml
Figure 6: GET Request Figure 6: GET Request
The following GET request uses content negotiation to indicate a The following GET request uses content negotiation to indicate a
preference for a presence document. preference for a presence document.
skipping to change at page 13, line 49 skipping to change at page 13, line 13
means of ensuring confidentiality of location information through means of ensuring confidentiality of location information through
encryption and mutual authentication. An authorization policy allows encryption and mutual authentication. An authorization policy allows
a Rule Maker to explicitly control how location information is a Rule Maker to explicitly control how location information is
provided to Location Recipients. provided to Location Recipients.
The process by which a Rule Maker establishes an authorization policy The process by which a Rule Maker establishes an authorization policy
is not covered by this document; several methods are possible, for is not covered by this document; several methods are possible, for
instance: [I-D.ietf-geopriv-policy-uri], [RFC4825]. instance: [I-D.ietf-geopriv-policy-uri], [RFC4825].
Use of TLS for the dereferencing of location URIs is strongly Use of TLS for the dereferencing of location URIs is strongly
RECOMMENDED, as discussed in Section 4. Location Recipients MUST RECOMMENDED, as discussed in Section 3. Location Recipients MUST
authenticate the host identity using the domain name included in the authenticate the host identity using the domain name included in the
location URI, using the procedure described in Section 3.1 of location URI, using the procedure described in Section 3.1 of
[RFC2818]. Local policy determines what a Location Recipient does if [RFC2818]. Local policy determines what a Location Recipient does if
authentication fails or cannot be attempted. authentication fails or cannot be attempted.
The authorization by possession model (Section 3.1) further relies on The authorization by possession model (Section 4.1) further relies on
TLS when transmitting the location URI to protect the secrecy of the TLS when transmitting the location URI to protect the secrecy of the
URI. Possession of such a URI implies the same privacy URI. Possession of such a URI implies the same privacy
considerations as possession of the PIDF-LO document that the URI considerations as possession of the PIDF-LO document that the URI
references. references.
Location URIs MUST only be disclosed to authorized Location Location URIs MUST only be disclosed to authorized Location
Recipients. The GEOPRIV architecture [I-D.ietf-geopriv-arch] Recipients. The GEOPRIV architecture [RFC6280] identifies the Rule
identifies the Rule Maker role as being the entity that authorizes Maker role as being the entity that authorizes disclosure of this
disclosure of this nature. nature.
Protection of the location URI is necessary, since the policy Protection of the location URI is necessary, since the policy
attached to such a location URI permits any who have the URI to view 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 it. This aspect of security is covered in more detail in the
specification of location conveyance protocols, such as specification of location conveyance protocols, such as [RFC6442].
[I-D.ietf-sipcore-location-conveyance].
The LS MUST NOT provide any information about the Target except its The LS MUST NOT provide any information about the Target except its
location, unless policy from a Rule Maker allows otherwise. In location, unless policy from a Rule Maker allows otherwise. In
particular, the requirements in [RFC5808] mandate this measure to particular, the requirements in [RFC5808] mandate this measure to
protect the identity of the Target. To this end, an unlinked protect the identity of the Target. To this end, an unlinked
pseudonym MUST be provided in the "entity" attribute of the PIDF-LO pseudonym MUST be provided in the "entity" attribute of the PIDF-LO
document. document.
Further security considerations and requirements relating to the use Further security considerations and requirements relating to the use
of location URIs are described in [RFC5808]. of location URIs are described in [RFC5808].
skipping to change at page 15, line 10 skipping to change at page 14, line 20
proposal that provided assistance with the security section of this proposal that provided assistance with the security section of this
document. Richard Barnes made helpful observations on the document. Richard Barnes made helpful observations on the
application of authorization policy. Bernard Aboba and Julian application of authorization policy. Bernard Aboba and Julian
Reschke contributed constructive reviews. Reschke contributed constructive reviews.
The participants of the GEOPRIV interim meeting 2008 provided The participants of the GEOPRIV interim meeting 2008 provided
significant feedback on this document. significant feedback on this document.
James Polk provided input on security in June 2008. 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.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
skipping to change at page 15, line 38 skipping to change at page 14, line 51
Format", RFC 4119, December 2005. Format", RFC 4119, December 2005.
[RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
Presence Information Data Format Location Object (PIDF-LO) Presence Information Data Format Location Object (PIDF-LO)
Usage Clarification, Considerations, and Recommendations", Usage Clarification, Considerations, and Recommendations",
RFC 5491, March 2009. RFC 5491, March 2009.
[RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)",
RFC 5985, September 2010. RFC 5985, September 2010.
9.2. Informative references [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.
[I-D.ietf-geopriv-arch] 9.2. Informative references
Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
Tschofenig, H., and H. Schulzrinne, "An Architecture for
Location and Location Privacy in Internet Applications",
draft-ietf-geopriv-arch-03 (work in progress),
October 2010.
[I-D.ietf-geopriv-dhcp-lbyr-uri-option] [I-D.ietf-geopriv-dhcp-lbyr-uri-option]
Polk, J., "Dynamic Host Configuration Protocol (DHCP) IPv4 Polk, J., "Dynamic Host Configuration Protocol (DHCP) IPv4
and IPv6 Option for a Location Uniform Resource Identifier and IPv6 Option for a Location Uniform Resource Identifier
(URI)", draft-ietf-geopriv-dhcp-lbyr-uri-option-12 (work (URI)", draft-ietf-geopriv-dhcp-lbyr-uri-option-14 (work
in progress), October 2011. in progress), March 2012.
[I-D.ietf-geopriv-policy] [I-D.ietf-geopriv-policy]
Schulzrinne, H., Tschofenig, H., Cuellar, J., Polk, J., Cuellar, J., Tschofenig, H., Schulzrinne, H., Polk, J.,
Morris, J., and M. Thomson, "Geolocation Policy: A Morris, J., and M. Thomson, "Geolocation Policy: A
Document Format for Expressing Privacy Preferences for Document Format for Expressing Privacy Preferences for
Location Information", draft-ietf-geopriv-policy-25 (work Location Information", draft-ietf-geopriv-policy-25 (work
in progress), October 2011. in progress), October 2011.
[I-D.ietf-geopriv-policy-uri] [I-D.ietf-geopriv-policy-uri]
Barnes, R., Thomson, M., Winterbottom, J., and H. Thomson, M., Winterbottom, J., Barnes, R., and H.
Tschofenig, "Location Configuration Extensions for Policy Tschofenig, "Location Configuration Extensions for Policy
Management", draft-ietf-geopriv-policy-uri-02 (work in Management", draft-ietf-geopriv-policy-uri-04 (work in
progress), October 2011. progress), November 2011.
[I-D.ietf-sipcore-location-conveyance]
Polk, J., Rosen, B., and J. Peterson, "Location Conveyance
for the Session Initiation Protocol",
draft-ietf-sipcore-location-conveyance-09 (work in
progress), September 2011.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
J. Polk, "Geopriv Requirements", RFC 3693, February 2004. J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J.,
skipping to change at page 17, line 9 skipping to change at page 16, line 16
Mail Extensions (S/MIME) Version 3.2 Message Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, January 2010. Specification", RFC 5751, January 2010.
[RFC5808] Marshall, R., "Requirements for a Location-by-Reference [RFC5808] Marshall, R., "Requirements for a Location-by-Reference
Mechanism", RFC 5808, May 2010. Mechanism", RFC 5808, May 2010.
[RFC6155] Winterbottom, J., Thomson, M., Tschofenig, H., and R. [RFC6155] Winterbottom, J., Thomson, M., Tschofenig, H., and R.
Barnes, "Use of Device Identity in HTTP-Enabled Location Barnes, "Use of Device Identity in HTTP-Enabled Location
Delivery (HELD)", RFC 6155, March 2011. 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 Appendix A. GEOPRIV Using Protocol Compliance
This section describes how use of HELD as a location dereference This section describes how use of HELD as a location dereference
protocol complies with the GEOPRIV requirements described in protocol complies with the GEOPRIV requirements described in
[RFC3693]. [RFC3693].
Req. 1. (Location Object generalities): Req. 1. (Location Object generalities):
This section relates to the PIDF-LO [RFC4119] document, This section relates to the PIDF-LO [RFC4119] document,
which is used by HELD. These requirements are addressed by which is used by HELD. These requirements are addressed by
skipping to change at page 18, line 15 skipping to change at page 17, line 29
Req. 5. "The using protocol will typically facilitate that the keys Req. 5. "The using protocol will typically facilitate that the keys
associated with the credentials are transported to the associated with the credentials are transported to the
respective parties, that is, key establishment is the respective parties, that is, key establishment is the
responsibility of the using protocol." responsibility of the using protocol."
Compliant: This document specifies that authentication of Compliant: This document specifies that authentication of
the LS uses the established public key infrastructure used the LS uses the established public key infrastructure used
by HTTP over TLS [RFC2818]. Authentication of Location by HTTP over TLS [RFC2818]. Authentication of Location
Recipients is either based on distribution of a secret (the Recipients is either based on distribution of a secret (the
location URI) using a conveyance protocol (for instance, location URI) using a conveyance protocol (for instance,
[I-D.ietf-sipcore-location-conveyance]), allowances are made [RFC6442]), allowances are made for later work to define
for later work to define alternative methods. alternative methods.
Req. 6. "(Single Message Transfer) In particular, for tracking of Req. 6. "(Single Message Transfer) In particular, for tracking of
small target devices, the design should allow a single small target devices, the design should allow a single
message/packet transmission of location as a complete message/packet transmission of location as a complete
transaction." transaction."
Not Compliant: The XML encoding specified in [RFC4119] is Not Compliant: The XML encoding specified in [RFC4119] is
not suited to single packet transfers. Use of compressed not suited to single packet transfers. Use of compressed
content encoding [RFC2616] might allow this condition to be content encoding [RFC2616] might allow this condition to be
met. met.
skipping to change at page 23, line 12 skipping to change at page 22, line 29
URI being invalidated. Authorization policies might include URI being invalidated. Authorization policies might include
rules that modify this behavior. rules that modify this behavior.
D5. "The location dereference protocol MUST support confidentiality D5. "The location dereference protocol MUST support confidentiality
protection of messages sent between the Location Recipient and protection of messages sent between the Location Recipient and
the location server." the location server."
Compliant: This document strongly recommends the use of TLS for Compliant: This document strongly recommends the use of TLS for
confidentiality and HELD mandates its implementation. Unsecured confidentiality and HELD mandates its implementation. Unsecured
HTTP is permitted: the associated risks are described in HTTP is permitted: the associated risks are described in
Section 4. Section 3.
Authors' Addresses Authors' Addresses
James Winterbottom James Winterbottom
Commscope Commscope
Andrew Building (39) Andrew Building (39)
Wollongong University Campus Wollongong University Campus
Northfields Avenue Northfields Avenue
Wollongong, NSW 2522 Wollongong, NSW 2522
AU AU
skipping to change at page 23, line 26 skipping to change at page 23, line 4
James Winterbottom James Winterbottom
Commscope Commscope
Andrew Building (39) Andrew Building (39)
Wollongong University Campus Wollongong University Campus
Northfields Avenue Northfields Avenue
Wollongong, NSW 2522 Wollongong, NSW 2522
AU AU
Phone: +61 242 212938 Phone: +61 242 212938
Email: james.winterbottom@commscope.com Email: james.winterbottom@commscope.com
Hannes Tschofenig Hannes Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
Linnoitustie 6 Linnoitustie 6
Espoo 02600 Espoo 02600
Finland Finland
Phone: +358 (50) 4871445 Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@gmx.net Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at URI: http://www.tschofenig.priv.at
Henning Schulzrinne Henning Schulzrinne
Columbia University Columbia University
Department of Computer Science Department of Computer Science
450 Computer Science Building, New York, NY 10027 450 Computer Science Building, New York, NY 10027
US US
Phone: +1 212 939 7004 Phone: +1 212 939 7004
Email: hgs@cs.columbia.edu Email: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu URI: http://www.cs.columbia.edu
Martin Thomson
Commscope
Andrew Building (39)
Wollongong University Campus
Northfields Avenue
Wollongong, NSW 2522
AU
Phone: +61 2 4221 2915
Email: martin.thomson@commscope.com
Martin Dawson Martin Thomson
Commscope (Unaffiliated)
Andrew Building (39) .
Wollongong University Campus Mountain View, CA 94043
Northfields Avenue US
Wollongong, NSW 2522
AU
Phone: +61 2 4221 2992 Phone: +1 650-353-1925
Email: martin.dawson@commscope.com Email: martin.thomson@gmail.com
 End of changes. 51 change blocks. 
282 lines changed or deleted 245 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/