doc: Add RFC documents

1 files changed, 1403 insertions, 0 deletions

diff --git a/doc/rfc/rfc6753.txt b/doc/rfc/rfc6753.txt
new file mode 100644
index 0000000..da6b737
--- /dev/null
+++ b/doc/rfc/rfc6753.txt
@@ -0,0 +1,1403 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                   J. Winterbottom
+Request for Comments: 6753                                     Commscope
+Category: Standards Track                                  H. Tschofenig
+ISSN: 2070-1721                                   Nokia Siemens Networks
+                                                          H. Schulzrinne
+                                                     Columbia University
+                                                              M. Thomson
+                                                               Microsoft
+                                                            October 2012
+
+
+                 A Location Dereference Protocol Using
+                 HTTP-Enabled Location Delivery (HELD)
+
+Abstract
+
+   This document describes how to use the Hypertext Transfer Protocol
+   (HTTP) over Transport Layer Security (TLS) as a dereference protocol
+   to resolve a reference to a Presence Information Data Format Location
+   Object (PIDF-LO).  This document assumes that a Location Recipient
+   possesses a URI that can be used in conjunction with the HTTP-Enabled
+   Location Delivery (HELD) protocol to request the location of the
+   Target.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6753.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Winterbottom, et al.         Standards Track                    [Page 1]
+
+RFC 6753                   HELD Dereferencing               October 2012
+
+
+Copyright Notice
+
+   Copyright (c) 2012 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   3.  HELD Dereference Protocol  . . . . . . . . . . . . . . . . . .  4
+     3.1.  HELD Usage Profile . . . . . . . . . . . . . . . . . . . .  4
+     3.2.  HTTP GET Behavior  . . . . . . . . . . . . . . . . . . . .  5
+   4.  Authorization Models . . . . . . . . . . . . . . . . . . . . .  6
+     4.1.  Authorization by Possession  . . . . . . . . . . . . . . .  7
+     4.2.  Authorization via Access Control . . . . . . . . . . . . .  8
+     4.3.  Access Control with HELD Dereference . . . . . . . . . . .  9
+   5.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
+   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
+   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
+   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
+     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 15
+     8.2.  Informative References . . . . . . . . . . . . . . . . . . 15
+   Appendix A.  GEOPRIV Using Protocol Compliance . . . . . . . . . . 18
+   Appendix B.  Compliance to Location Reference Requirements . . . . 21
+     B.1.  Requirements for a Location Configuration Protocol . . . . 21
+     B.2.  Requirements for a Location Dereference Protocol . . . . . 23
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Winterbottom, et al.         Standards Track                    [Page 2]
+
+RFC 6753                   HELD Dereferencing               October 2012
+
+
+1.  Introduction
+
+   A location URI [RFC5808] identifies a resource that contains the
+   location of an entity.  This document specifies how a holder of an
+   "http:" or "https:" location URI uses that URI to retrieve location
+   information using a subset of HELD functionality or an HTTP GET
+   request.
+
+   A location URI can be acquired using a location configuration
+   protocol, such as HTTP-Enabled Location Delivery (HELD) [RFC5985] or
+   the Dynamic Host Configuration Protocol (DHCP) location URI option
+   [DHCP-URI-OPT].
+
+   A Location Recipient that dereferences a location URI acquires
+   location information in the form of a Presence Information Data
+   Format - Location Object (PIDF-LO) document [RFC4119].  HELD
+   parameters allow for specifying the type of location information,
+   though some constraints are placed on allowable parameters.
+
+   Location URIs compatible with HELD dereferencing use the "https:" or
+   "http:" scheme.  HELD can be used by Location Recipients that are
+   aware of the fact that the URI is a location URI.  Mandatory support
+   for an HTTP GET request ensures that the URI can be used even if it
+   is not recognized as a location URI.
+
+2.  Terminology
+
+   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 [RFC2119].
+
+   This document uses key terminology from several sources:
+
+   o  The terms for the GEOPRIV reference model defined are in
+      [RFC6280].
+
+   o  The term "Location Information Server (LIS)", from [RFC5687], is a
+      node in the access network that provides location information to
+      an endpoint.  A LIS provides location URIs.
+
+   o  The term "Location Server (LS)", from [RFC6280], is used to
+      identify the role that responds to a location dereference request.
+      A Location Server might be the same entity as the LIS, but the
+      model in [RFC5808] allows for the existence of separate -- but
+      related -- entities.
+
+   o  The term "location URI" is coined in [RFC5808].
+
+
+
+
+Winterbottom, et al.         Standards Track                    [Page 3]
+
+RFC 6753                   HELD Dereferencing               October 2012
+
+
+3.  HELD Dereference Protocol
+
+   This section describes how HELD can be used to dereference a location
+   URI.  This process can be applied when a Location Recipient is in
+   possession of a location URI with an "https:" or "http:" URI scheme.
+
+   This document does not describe a specific authentication mechanism.
+   This means that authorization policies are unable to specifically
+   identify authorized Location Recipients.
+
+   A Location Recipient that wishes to dereference an "https:" or
+   "http:" URI performs a HELD request on HTTP to the identified
+   resource.
+
+      Note: In many cases, an "http:" URI does not provide sufficient
+      security for location URIs.  The absence of the security
+      mechanisms provided by TLS means that the Rule Maker has no
+      control over who receives location information, and the Location
+      Recipient has no assurance that the information is correct.
+
+   The Location Recipient establishes a connection to the LS, as
+   described in [RFC2818].
+
+   The scheme of a location URI determines whether or not TLS is used on
+   a given dereference transaction.  Location Servers MUST be configured
+   to issue only HTTPS URIs and respond to only to HTTPS dereference
+   requests, unless confidentiality and integrity protection are
+   provided by some other mechanism.  For example, the server might only
+   accept requests from clients within a trusted network or via an
+   IPsec-protected channel.  When TLS is used, the TLS ciphersuite
+   TLS_NULL_WITH_NULL_NULL MUST NOT be used, and the LS MUST be
+   authenticated [RFC6125] to ensure that the correct server is
+   contacted.
+
+   A Location Server MAY reject a request and ask that a Location
+   Recipient provide authentication credentials if authorization is
+   dependent on the Location Recipient identity.  Future specifications
+   could define an authentication mechanism and a means by which
+   Location Recipients are identified in authorization policies.  This
+   document does not provide definitions for either item.
+
+3.1.  HELD Usage Profile
+
+   Use of HELD as a location dereference protocol is largely the same as
+   its use as a location configuration protocol.  Aside from the
+   restrictions noted in this document, HELD semantics do not differ
+   from those established in [RFC5985].
+
+
+
+
+Winterbottom, et al.         Standards Track                    [Page 4]
+
+RFC 6753                   HELD Dereferencing               October 2012
+
+
+   The HELD "locationRequest" is the only request permitted by this
+   specification.  Similarly, request parameters other than the
+   following MUST NOT be accepted by the LS: "responseTime" and
+   "locationType" (including the associated "exact" attribute).
+
+   Parameters and requests that do not have known behavior for
+   dereference requests MUST NOT be used.  The LS MUST ignore any
+   parameters that it does not understand unless it knows the parameters
+   to be invalid.  If parameters are understood by the LS and known to
+   be invalid, the LS MAY generate a HELD error response.  For instance,
+   those defined in [RFC6155] are always invalid and can be rejected.
+
+   The LS MUST NOT generate location URIs or provide a "locationUriSet"
+   in response to a dereference request.  If the location request
+   contains a "locationType" element that includes "locationURI", this
+   parameter is either ignored or rejected as appropriate, based on the
+   associated "exact" attribute.
+
+3.2.  HTTP GET Behavior
+
+   GET is the method assumed by generic HTTP user agents; therefore,
+   unless context identifies an "https:" URI as a HELD URI, such a user
+   agent might simply send an HTTP GET.  Rather than providing an HTTP
+   405 (Method Not Allowed) response indicating that POST is the only
+   permitted method, a LIS MUST provide a HELD location response if it
+   receives an HTTP GET request.
+
+   An HTTP GET request to a HELD URI produces a HELD response as if the
+   following HELD request had been sent using HTTP POST:
+
+     <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">
+       <locationType exact="false">
+         geodetic civic
+       </locationType>
+     </locationRequest>
+
+             Figure 1: GET Request Equivalent Location Request
+
+   HTTP GET requests MUST be safe and idempotent [RFC2616] -- that is,
+   there are no side effects of making the request, and a repeated
+   request has no more effect than a single request.  Repeating a HELD
+   request might result in a different location, but only as a result of
+   a change in the state of the resource: the location of the Target.
+
+   Only the creation of a location URI as a result of receiving a
+   request causes a HELD request to have side effects.  A request to a
+   location URI can be both safe and idempotent, since a location URI
+   cannot be produced in response to a request to a location URI.  A
+
+
+
+Winterbottom, et al.         Standards Track                    [Page 5]
+
+RFC 6753                   HELD Dereferencing               October 2012
+
+
+   Location Recipient MAY infer from a response containing the HELD
+   content type "application/held+xml" that a URI references a resource
+   that supports HELD.
+
+   Content negotiation MAY be supported to produce a presence document
+   in place of a HELD location response.  Where the presence document
+   would otherwise be included in a "locationResponse" document, it can
+   be included in the body of the HTTP response directly by including an
+   "Accept" header that includes "application/pidf+xml".
+
+4.  Authorization Models
+
+   This section discusses two extreme types of authorization models for
+   dereferencing with HELD URIs, namely "Authorization by Possession"
+   and "Authorization by Access Control".  In the subsequent
+   subsections, we discuss the properties of these two models.
+   Figure 2, from [RFC5808], shows the model applicable to location
+   configuration, conveyance, and dereference.
+
+             +---------+--------+   Location    +-----------+
+             |         |        |  Dereference  | Location  |
+             |   LIS   -   LS   +---------------+ Recipient |
+             |         |        |   Protocol    |           |
+             +----+----+--------+      (3)      +-----+-----+
+                  |         `.                        |
+                  |    Policy `.                      |
+    Location      |    Exchange `.                    |
+    Configuration |      (*)      |                   |
+    Protocol      |          +----+----+              |
+      (1)         |          |  Rule   |   Location   |
+                  |          |  Maker  |   Conveyance |
+            +-----+----+     +---------+   Protocol   |
+            |          |                      (2)     |
+            |  Target  +------------------------------+
+            |          |
+            +----------+
+
+                       Figure 2: Communication Model
+
+   It is important to note that this document does not mandate a
+   specific authorization model.  It is possible to combine aspects of
+   both models.  However, no authentication framework is provided, which
+   limits the policy options available when the "Authorization by Access
+   Control" model is used.
+
+
+
+
+
+
+
+Winterbottom, et al.         Standards Track                    [Page 6]
+
+RFC 6753                   HELD Dereferencing               October 2012
+
+
+   For either authorization model, the overall process is similar.  The
+   following steps are followed, with minor alterations:
+
+   1.  The Target acquires a location URI from the LIS.  This uses a
+       location configuration protocol (LCP), such as HELD or DHCP.
+
+   2.  The Target then conveys the location URI to a third party, the
+       Location Recipient (for example, using SIP as described in
+       [RFC6442]).  This step is shown in (2) of Figure 2.
+
+   3.  The Location Recipient then needs to dereference the location URI
+       in order to obtain the Location Object (3).  An "https:" or
+       "http:" URI is dereferenced as described in this document; other
+       URI schemes might be dereferenced using another method.
+
+   In this final step, the Location Server (LS) or LIS makes an
+   authorization decision.  How this decision is reached depends on the
+   authorization model.
+
+4.1.  Authorization by Possession
+
+   In this model, possession -- or knowledge -- of the location URI is
+   used to control access to location information.  A location URI might
+   be constructed such that it is hard to guess (see C8 of [RFC5808]),
+   and the set of entities that it is disclosed to can be limited.  The
+   only authentication this would require by the LS is evidence of
+   possession of the URI.  The LS could immediately authorize any
+   request that indicates this URI.
+
+   Authorization by possession does not require direct interaction with
+   a Rule Maker; it is assumed that the Rule Maker is able to exert
+   control over the distribution of the location URI.  Therefore, the
+   LIS can operate with limited policy input from a Rule Maker.
+
+   Limited disclosure is an important aspect of this authorization
+   model.  The location URI is a secret; therefore, ensuring that
+   adversaries are not able to acquire this information is paramount.
+   Encryption, such as might be offered by TLS [RFC5246] or S/MIME
+   [RFC5751], protects the information from eavesdroppers.
+
+   Use of authorization by possession location URIs in a hop-by-hop
+   protocol such as SIP [RFC3261] adds the possibility of on-path
+   adversaries.  Depending on the usage of the location URI for certain
+   location-based applications (e.g., emergency services and location-
+   based routing), specific treatment is important, as discussed in
+   [RFC6442].
+
+
+
+
+
+Winterbottom, et al.         Standards Track                    [Page 7]
+
+RFC 6753                   HELD Dereferencing               October 2012
+
+
+   Using possession as a basis for authorization means that, once
+   granted, authorization cannot be easily revoked.  Cancellation of a
+   location URI ensures that legitimate users are also affected;
+   application of additional policy is theoretically possible but could
+   be technically infeasible.  Expiration of location URIs limits the
+   usable time for a location URI, requiring that an attacker continue
+   to learn new location URIs to retain access to current location
+   information.
+
+   A very simple policy might be established at the time that a location
+   URI is created.  This policy specifies that the location URI expires
+   after a certain time, which limits any inadvertent exposure of
+   location information to adversaries.  The expiration time of the
+   location URI might be negotiated at the time of its creation, or it
+   might be unilaterally set by the LIS.
+
+4.2.  Authorization via Access Control
+
+   Use of explicit access control provides a Rule Maker greater control
+   over the behavior of an LS.  In contrast to authorization by
+   possession, possession of this form of location URI does not imply
+   authorization.  Since an explicit policy is used to authorize access
+   to location information, the location URI can be distributed to many
+   potential Location Recipients.
+
+   Either before creation or dissemination of the location URI, the Rule
+   Maker establishes an authorization policy with the LS.  In reference
+   to Figure 2, authorization policies might be established at creation
+   (Step 1) and need to be established before the location URI is
+   published (Step 2) to ensure that the policy grants access to the
+   desired Location Recipients.  Depending on the mechanism used, it
+   might also be possible to change authorization policies at any time.
+
+   A possible format for these authorization policies is available with
+   GEOPRIV Common Policy [RFC4745] and Geolocation Policy
+   [GEOPRIV-POLICY].  Additional constraints might be established by
+   other means.
+
+   The LS enforces the authorization policy when a Location Recipient
+   dereferences the URI.  Explicit authorization policies allow a Rule
+   Maker to specify how location information is provided to Location
+   Recipients.
+
+
+
+
+
+
+
+
+
+Winterbottom, et al.         Standards Track                    [Page 8]
+
+RFC 6753                   HELD Dereferencing               October 2012
+
+
+4.3.  Access Control with HELD Dereference
+
+   This document does not describe a specific authentication mechanism;
+   therefore, the authorization by access control model is not an
+   option.  Instead, this document assumes the authorization by
+   possession model.
+
+   Other policy mechanisms, such as those described in [GEOPRIV-POLICY],
+   can be applied for different Location Recipients if each recipient is
+   given a different location URI.  Each location URI can be assigned a
+   different authorization policy.  Selective disclosure used in this
+   fashion can be used in place of identity-based authorization.
+
+   How policy is associated with a location URI is not defined by this
+   document.  [GEOPRIV-POLICY-URI] describes one possible mechanism.
+
+   Use of an identity-based authorization policy is not precluded.  A
+   Location Server MAY support an authentication mechanism that enables
+   identity-based authorization policies to be used.  Future
+   specifications might define means of identifying recipients.
+
+      Note: Policy frameworks like [RFC4745] degrade in a way that
+      protects privacy if features are not supported.  If a policy
+      specifies a rule that is conditional on the identity of a
+      recipient and the protocol does not (or cannot) provide an
+      assertion identity of the recipient, the rule has no effect, and
+      the policy defaults to providing less information.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Winterbottom, et al.         Standards Track                    [Page 9]
+
+RFC 6753                   HELD Dereferencing               October 2012
+
+
+5.  Examples
+
+   An example scenario envisioned by this document is shown in Figure 3.
+   This diagram shows how a location dereference protocol fits with
+   location configuration and conveyance.  [RFC5808] contains more
+   information on this scenario and others like it.
+                            +-------------+
+   +------------+           |  Location   |            +-----------+
+   | End Device |           | Information |            | Location  |
+   |  (Target)  |           |   Server    |            | Recipient |
+   +-----+------+           +------+------+            +-----+-----+
+         |                         |                         |
+      .- + - - - - - - - - - - - - + -.                      |
+      :  |     locationRequest     |  :                      |
+      .  |----(for location URI)-->|  .                      |
+      :  |                         |  : Location             |
+      .  |     locationResponse    |  . Configuration        |
+      :  |<-----(location URI)-----|  :                      |
+      .  |                         |  .                      |
+      `- + - - - - - - - - - - - - + -'                      |
+         |                         |                         |
+         |                Location Conveyance                |
+         |~ ~ ~ ~ ~ ~ ~ ~ ~ ~(location URI)~ ~ ~ ~ ~ ~ ~ ~ ~>|
+         |                         |                         |
+         |                      .- + - - - - - - - - - - - - + -.
+         |                      :  |     locationRequest     |  :
+         |                      .  |<------(for civic)-------|  .
+         |        Dereferencing :  |                         |  :
+         |                      .  |     locationResponse    |  .
+         |                      :  |--------(PIDF-LO)------->|  :
+         |                      .  |                         |  .
+         |                      `- + - - - - - - - - - - - - + -'
+         |                         |                         |
+
+            Figure 3: Example of Dereference Protocol Exchange
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Winterbottom, et al.         Standards Track                   [Page 10]
+
+RFC 6753                   HELD Dereferencing               October 2012
+
+
+   The example in Figure 4 shows the simplest form of dereferencing
+   request using HELD to the location URI
+   "https://ls.example.com:49152/uri/w3g61nf5n66p0".  The only way that
+   this differs from the example in Section 10.1 of [RFC5985] is in the
+   request URI and the source of the URI.
+
+   POST /uri/w3g61nf5n66p0 HTTP/1.1
+   Host: ls.example.com:49152
+   Content-Type: application/held+xml
+   Content-Length: 87
+
+   <?xml version="1.0"?>
+   <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"/>
+
+                  Figure 4: Minimal Dereferencing Request
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Winterbottom, et al.         Standards Track                   [Page 11]
+
+RFC 6753                   HELD Dereferencing               October 2012
+
+
+   Figure 5 shows the response to the previous request listing both
+   civic and geodetic location information of the Target's location.
+   Again, this is identical to the response in Section 10.1 of [RFC5985]
+   -- unless policy specifies otherwise, the Location Recipient receives
+   the same information as the Device.
+
+   HTTP/1.1 200 OK
+   Server: Example LIS
+   Date: Mon, 10 Jan 2011 03:42:29 GMT
+   Expires: Tue, 11 Jan 2011 03:42:29 GMT
+   Cache-control: private
+   Content-Type: application/held+xml
+   Content-Length: 676
+
+   <?xml version="1.0"?>
+   <locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
+   <presence xmlns="urn:ietf:params:xml:ns:pidf"
+             entity="pres:3650n87934c@ls.example.com">
+     <tuple id="b650sf789nd">
+     <status>
+      <geopriv xmlns="urn:ietf:params:xml:ns:pidf:geopriv10"
+        xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basic-policy">
+       <location-info>
+          <Point xmlns="http://www.opengis.net/gml"
+                 srsName="urn:ogc:def:crs:EPSG::4326">
+            <pos>-34.407 150.88001</pos>
+          </Point>
+        </location-info>
+        <usage-rules>
+          <gbp:retransmission-allowed>
+            false</gbp:retransmission-allowed>
+          <gbp:retention-expiry>
+            2011-01-11T03:42:29+00:00</gbp:retention-expiry>
+        </usage-rules>
+        <method>Wiremap</method>
+      </geopriv>
+     </status>
+     <timestamp>2006-01-10T03:42:28+00:00</timestamp>
+     </tuple>
+   </presence>
+   </locationResponse>
+
+               Figure 5: Response with Location Information
+
+
+
+
+
+
+
+
+Winterbottom, et al.         Standards Track                   [Page 12]
+
+RFC 6753                   HELD Dereferencing               October 2012
+
+
+   The following GET request is treated in an equivalent fashion.  The
+   LS treats this request as though it were a location request of the
+   form shown in Figure 1.  The same response might be provided.
+
+   GET /uri/w3g61nf5n66p0 HTTP/1.1
+   Host: ls.example.com:49152
+   Accept: application/held+xml
+
+                           Figure 6: GET Request
+
+   The following GET request uses content negotiation to indicate a
+   preference for a presence document.
+
+   GET /uri/w3g61nf5n66p0 HTTP/1.1
+   Host: ls.example.com:49152
+   Accept: application/pidf+xml,application/held+xml;q=0.5
+
+              Figure 7: GET Request with Content Negotiation
+
+   The response only differs from a normal HELD location response to a
+   POST request in that the "locationResponse" element is omitted and
+   the "Content-Type" header reflects the changed content.
+
+   HTTP/1.1 200 OK
+   Server: Example LIS
+   Date: Mon, 10 Jan 2011 03:42:29 GMT
+   Expires: Tue, 11 Jan 2011 03:42:29 GMT
+   Cache-control: private
+   Content-Type: application/pidf+xml
+   Content-Length: 591
+
+   <?xml version="1.0"?>
+   <presence xmlns="urn:ietf:params:xml:ns:pidf"
+             entity="pres:3650n87934c@ls.example.com">
+     <!-- PIDF contents are identical to the previous example -->
+   </presence>
+
+                    Figure 8: GET Response with PIDF-LO
+
+6.  Security Considerations
+
+   Privacy of location information is the most important security
+   consideration for this document.  Two measures in particular are used
+   to protect privacy: TLS and authorization policies.  TLS provides a
+   means of ensuring confidentiality of location information through
+   encryption and mutual authentication.  An authorization policy allows
+   a Rule Maker to explicitly control how location information is
+   provided to Location Recipients.
+
+
+
+Winterbottom, et al.         Standards Track                   [Page 13]
+
+RFC 6753                   HELD Dereferencing               October 2012
+
+
+   The process by which a Rule Maker establishes an authorization policy
+   is not covered by this document; several methods are possible, for
+   instance, [GEOPRIV-POLICY-URI] and [RFC4825].
+
+   TLS MUST be used for dereferencing location URIs unless
+   confidentiality and integrity are provided by some other mechanism,
+   as discussed in Section 3.  Location Recipients MUST authenticate the
+   host identity using the domain name included in the location URI,
+   using the procedure described in Section 3.1 of [RFC2818].  Local
+   policy determines what a Location Recipient does if authentication
+   fails or cannot be attempted.
+
+   The authorization by possession model (Section 4.1) further relies on
+   TLS when transmitting the location URI to protect the secrecy of the
+   URI.  Possession of such a URI implies the same privacy
+   considerations as possession of the PIDF-LO document that the URI
+   references.
+
+   Location URIs MUST only be disclosed to authorized Location
+   Recipients.  The GEOPRIV architecture [RFC6280] designates the Rule
+   Maker to authorize disclosure of the URI.
+
+   Protection of the location URI is necessary, since the policy
+   attached to such a location URI permits anyone who has the URI to
+   view the associated location information.  This aspect of security is
+   covered in more detail in the specification of location conveyance
+   protocols, such as [RFC6442].
+
+   According to the requirements in [RFC5808] the LS MUST NOT provide
+   any information about the Target except its location, unless policy
+   from a Rule Maker allows otherwise.  Thus, the Location Server MUST
+   only provide an unlinked pseudonym in the "entity" attribute of the
+   PIDF-LO document unless the Rule Maker policy allows for identity
+   disclosure.
+
+   Further security considerations and requirements relating to the use
+   of location URIs are described in [RFC5808].
+
+7.  Acknowledgements
+
+   Thanks to Barbara Stark and Guy Caron for providing early comments.
+   Thanks to Rohan Mahy for constructive comments on the scope and
+   format of the document.  Thanks to Ted Hardie for his strawman
+   proposal that provided assistance with the security section of this
+   document.  Richard Barnes made helpful observations on the
+   application of authorization policy.  Bernard Aboba and Julian
+   Reschke contributed constructive reviews.
+
+
+
+
+Winterbottom, et al.         Standards Track                   [Page 14]
+
+RFC 6753                   HELD Dereferencing               October 2012
+
+
+   The participants of the GEOPRIV interim meeting 2008 provided
+   significant feedback on this document.
+
+   James Polk provided input on security in June 2008.
+
+   Martin Dawson was an original author of this document.  Sadly, he
+   passed away prior to its publication.
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
+              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
+              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
+
+   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
+
+   [RFC4119]  Peterson, J., "A Presence-based GEOPRIV Location Object
+              Format", RFC 4119, December 2005.
+
+   [RFC5491]  Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
+              Presence Information Data Format Location Object (PIDF-LO)
+              Usage Clarification, Considerations, and Recommendations",
+              RFC 5491, March 2009.
+
+   [RFC5985]  Barnes, M., "HTTP-Enabled Location Delivery (HELD)",
+              RFC 5985, September 2010.
+
+   [RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and
+              Verification of Domain-Based Application Service Identity
+              within Internet Public Key Infrastructure Using X.509
+              (PKIX) Certificates in the Context of Transport Layer
+              Security (TLS)", RFC 6125, March 2011.
+
+8.2.  Informative References
+
+   [DHCP-URI-OPT]
+              Polk, J., "Dynamic Host Configuration Protocol (DHCP) IPv4
+              and IPv6 Option for a Location Uniform Resource Identifier
+              (URI)", Work in Progress, May 2012.
+
+
+
+
+
+
+
+Winterbottom, et al.         Standards Track                   [Page 15]
+
+RFC 6753                   HELD Dereferencing               October 2012
+
+
+   [GEOPRIV-POLICY]
+              Schulzrinne, H., Tschofenig, H., Cuellar, J., Polk, J.,
+              Morris, J., and M. Thomson, "Geolocation Policy: A
+              Document Format for Expressing Privacy Preferences for
+              Location Information", Work in Progress, August 2012.
+
+   [GEOPRIV-POLICY-URI]
+              Barnes, R., Thomson, M., Winterbottom, J., and H.
+              Tschofenig, "Location Configuration Extensions for Policy
+              Management", Work in Progress, November 2011.
+
+   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
+              A., Peterson, J., Sparks, R., Handley, M., and E.
+              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
+              June 2002.
+
+   [RFC3693]  Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
+              J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
+
+   [RFC4745]  Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J.,
+              Polk, J., and J. Rosenberg, "Common Policy: A Document
+              Format for Expressing Privacy Preferences", RFC 4745,
+              February 2007.
+
+   [RFC4825]  Rosenberg, J., "The Extensible Markup Language (XML)
+              Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
+
+   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.2", RFC 5246, August 2008.
+
+   [RFC5687]  Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
+              Location Configuration Protocol: Problem Statement and
+              Requirements", RFC 5687, March 2010.
+
+   [RFC5751]  Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
+              Mail Extensions (S/MIME) Version 3.2 Message
+              Specification", RFC 5751, January 2010.
+
+   [RFC5808]  Marshall, R., "Requirements for a Location-by-Reference
+              Mechanism", RFC 5808, May 2010.
+
+   [RFC6155]  Winterbottom, J., Thomson, M., Tschofenig, H., and R.
+              Barnes, "Use of Device Identity in HTTP-Enabled Location
+              Delivery (HELD)", RFC 6155, March 2011.
+
+
+
+
+
+
+
+Winterbottom, et al.         Standards Track                   [Page 16]
+
+RFC 6753                   HELD Dereferencing               October 2012
+
+
+   [RFC6280]  Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
+              Tschofenig, H., and H. Schulzrinne, "An Architecture for
+              Location and Location Privacy in Internet Applications",
+              BCP 160, RFC 6280, July 2011.
+
+   [RFC6442]  Polk, J., Rosen, B., and J. Peterson, "Location Conveyance
+              for the Session Initiation Protocol", RFC 6442,
+              December 2011.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Winterbottom, et al.         Standards Track                   [Page 17]
+
+RFC 6753                   HELD Dereferencing               October 2012
+
+
+Appendix A.  GEOPRIV Using Protocol Compliance
+
+   This section describes how use of HELD as a location dereference
+   protocol complies with the GEOPRIV requirements described in
+   [RFC3693].
+
+   Req. 1.  (Location Object generalities):
+
+            This requirement relates to the PIDF-LO [RFC4119] document,
+            which is used by HELD.  These requirements are addressed by
+            [RFC4119] and [RFC5491].
+
+   Req. 2.  (Location Object fields):
+
+            This requirement relates to the PIDF-LO [RFC4119] document,
+            which is used by HELD.  These requirements are addressed by
+            [RFC4119] and [RFC5491].
+
+   Req. 3.  (Location Data Types):
+
+            This requirement relates to the PIDF-LO [RFC4119] document,
+            which is used by HELD.  These requirements are addressed by
+            [RFC4119] and [RFC5491].
+
+   Section 7.2 of [RFC3693] details the requirements of a "Using
+   Protocol".  These requirements are restated, followed by a statement
+   of compliance:
+
+   Req. 4.  "The using protocol has to obey the privacy and security
+            instructions coded in the Location Object and in the
+            corresponding Rules regarding the transmission and storage
+            of the LO".
+
+            Compliant: This specification describes the use of HTTP over
+            TLS for carrying the PIDF-LO from the LS to the Location
+            Recipient.  The sending and receiving parties are expected
+            to comply with the instructions carried inside the object.
+
+            Though discouraged, using unsecured "http:" URIs is
+            permitted.  Using unsecured HTTP is likely to result in non-
+            compliance with this requirement.
+
+
+
+
+
+
+
+
+
+
+Winterbottom, et al.         Standards Track                   [Page 18]
+
+RFC 6753                   HELD Dereferencing               October 2012
+
+
+   Req. 5.  "The using protocol will typically facilitate that the keys
+            associated with the credentials are transported to the
+            respective parties, that is, key establishment is the
+            responsibility of the using protocol".
+
+            Compliant: This document specifies that authentication of
+            the LS uses the established public key infrastructure used
+            by HTTP over TLS [RFC2818].  Authentication of Location
+            Recipients is based on distribution of a secret (the
+            location URI) using a conveyance protocol (for instance,
+            [RFC6442]), allowances are made for later work to define
+            alternative methods.
+
+   Req. 6.  "(Single Message Transfer) In particular, for tracking of
+            small target devices, the design should allow a single
+            message/packet transmission of location as a complete
+            transaction".
+
+            Not Compliant: The XML encoding specified in [RFC4119] is
+            not suited to single packet transfers.  Use of compressed
+            content encoding [RFC2616] might allow this condition to be
+            met.
+
+   Section 7.3 of [RFC3693] details the requirements of a "Rule based
+   Location Data Transfer".  These requirements are restated where they
+   are applicable to this document:
+
+   Req. 7.   "(LS Rules) The decision of a Location Server to provide a
+             Location Recipient access to Location Information MUST be
+             based on Rule Maker-defined Privacy Rules".
+
+             Compliant: This document describes two alternative methods
+             by which a Rule Maker is able to control access to location
+             information.  Rule Maker policy is enforced by the LS when
+             a location URI is dereferenced.  However, this document
+             does not describe how a location URI is created or how a
+             Rule Maker associates policy with a location URI.  These
+             are covered by other specifications.
+
+   Req. 8.   (LG Rules) Not Applicable: This relationship between LS and
+             the source of its information (be that Location Generator
+             (LG) or LIS) is out of the scope of this document.
+
+   Req. 9.   "(Viewer Rules) A Viewer does not need to be aware of the
+             full Rules defined by the Rule Maker (because a Viewer
+             SHOULD NOT retransmit Location Information), and thus a
+             Viewer SHOULD receive only the subset of Privacy Rules
+             necessary for the Viewer to handle the LO in compliance
+
+
+
+Winterbottom, et al.         Standards Track                   [Page 19]
+
+RFC 6753                   HELD Dereferencing               October 2012
+
+
+             with the full Privacy Rules (such as, instruction on the
+             time period for which the LO can be retained)".
+
+             Compliant: The Rule Maker might define (via mechanisms
+             outside the scope of this document) which policy rules are
+             disclosed to other entities.  For instance, if [RFC4745] is
+             used to convey authorization policies from Rule Maker to
+             LS, this is possible using the parameters specified in
+             [GEOPRIV-POLICY].
+
+             In order to comply with these rules, a Location Recipient
+             MUST NOT redistribute a location URI without express
+             permission.  Depending on the access control model, the
+             location URI might be secret (see Section 3.3 of
+             [RFC5808]).
+
+   Req. 10.  (Full Rule language) Not Applicable: Note, however, that
+             GEOPRIV has defined a rule language capable of expressing a
+             wide range of privacy rules (see [RFC4745] and
+             [GEOPRIV-POLICY].
+
+   Req. 11.  (Limited Rule language) Not Applicable: This requirement
+             applies to (and is addressed by) PIDF-LO [RFC4119].
+
+   Section 7.4 of [RFC3693] details the requirements of "Location Object
+   Privacy and Security".  These requirements are restated where they
+   are applicable to this document:
+
+   Req. 12.  (Identity Protection) Compliant: Identity protection of the
+             Target is provided as long as both of the following
+             conditions are true:
+
+             (a)  the location URI is not associated with the identity
+                  of the Target in any context, and
+
+             (b)  the PIDF-LO does not contain information about the
+                  identity of the Target.
+
+             For instance, this requirement is complied with if the
+             protocol that conveys the location URI does not link the
+             identity of the Target to the location URI and the LS
+             doesn't include meaningful identification information in
+             the PIDF-LO document.  Section 6 recommends that an
+             unlinked pseudonym is used by the LS.
+
+
+
+
+
+
+
+Winterbottom, et al.         Standards Track                   [Page 20]
+
+RFC 6753                   HELD Dereferencing               October 2012
+
+
+   Req. 13.  (Credential Requirements) Compliant: The primary security
+             mechanism specified in this document is Transport Layer
+             Security.  TLS offers the ability to use different types of
+             credentials, including symmetric, asymmetric, or a
+             combination of them.
+
+   Req. 14.  (Security Features) Compliant: GEOPRIV defines a few
+             security requirements for the protection of Location
+             Objects such as mutual endpoint authentication, data object
+             integrity, data object confidentiality, and replay
+             protection.  The ability to use Transport Layer Security
+             fulfills most of these requirements.  Authentication of
+             Location Recipients in this document relies on proof of a
+             shared secret -- the location URI.  This does not preclude
+             the addition of more robust authentication procedures.
+
+   Req. 15.  (Minimal Crypto) Compliant: The mandatory-to-implement
+             ciphersuite is provided in the TLS layer security
+             specification [RFC5246].
+
+Appendix B.  Compliance to Location Reference Requirements
+
+   This section describes how HELD complies to the location reference
+   requirements stipulated in [RFC5808].  Compliance of [RFC5985] to the
+   Location Configuration Protocol is included.
+
+      Note: Use of HELD as a location dereference protocol does not
+      necessarily imply that HELD is the corresponding LCP.  This
+      document is still applicable to HTTP location URIs that are
+      acquired by other means.
+
+B.1.  Requirements for a Location Configuration Protocol
+
+   C1.  "Location URI support: The location configuration protocol MUST
+        support a location reference in URI form".
+
+        Compliant: HELD only provides location references in URI form.
+
+   C2.  "Location URI expiration: When a location URI has a limited
+        validity interval, its lifetime MUST be indicated".
+
+        Compliant: HELD indicates the expiry time of location URIs using
+        the "expires" attribute.  [GEOPRIV-POLICY-URI] provides a way to
+        control expiration of a location URI.
+
+   C3.  "Location URI cancellation: The location configuration protocol
+        MUST support the ability to request a cancellation of a specific
+        location URI".
+
+
+
+Winterbottom, et al.         Standards Track                   [Page 21]
+
+RFC 6753                   HELD Dereferencing               October 2012
+
+
+        Compliant with Extension: [GEOPRIV-POLICY-URI] describes how a
+        location URI can be canceled through the application of policy.
+        Without extensions, HELD does not provide a method for canceling
+        location URIs.
+
+   C4.  "Location Information Masking: The location URI MUST ensure, by
+        default, through randomization and uniqueness, that the location
+        URI does not contain location information specific components".
+
+        Compliant: The HELD specification [RFC5985] explicitly
+        references this requirement in providing guidance on the format
+        of the location URI.
+
+   C5.  "Target Identity Protection: The location URI MUST NOT contain
+        information that identifies the Target (e.g., user or device)".
+
+        Compliant: The HELD specification [RFC5985] provides specific
+        guidance on the anonymity of the Target with regards to the
+        generation of location URIs.  Section 6 expands on this
+        guidance.
+
+   C6.  "Reuse indicator: There SHOULD be a way to allow a Target to
+        control whether a location URI can be resolved once only, or
+        multiple times".
+
+        Not Compliant: Specific extensions to the protocol or
+        authorization policy formats are needed to alter the default
+        behavior, which allows unlimited resolution of the location URI.
+
+   C7.  "Selective disclosure: The location configuration protocol MUST
+        provide a mechanism that allows the Rule Maker to control what
+        information is being disclosed about the Target".
+
+        Compliant with Extension: Use of policy mechanisms and
+        [GEOPRIV-POLICY-URI] enable this capability.  Note that this
+        document recommends that only location information be provided.
+
+   C8.  "Location URI Not guessable: As a default, the location
+        configuration protocol MUST return location URIs that are random
+        and unique throughout the indicated lifetime.  A location URI
+        with 128-bits of randomness is RECOMMENDED".
+
+        Compliant: HELD specifies that location URIs conform to this
+        requirement.  The amount of randomness is not specifically
+        identified since it depends on a number of factors that change
+        over time, such as the number of valid location URIs, the
+        validity period of those URIs, and the rate that guesses can be
+        made.
+
+
+
+Winterbottom, et al.         Standards Track                   [Page 22]
+
+RFC 6753                   HELD Dereferencing               October 2012
+
+
+   C9.  "Location URI Options: In the case of user-provided
+        authorization policies, where anonymous or non-guessable
+        location URIs are not warranted, the location configuration
+        protocol MAY support a variety of optional location URI
+        conventions, as requested by a Target to a location
+        configuration server, (e.g., embedded location information
+        within the location URI)".
+
+        Not Compliant: HELD does not support Device-specified location
+        URI forms.
+
+B.2.  Requirements for a Location Dereference Protocol
+
+   D1.  "Location URI support: The location dereference protocol MUST
+        support a location reference in URI form".
+
+        Compliant: HELD only provides location references in URI form.
+
+   D2.  "Authentication: The location dereference protocol MUST include
+        mechanisms to authenticate both the client and the server".
+
+        Partially Compliant: TLS provides means for mutual
+        authentication.  This document only specifies the required
+        mechanism for server authentication.  Client authentication is
+        not precluded.
+
+   D3.  "Dereferenced Location Form: The value returned by the
+        dereference protocol MUST contain a well-formed PIDF-LO
+        document".
+
+        Compliant: HELD requires that Location Objects are in the form
+        of a PIDF-LO that complies with [RFC5491].
+
+   D4.  "Location URI Repeated Use: The location dereference protocol
+        MUST support the ability for the same location URI to be
+        resolved more than once, based on dereference server
+        configuration".
+
+        Compliant: A Location Recipient may access and use a location
+        URI as many times as desired until URI expiration results in the
+        URI being invalidated.  Authorization policies might include
+        rules that modify this behavior.
+
+
+
+
+
+
+
+
+
+Winterbottom, et al.         Standards Track                   [Page 23]
+
+RFC 6753                   HELD Dereferencing               October 2012
+
+
+   D5.  "The location dereference protocol MUST support confidentiality
+        protection of messages sent between the Location Recipient and
+        the location server".
+
+        Compliant: This document strongly recommends the use of TLS for
+        confidentiality, and HELD mandates its implementation.
+        Unsecured HTTP is permitted: the associated risks are described
+        in Section 3.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Winterbottom, et al.         Standards Track                   [Page 24]
+
+RFC 6753                   HELD Dereferencing               October 2012
+
+
+Authors' Addresses
+
+   James Winterbottom
+   Commscope
+   Andrew Building (39)
+   Wollongong University Campus
+   Northfields Avenue
+   Wollongong, NSW  2522
+   AU
+
+   Phone: +61 242 212938
+   EMail: james.winterbottom@commscope.com
+
+
+   Hannes Tschofenig
+   Nokia Siemens Networks
+   Linnoitustie 6
+   Espoo  02600
+   Finland
+
+   Phone: +358 (50) 4871445
+   EMail: Hannes.Tschofenig@gmx.net
+   URI:   http://www.tschofenig.priv.at
+
+
+   Henning Schulzrinne
+   Columbia University
+   Department of Computer Science
+   450 Computer Science Building
+   New York, NY  10027
+   USA
+
+   Phone: +1 212 939 7042
+   EMail: hgs@cs.columbia.edu
+   URI:   http://www.cs.columbia.edu
+
+
+   Martin Thomson
+   Microsoft
+   3210 Porter Drive
+   Palo Alto, CA  94304
+   USA
+
+   Phone: +1 650-353-1925
+   EMail: martin.thomson@skype.net
+
+
+
+
+
+
+Winterbottom, et al.         Standards Track                   [Page 25]
+