<?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
        &lt;https://ls.example.com:9768/policy/357lp6f64prlbvhl5nk3b&gt;, 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>
