draft-ietf-geopriv-deref-protocol-07.txt   rfc6753.txt 
GEOPRIV J. Winterbottom Internet Engineering Task Force (IETF) J. Winterbottom
Internet-Draft Commscope Request for Comments: 6753 Commscope
Intended status: Standards Track H. Tschofenig Category: Standards Track H. Tschofenig
Expires: January 15, 2013 Nokia Siemens Networks ISSN: 2070-1721 Nokia Siemens Networks
H. Schulzrinne H. Schulzrinne
Columbia University Columbia University
M. Thomson M. Thomson
Microsoft Microsoft
July 14, 2012 October 2012
A Location Dereferencing Protocol Using HELD A Location Dereference Protocol Using
draft-ietf-geopriv-deref-protocol-07 HTTP-Enabled Location Delivery (HELD)
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 dereference protocol
protocol to resolve a reference to a Presence Information Data Format to resolve a reference to a Presence Information Data Format Location
Location Object (PIDF-LO). The document assumes that a Location Object (PIDF-LO). This document assumes that a Location Recipient
Recipient possesses a URI that can be used in conjunction with the possesses a URI that can be used in conjunction with the HTTP-Enabled
HTTP-Enabled Location Delivery (HELD) protocol to request the Location Delivery (HELD) protocol to request the location of the
location of the Target. Target.
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on January 15, 2013. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6753.
Copyright Notice Copyright Notice
Copyright (c) 2012 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
skipping to change at page 2, line 22 skipping to change at page 2, line 30
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. HELD Dereference Protocol . . . . . . . . . . . . . . . . . . 4 3. HELD Dereference Protocol . . . . . . . . . . . . . . . . . . 4
3.1. HELD Usage Profile . . . . . . . . . . . . . . . . . . . . 4 3.1. HELD Usage Profile . . . . . . . . . . . . . . . . . . . . 4
3.2. HTTP GET Behavior . . . . . . . . . . . . . . . . . . . . 5 3.2. HTTP GET Behavior . . . . . . . . . . . . . . . . . . . . 5
4. Authorization Models . . . . . . . . . . . . . . . . . . . . . 6 4. Authorization Models . . . . . . . . . . . . . . . . . . . . . 6
4.1. Authorization by Possession . . . . . . . . . . . . . . . 7 4.1. Authorization by Possession . . . . . . . . . . . . . . . 7
4.2. Authorization via Access Control . . . . . . . . . . . . . 8 4.2. Authorization via Access Control . . . . . . . . . . . . . 8
4.3. Access Control with HELD Deference . . . . . . . . . . . . 8 4.3. Access Control with HELD Dereference . . . . . . . . . . . 9
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . . 15
9.2. Informative references . . . . . . . . . . . . . . . . . . 15 Appendix A. GEOPRIV Using Protocol Compliance . . . . . . . . . . 18
Appendix A. GEOPRIV Using Protocol Compliance . . . . . . . . . . 16 Appendix B. Compliance to Location Reference Requirements . . . . 21
Appendix B. Compliance to Location Reference Requirements . . . . 19 B.1. Requirements for a Location Configuration Protocol . . . . 21
B.1. Requirements for a Location Configuration Protocol . . . . 20 B.2. Requirements for a Location Dereference Protocol . . . . . 23
B.2. Requirements for a Location Dereference Protocol . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
A location URI [RFC5808] identifies a resource that contains the A location URI [RFC5808] identifies a resource that contains the
location of an entity. This document specifies how a holder of an location of an entity. This document specifies how a holder of an
"http:" or "https:" location URI uses that URI to retrieve location "http:" or "https:" location URI uses that URI to retrieve location
information. information using a subset of HELD functionality or an HTTP GET
request.
A location URI can be acquired using a location configuration A location URI can be acquired using a location configuration
protocol, such as HTTP-Enabled Location Delivery (HELD) [RFC5985] or protocol, such as HTTP-Enabled Location Delivery (HELD) [RFC5985] or
the Dynamic Host Configuration Protocol (DHCP) location URI option the Dynamic Host Configuration Protocol (DHCP) location URI option
[I-D.ietf-geopriv-dhcp-lbyr-uri-option]. [DHCP-URI-OPT].
A Location Recipient that dereferences a location URI acquires A Location Recipient that dereferences a location URI acquires
location information in the of a Presence Information Data Format - location information in the form of a Presence Information Data
Location Object (PIDF-LO) document [RFC4119]. HELD parameters allow Format - Location Object (PIDF-LO) document [RFC4119]. HELD
for specifying the type of location information, though some parameters allow for specifying the type of location information,
constraints are placed on allowable parameters. though some constraints are placed on allowable parameters.
Location URIs compatible with HELD dereferencing use the "https:" or Location URIs compatible with HELD dereferencing use the "https:" or
"http:" scheme. HELD can be used by Location Recipients that are "http:" scheme. HELD can be used by Location Recipients that are
aware of the fact that the URI is a location URI. Mandatory support 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 for an HTTP GET request ensures that the URI can be used even if it
is not recognized as a location URI. 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 [RFC6280]; o The terms for the GEOPRIV reference model defined are in
[RFC6280].
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 endpoint. A LIS provides location URIs.
o the term Location Server (LS), from [RFC6280], is used to identify o The term "Location Server (LS)", from [RFC6280], is used to
the role that responds to a location dereference request; this identify the role that responds to a location dereference request.
might be the same entity as the LIS, but the model in [RFC5808] A Location Server might be the same entity as the LIS, but the
allows for the existence of separate - but related - entities; and model in [RFC5808] allows for the existence of separate -- but
related -- entities.
o the term location URI is coined in [RFC5808]. o The term "location URI" is coined in [RFC5808].
3. HELD Dereference Protocol 3. HELD Dereference Protocol
This section describes how HELD can be used to dereference a location This section describes how HELD can be used to dereference a location
URI. This process can be applied when a Location Recipient is in URI. This process can be applied when a Location Recipient is in
possession of a location URI with a "https:" or "http:" URI scheme. possession of a location URI with an "https:" or "http:" URI scheme.
This document does not describe a specific authentication mechanism. This document does not describe a specific authentication mechanism.
This means that authorization policies are unable to specifically This means that authorization policies are unable to specifically
identify authorized Location Recipients. identify authorized Location Recipients.
A Location Recipient that wishes to dereference an "https:" or A Location Recipient that wishes to dereference an "https:" or
"http:" URI performs a HELD request on HTTP to the identified "http:" URI performs a HELD request on HTTP to the identified
resource. resource.
Note: In many cases, an "http:" URI does not provide sufficient Note: In many cases, an "http:" URI does not provide sufficient
security for location URIs. The absence of the security security for location URIs. The absence of the security
mechanisms provided by TLS means that the Rule Maker has no mechanisms provided by TLS means that the Rule Maker has no
control over who receives location information and the Location control over who receives location information, and the Location
Recipient has no assurance that the information is correct. Recipient has no assurance that the information is correct.
The Location Recipient establishes a connection to the LS, as The Location Recipient establishes a connection to the LS, as
described in [RFC2818]. described in [RFC2818].
The scheme of a location URI determines whether or not TLS is used on The scheme of a location URI determines whether or not TLS is used on
a given dereference transaction. Location Servers MUST be configured a given dereference transaction. Location Servers MUST be configured
to issue only HTTPS URIs and respond to only to HTTPS dereference to issue only HTTPS URIs and respond to only to HTTPS dereference
requests, unless confidentiality and integrity protection are requests, unless confidentiality and integrity protection are
provided by some other mechanism. For example, the server might only provided by some other mechanism. For example, the server might only
accept requests from clients within a trusted network, or via an accept requests from clients within a trusted network or via an
IPsec-protected channel. When TLS is used, the TLS ciphersuite IPsec-protected channel. When TLS is used, the TLS ciphersuite
TLS_NULL_WITH_NULL_NULL MUST NOT be used and the LS MUST be TLS_NULL_WITH_NULL_NULL MUST NOT be used, and the LS MUST be
authenticated [RFC6125] to ensure that the correct server is authenticated [RFC6125] to ensure that the correct server is
contacted. contacted.
A Location Server MAY reject a request and request that a Location A Location Server MAY reject a request and ask that a Location
Recipient provide authentication credentials if authorization is Recipient provide authentication credentials if authorization is
dependent on the Location Recipient identity. Future specifications dependent on the Location Recipient identity. Future specifications
could define an authentication mechanism and a means by which could define an authentication mechanism and a means by which
Location Recipients are identified in authorization policies. This Location Recipients are identified in authorization policies. This
document provides definitions for neither item. document does not provide definitions for either item.
3.1. HELD Usage Profile 3.1. HELD Usage Profile
Use of HELD as a location dereference protocol is largely the same as Use of HELD as a location dereference protocol is largely the same as
its use as a location configuration protocol. Aside from the its use as a location configuration protocol. Aside from the
restrictions noted in this document, HELD semantics do not differ restrictions noted in this document, HELD semantics do not differ
from those established in [RFC5985]. from those established in [RFC5985].
The HELD "locationRequest" is the only request permitted by this The HELD "locationRequest" is the only request permitted by this
specification. Similarly, request parameters other than the specification. Similarly, request parameters other than the
following MUST NOT be accepted by the LS: "responseTime", following MUST NOT be accepted by the LS: "responseTime" and
"locationType" (including the associated "exact" attribute). "locationType" (including the associated "exact" attribute).
Parameters and requests that do not have known behaviour for Parameters and requests that do not have known behavior for
dereference requests MUST NOT be used. The LS MUST ignore any dereference requests MUST NOT be used. The LS MUST ignore any
parameters that it does not understand unless it knows the parameters parameters that it does not understand unless it knows the parameters
to be invalid. If parameters are understood by the LS and known to 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, be invalid, the LS MAY generate a HELD error response. For instance,
those defined in [RFC6155] are always invalid and can be rejected. those defined in [RFC6155] are always invalid and can be rejected.
The LS MUST NOT generate location URIs or provide a "locationUriSet" The LS MUST NOT generate location URIs or provide a "locationUriSet"
in response to a dereference request. If the location request in response to a dereference request. If the location request
contains a "locationType" element that includes "locationURI", this contains a "locationType" element that includes "locationURI", this
parameter is either ignored or rejected as appropriate, based on the parameter is either ignored or rejected as appropriate, based on the
associated "exact" attribute. associated "exact" attribute.
3.2. HTTP GET Behavior 3.2. HTTP GET Behavior
GET is the method assumed by generic HTTP user agents, therefore GET is the method assumed by generic HTTP user agents; therefore,
unless context identifies an "https:" URI as a HELD URI, such a user 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 agent might simply send an HTTP GET. Rather than providing an HTTP
405 (Method Not Allowed) response indicating that POST is the only 405 (Method Not Allowed) response indicating that POST is the only
permitted method, a LIS MUST provide a HELD location response if it permitted method, a LIS MUST provide a HELD location response if it
receives an HTTP GET request. receives an HTTP GET request.
An HTTP GET request to a HELD URI produces a HELD response as if the An HTTP GET request to a HELD URI produces a HELD response as if the
following HELD request had been sent using HTTP POST: following HELD request had been sent using HTTP POST:
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"> <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationType exact="false"> <locationType exact="false">
geodetic civic geodetic civic
</locationType> </locationType>
</locationRequest> </locationRequest>
Figure 1: GET Request Equivalent Location Request Figure 1: GET Request Equivalent Location Request
HTTP GET requests MUST be safe and idempotent [RFC2616] - that is, HTTP GET requests MUST be safe and idempotent [RFC2616] -- that is,
there are no side-effects of making the request and a repeated 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 has no more effect than a single request. Repeating a HELD
request might result in a different location, but only as a result of 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. 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 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 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 location URI can be both safe and idempotent, since a location URI
cannot be produced in response to a request to 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
A Location Recipient MAY infer from a response containing the HELD content type "application/held+xml" that a URI references a resource
content type, "application/held+xml", that a URI references a that supports HELD.
resource that supports HELD.
Content negotiation MAY be supported to produce a presence document Content negotiation MAY be supported to produce a presence document
in place of a HELD location response. Where the presence document in place of a HELD location response. Where the presence document
would otherwise be included in a "locationResponse" document, it can would otherwise be included in a "locationResponse" document, it can
be included in the body of the HTTP response directly by including an be included in the body of the HTTP response directly by including an
"Accept" header that includes "application/pidf+xml". "Accept" header that includes "application/pidf+xml".
4. Authorization Models 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
we discuss the properties of these two models. Figure 2, from subsections, we discuss the properties of these two models.
[RFC5808], shows the model applicable to location configuration, Figure 2, from [RFC5808], shows the model applicable to location
conveyance and dereference. configuration, conveyance, and dereference.
+---------+--------+ Location +-----------+ +---------+--------+ Location +-----------+
| | | Dereference | Location | | | | Dereference | Location |
| LIS - LS +---------------+ Recipient | | LIS - LS +---------------+ Recipient |
| | | Protocol | | | | | Protocol | |
+----+----+--------+ (3) +-----+-----+ +----+----+--------+ (3) +-----+-----+
| `. | | `. |
| Policy `. | | Policy `. |
Location | Exchange `. | Location | Exchange `. |
Configuration | (*) | | Configuration | (*) | |
skipping to change at page 7, line 9 skipping to change at page 7, line 12
limits the policy options available when the "Authorization by Access limits the policy options available when the "Authorization by Access
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
[RFC6442]). This step is shown in (2) of Figure 2. [RFC6442]). This step is shown in (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.
4.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 might used to control access to location information. A location URI might
be constructed such that it is hard to guess (see C8 of [RFC5808]) be constructed such that it is hard to guess (see C8 of [RFC5808]),
and the set of entities that it is disclosed to can be limited. The and the set of entities that it is disclosed to can be limited. The
only authentication this would require by the LS is evidence of only authentication this would require by the LS is evidence of
possession of the URI. The LS could immediately authorize any possession of the URI. The LS could immediately authorize any
request that indicates this URI. request that indicates this URI.
Authorization by possession does not require direct interaction with Authorization by possession does not require direct interaction with
a Rule Maker; it is assumed that the Rule Maker is able to exert a Rule Maker; it is assumed that the Rule Maker is able to exert
control over the distribution of the location URI. Therefore, the control over the distribution of the location URI. Therefore, the
LIS can operate with limited policy input from a Rule Maker. LIS can operate with limited policy input from a Rule Maker.
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 and location-
routing) specific treatment is important, as discussed in [RFC6442]. based routing), specific treatment is important, as discussed in
[RFC6442].
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. Expiration of location URIs limits the be technically infeasible. Expiration of location URIs limits the
usable time for a location URI, requiring that an attacker continue usable time for a location URI, requiring that an attacker continue
to learn new location URIs to retain access to current location to learn new location URIs to retain access to current location
information. information.
A very simple policy might be established at the time that a location A very simple policy might be established at the time that a location
URI is created. This policy specifies that the location URI expires URI 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.
4.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 behavior of an LS. In contrast to authorization by
possession, possession of 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
might also be possible to change authorization policies at any time. might also be possible to change authorization policies at any time.
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 [GEOPRIV-POLICY]. Additional constraints might be established by
established by other means. 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.
4.3. Access Control with HELD Deference 4.3. Access Control with HELD Dereference
This document does not describe a specific authentication mechanism; This document does not describe a specific authentication mechanism;
therefore, the authorization by access control model is not an therefore, the authorization by access control model is not an
option. Instead, this document assumes the authorization by option. Instead, this document assumes the authorization by
possession model. possession model.
Other policy mechanisms, such as those described in Other policy mechanisms, such as those described in [GEOPRIV-POLICY],
[I-D.ietf-geopriv-policy], can be applied for different Location can be applied for different Location Recipients if each recipient is
Recipients if each recipient is given a different location URIs. given a different location URI. Each location URI can be assigned a
different authorization policy. Selective disclosure used in this
Each location URI can be assigned different authorization policy. fashion can be used in place of identity-based authorization.
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. [GEOPRIV-POLICY-URI] describes one possible mechanism.
mechanism.
Use of identity-based authorization policy is not precluded. A Use of an identity-based authorization policy is not precluded. A
Location Server MAY support an authentication mechanism that enables Location Server MAY support an authentication mechanism that enables
identity-based authorization policies to be used. Future identity-based authorization policies to be used. Future
specifications might define means of identifying recipients. specifications might define means of 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.
5. Examples 5. Examples
An example scenario envisioned by this document is shown in Figure 3. An example scenario envisioned by this document is shown in Figure 3.
This diagram shows how a location dereference protocol fits with This diagram shows how a location dereference protocol fits with
location configuration and conveyance. [RFC5808] contains more location configuration and conveyance. [RFC5808] contains more
information on this scenario and others like it. information on this scenario and others like it.
+-------------+ +-------------+
+------------+ | Location | +-----------+ +------------+ | Location | +-----------+
| End Device | | Information | | Location | | End Device | | Information | | Location |
| (Target) | | Server | | Recipient | | (Target) | | Server | | Recipient |
+-----+------+ +------+------+ +-----+-----+ +-----+------+ +------+------+ +-----+-----+
| | | | | |
.- + - - - - - - - - - - - - + -. | .- + - - - - - - - - - - - - + -. |
: | locationRequest | : | : | locationRequest | : |
. |----(for location URI)-->| . | . |----(for location URI)-->| . |
: | | : Location | : | | : Location |
skipping to change at page 11, line 4 skipping to change at page 12, line 7
Content-Type: application/held+xml Content-Type: application/held+xml
Content-Length: 87 Content-Length: 87
<?xml version="1.0"?> <?xml version="1.0"?>
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"/> <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"/>
Figure 4: Minimal Dereferencing Request Figure 4: Minimal Dereferencing Request
Figure 5 shows the response to the previous request listing both Figure 5 shows the response to the previous request listing both
civic and geodetic location information of the Target's location. civic and geodetic location information of the Target's location.
Again, this is identical to the response in Section 10.1 of [RFC5985] Again, this is identical to the response in Section 10.1 of [RFC5985]
- unless policy specifies otherwise, the Location Recipient receives -- unless policy specifies otherwise, the Location Recipient receives
the same information as the Device. the same information as the Device.
HTTP/1.1 200 OK HTTP/1.1 200 OK
Server: Example LIS Server: Example LIS
Date: Mon, 10 Jan 2011 03:42:29 GMT Date: Mon, 10 Jan 2011 03:42:29 GMT
Expires: Tue, 11 Jan 2011 03:42:29 GMT Expires: Tue, 11 Jan 2011 03:42:29 GMT
Cache-control: private Cache-control: private
Content-Type: application/held+xml Content-Type: application/held+xml
Content-Length: 676 Content-Length: 676
skipping to change at page 13, line 10 skipping to change at page 14, line 7
Privacy of location information is the most important security Privacy of location information is the most important security
consideration for this document. Two measures in particular are used consideration for this document. Two measures in particular are used
to protect privacy: TLS and authorization policies. TLS provides a to protect privacy: TLS and authorization policies. TLS provides a
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, [GEOPRIV-POLICY-URI] and [RFC4825].
TLS MUST be used for dereferencing location URIs unless TLS MUST be used for dereferencing location URIs unless
confidentiality and integrity are provided by some other mechanism, confidentiality and integrity are provided by some other mechanism,
as discussed in Section 3. Location Recipients MUST authenticate the as discussed in Section 3. Location Recipients MUST authenticate the
host identity using the domain name included in the location URI, host identity using the domain name included in the location URI,
using the procedure described in Section 3.1 of [RFC2818]. Local using the procedure described in Section 3.1 of [RFC2818]. Local
policy determines what a Location Recipient does if authentication policy determines what a Location Recipient does if authentication
fails or cannot be attempted. fails or cannot be attempted.
The authorization by possession model (Section 4.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 [RFC6280] identifies the Rule Recipients. The GEOPRIV architecture [RFC6280] designates the Rule
Maker role as being the entity that authorizes disclosure of this Maker to authorize disclosure of the URI.
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 anyone who has the URI to
it. This aspect of security is covered in more detail in the view the associated location information. This aspect of security is
specification of location conveyance protocols, such as [RFC6442]. 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 According to the requirements in [RFC5808] the LS MUST NOT provide
location, unless policy from a Rule Maker allows otherwise. In any information about the Target except its location, unless policy
particular, the requirements in [RFC5808] mandate this measure to from a Rule Maker allows otherwise. Thus, the Location Server MUST
protect the identity of the Target. To this end, an unlinked only provide an unlinked pseudonym in the "entity" attribute of the
pseudonym MUST be provided in the "entity" attribute of the PIDF-LO PIDF-LO document unless the Rule Maker policy allows for identity
document. disclosure.
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].
7. IANA Considerations 7. Acknowledgements
This document makes no request of IANA.
[[IANA/RFC-EDITOR: Please remove this section before publication.]]
8. Acknowledgements
Thanks to Barbara Stark and Guy Caron for providing early comments. Thanks to Barbara Stark and Guy Caron for providing early comments.
Thanks to Rohan Mahy for constructive comments on the scope and Thanks to Rohan Mahy for constructive comments on the scope and
format of the document. Thanks to Ted Hardie for his strawman format of the document. Thanks to Ted Hardie for his strawman
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 Martin Dawson was an original author of this document. Sadly, he
passed away prior to its publication. passed away prior to its publication.
9. References 8. References
9.1. Normative References 8.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.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
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.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, March 2011. Security (TLS)", RFC 6125, March 2011.
9.2. Informative references 8.2. Informative References
[I-D.ietf-geopriv-dhcp-lbyr-uri-option] [DHCP-URI-OPT]
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-15 (work (URI)", Work in Progress, May 2012.
in progress), May 2012.
[I-D.ietf-geopriv-policy] [GEOPRIV-POLICY]
Schulzrinne, H., Tschofenig, H., Cuellar, J., Polk, J., Schulzrinne, H., Tschofenig, H., Cuellar, J., 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-26 (work Location Information", Work in Progress, August 2012.
in progress), June 2012.
[I-D.ietf-geopriv-policy-uri] [GEOPRIV-POLICY-URI]
Thomson, M., Winterbottom, J., Barnes, R., and H. Barnes, R., Thomson, M., Winterbottom, J., and H.
Tschofenig, "Location Configuration Extensions for Policy Tschofenig, "Location Configuration Extensions for Policy
Management", draft-ietf-geopriv-policy-uri-04 (work in Management", Work in Progress, November 2011.
progress), November 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 16, line 33 skipping to change at page 18, line 13
December 2011. 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 requirement 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
[RFC4119] and [RFC5491]. [RFC4119] and [RFC5491].
Req. 2. (Location Object fields): Req. 2. (Location Object fields):
This section relates to the PIDF-LO [RFC4119] document, This requirement 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
[RFC4119] and [RFC5491]. [RFC4119] and [RFC5491].
Req. 3. (Location Data Types): Req. 3. (Location Data Types):
This section relates to the PIDF-LO [RFC4119] document, This requirement 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
[RFC4119] and [RFC5491]. [RFC4119] and [RFC5491].
Section 7.2 of [RFC3693] details the requirements of a "Using Section 7.2 of [RFC3693] details the requirements of a "Using
Protocol". These requirements are restated, followed by a statement Protocol". These requirements are restated, followed by a statement
of compliance: of compliance:
Req. 4. "The using protocol has to obey the privacy and security Req. 4. "The using protocol has to obey the privacy and security
instructions coded in the Location Object and in the instructions coded in the Location Object and in the
corresponding Rules regarding the transmission and storage corresponding Rules regarding the transmission and storage
of the LO." of the LO".
Compliant: This specification describes the use of HTTP over Compliant: This specification describes the use of HTTP over
TLS for carring the PIDF-LO from the LS to the Location TLS for carrying the PIDF-LO from the LS to the Location
Recipient. The sending and receiving parties are expected Recipient. The sending and receiving parties are expected
to comply with the instructions carried inside the object. to comply with the instructions carried inside the object.
Though discouraged, using unsecured http: URIs is permitted. Though discouraged, using unsecured "http:" URIs is
Using unsecured HTTP is likely to result in non-compliance permitted. Using unsecured HTTP is likely to result in non-
with this requirement. compliance with this requirement.
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 based on distribution of a secret (the
location URI) using a conveyance protocol (for instance, location URI) using a conveyance protocol (for instance,
[RFC6442]), allowances are made for later work to define [RFC6442]), allowances are made 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.
Section 7.3 of [RFC3693] details the requirements of a "Rule based Section 7.3 of [RFC3693] details the requirements of a "Rule based
Location Data Transfer". These requirements are restated where they Location Data Transfer". These requirements are restated where they
are applicable to this document: are applicable to this document:
Req. 7. "(LS Rules) The decision of a Location Server to provide a Req. 7. "(LS Rules) The decision of a Location Server to provide a
Location Recipient access to Location Information MUST be Location Recipient access to Location Information MUST be
based on Rule Maker-defined Privacy Rules." based on Rule Maker-defined Privacy Rules".
Compliant: This document describes two alternative methods Compliant: This document describes two alternative methods
by which a Rule Maker is able to control access to location by which a Rule Maker is able to control access to location
information. Rule Maker policy is enforced by the LS when information. Rule Maker policy is enforced by the LS when
a location URI is dereferenced. However, this document a location URI is dereferenced. However, this document
does not describe how a location URI is created, or how a does not describe how a location URI is created or how a
Rule Maker associates policy with a location URI. These Rule Maker associates policy with a location URI. These
are covered by other specifications. are covered by other specifications.
Req. 8. (LG Rules) Not Applicable: This relationship between LS and Req. 8. (LG Rules) Not Applicable: This relationship between LS and
the source of its information (be that Location Generator the source of its information (be that Location Generator
(LG) or LIS) is out of scope for this document. (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 Req. 9. "(Viewer Rules) A Viewer does not need to be aware of the
full Rules defined by the Rule Maker (because a Viewer full Rules defined by the Rule Maker (because a Viewer
SHOULD NOT retransmit Location Information), and thus a SHOULD NOT retransmit Location Information), and thus a
Viewer SHOULD receive only the subset of Privacy Rules Viewer SHOULD receive only the subset of Privacy Rules
necessary for the Viewer to handle the LO in compliance necessary for the Viewer to handle the LO in compliance
with the full Privacy Rules (such as, instruction on the with the full Privacy Rules (such as, instruction on the
time period for which the LO can be retained)." time period for which the LO can be retained)".
Compliant: The Rule Maker might define (via mechanisms Compliant: The Rule Maker might define (via mechanisms
outside the scope of this document) which policy rules are outside the scope of this document) which policy rules are
disclosed to other entities. For instance, if [RFC4745] is disclosed to other entities. For instance, if [RFC4745] is
used to convey authorization policies from Rule Maker to used to convey authorization policies from Rule Maker to
LS, this is possible using the parameters specified in LS, this is possible using the parameters specified in
[I-D.ietf-geopriv-policy]. [GEOPRIV-POLICY].
In order to comply with these rules, a Location Recipient In order to comply with these rules, a Location Recipient
MUST NOT redistribute a location URI without express MUST NOT redistribute a location URI without express
permission. Depending on the access control model, the permission. Depending on the access control model, the
location URI might be secret (see Section 3.3 of location URI might be secret (see Section 3.3 of
[RFC5808]). [RFC5808]).
Req. 10. (Full Rule language) Not Applicable: Note however that Req. 10. (Full Rule language) Not Applicable: Note, however, that
Geopriv has defined a rule language capable of expressing a GEOPRIV has defined a rule language capable of expressing a
wide range of privacy rules (see [RFC4745] and wide range of privacy rules (see [RFC4745] and
[I-D.ietf-geopriv-policy]. [GEOPRIV-POLICY].
Req. 11. (Limited Rule language) Not Applicable: This requirement Req. 11. (Limited Rule language) Not Applicable: This requirement
applies to (and is addressed by) PIDF-LO [RFC4119]. applies to (and is addressed by) PIDF-LO [RFC4119].
Section 7.4 of [RFC3693] details the requirements of "Location Object Section 7.4 of [RFC3693] details the requirements of "Location Object
Privacy and Security". These requirements are restated where they Privacy and Security". These requirements are restated where they
are applicable to this document: are applicable to this document:
Req. 12. (Identity Protection) Compliant: Identity protection of the Req. 12. (Identity Protection) Compliant: Identity protection of the
Target is provided as long as both of the following Target is provided as long as both of the following
skipping to change at page 19, line 21 skipping to change at page 21, line 8
For instance, this requirement is complied with if the For instance, this requirement is complied with if the
protocol that conveys the location URI does not link the protocol that conveys the location URI does not link the
identity of the Target to the location URI and the LS identity of the Target to the location URI and the LS
doesn't include meaningful identification information in doesn't include meaningful identification information in
the PIDF-LO document. Section 6 recommends that an the PIDF-LO document. Section 6 recommends that an
unlinked pseudonym is used by the LS. unlinked pseudonym is used by the LS.
Req. 13. (Credential Requirements) Compliant: The primary security Req. 13. (Credential Requirements) Compliant: The primary security
mechanism specified in this document is Transport Layer mechanism specified in this document is Transport Layer
Security. TLS offers the ability to use different types of Security. TLS offers the ability to use different types of
credentials, including symmetric, asymmetric credentials or credentials, including symmetric, asymmetric, or a
a combination of them. combination of them.
Req. 14. (Security Features) Compliant: Geopriv defines a few Req. 14. (Security Features) Compliant: GEOPRIV defines a few
security requirements for the protection of Location security requirements for the protection of Location
Objects such as mutual end-point authentication, data Objects such as mutual endpoint authentication, data object
object integrity, data object confidentiality and replay integrity, data object confidentiality, and replay
protection. The ability to use Transport Layer security protection. The ability to use Transport Layer Security
fulfills most of these requirements. Authentication of fulfills most of these requirements. Authentication of
Location Recipients in this document relies on proof of a Location Recipients in this document relies on proof of a
shared secret - the location URI. This does not preclude shared secret -- the location URI. This does not preclude
the addition of more robust authentication procedures. the addition of more robust authentication procedures.
Req. 15. (Minimal Crypto) Compliant: The mandatory to implement Req. 15. (Minimal Crypto) Compliant: The mandatory-to-implement
ciphersuite is provided in the TLS layer security ciphersuite is provided in the TLS layer security
specification. specification [RFC5246].
Appendix B. Compliance to Location Reference Requirements Appendix B. Compliance to Location Reference Requirements
This section describes how HELD complies to the location reference This section describes how HELD complies to the location reference
requirements stipulated in [RFC5808]. Compliance of [RFC5985] to the requirements stipulated in [RFC5808]. Compliance of [RFC5985] to the
Location Configuration Protocol is included. Location Configuration Protocol is included.
Note that use of HELD as a location dereference protocol does not Note: Use of HELD as a location dereference protocol does not
necessarily imply that HELD is the corresponding LCP. This necessarily imply that HELD is the corresponding LCP. This
document is still applicable to HTTP location URIs that are document is still applicable to HTTP location URIs that are
acquired by other means. acquired by other means.
B.1. Requirements for a Location Configuration Protocol B.1. Requirements for a Location Configuration Protocol
C1. "Location URI support: The location configuration protocol MUST C1. "Location URI support: The location configuration protocol MUST
support a location reference in URI form." support a location reference in URI form".
Compliant: HELD only provides location references in URI form. Compliant: HELD only provides location references in URI form.
C2. "Location URI expiration: When a location URI has a limited C2. "Location URI expiration: When a location URI has a limited
validity interval, its lifetime MUST be indicated." validity interval, its lifetime MUST be indicated".
Compliant: HELD indicates the expiry time of location URIs using Compliant: HELD indicates the expiry time of location URIs using
the "expires" attribute. [I-D.ietf-geopriv-policy-uri] provides the "expires" attribute. [GEOPRIV-POLICY-URI] provides a way to
a way to control expiration of a location URI. control expiration of a location URI.
C3. "Location URI cancellation: The location configuration protocol C3. "Location URI cancellation: The location configuration protocol
MUST support the ability to request a cancellation of a specific MUST support the ability to request a cancellation of a specific
location URI." location URI".
Compliant with Extension: [I-D.ietf-geopriv-policy-uri] Compliant with Extension: [GEOPRIV-POLICY-URI] describes how a
describes how a location URI can be cancelled through the location URI can be canceled through the application of policy.
application of policy. Without extensions, HELD does not Without extensions, HELD does not provide a method for canceling
provide a method for cancelling location URIs. location URIs.
C4. "Location Information Masking: The location URI MUST ensure, by C4. "Location Information Masking: The location URI MUST ensure, by
default, through randomization and uniqueness, that the location default, through randomization and uniqueness, that the location
URI does not contain location information specific components." URI does not contain location information specific components".
Compliant: The HELD specification explicitly references this Compliant: The HELD specification [RFC5985] explicitly
requirement in providing guidance on the format of the location references this requirement in providing guidance on the format
URI. of the location URI.
C5. "Target Identity Protection: The location URI MUST NOT contain C5. "Target Identity Protection: The location URI MUST NOT contain
information that identifies the Target (e.g., user or device)." information that identifies the Target (e.g., user or device)".
Compliant: The HELD specification provides specific guidance on Compliant: The HELD specification [RFC5985] provides specific
the anonymity of the Target with regards to the generation of guidance on the anonymity of the Target with regards to the
location URIs. Section 6 expands on this guidance. generation of location URIs. Section 6 expands on this
guidance.
C6. "Reuse indicator: There SHOULD be a way to allow a Target to C6. "Reuse indicator: There SHOULD be a way to allow a Target to
control whether a location URI can be resolved once only, or control whether a location URI can be resolved once only, or
multiple times." multiple times".
Not Compliant: Specific extensions to the protocol or Not Compliant: Specific extensions to the protocol or
authorization policy formats is needed to alter the default authorization policy formats are needed to alter the default
behavior, which allows unlimited resolution of the location URI. behavior, which allows unlimited resolution of the location URI.
C7. "Selective disclosure: The location configuration protocol MUST C7. "Selective disclosure: The location configuration protocol MUST
provide a mechanism that allows the Rule Maker to control what provide a mechanism that allows the Rule Maker to control what
information is being disclosed about the Target." information is being disclosed about the Target".
Compliant with Extension: Use of policy mechanisms and Compliant with Extension: Use of policy mechanisms and
[I-D.ietf-geopriv-policy-uri] enable this capability. Note that [GEOPRIV-POLICY-URI] enable this capability. Note that this
this document recommends that only location information be document recommends that only location information be provided.
provided.
C8. "Location URI Not guessable: As a default, the location C8. "Location URI Not guessable: As a default, the location
configuration protocol MUST return location URIs that are random configuration protocol MUST return location URIs that are random
and unique throughout the indicated lifetime. A location URI and unique throughout the indicated lifetime. A location URI
with 128-bits of randomness is RECOMMENDED." with 128-bits of randomness is RECOMMENDED".
Compliant: HELD specifies that location URIs conform to this Compliant: HELD specifies that location URIs conform to this
requirement. The amount of randomness is not specifically requirement. The amount of randomness is not specifically
identified since it depends on a number of factors that change identified since it depends on a number of factors that change
over time, such as the number of valid location URIs, the over time, such as the number of valid location URIs, the
validity period of those URIs and the rate that guesses can be validity period of those URIs, and the rate that guesses can be
made. made.
C9. "Location URI Options: In the case of user-provided C9. "Location URI Options: In the case of user-provided
authorization policies, where anonymous or non-guessable authorization policies, where anonymous or non-guessable
location URIs are not warranted, the location configuration location URIs are not warranted, the location configuration
protocol MAY support a variety of optional location URI protocol MAY support a variety of optional location URI
conventions, as requested by a Target to a location conventions, as requested by a Target to a location
configuration server, (e.g., embedded location information configuration server, (e.g., embedded location information
within the location URI)." within the location URI)".
Not Compliant: HELD does not support Device-specified location Not Compliant: HELD does not support Device-specified location
URI forms. URI forms.
B.2. Requirements for a Location Dereference Protocol B.2. Requirements for a Location Dereference Protocol
D1. "Location URI support: The location dereference protocol MUST D1. "Location URI support: The location dereference protocol MUST
support a location reference in URI form." support a location reference in URI form".
Compliant: HELD only provides location references in URI form. Compliant: HELD only provides location references in URI form.
D2. "Authentication: The location dereference protocol MUST include D2. "Authentication: The location dereference protocol MUST include
mechanisms to authenticate both the client and the server." mechanisms to authenticate both the client and the server".
Partially Compliant: TLS provides means for mutual Partially Compliant: TLS provides means for mutual
authentication. This document only specifies the required authentication. This document only specifies the required
mechanism for server authentication. Client authentication is mechanism for server authentication. Client authentication is
not precluded. not precluded.
D3. "Dereferenced Location Form: The value returned by the D3. "Dereferenced Location Form: The value returned by the
dereference protocol MUST contain a well-formed PIDF-LO dereference protocol MUST contain a well-formed PIDF-LO
document." document".
Compliant: HELD requires that location objects are in the form Compliant: HELD requires that Location Objects are in the form
of a PIDF-LO that complies with [RFC5491]. of a PIDF-LO that complies with [RFC5491].
D4. "Location URI Repeated Use: The location dereference protocol D4. "Location URI Repeated Use: The location dereference protocol
MUST support the ability for the same location URI to be MUST support the ability for the same location URI to be
resolved more than once, based on dereference server resolved more than once, based on dereference server
configuration." configuration".
Compliant: A Location Recipient may access and use a location Compliant: A Location Recipient may access and use a location
URI as many times as desired until URI expiration results in the URI as many times as desired until URI expiration results in the
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.
HTTP is permitted: the associated risks are described in Unsecured HTTP is permitted: the associated risks are described
Section 3. in 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
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
US New York, NY 10027
USA
Phone: +1 212 939 7004 Phone: +1 212 939 7042
Email: hgs@cs.columbia.edu EMail: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu URI: http://www.cs.columbia.edu
Martin Thomson Martin Thomson
Microsoft Microsoft
3210 Porter Drive 3210 Porter Drive
Palo Alto, CA 94304 Palo Alto, CA 94304
US USA
Phone: +1 650-353-1925 Phone: +1 650-353-1925
Email: martin.thomson@skype.net EMail: martin.thomson@skype.net
 End of changes. 115 change blocks. 
209 lines changed or deleted 191 lines changed or added

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