GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6753

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6753.txt · Last modified: 2012/10/25 04:08 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki