One document matched: draft-ietf-geopriv-policy-uri-02.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="yes"?>
<!-- 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-ietf-geopriv-policy-uri-02.txt"
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 -->
<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>
<author fullname="Martin Thomson" initials="M." surname="Thomson">
<organization>Andrew Corporation</organization>
<address>
<postal>
<street>Andrew Building (39)</street>
<street>Wollongong University Campus</street>
<street>Northfields Avenue</street>
<city>Wollongong</city>
<region>NSW</region>
<code>2522</code>
<country>AU</country>
</postal>
<phone>+61 2 4221 2915</phone>
<email>martin.thomson@andrew.com</email>
</address>
</author>
<author fullname="James Winterbottom" initials="J." surname="Winterbottom">
<organization>Andrew Corporation</organization>
<address>
<postal>
<street>Andrew Building (39)</street>
<street>Wollongong University Campus</street>
<street>Northfields Avenue</street>
<city>Wollongong</city>
<region>NSW</region>
<code>2522</code>
<country>AU</country>
</postal>
<phone>+61 242 212938</phone>
<email>james.winterbottom@andrew.com</email>
</address>
</author>
<author fullname="Hannes Tschofenig" initials="H." surname="Tschofenig">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>Linnoitustie 6</street>
<city>Espoo</city>
<code>02600</code>
<country>Finland</country>
</postal>
<phone>+358 (50) 4871445</phone>
<email>Hannes.Tschofenig@gmx.net</email>
<uri>http://www.tschofenig.priv.at</uri>
</address>
</author>
<date month="October" year="2011" />
<!-- 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. -->
<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.
These protocols lack a mechanism for the target 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="RFC5687"></xref>, which allows 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="RFC5808"></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="RFC6225"></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 hosts (the clients 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, an LCP server (acting for the
Location Server) can inform a host as to which policy document controls
a given location resource, and the host (in its Rule Maker role) can
inspect this document and modify it as necessary.</t>
<t>In the following figure, adapted from RFC 5808, this document extends
the Location Configuration Protocols (1) and defines a simple protocol
for policy exchange (4).</t>
<figure>
<artwork><![CDATA[ +---------+---------+ Location +-----------+
| | | Dereference | Location |
| LIS/LS +---------------+ Recipient |
| | | Protocol | |
+----+----+----+----+ (3) +-----+-----+
| | |
| | |
Policy| |Location |Location
Exchange| |Configuration |Conveyance
(4)| |Protocol |Protocol
| |(1) |(2)
| | |
+------+----+----+----+ |
| Rule | Target/ | |
| Maker | Host +---------------------+
| | |
+-----------+---------+
]]></artwork>
</figure>
<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 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 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 <xref target="RFC2616">HTTP</xref> or <xref
target="RFC2818">HTTPS</xref>URI that identifies a policy resource that
contains the authorization policy for a linked location resource. Access
to the location resource is governed by the contents of the
authorization policy.</t>
<t>A policy URI identifies an HTTP resource that a Rule Maker can use to
inspect and install policy documents that tell a Location Server how it
should protect the associated location resource. A policy URI always
identifies a resource that can be represented as a <xref
target="RFC4745">common-policy document</xref> (possibly including some
extensions; e.g., for <xref target="I-D.ietf-geopriv-policy">geolocation
policy</xref>).</t>
<t><list style="hanging">
<t hangText="Note:"><xref target="RFC3693">RFC 3693</xref>
identified the Rule Holder role as the one that stores policy
information. In this document, the Location Server is also a Rule
Holder.</t>
</list></t>
<section anchor="policy-uri-usage-sec" title="Policy URI Usage">
<t>A Location 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. Clients
support the three request methods as they desire to perform these
operations.</t>
<t>Knowledge of the policy URI can be considered adequate evidence of
authorization. A Location Server SHOULD allow all requests, but it MAY
deny certain requests based on local policy. For instance, a Location
Server might allow clients to inspect policy (GET), but not to update
it (PUT).</t>
<t>A GET request to a policy URI is a request for the referenced
policy information. If the request is authorized, then the Location
Server sends an HTTP 200 response containing the complete policy
identified by the URI.</t>
<t>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
document. When a Location Server receives a PUT request, it MUST
validate the policy document included in the body of the request. If
the request is valid and authorized, then the Location Server MUST
replace the current policy with the policy provided in the
request.</t>
<t>A DELETE request to a policy URI is a request to delete the
referenced policy document. If the request is authorized, then the
Location Server MUST delete the policy referenced by the URI and
disallow access to the location URIs it governs until a new policy
document has been put in place via a PUT request.</t>
<t>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
policy URIs once the corresponding location URI set has expired. This
expiry time is specified by the 'expires' attribute in the HELD
locationResponse or the 'Valid-For' LuriType in DHCP.</t>
<t><list style="empty">
<t>A location URI can thus become invalid in three ways: By the
expiration of a validity interval in policy, by the removal of a
policy document with a DELETE request, or by the expiry of the
LCP-specified validity interval. The former two are temporary,
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
invalidated as well.</t>
</list></t>
<t>The Location Server MUST support policy documents in the <xref
target="RFC4745">common-policy format</xref>, as identified by the
MIME media type of <spanx style="verb">application/auth-policy+xml</spanx>.
The common-policy format MUST be provided as the default format in
response to GET requests that do not include specific <spanx
style="verb">Accept</spanx> headers, but content negotiation MAY be
used to allow for other formats.</t>
<t>This usage of HTTP is generally compatible with the use of <xref
target="RFC4825">XCAP</xref> or <xref target="RFC4918">WebDAV</xref>
to manage policy documents, but this document does not define or
require the use of these protocols.</t>
</section>
<section anchor="policy-uri-alloc-sec" title="Policy URI Allocation">
<t>A Location Server creates a policy URI for a specific location
resource at the time that the location resource is created; that is, a
policy URI is created at the same time as the location URI that it
controls. The URI of the policy resource MUST be different from the
location URI.</t>
<t>A policy URI is provided in response to location configuration
requests. A policy URI MUST NOT be provided to an entity that is not
authorized to view or set policy. This document does not describe how
policy might be provided to entities other than for location
configuration, for example, in responses to <xref
target="I-D.ietf-geopriv-deref-protocol">dereferencing requests</xref>
or <xref target="RFC6155">requests from third parties</xref>.</t>
<t>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 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
location URI as they would have if no policy URI were provided.</t>
<t><list style="empty">
<t>For DHCP and HELD, the client assumes that the default policy
grants any requester access to location information, as long as
the request possesses the location URI. To ensure that the
authorization policy is less permissive, a client updates the
policy prior to distributing the location URI.</t>
</list></t>
<t>A Location Server chooses whether or not to provide a policy URI
based on local policy. A HELD-specific extension also allows a
requester to specifically ask for a policy URI.</t>
<t>A policy URI is effectively a shared secret between Location Server
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
should be constructed so that it is hard to predict and
confidentiality-protected when transmitted (see <xref
target="sec-cons-sec"></xref>). To avoid re-using these shared
secrets, the Location Server MUST generate a new policy URI whenever
it generates a new location URI set.</t>
</section>
</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
Location Server uses to guide how it serves location URIs. 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="RFC5985"></xref> defines a <spanx
style="verb">locationUriSet</spanx> element, 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 <xref
target="policy-uri-schema"></xref> defines two extension elements for
HELD: an empty <spanx style="verb">requestPolicyUri</spanx> element
that is added to a location request to indicate that a Device desires
that a policy URI be allocated; and a <spanx style="verb">policyUri</spanx>
element that is included in the location response.</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:hp="urn:ietf:params:xml:ns:geopriv:held:policy"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="requestPolicyUri">
<xs:complexType name="empty"/>
</xs:element>
<xs:element name="policyUri" type="xs:anyURI"/>
</xs:schema>
]]></artwork>
</figure>
<t>The URI carried in a <spanx style="verb">policyUri</spanx> element
refers to the common access control policy for location URIs in the
location response. The URI MUST be a policy URI as described in <xref
target="policy-uri-sec"></xref>. A policy URI MUST use the <spanx
style="verb">http:</spanx> or <spanx style="verb">https:</spanx>
scheme, and the Location Server MUST support the specified operations
on the URI.</t>
<t>A HELD request MAY contain an explicit request for a policy URI.
The presence of the <spanx style="verb">requestPolicyUri</spanx>
element in a location request indicates that a policy URI is
desired.</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 hangIndent="11" style="hanging">
<t hangText="LuriType=TBD ">Policy-URI - This is a policy URI that
refers to the access control policy for the location URIs.</t>
</list></t>
<t>[NOTE TO IANA/RFC-EDITOR: Please replace TBD above with the
assigned LuriType value and remove this note]</t>
<t>A Policy-URI LuriElement uses a UTF-8 character encoding.</t>
<t>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 <xref target="policy-uri-sec"></xref>: It
MUST use either the <spanx style="verb">http:</spanx> or <spanx
style="verb">https:</spanx> scheme, and the Location Server MUST
support the specified operations on the URI.</t>
</section>
<section title="Client Processing">
<t>It is possible that this document will be updated to allow the use
of policy URIs that use protocols other than the HTTP-based protocol
described above. To ensure that they fail safely when presented with
such a URI, clients implementing this specification MUST verify that a
policy URI received from either HELD or DHCP uses either the <spanx
style="verb">http:</spanx> or <spanx style="verb">https:</spanx>
scheme. If the URI does not match those schemes, then the client MUST
discard the URI and behave as if no policy URI was provided.</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 request that explicitly requests the creation of a policy
URI has the following form:</t>
<figure>
<artwork><![CDATA[
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationType exact="true">locationURI</locationType>
<requestPolicyUri
xmlns="urn:ietf:params:xml:ns:geopriv:held:policy"/>
</locationRequest>
]]></artwork>
</figure>
<t>A HELD response providing a single <spanx style="verb">locationUriSet</spanx>,
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 expires="2011-01-01T13:00:00.0Z">
<locationURI>
https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
</locationURI>
<locationURI>
sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com:
</locationURI>
</locationUriSet>
<policyUri xmlns="urn:ietf:params:xml:ns:geopriv:held:policy">
https://ls.example.com:9768/policy/357lp6f64prlbvhl5nk3b
</policyUri>
</locationResponse>
]]></artwork>
</figure>
</section>
<section anchor="dhcp-example-sec" title="DHCP">
<t>A DHCP option providing one of the location URIs and the
corresponding policy URI from the previous example 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 | 110 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 0 | 1 | 49 | 'h' |
+---------------+---------------+---------------+---------------|
| 't' | 't' | 'p' | 's' |
+---------------+---------------+---------------+---------------|
| ':' | '/' | '/' | 'l' |
+---------------+---------------+---------------+---------------|
| 's' | '.' | ... |
+---------------+---------------+---------------+---------------|
| TBD | 56 | 'h' 't' |
+---------------+---------------+---------------+---------------|
| 't' | 'p' | 's' | ':' |
+---------------+---------------+---------------+---------------|
| '/' | '/' | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>[NOTE TO IANA/RFC-EDITOR: Please replace TBD above with the
assigned LuriType value and remove this note]</t>
</section>
<section anchor="policy-example-sec" title="Basic Access Control Policy">
<t>Consider a client that gets the policy URI
<https://ls.example.com:9768/policy/357lp6f64prlbvhl5nk3b>, as
in the 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:</t>
<figure>
<artwork><![CDATA[
GET /policy/357lp6f64prlbvhl5nk3b 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"
xmlns:gp="urn:ietf:params:xml:ns:geolocation-policy">
<rule id="AA56ia9">
<conditions>
<validity>
<until>2011-01-01T13:00:00.0Z</until>
</validity>
</conditions>
<actions/>
<transformations>
<gp:provide-location/>
<gp:set-retransmission-allowed>
false
</gp:set-retransmission-allowed>
<gp:set-retention-expiry>0</gp:set-retention-expiry>
</transformations>
</rule>
</ruleset>
]]></artwork>
</figure>
<t>This policy allows any requester to obtain location information, as
long as they know the location URI. 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 the client can install
this policy on the Location Server:</t>
<figure>
<artwork><![CDATA[
PUT /policy/357lp6f64prlbvhl5nk3b 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>
<validity>
<until>2011-01-01T13:00:00.0Z</until>
</validity>
</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/357lp6f64prlbvhl5nk3b HTTP/1.1
Host: ls.example.com:9768
HTTP/1.1 200 OK
]]></artwork>
</figure>
</section>
</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, <spanx style="verb">urn:ietf:params:xml:ns:geopriv:held:policy</spanx>,
per the guidelines in <xref target="RFC3688"></xref>. <list
hangIndent="3" style="empty">
<t>URI: urn:ietf:params:xml:ns:geopriv:held:policy</t>
<t>Registrant Contact: IETF, GEOPRIV working group,
(geopriv@ietf.org), Richard Barnes (rbarnes@bbn.com).</t>
<t>XML: <figure>
<artwork><![CDATA[
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></t>
</list></t>
</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 hangIndent="3" style="hanging">
<t
hangText="URI:">urn:ietf:params:xml:schema:geopriv:held:policy</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 |
+------------+----------------------------------------+-----------+
| 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.
]]></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 and
confidentially transmitted to the client, and second, the policy
document has to be faithfully and confidentially transmitted to the
Location Server. The mechanism also needs to ensure that only authorized
entities are able to acquire or alter policy.</t>
<section title="Integrity and Confidentiality for Authorization Policy Data">
<t>Each LCP ensures integrity and confidentiality through different
means (see <xref target="RFC5985"></xref> and <xref
target="I-D.ietf-geopriv-dhcp-lbyr-uri-option"></xref>). These
measures ensure that a policy URI is conveyed to the client without
modification or interception.</t>
<t>To protect the integrity and confidentiality of policy data during
management, the Location Server SHOULD provide policy URIs with the
<spanx style="verb">https:</spanx> scheme and require the use of <xref
target="RFC2818">HTTP over TLS</xref>. The cipher suites required by
<xref target="RFC5246">TLS</xref> provide both integrity protection
and confidentiality. If other means of protection are available, an
<spanx style="verb">http:</spanx> URI MAY be used.</t>
</section>
<section title="Access Control for Authorization Policy">
<t>Access control for the policy resource is based on knowledge of its
URI. The URI of a policy resource operates under the same constraints
as a <xref target="RFC5808">possession model location URI</xref> and
is subject to the same constraints: <list style="symbols">
<t>Knowledge of a policy URI MUST be restricted to authorized Rule
Makers. Confidentiality is required for its conveyance in the
location configuration protocol, and in the requests that are used
to inspect, change or delete the policy resource.</t>
<t>The Location Server MUST ensure that the URI cannot be easily
predicted. The policy URI MUST NOT be derived solely from
information that might be public, including the Target identity or
any location URI. The addition of random entropy increases the
difficulty of guessing a policy URI.</t>
</list></t>
<!-- <t>Additional requestor authentication MAY be used for policy resources. For instance, in the particular case where the Device is identified to the Location Server by its IP address, the Location Server could use IP return routability as an additional authentication mechanism.</t> -->
</section>
<section title="Location URI Allocation">
<t>A policy URI enables the <xref target="RFC5808">authorization by
access control lists model</xref> for associated location URIs. Under
this model, it might be possible to more widely distribute a location
URI, relying on the authorization policy to constrain access to
location information.</t>
<t>To allow for wider distribution, authorization by access control
lists places additional constraints on the construction of location
URIs.</t>
<t>If multiple Targets share a location URI, an unauthorized location
recipient that acquires location URIs for the Targets can determine
that the Targets are at the same location by comparing location URIs.
With shared policy URIs, Targets are able to see and modify
authorization policy for other Targets.</t>
<t>To allow for the creation of Target-specific authorization policies
that are adequately privacy-protected, each location URI and policy
URI that is issued to a different Target MUST be different from other
location URIs and policy URIs. That is, two clients MUST NOT receive
the same location URI or the same policy URI.</t>
<t>In some deployments, it is not always apparent to a LCP server that
two clients are different. In particular, where a <xref
target="RFC3234">middlebox</xref> exists two or more clients might
appear as a single client. An example of a deployment scenario of this
nature is described in <xref target="RFC5687"></xref>. An LCP server
MUST create a different location URI and policy URI for every request,
unless the requests can be reliably identified as being from the same
client.</t>
</section>
</section>
<section anchor="ack-sec" title="Acknowledgements">
<t>Thanks to Mary Barnes and Alissa Cooper for providing critical
commentary and input on the ideas described in this document, and to Ted
Hardie and Adam Roach for helping clarify the relationships between
policy URIs, policy documents, and location resources.</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.2616.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2818.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.5246.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3688.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5985.xml"?>
<?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.3234.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3693.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4119.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4825.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4918.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5606.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5687.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5808.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6155.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-policy"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6225.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-deref-protocol"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 00:11:47 |