One document matched: draft-barnes-geopriv-policy-uri-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="no"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-barnes-geopriv-policy-uri-00" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="LCP Policy URIs">Location Configuration Extensions for Policy Management</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Richard Barnes" initials="R.L." surname="Barnes">
<organization>BBN Technologies</organization>
<address>
<postal>
<street>9861 Broken Land Parkway</street>
<city>Columbia</city>
<region>MD</region>
<code>21046</code>
<country>US</country>
</postal>
<phone>+1 410 290 6169</phone>
<email>rbarnes@bbn.com</email>
</address>
</author>
<date month="October" year="2009" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>RAI</area>
<workgroup>GEOPRIV</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>geopriv, geolocation, privacy, policy</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>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 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.</t>
</abstract>
</front>
<middle>
<section anchor="intro-sec" title="Introduction">
<t>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) <xref target="I-D.ietf-geopriv-l7-lcp-ps"></xref>, which allow a location provider (e.g., a local access network) to inform a host about its location.</t>
<t>There are two basic patterns for location configuration, namely configuration "by value" and "by reference" <xref target="I-D.ietf-geopriv-lbyr-requirements"></xref>. 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.</t>
<t>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 <xref target="RFC5606"></xref>). 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 <xref target="I-D.ietf-geopriv-rfc3825bis"></xref> versus GML in a PIDF-LO <xref target="RFC4119"></xref>). </t>
<t>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.</t>
<t>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.</t>
</section>
<section anchor="def-sec" title="Definitions">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
<section anchor="policy-uri-sec" title="Policy URIs">
<t>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 <xref target="RFC4745"></xref> (possibly including some extensions, e.g., for geolocation policy <xref target="I-D.ietf-geopriv-policy"></xref>).</t>
<t>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.</t>
<t>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'.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section anchor="extn-sec" title="Location Configuration Extensions">
<t>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.</t>
<section anchor="held-extn-sec" title="HELD">
<t>The HELD protocol <xref target="I-D.ietf-geopriv-http-location-delivery"></xref> 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 <xref target="policy-uri-schema"></xref> defines an extended <locationUriSet> object with a new optional attribute "policy" </t>
<figure anchor="policy-uri-schema">
<artwork><![CDATA[
<?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>
]]>
</artwork>
</figure>
<t>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 <xref target="policy-uri-sec"></xref>: It MUST be an HTTP or HTTPS URI, and the server MUST support the specified operations on the URI.</t>
</section>
<section anchor="dhcp-extn-sec" title="DHCP">
<t>The DHCP location by reference option <xref target="I-D.ietf-geopriv-dhcp-lbyr-uri-option"></xref> provides location URIs in sub-options called LuriElements. This document defines a new LuriElement type for policy URIs</t>
<t>
<list style="hanging" hangIndent="11">
<t hangText="LuriType=X ">Policy-URI - This is a policy URI that refers to the access control policy for the location URI in the preceding LuriElement.</t>
</list>
</t>
<t>[NOTE TO IANA/RFC-EDITOR: Please replace X above with the assigned LuriType value]</t>
<t>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 <xref target="policy-uri-sec"></xref>: It MUST be an HTTP or HTTPS URI, and the server MUST support the specified operations on the URI.</t>
</section>
</section>
<section anchor="example-sec" title="Examples">
<t>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</t>
<section anchor="held-example-sec" title="HELD">
<t>A HELD response providing a single <locationUriSet>, containing two URIs under a common policy, would have the following form:</t>
<figure><artwork><![CDATA[
<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>
]]></artwork></figure>
</section>
<section anchor="dhcp-example-sec" title="DHCP">
<t>A DHCP option providing a single location URI along with a single policy URI would have the following form:</t>
<figure><artwork><![CDATA[
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' | ':' |
+---------------+---------------+---------------+---------------|
| '/' | '/' | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
</section>
<section anchor="policy-example-sec" title="Basic access control policy">
<t>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:</t>
<figure><artwork><![CDATA[
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>
]]></artwork></figure>
<t>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:</t>
<figure><artwork><![CDATA[
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
]]></artwork></figure>
<t>Finally, after using the URI for a period, the user wishes to permanently invalidate the URI.</t>
<figure><artwork><![CDATA[
DELETE /policy/357yc6s64ceyoiuy5ax3o HTTP/1.1
Host: ls.example.com:9768
HTTP/1.1 200 OK
]]></artwork></figure>
</section>
<section anchor="possession-example-sec" title="The possession model"></section>
</section>
<section anchor="ack-sec" title="Acknowledgements">
<t>Thanks to James Winterbottom, Martin Thomson, Hannes Tschofenig, and Mary Barnes for providing critical commentary on the ideas described in this document. </t>
</section>
<section anchor="iana-sec" title="IANA Considerations">
<t>This document requires several IANA registrations, detailed below.</t>
<section anchor="iana-ns-sec" title="URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:held:policy">
<t>This section registers a new XML namespace, "urn:ietf:params:xml:ns:geopriv:held", per the guidelines in <xref target="RFC3688"></xref>.</t>
<figure><artwork><![CDATA[
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
]]></artwork></figure>
</section>
<section anchor="iana-schema-sec" title="XML Schema Registration">
<t>This section registers an XML schema as per the guidelines in <xref target="RFC3688"></xref>.
<list style="hanging" hangIndent="3">
<t hangText="URI:"> urn:ietf:params:xml:schema:geopriv:held</t>
<t hangText="Registrant Contact:"> IETF, GEOPRIV working group (geopriv@ietf.org), Richard Barnes (rbarnes@bbn.com)</t>
<t hangText="Schema:">The XML for this schema can be found in Section <xref target="held-extn-sec"></xref>.</t>
</list>
</t>
</section>
<section anchor="iana-dhcp-sec" title="DHCP LuriType Registration">
<t>IANA is requested to add a value to the LuriTypes registry, as follows:</t>
<figure><artwork><![CDATA[
+------------+----------------------------------------+-----------+
| 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.
]]></artwork></figure>
</section>
</section>
<section anchor="sec-cons-sec" title="Security Considerations">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4745.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3688.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-policy"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-http-location-delivery"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-dhcp-lbyr-uri-option"?>
</references>
<references title="Informative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4119.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5606.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-lbyr-requirements"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-l7-lcp-ps"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-rfc3825bis"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 23:22:20 |