draft-ietf-geopriv-policy-uri-00.txt   draft-ietf-geopriv-policy-uri-01.txt 
GEOPRIV R. Barnes GEOPRIV R. Barnes
Internet-Draft BBN Technologies Internet-Draft BBN Technologies
Intended status: Informational M. Thomson Intended status: Informational M. Thomson
Expires: July 16, 2011 J. Winterbottom Expires: December 22, 2011 J. Winterbottom
Andrew Corporation Andrew Corporation
H. Tschofenig H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
January 12, 2011 June 20, 2011
Location Configuration Extensions for Policy Management Location Configuration Extensions for Policy Management
draft-ietf-geopriv-policy-uri-00 draft-ietf-geopriv-policy-uri-01.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.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 16, 2011. This Internet-Draft will expire on December 22, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 16 skipping to change at page 2, line 16
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 . . . . . . . . . . . . . . . . . . . . . 4 3.1. Policy URI Usage . . . . . . . . . . . . . . . . . . . . . 5
3.2. Policy URI Allocation . . . . . . . . . . . . . . . . . . 5 3.2. Policy URI Allocation . . . . . . . . . . . . . . . . . . 6
4. Location Configuration Extensions . . . . . . . . . . . . . . 6 4. Location Configuration Extensions . . . . . . . . . . . . . . 7
4.1. HELD . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. HELD . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.3. Client Processing . . . . . . . . . . . . . . . . . . . . 8
5.1. HELD . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. HELD . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.3. Basic access control policy . . . . . . . . . . . . . . . 9 5.2. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 5.3. Basic Access Control Policy . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7.1. URN Sub-Namespace Registration for 7.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held:policy . . . . . . . . 11 urn:ietf:params:xml:ns:geopriv:held:policy . . . . . . . . 12
7.2. XML Schema Registration . . . . . . . . . . . . . . . . . 11 7.2. XML Schema Registration . . . . . . . . . . . . . . . . . 12
7.3. DHCP LuriType Registration . . . . . . . . . . . . . . . . 12 7.3. DHCP LuriType Registration . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8.1. Integrity and Confidentiality for Authorization Policy 8.1. Integrity and Confidentiality for Authorization Policy
Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.2. Access Control for Authorization Policy . . . . . . . . . 13 8.2. Access Control for Authorization Policy . . . . . . . . . 14
8.3. Location URI Allocation . . . . . . . . . . . . . . . . . 13 8.3. Location URI Allocation . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
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
skipping to change at page 3, line 35 skipping to change at page 3, line 35
(e.g., SIP through untrusted proxies [RFC5606]). If the target host (e.g., SIP through untrusted proxies [RFC5606]). If the target host
is mobile, an application provider can use a single reference to is mobile, an application provider can use a single reference to
obtain the location of the host multiple times, saving bandwidth to obtain the location of the host multiple times, saving bandwidth to
the host. For some configuration protocols, the location object the host. For some configuration protocols, the location object
referenced by a location URI provides a much more expressive syntax referenced by a location URI provides a much more expressive syntax
for location values than the configuration protocol itself (e.g., for location values than the configuration protocol itself (e.g.,
DHCP geodetic location [I-D.ietf-geopriv-rfc3825bis] versus GML in a DHCP geodetic location [I-D.ietf-geopriv-rfc3825bis] versus GML in a
PIDF-LO [RFC4119]). 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 the Device (the client their flexibility, in that they do not provide hosts (the clients in
in an LCP) with a way to inform the Location Server with policy for an LCP) with a way to inform the Location Server with policy for how
how his location information should be handled. This document his location information should be handled. This document addresses
addresses this gap by defining a simple mechanism for referring to this gap by defining a simple mechanism for referring to and
and manipulating policy, and by extending current LCPs to carry manipulating policy, and by extending current LCPs to carry policy
policy references. Using the mechanisms defined in this document, an references. Using the mechanisms defined in this document, an LCP
LCP server (acting for the Location Server) can inform a client as to server (acting for the Location Server) can inform a host as to which
which policy document controls a given location resource, and the LCP policy document controls a given location resource, and the host (in
client (in its Rule Maker role) can inspect this document and modify its Rule Maker role) can inspect this document and modify it as
it as necessary. necessary.
In the following figure, adapted from RFC 5808, this document extends
the Location Configuration Protocols (1) and defines a simple
protocol for policy exchange (4).
+---------+---------+ Location +-----------+
| | | Dereference | Location |
| LIS/LS +---------------+ Recipient |
| | | Protocol | |
+----+----+----+----+ (3) +-----+-----+
| | |
| | |
Policy| |Location |Location
Exchange| |Configuration |Conveyance
(4)| |Protocol |Protocol
| |(1) |(2)
| | |
+------+----+----+----+ |
| Rule | Target/ | |
| Maker | Host +---------------------+
| | |
+-----------+---------+
The remainder of this document is structured as follows: After The remainder of this document is structured as follows: After
introducing a few relevant terms, we define policy URIs as a channel introducing a few relevant terms, we define policy URIs as a channel
for referencing, inspecting, and updating policy documents. We then for referencing, inspecting, and updating policy documents. We then
define extensions to the HELD protocol and the DHCP option for define extensions to the HELD protocol and the DHCP option for
location by reference to allow these protocols to carry policy URIs. location by reference to allow these protocols to carry policy URIs.
Examples are given that demonstrate how policy URIs are carried in Examples are given that demonstrate how policy URIs are carried in
these protocols and how they can be used by clients. these protocols and how they 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] URI that identifies a policy A policy URI is an HTTP [RFC2616] or HTTPS [RFC2818]URI that
resource that contains the authorization policy for a linked location identifies a policy resource that contains the authorization policy
resource. Access to the location resource is governed by the for a linked location resource. Access to the location resource is
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 [I-D.ietf-geopriv-policy]).
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
skipping to change at page 5, line 8 skipping to change at page 5, line 36
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 the request is valid and authorized, then the Location Server
replaces the current policy with the policy provided in the request. replaces 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 and terminate access to the protected referenced policy document. If the request is authorized, then the
resource. If the request is authorized, then the Location Server Location Server MUST delete the policy referenced by the URI and
deletes the policy referenced by the URI and disallows any further disallow access to the location URIs it governs until a new policy
access to the location resource it governs. document has been put in place via a PUT request.
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
policy URIs once the corresponding location URI set has expired.
This expiry time is specified by the 'expires' attribute in the HELD
locationResponse or the 'Valid-For' LuriType in DHCP.
A location URI can thus become invalid in three ways: By the
expiration of a validity interval in policy, by the removal of a
policy document with a DELETE request, or by the expiry of the
LCP-specified validity interval. The former two are temporary,
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
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 XCAP
[RFC4825] or WebDAV [RFC4918] to manage policy documents, but this [RFC4825] or WebDAV [RFC4918] to manage policy documents, but this
skipping to change at page 5, line 36 skipping to change at page 6, line 29
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 to the controls. The URI of the policy resource MUST be different to 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. in responses to dereferencing requests configuration. In responses to dereferencing requests
[I-D.ietf-geopriv-deref-protocol] or requests from third parties [I-D.ietf-geopriv-deref-protocol] or requests from third parties
[I-D.ietf-geopriv-held-identity-extensions]. [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 DHCP and HELD, the client assumes that the default policy
grants any requester access to location information, as long as grants any requester access to location information, as long as
the request possesses the location URI. To ensure that the the request possesses the location URI. To ensure that the
authorization policy is less permissive, a client updates the authorization policy is less permissive, a client updates the
policy prior to distributing the location URI. policy prior to 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 a shared secret between Location Server and its A policy URI is effectively a shared secret between Location Server
clients. Knowledge of a policy URI is all that is required to and its clients. Knowledge of a policy URI is all that is required
perform any operations allowed on the policy. Thus, a policy URI is to perform any operations allowed on the policy. Thus, a policy URI
constructed so that it is hard to predict (see Section 8). should be constructed so that it is hard to predict and
confidentiality-protected when transmitted (see Section 8). To avoid
re-using these shared secrets, the Location Server MUST generate a
new policy URI whenever it generates a new location URI set.
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.
skipping to change at page 7, line 33 skipping to change at page 8, line 30
LuriType value and remove this note] LuriType value and remove this note]
A Policy-URI LuriElement uses a UTF-8 character encoding. A Policy-URI LuriElement uses a UTF-8 character encoding.
A Policy-URI LuriElement identifies the policy resource for all A Policy-URI LuriElement identifies the policy resource for all
location URIs included in the location URI option. The URI MUST be a 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:" policy URI as described in Section 3: It MUST use either the "http:"
or "https:" scheme, and the Location Server MUST support the or "https:" scheme, and the Location Server MUST support the
specified operations on the URI. specified operations on the URI.
4.3. Client Processing
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
described above. To ensure that they fail safely when presented with
such a URI, clients implementing this specification MUST verify that
a policy URI received from either HELD or DHCP uses either the
"http:" or "https:" scheme. If the URI does not match those schemes,
then the client MUST discard the URI and behave as if no policy URI
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 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:
skipping to change at page 9, line 5 skipping to change at page 10, line 8
| TBD | 56 | 'h' 't' | | TBD | 56 | 'h' 't' |
+---------------+---------------+---------------+---------------| +---------------+---------------+---------------+---------------|
| 't' | 'p' | 's' | ':' | | 't' | 'p' | 's' | ':' |
+---------------+---------------+---------------+---------------| +---------------+---------------+---------------+---------------|
| '/' | '/' | ... | | '/' | '/' | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[NOTE TO IANA/RFC-EDITOR: Please replace TBD above with the assigned [NOTE TO IANA/RFC-EDITOR: Please replace TBD above with the assigned
LuriType value and remove this note] LuriType value and remove this note]
5.3. Basic access control policy 5.3. Basic Access Control Policy
Consider a user that gets the policy URI Consider a client that gets the policy URI
<https://ls.example.com:9768/policy/357lp6f64prlbvhl5nk3b>, as in the <https://ls.example.com:9768/policy/357lp6f64prlbvhl5nk3b>, as in the
above LCP example. The first thing this allows the user to do is above LCP example. The first thing this allows the client to do is
inspect the default policy that the LS has assigned to this URI: inspect 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"?>
skipping to change at page 9, line 42 skipping to change at page 10, line 45
false false
</gp:set-retransmission-allowed> </gp:set-retransmission-allowed>
<gp:set-retention-expiry>0</gp:set-retention-expiry> <gp:set-retention-expiry>0</gp:set-retention-expiry>
</transformations> </transformations>
</rule> </rule>
</ruleset> </ruleset>
This policy allows any requester to obtain location information, as This policy allows any requester to obtain location information, as
long as they know the location URI. If the user disagrees with this long as they know the location URI. If the user disagrees with this
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 he can install this friend, at a city level of granularity, then the client can install
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">
<rule id="f3g44r1"> <rule id="f3g44r1">
<conditions> <conditions>
skipping to change at page 11, line 16 skipping to change at page 12, line 16
This document requires several IANA registrations, detailed below. This document requires several IANA registrations, detailed below.
7.1. URN Sub-Namespace Registration for 7.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:grip 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 (rbarnes@bbn.com).
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">
skipping to change at page 13, line 41 skipping to change at page 14, line 41
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, every 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. That is, URI that is issued to a different Target MUST be different from other
no two client can receive the same location URI or policy URI. location URIs and policy URIs. That is, two clients MUST NOT receive
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 a 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 client.
An example of a deployment scenario of this nature is described in An example of a deployment scenario of this nature is described in
[RFC5687]. An LCP server MUST create a different location URI and [RFC5687]. An LCP server MUST create a different location URI and
policy URI for every request, unless the requests can be reliably policy URI for every request, unless the requests can be reliably
identified as being from the same client. identified as being from the same client.
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-geopriv-dhcp-lbyr-uri-option] [I-D.ietf-geopriv-dhcp-lbyr-uri-option]
Polk, J., "Dynamic Host Configuration Protocol (DHCP) IPv4 Polk, J., "Dynamic Host Configuration Protocol (DHCP) IPv4
and IPv6 Option for a Location Uniform Resource Identifier and IPv6 Option for a Location Uniform Resource Identifier
(URI)", draft-ietf-geopriv-dhcp-lbyr-uri-option-09 (work (URI)", draft-ietf-geopriv-dhcp-lbyr-uri-option-11 (work
in progress), October 2010. in progress), February 2011.
[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.
skipping to change at page 14, line 46 skipping to change at page 15, line 46
RFC 5985, September 2010. RFC 5985, September 2010.
9.2. Informative References 9.2. Informative References
[I-D.ietf-geopriv-deref-protocol] [I-D.ietf-geopriv-deref-protocol]
Winterbottom, J., Tschofenig, H., Schulzrinne, H., Winterbottom, J., Tschofenig, H., Schulzrinne, H.,
Thomson, M., and M. Dawson, "A Location Dereferencing Thomson, M., and M. Dawson, "A Location Dereferencing
Protocol Using HELD", draft-ietf-geopriv-deref-protocol-02 Protocol Using HELD", draft-ietf-geopriv-deref-protocol-02
(work in progress), December 2010. (work in progress), December 2010.
[I-D.ietf-geopriv-held-identity-extensions]
Winterbottom, J., Thomson, M., Tschofenig, H., and R.
Barnes, "Use of Device Identity in HTTP-Enabled Location
Delivery (HELD)",
draft-ietf-geopriv-held-identity-extensions-06 (work in
progress), November 2010.
[I-D.ietf-geopriv-policy] [I-D.ietf-geopriv-policy]
Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J.,
and J. Polk, "Geolocation Policy: A Document Format for and J. Polk, "Geolocation Policy: A Document Format for
Expressing Privacy Preferences for Location Information", Expressing Privacy Preferences for Location Information",
draft-ietf-geopriv-policy-22 (work in progress), draft-ietf-geopriv-policy-23 (work in progress),
October 2010. March 2011.
[I-D.ietf-geopriv-rfc3825bis] [I-D.ietf-geopriv-rfc3825bis]
Polk, J., Schnizlein, J., Linsner, M., Thomson, M., and B. Polk, J., Linsner, M., Thomson, M., and B. Aboba, "Dynamic
Aboba, "Dynamic Host Configuration Protocol Options for Host Configuration Protocol Options for Coordinate-based
Coordinate-based Location Configuration Information", Location Configuration Information",
draft-ietf-geopriv-rfc3825bis-14 (work in progress), draft-ietf-geopriv-rfc3825bis-17 (work in progress),
November 2010. February 2011.
[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.
skipping to change at page 16, line 5 skipping to change at page 16, line 38
'retransmission-allowed' for SIP Location Conveyance", 'retransmission-allowed' for SIP Location Conveyance",
RFC 5606, August 2009. RFC 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.
Barnes, "Use of Device Identity in HTTP-Enabled Location
Delivery (HELD)", RFC 6155, March 2011.
Authors' Addresses Authors' Addresses
Richard Barnes Richard Barnes
BBN Technologies BBN Technologies
9861 Broken Land Parkway 9861 Broken Land Parkway
Columbia, MD 21046 Columbia, MD 21046
US US
Phone: +1 410 290 6169 Phone: +1 410 290 6169
Email: rbarnes@bbn.com Email: rbarnes@bbn.com
 End of changes. 26 change blocks. 
76 lines changed or deleted 125 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/