< draft-ietf-geopriv-policy-uri-05.txt   draft-ietf-geopriv-policy-uri-06.txt >
GEOPRIV R. Barnes GEOPRIV R. Barnes
Internet-Draft BBN Technologies Internet-Draft BBN Technologies
Intended status: Standards Track M. Thomson Intended status: Standards Track M. Thomson
Expires: March 24, 2013 Microsoft Expires: March 25, 2013 Microsoft
J. Winterbottom J. Winterbottom
Andrew Corporation Andrew Corporation
H. Tschofenig H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
September 20, 2012 September 21, 2012
Location Configuration Extensions for Policy Management Location Configuration Extensions for Policy Management
draft-ietf-geopriv-policy-uri-05.txt draft-ietf-geopriv-policy-uri-06.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 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 24, 2013. This Internet-Draft will expire on March 25, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 21 skipping to change at page 2, line 21
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.2. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.3. Client Processing . . . . . . . . . . . . . . . . . . . . 9
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. HELD . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. HELD . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Basic Access Control Policy . . . . . . . . . . . . . . . 9 5.2. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . 12 urn:ietf:params:xml:ns:geopriv:held:policy . . . . . . . . 13
6.2. XML Schema Registration . . . . . . . . . . . . . . . . . 12 6.2. XML Schema Registration . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6.3. DHCP LuriType Registration . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7.1. Integrity and Confidentiality for Authorization Policy 7.1. Integrity and Confidentiality for Authorization Policy
Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.2. Access Control for Authorization Policy . . . . . . . . . 13 7.2. Access Control for Authorization Policy . . . . . . . . . 15
7.3. Location URI Allocation . . . . . . . . . . . . . . . . . 15 7.3. Location URI Allocation . . . . . . . . . . . . . . . . . 16
7.4. Policy URI Handling . . . . . . . . . . . . . . . . . . . 15 7.4. Policy URI Handling . . . . . . . . . . . . . . . . . . . 17
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . . 18
Appendix A. Example Policy URI Generation Algorithm . . . . . . . 18 Appendix A. Example Policy URI Generation Algorithm . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 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
skipping to change at page 4, line 26 skipping to change at page 4, line 26
| | | | | |
+------+----+----+----+ | +------+----+----+----+ |
| 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: 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 an extension to the HELD protocol to carry policy URIs. define extensions to the HELD protocol and the DHCP option for
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
skipping to change at page 5, line 50 skipping to change at page 5, line 50
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 URIs once the corresponding location URI set has expired.
This expiry time is specified by the 'expires' attribute in the HELD This expiry time is specified by the 'expires' attribute in the HELD
locationResponse. locationResponse or the 'Valid-For' LuriType in DHCP.
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-
skipping to change at page 6, line 46 skipping to change at page 6, line 46
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 [I-D.ietf-geopriv-deref-protocol] 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 HELD, the client assumes that the default policy grants any For DHCP and HELD, the client assumes that the default policy
requester access to location information, as long as the requestor grants any requester access to location information, as long as
possesses the location URI. To ensure that the authorization the request possesses the location URI. To ensure that the
policy is less permissive, a client updates the policy prior to authorization policy is less permissive, a client updates the
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 effectively a shared secret between Location Server A policy URI is effectively a shared secret between Location Server
and its clients. Knowledge of a policy URI is all that is required and its clients. Knowledge of a policy URI is all that is required
to perform any operations allowed on the policy. Thus, a policy URI to perform any operations allowed on the policy. Thus, a policy URI
should be constructed so that it is hard to predict and 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
skipping to change at page 8, line 12 skipping to change at page 8, line 12
change its default policy to something more restrictive -- even the change its default policy to something more restrictive -- even the
empty, default-deny policy -- since the client can specify something empty, default-deny policy -- since the client can specify something
more permissive if desired. 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 the HELD LCP to carry policy URIs This section defines extensions to LCPs to carry policy URIs that the
that the target can use to control access to location resources. target can use to control access to location resources.
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 contain 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"?>
skipping to change at page 8, line 50 skipping to change at page 9, line 5
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
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 policy-management protocols other than the HTTP- policy URIs that use protocols other than the HTTP-based protocol
based protocol described above. To ensure that they fail safely when described above. To ensure that they fail safely when presented with
presented with such a URI, clients implementing this specification such a URI, clients implementing this specification MUST verify that
MUST verify that a policy URI received from an LCP uses either the a policy URI received from either HELD or DHCP uses either the
"http:" or "https:" scheme. If the URI does not match those schemes, "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 then the client 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.
skipping to change at page 9, line 27 skipping to change at page 10, line 4
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:
<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>
<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. Basic Access Control Policy 5.2. DHCP
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://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 client 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
skipping to change at page 12, line 47 skipping to change at page 13, line 47
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 (rbarnes@bbn.com)
Schema: The XML for this schema can be found in Section Section 4. 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
** 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, and 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, for example, [RFC5985]). These measures ensure that a means (see [RFC5985] and [I-D.ietf-geopriv-dhcp-lbyr-uri-option]).
policy URI is conveyed to the client without modification or These measures ensure that a policy URI is conveyed to the client
interception. without modification or interception.
In general, the requirements for transport-layer security on policy In general, the requirements for transport-layer security on policy
transactions are the same as for the dereference transactions they transactions are the same as for the dereference transactions they
set policy for [I-D.ietf-geopriv-deref-protocol]. To protect the set policy for [I-D.ietf-geopriv-deref-protocol]. To protect the
integrity and confidentiality of policy data during management, the integrity and confidentiality of policy data during management, the
Location Server SHOULD provide policy URIs with the "https:" scheme Location Server SHOULD provide policy URIs with the "https:" scheme
and require the use of HTTP over TLS [RFC2818]. The cipher suites and require the use of HTTP over TLS [RFC2818]. The cipher suites
required by TLS [RFC5246] provide both integrity protection and required by TLS [RFC5246] provide both integrity protection and
confidentiality. If other means of protection are available, an confidentiality. If other means of protection are available, an
"http:" URI MAY be used, but location servers SHOULD reject PUT and "http:" URI MAY be used, but location servers SHOULD reject PUT and
skipping to change at page 14, line 21 skipping to change at page 15, line 37
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.) "expires" attribute in HELD or the "Valid-For" LuriType in DHCP.)
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 27 skipping to change at page 17, line 42
commentary and input on the ideas described in this document, and to commentary and input on the ideas described in this document, and to
Ted Hardie and Adam Roach for helping clarify the relationships Ted Hardie and Adam Roach for helping clarify the relationships
between policy URIs, policy documents, and location resources. between policy URIs, policy documents, and location resources.
Thanks to Stephen Farrell for a helpful discussion on security and Thanks to Stephen Farrell for a helpful discussion on security and
privacy challenges. 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",
 End of changes. 20 change blocks. 
38 lines changed or deleted 119 lines changed or added

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