draft-ietf-geopriv-policy-uri-03.txt   draft-ietf-geopriv-policy-uri-04.txt 
GEOPRIV R. Barnes GEOPRIV R. Barnes
Internet-Draft BBN Technologies Internet-Draft BBN Technologies
Intended status: Informational M. Thomson Intended status: Standards Track M. Thomson
Expires: May 20, 2012 J. Winterbottom Expires: May 31, 2012 J. Winterbottom
Andrew Corporation Andrew Corporation
H. Tschofenig H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
November 17, 2011 November 28, 2011
Location Configuration Extensions for Policy Management Location Configuration Extensions for Policy Management
draft-ietf-geopriv-policy-uri-03.txt draft-ietf-geopriv-policy-uri-04.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 May 20, 2012. This Internet-Draft will expire on May 31, 2012.
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 34 skipping to change at page 2, line 34
5.2. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.2. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.3. Basic Access Control Policy . . . . . . . . . . . . . . . 10 5.3. Basic Access Control Policy . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
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 . . . . . . . . 12
6.2. XML Schema Registration . . . . . . . . . . . . . . . . . 12 6.2. XML Schema Registration . . . . . . . . . . . . . . . . . 12
6.3. DHCP LuriType Registration . . . . . . . . . . . . . . . . 13 6.3. DHCP LuriType Registration . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7.1. Integrity and Confidentiality for Authorization Policy 7.1. Integrity and Confidentiality for Authorization Policy
Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.2. Access Control for Authorization Policy . . . . . . . . . 13 7.2. Access Control for Authorization Policy . . . . . . . . . 14
7.3. Location URI Allocation . . . . . . . . . . . . . . . . . 14 7.3. Location URI Allocation . . . . . . . . . . . . . . . . . 14
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
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
skipping to change at page 13, line 46 skipping to change at page 13, line 46
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] and [I-D.ietf-geopriv-dhcp-lbyr-uri-option]).
These measures ensure that a policy URI is conveyed to the client These measures ensure that a policy URI is conveyed to the client
without modification or interception. without modification or interception.
To protect the integrity and confidentiality of policy data during To protect the integrity and confidentiality of policy data during
management, the Location Server SHOULD provide policy URIs with the management, the Location Server SHOULD provide policy URIs with the
"https:" scheme and require the use of HTTP over TLS [RFC2818]. The "https:" scheme and require the use of HTTP over TLS [RFC2818]. The
cipher suites required by TLS [RFC5246] provide both integrity cipher suites required by TLS [RFC5246] provide both integrity
protection and confidentiality. If other means of protection are protection and confidentiality. If other means of protection are
available, an "http:" URI MAY be used. available, an "http:" URI MAY be used, but location servers SHOULD
reject PUT and DELETE requests for policy URIs that 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. ConfideConfidentiality and integrity protections SHOULD Makers. ConfideConfidentiality and integrity protections SHOULD
be used when policy URIs are conveyed in a location configuration be used when policy URIs are conveyed in a location configuration
protocol, and in the requests that are used to inspect, change or protocol, and in the requests that are used to inspect, change or
delete the policy resource. Note that in some protocols (such as delete the policy resource. Note that in some protocols (such as
DHCP), these protections may arise from limiting the use of the DHCP), these protections may arise from limiting the use of the
protocol to the local network, thus relying on lower-layer protocol to the local network, thus relying on lower-layer
security mechanisms. When neither application-layer or network- security mechanisms. When neither application-layer or network-
layer security is provided, location servers MUST reject requests layer security is provided, location servers MUST reject requests
using the PUT and DELETE methods, and SHOULD reject PUT and DELETE using the PUT and DELETE methods.
requests for policy URIs that use the "http:" URI scheme.
o The Location Server MUST ensure that the URI cannot be easily o The Location Server MUST ensure that the URI cannot be easily
predicted. The policy URI MUST NOT be derived solely from predicted. The policy URI MUST NOT be derived solely from
information that might be public, including the Target identity or information that might be public, including the Target identity or
any location URI. The addition of 32 bits or more of random any location URI. The addition of 32 bits or more of random
entropy is RECOMMENDED to make it infeasible for a third party to entropy is RECOMMENDED to make it infeasible for a third party to
guess a policy URI. guess a 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 policy URIs that guessing infeasible. If a server allocates policy URIs that
 End of changes. 7 change blocks. 
9 lines changed or deleted 10 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/