draft-ietf-geopriv-policy-uri-02.txt   draft-ietf-geopriv-policy-uri-03.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: April 6, 2012 J. Winterbottom Expires: May 20, 2012 J. Winterbottom
Andrew Corporation Andrew Corporation
H. Tschofenig H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
October 4, 2011 November 17, 2011
Location Configuration Extensions for Policy Management Location Configuration Extensions for Policy Management
draft-ietf-geopriv-policy-uri-02.txt draft-ietf-geopriv-policy-uri-03.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 April 6, 2012. This Internet-Draft will expire on May 20, 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 36 skipping to change at page 2, line 36
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 . . . . . . . . . 13
7.3. Location URI Allocation . . . . . . . . . . . . . . . . . 14 7.3. Location URI Allocation . . . . . . . . . . . . . . . . . 14
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 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
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 40 skipping to change at page 3, line 40
for location values than the configuration protocol itself (e.g., for location values than the configuration protocol itself (e.g.,
DHCP geodetic location [RFC6225] versus GML in a PIDF-LO [RFC4119]). DHCP geodetic location [RFC6225] versus GML in a 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) can inform a host as to which server (acting for the Location Server (LS) or Location Information
policy document controls a given location resource, and the host (in Server (LIS)) can inform a host as to which policy document controls
its Rule Maker role) can inspect this document and modify it as a given location resource, and the host (in its Rule Maker role) can
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).
+---------+---------+ Location +-----------+ +---------+---------+ Location +-----------+
| | | Dereference | Location | | | | Dereference | Location |
| LIS/LS +---------------+ Recipient | | LIS/LS +---------------+ Recipient |
| | | Protocol | | | | | Protocol | |
+----+----+----+----+ (3) +-----+-----+ +----+----+----+----+ (3) +-----+-----+
skipping to change at page 5, line 18 skipping to change at page 5, line 18
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 Location Server SHOULD allow all requests, but it authorization; a policy URI functions as a shared secret between the
MAY deny certain requests based on local policy. For instance, a client and the server (see Section 7). A Location Server SHOULD
Location Server might allow clients to inspect policy (GET), but not allow all requests, but it MAY deny certain requests based on local
to update it (PUT). policy. For instance, a Location Server might allow clients to
inspect policy (GET), but not to update it (PUT).
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
skipping to change at page 13, line 22 skipping to change at page 13, line 22
+------------+----------------------------------------+-----------+ +------------+----------------------------------------+-----------+
| TBD* | Policy-URI | RFC XXXX**| | TBD* | Policy-URI | RFC XXXX**|
+------------+----------------------------------------+-----------+ +------------+----------------------------------------+-----------+
* TBD is to be replaced with the assigned value * TBD is to be replaced with the assigned value
** RFC XXXX is to be replaced with this document's RFC number. ** 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 disclosure of the policy management: The risk of unauthorized grants or denial of
protected resource via manipulation of the policy management process, access to the protected resource via manipulation of the policy
and the risk of disclosure of policy information itself. management process, and the risk of disclosure of policy information
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
skipping to change at page 14, line 7 skipping to change at page 14, line 8
available, an "http:" URI MAY be used. available, an "http:" URI MAY be used.
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 is required for its conveyance in the Makers. ConfideConfidentiality and integrity protections SHOULD
location configuration protocol, and in the requests that are used be used when policy URIs are conveyed in a location configuration
to inspect, change or delete the policy resource. protocol, and in the requests that are used to inspect, change or
delete the policy resource. Note that in some protocols (such as
DHCP), these protections may arise from limiting the use of the
protocol to the local network, thus relying on lower-layer
security mechanisms. When neither application-layer or network-
layer security is provided, location servers MUST reject requests
using the PUT and DELETE methods, and SHOULD reject PUT and DELETE
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 random entropy increases the any location URI. The addition of 32 bits or more of random
difficulty of guessing a policy URI. entropy is RECOMMENDED to make it infeasible for a third party to
guess a policy URI.
o Servers SHOULD apply rate limits in order to make brute-force
guessing infeasible. If a server allocates policy URIs that
include N bits of entropy with a default lifetime of T seconds,
then the server should limit clients to 2^(N/2)/T queries per
second.
7.3. Location URI Allocation 7.3. Location URI Allocation
A policy URI enables the authorization by access control lists model A policy URI enables the authorization by access control lists model
[RFC5808] for associated location URIs. Under this model, it might [RFC5808] for associated location URIs. Under this model, it might
be possible to more widely distribute a location URI, relying on the be possible to more widely distribute a location URI, relying on the
authorization policy to constrain access to location information. authorization policy to constrain access to location information.
To allow for wider distribution, authorization by access control To allow for wider distribution, authorization by access control
lists places additional constraints on the construction of location lists places additional constraints on the construction of location
skipping to change at page 15, line 46 skipping to change at page 16, line 14
(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 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-03 Protocol Using HELD", draft-ietf-geopriv-deref-protocol-04
(work in progress), June 2011. (work in progress), October 2011.
[I-D.ietf-geopriv-policy] [I-D.ietf-geopriv-policy]
Schulzrinne, H., Tschofenig, H., Cuellar, J., Polk, J., Schulzrinne, H., Tschofenig, H., Cuellar, J., Polk, J.,
and J. Morris, "Geolocation Policy: A Document Format for Morris, J., and M. Thomson, "Geolocation Policy: A
Expressing Privacy Preferences for Location Information", Document Format for Expressing Privacy Preferences for
draft-ietf-geopriv-policy-24 (work in progress), Location Information", draft-ietf-geopriv-policy-25 (work
September 2011. in progress), October 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.
 End of changes. 13 change blocks. 
29 lines changed or deleted 45 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/