draft-ietf-geopriv-policy-uri-07.txt   rfc7199.txt 
GEOPRIV R. Barnes Internet Engineering Task Force (IETF) R. Barnes
Internet-Draft BBN Technologies Request for Comments: 7199 M. Thomson
Intended status: Standards Track M. Thomson Category: Standards Track Mozilla
Expires: April 7, 2013 Microsoft ISSN: 2070-1721 J. Winterbottom
J. Winterbottom Unaffiliated
Andrew Corporation
H. Tschofenig H. Tschofenig
Nokia Siemens Networks April 2014
October 4, 2012
Location Configuration Extensions for Policy Management Location Configuration Extensions for Policy Management
draft-ietf-geopriv-policy-uri-07.txt
Abstract Abstract
Current location configuration protocols are capable of provisioning Current location configuration protocols are capable of provisioning
an Internet host with a location URI that refers to the host's an Internet host with a location URI that refers to the host's
location. These protocols lack a mechanism for the target host to location. These protocols lack a mechanism for the target host to
inspect or set the privacy rules that are applied to the URIs they inspect or set the privacy rules that are applied to the URIs they
distribute. This document extends the current location configuration distribute. This document extends the current location configuration
protocols to provide hosts with a reference to the rules that are protocols to provide hosts with a reference to the rules that are
applied to a URI, so that the host can view or set these rules. applied to a URI so that the host can view or set these rules.
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 April 7, 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/rfc7199.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2014 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. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Policy URIs . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Policy URIs . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Policy URI Usage . . . . . . . . . . . . . . . . . . . . . 5 3.1. Policy URI Usage . . . . . . . . . . . . . . . . . . . . 5
3.2. Policy URI Allocation . . . . . . . . . . . . . . . . . . 6 3.2. Policy URI Allocation . . . . . . . . . . . . . . . . . . 6
3.3. Policy Defaults . . . . . . . . . . . . . . . . . . . . . 7 3.3. Policy Defaults . . . . . . . . . . . . . . . . . . . . . 7
4. Location Configuration Extensions . . . . . . . . . . . . . . 8 4. Location Configuration Extensions . . . . . . . . . . . . . . 8
4.1. HELD . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. HELD . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Client Processing . . . . . . . . . . . . . . . . . . . . 9
4.3. Client Processing . . . . . . . . . . . . . . . . . . . . 9 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Basic Access Control Policy . . . . . . . . . . . . . . . 10
5.1. HELD . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
5.2. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.3. Basic Access Control Policy . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6.1. URN Sub-Namespace Registration for 6.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held:policy . . . . . . . . 13 urn:ietf:params:xml:ns:geopriv:held:policy . . . . . . . 12
6.2. XML Schema Registration . . . . . . . . . . . . . . . . . 13 6.2. XML Schema Registration . . . . . . . . . . . . . . . . . 12
6.3. DHCP LuriType Registration . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7.1. Integrity and Confidentiality for Authorization Policy 7.1. Integrity and Confidentiality for Authorization Policy
Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Data . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.2. Access Control for Authorization Policy . . . . . . . . . 15 7.2. Access Control for Authorization Policy . . . . . . . . . 13
7.3. Location URI Allocation . . . . . . . . . . . . . . . . . 16 7.3. Location URI Allocation . . . . . . . . . . . . . . . . . 15
7.4. Policy URI Handling . . . . . . . . . . . . . . . . . . . 17 7.4. Policy URI Handling . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . . 18 9.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. Example Policy URI Generation Algorithm . . . . . . . 19 Appendix A. Example Policy URI Generation Algorithm . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
A critical step in enabling Internet hosts to access location-based A critical step in enabling Internet hosts to access location-based
services is to provision those hosts with information about their own services is to provision those hosts with information about their own
location. This is accomplished via a Location Configuration Protocol location. This is accomplished via a Location Configuration Protocol
(LCP) [RFC5687], which allows a location provider (e.g., a local (LCP) [RFC5687], which allows a location provider (e.g., a local
access network) to inform a host about its location. access network) to inform a host about its location.
There are two basic patterns for location configuration, namely There are two basic patterns for location configuration, namely
configuration "by value" and "by reference" [RFC5808]. Configuration configuration "by value" and "by reference" [RFC5808]. Configuration
by value provisions a host directly with its location, by providing by value provisions a host directly with its location, by providing
it location information that is directly usable (e.g., coordinates or it location information that is directly usable (e.g., coordinates or
a civic address). Configuration by reference provides a host with a a civic address). Configuration by reference provides a host with a
URI that references the host's location, i.e., one that can be URI that references the host's location, i.e., one that can be
dereferenced to obtain the location (by value) of the host. dereferenced to obtain the location (by value) of the host.
In some cases, location by reference offers a few benefits over In some cases, location by reference offers a few benefits over
location by value. From a privacy perspective, the required location by value. From a privacy perspective, the required
dereference transaction provides a policy enforcement point, so that dereference transaction provides a policy enforcement point so that
if suitable privacy policies have been provisioned, the opaque if suitable privacy policies have been provisioned, the opaque
location URI can be safely conveyed over untrusted media. (If the location URI can be safely conveyed over untrusted media. (If the
location URI is not subject to privacy rules, then conveying the location URI is not subject to privacy rules, then conveying the
location URI may pose even greater risk than sending location by location URI may pose even greater risk than sending location by
value [RFC5606]) If the target host is mobile, an application value [RFC5606].) If the target host is mobile, an application
provider can use a single reference to obtain the location of the provider can use a single reference to obtain the location of the
host multiple times, saving bandwidth to the host. For some host multiple times, saving bandwidth to the host. For some
configuration protocols, the location object referenced by a location configuration protocols, the location object referenced by a location
URI provides a much more expressive syntax for location values than URI provides a much more expressive syntax for location values than
the configuration protocol itself (e.g., DHCP geodetic location the configuration protocol itself (e.g., DHCP geodetic location
[RFC6225] versus GML in a PIDF-LO [RFC4119]). [RFC6225] versus Geography Markup Language (GML) in a Presence
Information Data Format Location Object (PIDF-LO) [RFC4119]).
From a privacy perspective, however, current LCPs are limited in From a privacy perspective, however, current LCPs are limited in
their flexibility, in that they do not provide hosts (the clients in their flexibility, in that they do not provide hosts (the clients in
an LCP) with a way to inform the Location Server with policy for how an LCP) with a way to inform the Location Server with policy for how
his location information should be handled. This document addresses his location information should be handled. This document addresses
this gap by defining a simple mechanism for referring to and this gap by defining a simple mechanism for referring to and
manipulating policy, and by extending current LCPs to carry policy manipulating policy and by extending current LCPs to carry policy
references. Using the mechanisms defined in this document, an LCP references. Using the mechanisms defined in this document, an LCP
server (acting for the Location Server (LS) or Location Information server (acting for the Location Server (LS) or Location Information
Server (LIS)) can inform a host as to which policy document controls Server (LIS)) can inform a host as to which policy document controls
a given location resource, and the host (in its Rule Maker role) can a given location resource, and the host (in its Rule Maker role) can
inspect this document and modify it as necessary. inspect this document and modify it as necessary.
In the following figure, adapted from RFC 5808, this document extends In the following figure, adapted from RFC 5808, this document extends
the Location Configuration Protocols (1) and defines a simple the Location Configuration Protocols (1) and defines a simple
protocol for policy exchange (4). protocol for policy exchange (4).
skipping to change at page 4, line 23 skipping to change at page 4, line 23
Exchange| |Configuration |Conveyance Exchange| |Configuration |Conveyance
(4)| |Protocol |Protocol (4)| |Protocol |Protocol
| |(1) |(2) | |(1) |(2)
| | | | | |
+------+----+----+----+ | +------+----+----+----+ |
| Rule | Target/ | | | Rule | Target/ | |
| Maker | Host +---------------------+ | Maker | Host +---------------------+
| | | | | |
+-----------+---------+ +-----------+---------+
The remainder of this document is structured as follows: After The remainder of this document is structured as follows:
introducing a few relevant terms, we define policy URIs as a channel
for referencing, inspecting, and updating policy documents. We then After introducing a few relevant terms, we define policy URIs as a
define extensions to the HELD protocol and the DHCP option for channel for referencing, inspecting, and updating policy documents.
location by reference to allow these protocols to carry policy URIs. We then define an extension to the HELD protocol to allow it to carry
Examples are given that demonstrate how policy URIs are carried in policy URIs. Examples are given that demonstrate how policy URIs are
these protocols and how they can be used by clients. carried in this protocol and how it can be used by clients.
2. Definitions 2. Definitions
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 RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Policy URIs 3. Policy URIs
A policy URI is an HTTP [RFC2616] or HTTPS [RFC2818]URI that A policy URI is an HTTP [RFC2616] or HTTPS [RFC2818] URI that
identifies a policy resource that contains the authorization policy identifies a policy resource that contains the authorization policy
for a linked location resource. Access to the location resource is for a linked location resource. Access to the location resource is
governed by the contents of the authorization policy. governed by the contents of the authorization policy.
A policy URI identifies an HTTP resource that a Rule Maker can use to A policy URI identifies an HTTP resource that a Rule Maker can use to
inspect and install policy documents that tell a Location Server how inspect and install policy documents that tell a Location Server how
it should protect the associated location resource. A policy URI it should protect the associated location resource. A policy URI
always identifies a resource that can be represented as a common- always identifies a resource that can be represented as a common-
policy document [RFC4745] (possibly including some extensions; e.g., policy document [RFC4745] (possibly including some extensions; e.g.,
for geolocation policy [I-D.ietf-geopriv-policy]). for geolocation policy [RFC6772]).
Note: RFC 3693 [RFC3693] identified the Rule Holder role as the one Note: RFC 3693 [RFC3693] identified the Rule Holder role as the one
that stores policy information. In this document, the Location that stores policy information. In this document, the Location
Server is also a Rule Holder. Server is also a Rule Holder.
3.1. Policy URI Usage 3.1. Policy URI Usage
A Location Server that is the authority for policy URIs MUST support A Location Server that is the authority for policy URIs MUST support
GET, PUT, and DELETE requests to these URIs, in order to allow GET, PUT, and DELETE requests to these URIs, in order to allow
clients to inspect, replace, and delete policy documents. Clients clients to inspect, replace, and delete policy documents. Clients
support the three request methods as they desire to perform these support the three request methods as they desire to perform these
operations. operations.
Knowledge of the policy URI can be considered adequate evidence of Knowledge of the policy URI can be considered adequate evidence of
authorization; a policy URI functions as a shared secret between the authorization; a policy URI functions as a shared secret between the
client and the server (see Section 7). A Location Server SHOULD client and the server (see Section 7). A Location Server SHOULD
allow all requests, but it MAY deny certain requests based on local allow all requests, but it MAY deny certain requests based on local
policy. For instance, a Location Server might allow clients to policy. For instance, a Location Server might allow clients to
inspect policy (GET), but not to update it (PUT). Or a Location inspect policy (GET), but not to update it (PUT). Or, a Location
Server might require clients to authenticate using HTTP or TLS client Server might require clients to authenticate using HTTP or Transport
authentication. Clients implementing this specification SHOULD Layer Security (TLS) client authentication. Clients implementing
support HTTP client authentication [RFC2617] and MAY support TLS this specification SHOULD support HTTP client authentication
client certificates. [RFC2617] and MAY support TLS client certificates.
A GET request to a policy URI is a request for the referenced policy A GET request to a policy URI is a request for the referenced policy
information. If the request is authorized, then the Location Server information. If the request is authorized, then the Location Server
sends an HTTP 200 response containing the complete policy identified sends an HTTP 200 response containing the complete policy identified
by the URI. by the URI.
A PUT request to a policy URI is a request to replace the current A PUT request to a policy URI is a request to replace the current
policy. The entity-body of a PUT request includes a complete policy policy. The entity-body of a PUT request includes a complete policy
document. When a Location Server receives a PUT request, it MUST document. When a Location Server receives a PUT request, it MUST
validate the policy document included in the body of the request. If validate the policy document included in the body of the request. If
the request is valid and authorized, then the Location Server MUST the request is valid and authorized, then the Location Server MUST
replace the current policy with the policy provided in the request. replace the current policy with the policy provided in the request.
A DELETE request to a policy URI is a request to delete the A DELETE request to a policy URI is a request to delete the
referenced policy document. If the request is authorized, then the referenced policy document. If the request is authorized, then the
Location Server MUST delete the policy referenced by the URI and Location Server MUST delete the policy referenced by the URI and
disallow access to the location URIs it governs until a new policy disallow access to the location URIs it governs until a new policy
document has been put in place via a PUT request. document has been put in place via a PUT request.
A policy URI is only valid while the corresponding location URI set A policy URI is only valid while the corresponding location URI set
is valid. A location server MUST NOT respond to any requests to a is valid. A Location Server MUST NOT respond to any requests to a
policy URIs once the corresponding location URI set has expired. policy URI once the corresponding location URI set has expired. This
This expiry time is specified by the 'expires' attribute in the HELD expiry time is specified by the 'expires' attribute in the HELD
locationResponse or the 'Valid-For' LuriType in DHCP. locationResponse.
A location URI can thus become invalid in three ways: By the A location URI can thus become invalid in three ways: By the
expiration of a validity interval in policy, by the removal of a expiration of a validity interval in policy, by the removal of a
policy document with a DELETE request, or by the expiry of the policy document with a DELETE request, or by the expiry of the
LCP-specified validity interval. The former two are temporary, LCP-specified validity interval. The former two are temporary,
since the policy URI can be used to update the policy. The latter since the policy URI can be used to update the policy. The latter
one is permanent, since the expiry causes the policy URI to be one is permanent, since the expiry causes the policy URI to be
invalidated as well. invalidated as well.
The Location Server MUST support policy documents in the common- The Location Server MUST support policy documents in the common-
policy format [RFC4745], as identified by the MIME media type of policy format [RFC4745], as identified by the MIME media type of
"application/auth-policy+xml". The common-policy format MUST be "application/auth-policy+xml". The common-policy format MUST be
provided as the default format in response to GET requests that do provided as the default format in response to GET requests that do
not include specific "Accept" headers, but content negotiation MAY be not include specific "Accept" headers, but content negotiation MAY be
used to allow for other formats. used to allow for other formats.
This usage of HTTP is generally compatible with the use of XCAP This usage of HTTP is generally compatible with the use of Extensible
[RFC4825] or WebDAV [RFC4918] to manage policy documents, but this Markup Language (XML) Configuration Access Protocol (XCAP) [RFC4825]
document does not define or require the use of these protocols. or Web Distributed Authoring and Versioning (WebDAV) [RFC4918] to
manage policy documents, but this document does not define or require
the use of these protocols.
3.2. Policy URI Allocation 3.2. Policy URI Allocation
A Location Server creates a policy URI for a specific location A Location Server creates a policy URI for a specific location
resource at the time that the location resource is created; that is, resource at the time that the location resource is created; that is,
a policy URI is created at the same time as the location URI that it a policy URI is created at the same time as the location URI that it
controls. The URI of the policy resource MUST be different from the controls. The URI of the policy resource MUST be different from the
location URI. location URI.
A policy URI is provided in response to location configuration A policy URI is provided in response to location configuration
requests. A policy URI MUST NOT be provided to an entity that is not requests. A policy URI MUST NOT be provided to an entity that is not
authorized to view or set policy. This document does not describe authorized to view or set policy. This document does not describe
how policy might be provided to entities other than for location how policy might be provided to entities other than for location
configuration, for example, in responses to dereferencing requests configuration, for example, in responses to dereferencing requests
[I-D.ietf-geopriv-deref-protocol] or requests from third parties [RFC6753] or requests from third parties [RFC6155].
[RFC6155].
Each location URI has either one policy URI or no policy URI. The Each location URI has either one policy URI or no policy URI. The
initial policy that is referenced by a policy URI MUST be identical initial policy that is referenced by a policy URI MUST be identical
to the policy that would be applied in the absence of a policy URI. to the policy that would be applied in the absence of a policy URI.
A client that does not support policy URIs can continue to use the A client that does not support policy URIs can continue to use the
location URI as they would have if no policy URI were provided. location URI as they would have if no policy URI were provided.
For DHCP and HELD, the client assumes that the default policy For HELD, the client assumes that the default policy grants any
grants any requester access to location information, as long as requester access to location information, as long as the request
the request possesses the location URI. To ensure that the possesses the location URI. To ensure that the authorization
authorization policy is less permissive, a client updates the policy is less permissive, a client updates the policy prior to
policy prior to distributing the location URI. distributing the location URI.
A Location Server chooses whether or not to provide a policy URI A Location Server chooses whether or not to provide a policy URI
based on local policy. A HELD-specific extension also allows a based on local policy. A HELD-specific extension also allows a
requester to specifically ask for a policy URI. requester to specifically ask for a policy URI.
A policy URI is effectively a shared secret between Location Server A policy URI is effectively a shared secret between the Location
and its clients. Knowledge of a policy URI is all that is required Server and its clients. Knowledge of a policy URI is all that is
to perform any operations allowed on the policy. Thus, a policy URI required to perform any operations allowed on the policy. Thus, a
should be constructed so that it is hard to predict and policy URI should be constructed so that it is hard to predict and
confidentiality-protected when transmitted (see Section 7). To avoid confidentiality protected when transmitted (see Section 7). To avoid
re-using these shared secrets, the Location Server MUST generate a reusing these shared secrets, the Location Server MUST generate a new
new policy URI whenever it generates a new location URI set. policy URI whenever it generates a new location URI set.
3.3. Policy Defaults 3.3. Policy Defaults
Client implementors should keep in mind that setting no policy (never Client implementors should keep in mind that setting no policy (never
performing an HTTP request to a policy URI) is very different from performing an HTTP request to a policy URI) is very different from
setting an empty policy (performing a PUT with the empty policy). By setting an empty policy (performing a PUT with the empty policy). By
"the empty policy", we mean a policy containing no rules, which would "the empty policy", we mean a policy containing no rules, which would
be represented by the following policy document: be represented by the following policy document:
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy"> <ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
</ruleset> </ruleset>
Figure 1: The empty policy Figure 1: The Empty Policy
If no policy is set, then the client tacitly accepts whatever policy If no policy is set, then the client tacitly accepts whatever policy
the server applies to location URIs, including a policy that provides the server applies to location URIs, including a policy that provides
location to anyone that makes a dereference request. If the empty location to anyone that makes a dereference request. If the empty
policy is set, then the opposite is true; the client directs the policy is set, then the opposite is true; the client directs the
server to never provide access to location. (Since there are no server to never provide access to location. (Since there are no
rules to allow access, and the policy language is default-deny.) rules to allow access and the policy language is default-deny.)
Implementors should thus consider carefully how to handle the case Thus, implementors should consider carefully how to handle the case
where the user provides no privacy policy input. On the one hand, an where the user provides no privacy policy input. On the one hand, an
implementation might treat this case as if the user had no privacy implementation might treat this case as if the user had no privacy
preferences, and thus set no policy. On the other hand, another preferences and, thus, set no policy. On the other hand, another
implementation might decide that if a user provides no positive implementation might decide that if a user provides no positive
authorization, then the empty policy should be installed. authorization, then the empty policy should be installed.
The same reasoning could also be applied to servers, with the caveat The same reasoning could also be applied to servers, with the caveat
that servers do not know whether a given HELD client supports the use that servers do not know whether a given HELD client supports the use
of policy URIs. A client that does not understand policy URIs will of policy URIs. A client that does not understand policy URIs will
not be able to set its own policy, and so the server must choose a not be able to set its own policy, so the server must choose a
default that is open enough that clients will find it useful. On the default that is open enough that clients will find it useful. On the
other hand, once a client indicates that it understands policy URIs other hand, once a client indicates that it understands policy URIs
(by including a "requestPolicyUri" element in its HELD request), the (by including a "requestPolicyUri" element in its HELD request), the
server may change its default policy to something more restrictive -- server may change its default policy to something more restrictive --
even the empty, default-deny policy -- since the client can specify even the empty, default-deny policy -- since the client can specify
something more permissive if desired. something more permissive if desired.
4. Location Configuration Extensions 4. Location Configuration Extensions
Location configuration protocols can provision hosts with location Location configuration protocols can provision hosts with location
URIs that refer to the host's location. If the target host is to URIs that refer to the host's location. If the target host is to
control policy on these URIs, it needs a way to access the policy control policy on these URIs, it needs a way to access the policy
that the Location Server uses to guide how it serves location URIs. that the Location Server uses to guide how it serves location URIs.
This section defines extensions to LCPs to carry policy URIs that the This section defines extensions to LCPs to carry policy URIs that the
target can use to control access to location resources. target can use to control access to location resources.
4.1. HELD 4.1. HELD
The HELD protocol [RFC5985] defines a "locationUriSet" element, which The HELD protocol [RFC5985] defines a "locationUriSet" element, which
contain a set of one or more location URIs that reference the same contains a set of one or more location URIs that reference the same
resource and share a common access control policy. The schema in resource and share a common access control policy. The schema in
Figure 2 defines two extension elements for HELD: an empty Figure 2 defines two extension elements for HELD: an empty
"requestPolicyUri" element that is added to a location request to "requestPolicyUri" element that is added to a location request to
indicate that a Device desires that a policy URI be allocated; and a indicate that a Device desires that a policy URI be allocated and a
"policyUri" element that is included in the location response. "policyUri" element that is included in the location response.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xs:schema <xs:schema
targetNamespace="urn:ietf:params:xml:ns:geopriv:held:policy" targetNamespace="urn:ietf:params:xml:ns:geopriv:held:policy"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:hp="urn:ietf:params:xml:ns:geopriv:held:policy" xmlns:hp="urn:ietf:params:xml:ns:geopriv:held:policy"
elementFormDefault="qualified" attributeFormDefault="unqualified"> elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:element name="requestPolicyUri"> <xs:element name="requestPolicyUri">
<xs:complexType name="empty"/> <xs:complexType name="empty"/>
</xs:element> </xs:element>
<xs:element name="policyUri" type="xs:anyURI"/> <xs:element name="policyUri" type="xs:anyURI"/>
</xs:schema> </xs:schema>
Figure 2: XML Schema for the policy URI extension Figure 2: XML Schema for the Policy URI Extension
The URI carried in a "policyUri" element refers to the common access The URI carried in a "policyUri" element refers to the common access
control policy for location URIs in the location response. The URI control policy for location URIs in the location response. The URI
MUST be a policy URI as described in Section 3. A policy URI MUST MUST be a policy URI as described in Section 3. A policy URI MUST
use the "http:" or "https:" scheme, and the Location Server MUST use the "http:" or "https:" scheme, and the Location Server MUST
support the specified operations on the URI. support the specified operations on the URI.
A HELD request MAY contain an explicit request for a policy URI. The A HELD request MAY contain an explicit request for a policy URI. The
presence of the "requestPolicyUri" element in a location request presence of the "requestPolicyUri" element in a location request
indicates that a policy URI is desired. indicates that a policy URI is desired.
4.2. DHCP 4.2. Client Processing
The DHCP location by reference option
[I-D.ietf-geopriv-dhcp-lbyr-uri-option] provides location URIs in
sub-options called LuriElements. This document defines a new
LuriElement type for policy URIs.
LuriType=TBD Policy-URI - This is a policy URI that refers to the
access control policy for the location URIs.
[NOTE TO IANA/RFC-EDITOR: Please replace TBD above with the assigned
LuriType value and remove this note]
A Policy-URI LuriElement uses a UTF-8 character encoding.
A Policy-URI LuriElement identifies the policy resource for all
location URIs included in the location URI option. The URI MUST be a
policy URI as described in Section 3: It MUST use either the "http:"
or "https:" scheme, and the Location Server MUST support the
specified operations on the URI.
4.3. Client Processing
It is possible that this document will be updated to allow the use of It is possible that this document will be updated to allow the use of
policy URIs that use protocols other than the HTTP-based protocol policy URIs that use protocols other than the HTTP-based protocol
described above. To ensure that they fail safely when presented with described above. To ensure that they fail safely when presented with
such a URI, clients implementing this specification MUST verify that such a URI, clients implementing this specification MUST verify that
a policy URI received from either HELD or DHCP uses either the a policy URI received from HELD uses either the "http:" or "https:"
"http:" or "https:" scheme. If the URI does not match those schemes, scheme. If the URI does not match those schemes, then the client
then the client MUST discard the URI and behave as if no policy URI MUST discard the URI and behave as if no policy URI was provided.
was provided.
5. Examples 5. Examples
In this section, we provide some brief illustrations of how policy In this section, we provide some brief illustrations of how policy
URIs are delivered to target hosts and used by those hosts to manage URIs are delivered to target hosts and used by those hosts to manage
policy. policy.
5.1. HELD
A HELD request that explicitly requests the creation of a policy URI A HELD request that explicitly requests the creation of a policy URI
has the following form: has the following form:
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"> <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationType exact="true">locationURI</locationType> <locationType exact="true">locationURI</locationType>
<requestPolicyUri <requestPolicyUri
xmlns="urn:ietf:params:xml:ns:geopriv:held:policy"/> xmlns="urn:ietf:params:xml:ns:geopriv:held:policy"/>
</locationRequest> </locationRequest>
A HELD response providing a single "locationUriSet", containing two A HELD response providing a single "locationUriSet", containing two
URIs under a common policy, would have the following form: URIs under a common policy, would have the following form:
<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held"> <locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationUriSet expires="2011-01-01T13:00:00.0Z"> <locationUriSet expires="2011-01-01T13:00:00.0Z">
<locationURI> <locationURI>
https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
</locationURI> </locationURI>
skipping to change at page 10, line 24 skipping to change at page 10, line 5
</locationURI> </locationURI>
<locationURI> <locationURI>
sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com: sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com:
</locationURI> </locationURI>
</locationUriSet> </locationUriSet>
<policyUri xmlns="urn:ietf:params:xml:ns:geopriv:held:policy"> <policyUri xmlns="urn:ietf:params:xml:ns:geopriv:held:policy">
https://ls.example.com:9768/policy/357lp6f64prlbvhl5nk3b https://ls.example.com:9768/policy/357lp6f64prlbvhl5nk3b
</policyUri> </policyUri>
</locationResponse> </locationResponse>
5.2. DHCP 5.1. Basic Access Control Policy
A DHCP option providing one of the location URIs and the
corresponding policy URI from the previous example would have the
following form:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | 110 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 0 | 1 | 49 | 'h' |
+---------------+---------------+---------------+---------------|
| 't' | 't' | 'p' | 's' |
+---------------+---------------+---------------+---------------|
| ':' | '/' | '/' | 'l' |
+---------------+---------------+---------------+---------------|
| 's' | '.' | ... |
+---------------+---------------+---------------+---------------|
| TBD | 56 | 'h' 't' |
+---------------+---------------+---------------+---------------|
| 't' | 'p' | 's' | ':' |
+---------------+---------------+---------------+---------------|
| '/' | '/' | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[NOTE TO IANA/RFC-EDITOR: Please replace TBD above with the assigned
LuriType value and remove this note]
5.3. Basic Access Control Policy
Consider a client that gets the policy URI Consider a client that gets the policy URI <https://
<https://ls.example.com:9768/policy/357lp6f64prlbvhl5nk3b>, as in the ls.example.com:9768/policy/357lp6f64prlbvhl5nk3b>, as in the above
above LCP example. The first thing this allows the client to do is LCP example. The first thing this allows the client to do is inspect
inspect the default policy that the LS has assigned to this URI: the default policy that the LS has assigned to this URI:
GET /policy/357lp6f64prlbvhl5nk3b HTTP/1.1 GET /policy/357lp6f64prlbvhl5nk3b HTTP/1.1
Host: ls.example.com:9768 Host: ls.example.com:9768
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-type: application/auth-policy+xml Content-type: application/auth-policy+xml
Content-length: 388 Content-length: 388
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy" <ruleset xmlns="urn:ietf:params:xml:ns:common-policy"
skipping to change at page 12, line 11 skipping to change at page 11, line 11
policy, and prefers for example, to only provide location to one policy, and prefers for example, to only provide location to one
friend, at a city level of granularity, then the client can install friend, at a city level of granularity, then the client can install
this policy on the Location Server: this policy on the Location Server:
PUT /policy/357lp6f64prlbvhl5nk3b HTTP/1.1 PUT /policy/357lp6f64prlbvhl5nk3b HTTP/1.1
Host: ls.example.com:9768 Host: ls.example.com:9768
Content-type: application/auth-policy+xml Content-type: application/auth-policy+xml
Content-length: 462 Content-length: 462
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy"> <ruleset xmlns="urn:ietf:params:xml:ns:common-policy"
xmlns:gp="urn:ietf:params:xml:ns:geolocation-policy"
xmlns:lp="urn:ietf:params:xml:ns:basic-location-profiles">
<rule id="f3g44r1"> <rule id="f3g44r1">
<conditions> <conditions>
<identity> <identity>
<one id="sip:friend@example.com"/> <one id="sip:friend@example.com"/>
</identity> </identity>
<validity> <validity>
<until>2011-01-01T13:00:00.0Z</until> <until>2011-01-01T13:00:00.0Z</until>
</validity> </validity>
</conditions> </conditions>
<actions/> <actions/>
skipping to change at page 13, line 15 skipping to change at page 12, line 19
6.1. URN Sub-Namespace Registration for 6.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held:policy urn:ietf:params:xml:ns:geopriv:held:policy
This section registers a new XML namespace, This section registers a new XML namespace,
"urn:ietf:params:xml:ns:geopriv:held:policy", per the guidelines in "urn:ietf:params:xml:ns:geopriv:held:policy", per the guidelines in
[RFC3688]. [RFC3688].
URI: urn:ietf:params:xml:ns:geopriv:held:policy URI: urn:ietf:params:xml:ns:geopriv:held:policy
Registrant Contact: IETF, GEOPRIV working group, Registrant Contact: IETF, GEOPRIV working group,
(geopriv@ietf.org), Richard Barnes (rbarnes@bbn.com). (geopriv@ietf.org), Richard Barnes (rlb@ipv.sx).
XML: XML:
BEGIN BEGIN
<?xml version="1.0"?> <?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head> <head>
<title>HELD Policy URI Extension</title> <title>HELD Policy URI Extension</title>
</head> </head>
<body> <body>
<h1>Namespace for HELD Policy URI Extension</h1> <h1>Namespace for HELD Policy URI Extension</h1>
<h2>urn:ietf:params:xml:ns:geopriv:held:policy</h2> <h2>urn:ietf:params:xml:ns:geopriv:held:policy</h2>
[NOTE TO IANA/RFC-EDITOR: Please replace XXXX <p>See <a href="http://www.rfc-editor.org/rfc/rfc7199.txt">
with the RFC number for this specification.] RFC 7199</a>.</p>
<p>See RFCXXXX</p> </body>
</body> </html>
</html> END
END
6.2. XML Schema Registration 6.2. XML Schema Registration
This section registers an XML schema as per the guidelines in This section registers an XML schema as per the guidelines in
[RFC3688]. [RFC3688].
URI: urn:ietf:params:xml:schema:geopriv:held:policy URI: urn:ietf:params:xml:schema:geopriv:held:policy
Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org),
Richard Barnes (rbarnes@bbn.com) Richard Barnes (rlb@ipv.sx)
Schema: The XML for this schema can be found in Section Section 4.1.
6.3. DHCP LuriType Registration
IANA is requested to add a value to the LuriTypes registry, as
follows:
+------------+----------------------------------------+-----------+
| LuriType | Name | Reference |
+------------+----------------------------------------+-----------+
| TBD* | Policy-URI | RFC XXXX**|
+------------+----------------------------------------+-----------+
* TBD is to be replaced with the assigned value Schema: The XML for this schema can be found in Section 4.1.
** RFC XXXX is to be replaced with this document's RFC number.
7. Security Considerations 7. Security Considerations
There are two main classes of risks associated with access control There are two main classes of risks associated with access control
policy management: The risk of unauthorized grants or denial of policy management: The risk of unauthorized grants or denial of
access to the protected resource via manipulation of the policy access to the protected resource via manipulation of the policy
management process, and the risk of disclosure of policy information management process, and the risk of disclosure of policy information
itself. itself.
Protecting the policy management process from manipulation entails Protecting the policy management process from manipulation entails
two primary requirements: First, the policy URI has to be faithfully two primary requirements. First, the policy URI has to be faithfully
and confidentially transmitted to the client, and second, the policy and confidentially transmitted to the client; second, the policy
document has to be faithfully and confidentially transmitted to the document has to be faithfully and confidentially transmitted to the
Location Server. The mechanism also needs to ensure that only Location Server. The mechanism also needs to ensure that only
authorized entities are able to acquire or alter policy. authorized entities are able to acquire or alter policy.
7.1. Integrity and Confidentiality for Authorization Policy Data 7.1. Integrity and Confidentiality for Authorization Policy Data
Each LCP ensures integrity and confidentiality through different Each LCP ensures integrity and confidentiality through different
means (see [RFC5985] and [I-D.ietf-geopriv-dhcp-lbyr-uri-option]). means (see [RFC5985]). These measures ensure that a policy URI is
These measures ensure that a policy URI is conveyed to the client conveyed to the client without modification or interception.
without modification or interception.
In general, the requirements for transport-layer security on policy In general, the requirements for TLS on policy transactions are the
transactions are the same as for the dereference transactions they same as for the dereference transactions they set policy for
set policy for [I-D.ietf-geopriv-deref-protocol]. To protect the [RFC6753]. To protect the integrity and confidentiality of policy
integrity and confidentiality of policy data during management, the data during management, the Location Server SHOULD provide policy
Location Server SHOULD provide policy URIs with the "https:" scheme URIs with the "https:" scheme and require the use of HTTP over TLS
and require the use of HTTP over TLS [RFC2818]. The cipher suites [RFC2818]. The cipher suites required by TLS [RFC5246] provide both
required by TLS [RFC5246] provide both integrity protection and integrity protection and confidentiality. If other means of
confidentiality. If other means of protection are available, an protection are available, an "http:" URI MAY be used, but location
"http:" URI MAY be used, but location servers SHOULD reject PUT and servers SHOULD reject PUT and DELETE requests for policy URIs that
DELETE requests for policy URIs that use the "http:" URI scheme. use the "http:" URI scheme.
7.2. Access Control for Authorization Policy 7.2. Access Control for Authorization Policy
Access control for the policy resource is based on knowledge of its Access control for the policy resource is based on knowledge of its
URI. The URI of a policy resource operates under the same URI. The URI of a policy resource operates under the same
constraints as a possession model location URI [RFC5808] and is constraints as a possession model location URI [RFC5808] and is
subject to the same constraints: subject to the same constraints:
o Knowledge of a policy URI MUST be restricted to authorized Rule o Knowledge of a policy URI MUST be restricted to authorized Rule
Makers. Confidentiality and integrity protections SHOULD be used Makers. Confidentiality and integrity protections SHOULD be used
when policy URIs are conveyed in a location configuration when policy URIs are conveyed in a location configuration protocol
protocol, and in the requests that are used to inspect, change or and in the requests that are used to inspect, change, or delete
delete the policy resource. Note that in some protocols (such as the policy resource. Note that in some protocols (such as DHCP),
DHCP), these protections may arise from limiting the use of the these protections may arise from limiting the use of the protocol
protocol to the local network, thus relying on lower-layer to the local network thus relying on lower-layer security
security mechanisms. When neither application-layer or network- mechanisms. When neither application-layer nor network-layer
layer security is provided, location servers MUST reject requests security is provided, location servers MUST reject requests using
using the PUT and DELETE methods. the PUT and DELETE methods.
o The Location Server MUST ensure that it is not practical for an o The Location Server MUST ensure that it is not practical for an
attacker to guess a policy URI value, even if the attacker has attacker to guess a policy URI value, even if the attacker has
requested many policy URIs from the Location Server over time. requested many policy URIs from the Location Server over time.
The policy URI MUST NOT be derived solely from information that The policy URI MUST NOT be derived solely from information that
might be public, including the Target identity or any location might be public, including the Target identity or any location
URI. The addition of 128 bits or more of random entropy is URI. The addition of 128 bits or more of random entropy is
RECOMMENDED to make it infeasible for a third party to guess a RECOMMENDED to make it infeasible for a third party to guess a
policy URI. policy URI.
o Servers SHOULD apply rate limits in order to make brute-force o Servers SHOULD apply rate limits in order to make brute-force
guessing infeasible. If a server allocates location URIs that guessing infeasible. If a server allocates location URIs that
include N bits of entropy with a lifetime of T seconds, then the include N bits of entropy with a lifetime of T seconds, then the
server should limit clients to (2^(N/2))/T queries per second. server should limit clients to (2^(N/2))/T queries per second.
(The lifetime T of a location URI set is specified by the (The lifetime T of a location URI set is specified by the
"expires" attribute in HELD or the "Valid-For" LuriType in DHCP.) "expires" attribute in HELD.)
One possible algorithm for generating appropriately unpredictable One possible algorithm for generating appropriately unpredictable
policy URIs for a location URI set is described in Appendix A. policy URIs for a location URI set is described in Appendix A.
The goal of the above recommendation on rate limiting is to bound the The goal of the above recommendation on rate limiting is to bound the
probability that an attacker can guess a policy URI during its probability that an attacker can guess a policy URI during its
lifetime. If an attacker is limited to (2^(N/2))/T queries per lifetime. If an attacker is limited to (2^(N/2))/T queries per
second, then he will be able to make at most 2^(N/2) guesses over the second, then he will be able to make at most 2^(N/2) guesses over the
lifetime of the URI. Assuming these guesses are distinct, the lifetime of the URI. Assuming these guesses are distinct, the
probability of the attacker guessing any given URI is probability of the attacker guessing any given URI is
skipping to change at page 16, line 41 skipping to change at page 15, line 27
lists places additional constraints on the construction of location lists places additional constraints on the construction of location
URIs. URIs.
If multiple Targets share a location URI, an unauthorized location If multiple Targets share a location URI, an unauthorized location
recipient that acquires location URIs for the Targets can determine recipient that acquires location URIs for the Targets can determine
that the Targets are at the same location by comparing location URIs. that the Targets are at the same location by comparing location URIs.
With shared policy URIs, Targets are able to see and modify With shared policy URIs, Targets are able to see and modify
authorization policy for other Targets. authorization policy for other Targets.
To allow for the creation of Target-specific authorization policies To allow for the creation of Target-specific authorization policies
that are adequately privacy-protected, each location URI and policy that are adequately privacy protected, each location URI and policy
URI that is issued to a different Target MUST be different from other URI that is issued to a different Target MUST be different from other
location URIs and policy URIs. That is, two clients MUST NOT receive location URIs and policy URIs. That is, two clients MUST NOT receive
the same location URI or the same policy URI. the same location URI or the same policy URI.
In some deployments, it is not always apparent to a LCP server that In some deployments, it is not always apparent to an LCP server that
two clients are different. In particular, where a middlebox two clients are different. In particular, where a middlebox
[RFC3234] exists two or more clients might appear as a single client. [RFC3234] exists, two or more clients might appear as a single
An example of a deployment scenario of this nature is described in client. An example of a deployment scenario of this nature is
[RFC5687]. An LCP server MUST create a different location URI and described in [RFC5687]. An LCP server MUST create a different
policy URI for every request, unless the requests can be reliably location URI and policy URI for every request, unless the requests
identified as being from the same client. can be reliably identified as being from the same client.
7.4. Policy URI Handling 7.4. Policy URI Handling
Although servers may choose to implement access controls on policy Although servers may choose to implement access controls on policy
URIs, by default, any holder of a policy URI is authorized to access URIs, by default, any holder of a policy URI is authorized to access
and modify the referenced policy document, and thus, to control and modify the referenced policy document and, thus, to control
access to the associated location resources. Because policy URIs access to the associated location resources. Because policy URIs
function as shared secrets, clients SHOULD protect them as they would function as shared secrets, clients SHOULD protect them as they would
passwords. For example, policy URIs SHOULD NOT be transmitted to passwords. For example, policy URIs SHOULD NOT be transmitted to
other hosts or stored in plaintext. other hosts or stored in plaintext.
It should be noted that one of the benefits of the policy URI It should be noted that one of the benefits of the policy URI
construct is that in most cases, there is not a policy URI to leave construct is that in most cases, there is not a policy URI to leave
the client device to which it is provided. Without policy URIs, the client device to which it is provided. Without policy URIs,
location URIs are subject to a default policy set unilaterally by the location URIs are subject to a default policy set unilaterally by the
server, and location URIs must be conveyed to another entity in order server, and location URIs must be conveyed to another entity in order
skipping to change at page 17, line 32 skipping to change at page 16, line 21
access controls, and the shared secret used to authenticate the access controls, and the shared secret used to authenticate the
client (i.e., the policy URI) can simply be stored on the client and client (i.e., the policy URI) can simply be stored on the client and
used to set the access control policy on the location URI. So while used to set the access control policy on the location URI. So while
policy URIs do use a default model of authorization by possession, policy URIs do use a default model of authorization by possession,
they reduce the overall risk to location privacy posed by leakage of they reduce the overall risk to location privacy posed by leakage of
shared secret URIs. shared secret URIs.
8. Acknowledgements 8. Acknowledgements
Thanks to Mary Barnes and Alissa Cooper for providing critical Thanks to Mary Barnes and Alissa Cooper for providing critical
commentary and input on the ideas described in this document, and to commentary and input on the ideas described in this document. Also,
Ted Hardie and Adam Roach for helping clarify the relationships thanks to Ted Hardie and Adam Roach for helping clarify the
between policy URIs, policy documents, and location resources. relationships between policy URIs, policy documents, and location
Thanks to Stephen Farrell for a helpful discussion on security and resources. Thanks to Stephen Farrell for a helpful discussion on
privacy challenges. security and privacy challenges.
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-geopriv-dhcp-lbyr-uri-option]
Polk, J., "Dynamic Host Configuration Protocol (DHCP) IPv4
and IPv6 Option for a Location Uniform Resource Identifier
(URI)", draft-ietf-geopriv-dhcp-lbyr-uri-option-15 (work
in progress), May 2012.
[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.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication", Authentication: Basic and Digest Access Authentication",
skipping to change at page 18, line 27 skipping to change at page 17, line 34
January 2004. January 2004.
[RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J.,
Polk, J., and J. Rosenberg, "Common Policy: A Document Polk, J., and J. Rosenberg, "Common Policy: A Document
Format for Expressing Privacy Preferences", RFC 4745, Format for Expressing Privacy Preferences", RFC 4745,
February 2007. February 2007.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC
RFC 5985, September 2010. 5985, September 2010.
9.2. Informative References 9.2. Informative References
[I-D.ietf-geopriv-deref-protocol]
Winterbottom, J., Tschofenig, H., Schulzrinne, H., and M.
Thomson, "A Location Dereferencing Protocol Using HELD",
draft-ietf-geopriv-deref-protocol-07 (work in progress),
July 2012.
[I-D.ietf-geopriv-policy]
Schulzrinne, H., Tschofenig, H., Cuellar, J., Polk, J.,
Morris, J., and M. Thomson, "Geolocation Policy: A
Document Format for Expressing Privacy Preferences for
Location Information", draft-ietf-geopriv-policy-27 (work
in progress), August 2012.
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
Issues", RFC 3234, February 2002. Issues", RFC 3234, February 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.
[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.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006. Encodings", RFC 4648, October 2006.
[RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)", RFC 4825, May 2007. Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed [RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed
Authoring and Versioning (WebDAV)", RFC 4918, June 2007. Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
[RFC5606] Peterson, J., Hardie, T., and J. Morris, "Implications of [RFC5606] Peterson, J., Hardie, T., and J. Morris, "Implications of
'retransmission-allowed' for SIP Location Conveyance", 'retransmission-allowed' for SIP Location Conveyance", RFC
RFC 5606, August 2009. 5606, August 2009.
[RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 [RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
Location Configuration Protocol: Problem Statement and Location Configuration Protocol: Problem Statement and
Requirements", RFC 5687, March 2010. Requirements", RFC 5687, March 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.
[RFC6225] Polk, J., Linsner, M., Thomson, M., and B. Aboba, "Dynamic [RFC6225] Polk, J., Linsner, M., Thomson, M., and B. Aboba, "Dynamic
Host Configuration Protocol Options for Coordinate-Based Host Configuration Protocol Options for Coordinate-Based
Location Configuration Information", RFC 6225, July 2011. Location Configuration Information", RFC 6225, July 2011.
[RFC6753] Winterbottom, J., Tschofenig, H., Schulzrinne, H., and M.
Thomson, "A Location Dereference Protocol Using HTTP-
Enabled Location Delivery (HELD)", RFC 6753, October 2012.
[RFC6772] Schulzrinne, H., Tschofenig, H., Cuellar, J., Polk, J.,
Morris, J., and M. Thomson, "Geolocation Policy: A
Document Format for Expressing Privacy Preferences for
Location Information", RFC 6772, January 2013.
Appendix A. Example Policy URI Generation Algorithm Appendix A. Example Policy URI Generation Algorithm
One possible algorithm for generating appropriately unpredictable One possible algorithm for generating appropriately unpredictable
policy URIs for a location URI set is as follows: policy URIs for a location URI set is as follows:
1. Choose parameters: 1. Choose parameters:
* A cryptographic hash function H, e.g., SHA256 * A cryptographic hash function H, e.g., SHA256
* A number N of bits of entropy to add, such that N is no more * A number N of bits of entropy to add, such that N is no more
skipping to change at page 20, line 14 skipping to change at page 20, line 8
location URI set (e.g., the XML from a HELD response) location URI set (e.g., the XML from a HELD response)
3. Form the policy URI by appending the base64url-encoded form 3. Form the policy URI by appending the base64url-encoded form
of the hash [RFC4648] to one of the location URIs, e.g., as a of the hash [RFC4648] to one of the location URIs, e.g., as a
query parameter: "http://example.com/loc/ query parameter: "http://example.com/loc/
foo?policy=j3WTGUb3smxcZA6eKIqmqdV3ALE" foo?policy=j3WTGUb3smxcZA6eKIqmqdV3ALE"
Authors' Addresses Authors' Addresses
Richard Barnes Richard Barnes
BBN Technologies Mozilla
9861 Broken Land Parkway 331 E. Evelyn Ave.
Columbia, MD 21046 Mountain View, CA 94041
US US
Phone: +1 410 290 6169 EMail: rlb@ipv.sx
Email: rbarnes@bbn.com
Martin Thomson Martin Thomson
Microsoft Mozilla
3210 Porter Drive Suite 300
Palo Alto, CA 94304 331 E Evelyn Street
Mountain View, CA 94041
US US
Phone: +1 650-353-1925 EMail: martin.thomson@gmail.com
Email: martin.thomson@outlook.com
James Winterbottom James Winterbottom
Andrew Corporation Unaffiliated
Andrew Building (39)
Wollongong University Campus
Northfields Avenue
Wollongong, NSW 2522
AU AU
Phone: +61 242 212938 EMail: a.james.winterbottom@gmail.com
Email: james.winterbottom@andrew.com
Hannes Tschofenig Hannes Tschofenig
Nokia Siemens Networks Hall in Tirol 6060
Linnoitustie 6 Austria
Espoo 02600
Finland
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
 End of changes. 72 change blocks. 
294 lines changed or deleted 200 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/