One document matched: draft-barnes-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" 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 day="9" month="November" year="2010" />
<!-- 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="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 Device (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, an LCP server (acting for the
Location Server) can inform a client as to which policy document
controls a given location resource, and the LCP client (in its Rule
Maker role) 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 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> 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 replaces
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 and terminate access to the protected
resource. If the request is authorized, then the Location Server
deletes the policy referenced by the URI and disallows any further
access to the location resource it governs.</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 to the
location URI.</t>
<t>A policy URI is provided to a target device as part of the location
configuration process. A policy URI MUST NOT be provided to an entity
that is not authorized to view or set policy. A location server that
provides a location configuration in addition to other location
services (e.g., answering <xref
target="I-D.ietf-geopriv-deref-protocol">dereferencing requests</xref>
or <xref target="I-D.ietf-geopriv-held-identity-extensions">requests
from third parties</xref>) MUST only include policy URIs in response
to location configuration requests.</t>
<t>Each location URI has either one policy URI or no policy URI. A
location server MUST NOT allocate multiple policy URIs controlling the
same locatin 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>Without a policy URI, clients have no way to know what this
default policy is. The safest assumption for clients is that the
default policy grants any request to dereference a location URI,
regardless of the requester's identity. With a policy URI, a
client can ask the server to describe the default policy (with a
GET request), or update the policy with a PUT request, 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 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 is
constructed so that it is hard to predict (see <xref
target="sec-cons-sec"></xref>).</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="I-D.ietf-geopriv-http-location-delivery"></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 as a sub-element of the HELD <spanx
style="verb">locationResponse</spanx> element.</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 requests for the
target's location, including dereference requests for location URIs in
the location response as well as third-party requests. 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.
A ocation server may provide a policy URI regardless of the presence
of this element.</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>
<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 user that gets the policy URI
<https://ls.example.com:9768/policy/357lp6f64prlbvhl5nk3b>, 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/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 he 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="ack-sec" title="Acknowledgements">
<t>Thanks to Mary Barnes, Alissa Cooper, and Hannes Tschofenig for
providing critical commentary and input 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, <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:grip</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="ops-cons" title="Operational Considerations">
<t>Associating a user's privacy preferences with a location URI can have
a performance impact on the location configuration process, both in
terms of protocol execution time and the state that a location server is
required to store. There are additional protocol interactions (as
described above), and the location server must store the user's privacy
policies in addition to purely location-related state.</t>
<t>The mechanism that this document defines for installing policy
conducts policy management actions through a separate set of
interactions from the main location configuration transaction, rather
than carrying policy-management messages in existing location
configuration messages. This design decision imposes the cost of at
least one an additional HTTP transaction on endpoints that wish to
configure privacy policies. At the same time, however, it minimizes the
changes that need to be made to a location configuration protocol, so
that both HELD and DHCP can support policy management in basically the
same fashion.</t>
<t>A server that supports this extension must store additional state for
a location URI. By default, a location server only needs to keep
location-related state for a location URI, so that it can compute
location values to return in response to dereference requests. A server
supporting this extension also has to store policy information. Such a
server can mitigate the impact of this requirement by not storing policy
information explicitly for each location URI. Until a user supplies his
own policies, the server will apply a default policy, which doesn't need
to be described separately for each location URI. So the amount of
policy state that a server has to maintain scales as the number of users
that actually supply their own policy information. If policy URIs are
constructed so that they can be associated with their corresponding
location URIs algorithmically, then the server doesn't even need to
maintain a table to store these associations.</t>
<t>Finally, a server that does not wish to be subject to any of these
costs can opt not to support this extension at all. Such a server would
simply never provide a <spanx style="verb">policyUri</spanx> element in
a response, silently ignoring any <spanx style="verb">requestPolicyUri</spanx>
element it might receive in a request.</t>
</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="I-D.ietf-geopriv-http-location-delivery"></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, every location URI and policy
URI that is issued to a different Target MUST be different. That is,
no two client can receive the same location URI or 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>
<t>Conversely, if a location server chooses to provide the same
location URI and policy URI to multiple endpoints, then it MUST use a
restricted profile of the above protocol for policy management. (A
server might do this to mitigate problems with link-layer
confidentiality, e.g., for multiple clients on a shared medium.) Such
a server MAY allow GET requests to allow clients to know the default
policy, but it MUST NOT allow PUT or DELETE requests to control policy
unless it has an out-of-band mechanism to distinguish and separately
authorize clients.</t>
</section>
</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/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.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/bibxml3/reference.I-D.ietf-geopriv-policy"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-rfc3825bis"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-deref-protocol"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-held-identity-extensions"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 00:05:36 |