GEOPRIV R. Barnes
Internet-Draft BBN Technologies
Intended status: Informational October 7, 2009
Expires: April 10, 2010
Location Configuration Extensions for Policy Management
draft-barnes-geopriv-policy-uri-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 10, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
Current location configuration protocols are capable of provisioning
an Internet host with a location URI that refers to the host's
location. However, these protocols lack a mechnism for the htarget
Barnes Expires April 10, 2010 [Page 1]
Internet-Draft LCP Policy URIs October 2009
host to inspect or set the privacy rules that are applied to the URIs
they distribute. This document extends the current location
configuration 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Policy URIs . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Location Configuration Extensions . . . . . . . . . . . . . . 5
4.1. HELD . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. HELD . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.2. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.3. Basic access control policy . . . . . . . . . . . . . . . 7
5.4. The possession model . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held:policy . . . . . . . . 10
7.2. XML Schema Registration . . . . . . . . . . . . . . . . . 10
7.3. DHCP LuriType Registration . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
Barnes Expires April 10, 2010 [Page 2]
Internet-Draft LCP Policy URIs October 2009
1. Introduction
A critical step in enabling Internet hosts to access location-based
services is to provision those hosts with information about their own
location. This is accomplished via a Location Configuration Protocol
(LCP) [7], which allow a location provider (e.g., a local access
network) to inform a host about its location.
There are two basic patterns for location configuration, namely
configuration "by value" and "by reference" [8]. Configuration by
value provisions a host directly with its location, by providing it
location information that is directly usable (e.g., coordinates or a
civic address). Configuration by reference provides a host with a
URI that references the host's location, i.e., one that can be
dereferenced to obtain the location (by value) of the host.
In some cases, location by reference offers a few benefits over
location by value. From a privacy perspective, the required
dereference transaction provides a policy enforcement point, so that
the opaque URI itself can be safely conveyed over untrusted media
(e.g., SIP through untrusted proxies [9]). If the target host is
mobile, an application provider can use a single reference to obtain
the location of the host multiple times, saving bandwidth to the
host. For some configuration protocols, the location object
referenced by a location URI provides a much more expressive syntax
for location values than the configuration protocol itself (e.g.,
DHCP geodetic location [10] versus GML in a PIDF-LO [11]).
From a privacy perspective, however, current LCPs are limited in
their flexibility, in that they do not provide the Target (the client
in an LCP) with a way to inform the Location Server with policy for
how his location information should be handled. This document
addresses this gap by defining a simple mechanism for referring to
and manipulating policy, and by extending current LCPs to carry
policy references. Using the mechanisms defined in this document, a
Location Server (acting as an LCP server) can inform a client as to
which policy document controls a given location resource, and the LCP
client (a Target and Rule Maker) can inspect this document and modify
it as necessary.
The remainder of this document is structured as follows: After
introducing a few relevant terms, we define policy URIs as a channel
for referencing, inspecting, and updating policy documents. We then
define extensions to HELD protocol and the DHCP option for location
by reference to allow these protocols to cary policy URIs. Examples
are given that demonstrate how policy URIs are carried in these
protocols and how they can be used by clients.
Barnes Expires April 10, 2010 [Page 3]
Internet-Draft LCP Policy URIs October 2009
2. Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
3. Policy URIs
A policy URI is an HTTP or HTTPS URI that a Rule Holder can use to
inspect and install policy documents that tell a location server how
it should protect a given location resource. A policy URI is always
a reference to a common-policy document [2] (possibly including some
extensions, e.g., for geolocation policy [3]).
A server that is the authority for policy URIs MUST support GET, PUT,
and DELETE requests to these URIs, in order to allow clients to
inspect, replace, and delete policy documents. While the server MAY
deny any particular request according to local policy, it SHOULD
allow all requests (with any of the three methods) from the Target of
the protected location resource. Clients MUST likewise support the
three required request types.
A GET request to a policy URI is a request for the referenced policy
information. In response to a GET request, the server MUST validate
that the requestor is an authorized Rule Maker or Rule Holder
according to local policy. If the request is valid, then the server
MUST send an HTTP 200 response containing the full policy document
referenced by the URI, in the common-policy format; these responses
MUST have content-type 'application/auth-policy+xml'.
A PUT request to a policy URI is a request to replace the current
policy. The entity-body of a PUT requests MUST be a common-policy
document; it must have content-type 'application/auth-policy+xml'.
When a server receives a PUT request, it MUST validate the policy
document included in the body of the request, and it MUST validate
that the requestor is an authorized Rule Maker or Rule Holder
according to local policy. If the request is valid, then the server
MUST replace the current policy document referenced by the URI with
the policy document provided in the request.
A DELETE request to a policy URI is a request to delete the
referenced policy document and terminate access to the protected
resource. In response to a DELETE request, the server MUST validate
that the requestor is an authorized Rule Maker or Rule Holder
according to local policy. If the request is valid, then the server
MUST delete the policy document referenced by the URI and disallow
any further access to the location resource it governs.
Barnes Expires April 10, 2010 [Page 4]
Internet-Draft LCP Policy URIs October 2009
It should be noted that this usage of HTTP is generally compatible
with the use of XCAP or WebDAV to manage policy documents, but this
document does not define or require the use of these protocols.
4. Location Configuration Extensions
Location configuration protocols can provision hosts with location
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
that the server will use to guide its interactions. This section
defines extensions to LCPs to carry policy URIs that the target can
use to control access to location resources.
4.1. HELD
The HELD protocol [4] provides <locationUriSet> elements, which
contain a set of one or more location URIs that reference the same
resource and share a common access control policy. The schema in
Figure Figure 1 defines an extended <locationUriSet> object with a
new optional attribute "policy"
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:geopriv:held:policy"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:held="urn:ietf:params:xml:ns:geopriv:held"
xmlns:hp="urn:ietf:params:xml:ns:geopriv:held:policy"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:import namespace="http://www.w3.org/XML/1998/namespace" />
<xs:complexType name="returnLocationTypeWithPolicy">
<xs:complexContent>
<xs:restriction base="held:returnLocationType">
<xs:attribute name="policy" type="xs:anyURI" use="optional"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:element name="locationUriSet"
type="hp:returnLocationTypeWithPolicy"/>
</xs:schema>
Figure 1
Barnes Expires April 10, 2010 [Page 5]
Internet-Draft LCP Policy URIs October 2009
The URI carried in a "policy" attribute refers to the common access
control policy for the location URIs in the <locationUriSet>. The
URI MUST be a policy URI as described in Section Section 3: It MUST
be an HTTP or HTTPS URI, and the server MUST support the specified
operations on the URI.
4.2. DHCP
The DHCP location by reference option [5] provides location URIs in
sub-options called LuriElements. This document defines a new
LuriElement type for policy URIs
LuriType=X Policy-URI - This is a policy URI that refers to the
access control policy for the location URI in the
preceding LuriElement.
[NOTE TO IANA/RFC-EDITOR: Please replace X above with the assigned
LuriType value]
Each Policy-URI LuriElement MUST immediately follow a sub-option that
carries a location URI, for example, a sub-option with LuriType 1.
The URI carried in a Policy-URI LuriElement refers to the access
control policy for the location URI in the sub-option that precedes
it. The URI MUST be a policy URI as described in Section Section 3:
It MUST be an HTTP or HTTPS URI, and the server MUST support the
specified operations on the URI.
5. Examples
In this section, we provide some brief illustrations of how policy
URIs are delivered to target hosts and used by those hosts to manage
policy
5.1. HELD
A HELD response providing a single <locationUriSet>, containing two
URIs under a common policy, would have the following form:
Barnes Expires April 10, 2010 [Page 6]
Internet-Draft LCP Policy URIs October 2009
<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationUriSet
xmlns="urn:ietf:params:xml:ns:geopriv:held:policy"
expires="2006-01-01T13:00:00.0Z"
policy="https://ls.example.com:9768/policy/357yc6s64ceyoiuy5ax3o">
<locationURI>
https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
</locationURI>
<locationURI>
sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com:
</locationURI>
</locationUriSet>
</locationResponse>
5.2. DHCP
A DHCP option providing a single location URI along with a single
policy URI 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 | 111 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 0 | 1 | 49 | 'h' |
+---------------+---------------+---------------+---------------|
| 't' | 't' | 'p' | 's' |
+---------------+---------------+---------------+---------------|
| ':' | '/' | '/' | 'l' |
+---------------+---------------+---------------+---------------|
| 's' | '.' | ... |
+---------------+---------------+---------------+---------------|
| 3 | 56 | 'h' 't' |
+---------------+---------------+---------------+---------------|
| 't' | 'p' | 's' | ':' |
+---------------+---------------+---------------+---------------|
| '/' | '/' | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.3. Basic access control policy
Consider a user that gets the policy URI <https://ls.example.com/>,
as in the above LCP example. The first thing this allows the user to
do is inspect the default policy that the LS has assigned to this
URI:
Barnes Expires April 10, 2010 [Page 7]
Internet-Draft LCP Policy URIs October 2009
GET /policy/357yc6s64ceyoiuy5ax3o HTTP/1.1
Host: ls.example.com:9768
HTTP/1.1 200 OK
Content-type: application/auth-policy+xml
Content-length: 388
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<rule id="f3g44r1">
<conditions>
<identity>
<many domain="example.com">
<except id="sip:alice@example.com"/>
<except id="sip:bob@example.com"/>
</many>
</identity>
</conditions>
<actions/>
<transformations/>
</rule>
</ruleset>
This policy allows all users in the domain "example.com" to access
the bound location URI, except for users "alice" and "bob". If the
user disagrees with this policy, and prefers for example, to only
provide location to one friend, at a city level of granularity, then
he can install this policy on the LS:
Barnes Expires April 10, 2010 [Page 8]
Internet-Draft LCP Policy URIs October 2009
PUT /policy/357yc6s64ceyoiuy5ax3o HTTP/1.1
Host: ls.example.com:9768
Content-type: application/auth-policy+xml
Content-length: 462
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<rule id="f3g44r1">
<conditions>
<identity>
<one id="sip:friend@example.com"/>
</identity>
</conditions>
<actions/>
<transformations>
<gp:provide-location
profile="civic-transformation">
<lp:provide-civic>city</lp:provide-civic>
</gp:provide-location>
</transformations>
</rule>
</ruleset>
HTTP/1.1 200 OK
Finally, after using the URI for a period, the user wishes to
permanently invalidate the URI.
DELETE /policy/357yc6s64ceyoiuy5ax3o HTTP/1.1
Host: ls.example.com:9768
HTTP/1.1 200 OK
5.4. The possession model
6. Acknowledgements
Thanks to James Winterbottom, Martin Thomson, Hannes Tschofenig, and
Mary Barnes for providing critical commentary on the ideas described
in this document.
Barnes Expires April 10, 2010 [Page 9]
Internet-Draft LCP Policy URIs October 2009
7. IANA Considerations
This document requires several IANA registrations, detailed below.
7.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held:policy
This section registers a new XML namespace,
"urn:ietf:params:xml:ns:geopriv:held", per the guidelines in [6].
URI: urn:ietf:params:xml:ns:geopriv:held:policy
Registrant Contact: IETF, GEOPRIV working group,
(geopriv@ietf.org), Richard Barnes (rbarnes@bbn.com).
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>HELD Policy URI Extension</title>
</head>
<body>
<h1>Namespace for HELD Policy URI Extension</h1>
<h2>urn:ietf:params:xml:ns:geopriv:held:policy</h2>
[NOTE TO IANA/RFC-EDITOR: Please replace XXXX
with the RFC number for this specification.]
<p>See RFCXXXX</p>
</body>
</html>
END
7.2. XML Schema Registration
This section registers an XML schema as per the guidelines in [6].
URI: urn:ietf:params:xml:schema:geopriv:held
Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org),
Richard Barnes (rbarnes@bbn.com)
Schema: The XML for this schema can be found in Section Section 4.1.
Barnes Expires April 10, 2010 [Page 10]
Internet-Draft LCP Policy URIs October 2009
7.3. DHCP LuriType Registration
IANA is requested to add a value to the LuriTypes registry, as
follows:
+------------+----------------------------------------+-----------+
| LuriType | Name | Reference |
+------------+----------------------------------------+-----------+
| X* | Policy-URI | RFC XXXX**|
+------------+----------------------------------------+-----------+
* X is to be replaced with the assigned value
** RFC XXXX is to be replaced with this document's RFC-Editor RFC
number.
8. Security Considerations
There are two main classes of risks associated with access control
policy management: The risk of unauthorized disclosure of the
protected resource via manipulation of the policy management process,
and the risk of disclosure of policy information itself.
Protecting the policy management process from manipulation entails
two primary requirements: First, the policy URI has to be faithfully
transmitted to the client, and second, the policy document has to be
faithfully transmitted to the location server. The first requirement
is met by the integrity properties of the underlying LCP. To meet
the second requirement, the LCP server SHOULD provide HTTPS policy
URIs and the policy server SHOULD support cipher suites that provide
integrity protection.
Authorization policy at the policy server also plays a central role
in the protection of both location information and user policy
information. In order to prevent the unauthorized disclosure of
location information and policyinformation, the policy server MUST
authenticate all requests to policy URIs and verify that the
requestor is an authorized Rule Maker for the protected location
resource. In the particular case where the target itself is an
authorized Rule Maker and the target is identified to the LS by its
IP address, the server MAY use IP return routability as an
authentication mechanism.
Finally, policy information must be protected from observation by
unauthorized entities en route between the client and the policy
server. This protection is provided by the use of HTTPS with
appropriate cipher suites.
Barnes Expires April 10, 2010 [Page 11]
Internet-Draft LCP Policy URIs October 2009
9. References
9.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk,
J., and J. Rosenberg, "Common Policy: A Document Format for
Expressing Privacy Preferences", RFC 4745, February 2007.
[3] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., and
J. Polk, "Geolocation Policy: A Document Format for Expressing
Privacy Preferences for Location Information",
draft-ietf-geopriv-policy-21 (work in progress), July 2009.
[4] Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, "HTTP
Enabled Location Delivery (HELD)",
draft-ietf-geopriv-http-location-delivery-16 (work in
progress), August 2009.
[5] 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-06 (work in progress),
September 2009.
[6] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
9.2. Informative References
[7] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location
Configuration Protocol; Problem Statement and Requirements",
draft-ietf-geopriv-l7-lcp-ps-10 (work in progress), July 2009.
[8] Marshall, R., "Requirements for a Location-by-Reference
Mechanism", draft-ietf-geopriv-lbyr-requirements-08 (work in
progress), September 2009.
[9] Peterson, J., Hardie, T., and J. Morris, "Implications of
'retransmission-allowed' for SIP Location Conveyance",
RFC 5606, August 2009.
[10] Polk, J., Schnizlein, J., Linsner, M., and B. Aboba, "Dynamic
Host Configuration Protocol Option for Coordinate-based
Location Configuration Information",
draft-ietf-geopriv-rfc3825bis-01 (work in progress), July 2009.
Barnes Expires April 10, 2010 [Page 12]
Internet-Draft LCP Policy URIs October 2009
[11] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005.
Author's Address
Richard Barnes
BBN Technologies
9861 Broken Land Parkway
Columbia, MD 21046
US
Phone: +1 410 290 6169
Email: rbarnes@bbn.com
Barnes Expires April 10, 2010 [Page 13]