Internet DRAFT - draft-winterbottom-location-uri


GEOPRIV WG                                               J. Winterbottom
Internet-Draft                                                M. Thomson
Expires: July 24, 2006                                            Andrew
                                                             J. Peterson
                                                           NeuStar, Inc.
                                                        January 20, 2006

                  Rationale for Location by Reference

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on July 24, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).


   An analysis is performed on the advantages and disadvantages for
   provision of Location Information (LI) by-reference in the GEOPRIV
   architecture.  The concept of a Location URI, that is, a URI that
   references LI, is introduced.  A number of usage patterns for
   Location URIs are discussed, particularly with regard to addressing
   mobility.  Security concerns that are introduced by Location URIs are

Winterbottom, et al.      Expires July 24, 2006                 [Page 1]
Internet-Draft                Location URI                  January 2006

   also considered.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Location By-Value  . . . . . . . . . . . . . . . . . . . .  3
     1.2.  Location By-Reference  . . . . . . . . . . . . . . . . . .  3
   2.  Conventions and Terminology  . . . . . . . . . . . . . . . . .  5
   3.  Session Decoupling . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Subscriptions and Presence . . . . . . . . . . . . . . . .  6
     3.2.  Location Format  . . . . . . . . . . . . . . . . . . . . .  6
   4.  Performance and Optimization . . . . . . . . . . . . . . . . .  7
     4.1.  Reducing Device Responsibilities . . . . . . . . . . . . .  7
     4.2.  Open Medium Scenarios  . . . . . . . . . . . . . . . . . .  8
   5.  Device Mobility  . . . . . . . . . . . . . . . . . . . . . . .  9
     5.1.  The Cost of Determining Location Information . . . . . . .  9
     5.2.  Impact of Mobility on By-Value Location  . . . . . . . . .  9
     5.3.  Addressing Mobility  . . . . . . . . . . . . . . . . . . . 10
     5.4.  Expiry of Location Information . . . . . . . . . . . . . . 10
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
     6.1.  Authorizing the Source of Location Information . . . . . . 11
     6.2.  Assigning a Location URI . . . . . . . . . . . . . . . . . 12
     6.3.  Location URI Theft . . . . . . . . . . . . . . . . . . . . 12
       6.3.1.  Protecting the Location URI  . . . . . . . . . . . . . 12
       6.3.2.  Strong Identity Association  . . . . . . . . . . . . . 12
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
   Intellectual Property and Copyright Statements . . . . . . . . . . 15

Winterbottom, et al.      Expires July 24, 2006                 [Page 2]
Internet-Draft                Location URI                  January 2006

1.  Introduction

   The basic GEOPRIV architecture [RFC3693] concentrates on how Location
   Information (LI) is conveyed from creation at a Location Generator
   (LG) to consumption at a Location Recipient (LR).  Particular
   emphasis is placed on ensuring that appropriate privacy constraints
   exist to protect the Target.

   Two primary usage models have evolved from this basic architecture,
   which we shall call _by-value_ and _by-reference_.  This document
   concentrates on the by-reference method for conveyance of LI.  The
   strengths and particular vulnerabilities, from implementation,
   network architecture, security and privacy perspectives are

   This document is intended to provide a guide to making a choice
   between the two approaches, as well as providing some additional
   information on providing LI by-reference.

1.1.  Location By-Value

   The by-value usage model is based on the concept that the Target, as
   the subject of the LI, should also be the owner and controller of the
   data.  The Target receives LI from the LG and is then responsible for
   providing a Location Object (LO) [RFC4119] to LRs.  This model places
   the control over which LRs gain access to LI directly with the

       +-----------+           +--------+          +-----------+
       | Location  |           |        |          | Location  |
       | Generator |---LI/LO-->| Target |----LO--->| Recipient |
       |           |           |        |          |           |
       +-----------+           +--------+          +-----------+

   Figure 1: Basic By-Value Model

   Implicit in this diagram are a number of other entities from the
   GEOPRIV architecture.  The Target also assumes the roles of Rule
   Maker (RM), Rule Holder (RH) and Location Server (LS).  The Device is
   considered to be acting for the Target.

   Two minor variations have evolved from this model, either of the LG
   or Target can construct the LO.

1.2.  Location By-Reference

   When a Location URI is used, a Location Server (LS) is employed to
   manage interactions with LRs.  The Target either explicitly delegates

Winterbottom, et al.      Expires July 24, 2006                 [Page 3]
Internet-Draft                Location URI                  January 2006

   this task, or the LG arranges for this.  The Target then makes a
   Location URI available to the LR, which de-references that URI to
   acquire the Target's LO.

         +-----------+            +-----------+
         | Location  |            | Location  |
         | Generator |---LI/LO--->|  Server   |
         |           |     (a) ,->|           |
         +-----------+        /   +---<URI>---+
              |              /          |
            LI/LO (b)     LI/LO         LO
              |           (b)           |
              V           /             V
         +-----------+   /        +-----------+
         |           |--'         | Location  |
         |  Target   |----URI---->| Recipient |
         |           |            |           |
         +-----------+            +-----------+

   Figure 2: Basic By-Reference Model

   Two variations are shown in the diagram: (a) shows the LG publishing
   LI to the LS directly; (b) shows that the LI is first provided to the
   Target, which then publishes LI to the LS.  Note: To simplify this
   diagram, variations related to privacy and the means by which
   authorization rules are made available to the LS are not shown.

Winterbottom, et al.      Expires July 24, 2006                 [Page 4]
Internet-Draft                Location URI                  January 2006

2.  Conventions and Terminology

   This document uses the terminology and acronyms defined in RFC 3693

   The term _Location URI_ is defined as a reference to a Location
   Object (LO).  A Location URI contains the address of a Location
   Server (LS) and provides sufficient additional information for the LS
   to be able to retrieve a LO.  Location URI is preferred over the term
   _location-key_, which is sometimes used in this context.

Winterbottom, et al.      Expires July 24, 2006                 [Page 5]
Internet-Draft                Location URI                  January 2006

3.  Session Decoupling

   A Location URI decouples interactions between LR and LS from any
   application-specific interactions between Target and LR.  This
   introduces the possibility of a different protocol, and enables more
   sophisticated interactions between LR and LS.

3.1.  Subscriptions and Presence

   The LR is able to subscribe to the LS for notifications of changes in
   a particular Target's location.  The LR is also able to provide its
   own time and resolution constraints to limit these notifications, see
   [I-D.mahy-geopriv-loc-filters].  This subscribe/notify mode of
   operation closely matches the general presence model [RFC3859].

   Note: In order to support a subscription service for location the LG
   must be able to detect changes in location and then communicate these
   changes to the LS.

3.2.  Location Format

   When LI is provided to an LR by-value, the LR is somewhat dependent
   on the Target to provide LI in a form that can be used.  For
   instance, the LR could be unable to make use of a civic address
   [I-D.ietf-geopriv-revised-civic-lo].  Therefore, application
   protocols that support by-value provision of LI need to support
   negotiation for the correct form of LI.

   A Location URI enables the retrieval of LI directly from the LS; the
   LR can request the necessary form of LI directly.  This reduces the
   level of support required for LI in application protocols.

Winterbottom, et al.      Expires July 24, 2006                 [Page 6]
Internet-Draft                Location URI                  January 2006

4.  Performance and Optimization

   Using a Location URI also introduces a retrieval step that could add
   additional delay to a time-critical application.  By-value location
   can be used in these situations to remove this step; if a Target is
   able to acquire LI beforehand, this information can be provided by-
   value, thus avoiding adding delays.  However, care must be taken to
   ensure the validity of LI, particularly when the Target is mobile,
   see Section 5.

   Note also that if a time-critical operation is started when LI is not
   available, by-value location provision is delayed until location
   generation has completed.

   Using Location URIs places the control over when location is
   generated with the LR.  Again, in a time-critical application this
   also means that the LR may be forced to wait for location generation
   to occur.

   Several methods can reduce the impact of the location generation
   delay when using Location URIs:

   o  Because the LR interacts with the LS directly, it has some degree
      of control over the costs involved.  The LR can communicate
      urgency to the LS and request that the LI is generated quickly; a
      parameter indicating priority, or maximum time to respond could be

   o  The LS is able to perform caching of LI.  Subsequent requests for
      LI can use cached values without incurring the costs associated
      with generating location.

   o  The generation or assignment of a Location URI has a minimal cost,
      therefore a Location URI can be provided to an LR without adding
      additional delays at the start of time-critical operations.  The
      Target could also initiate a location generation process at this
      time; this way some of the delay can occur in parallel to the main
      operation, and potentially LI can be pre-cached at the LS in
      preparation for a request from the LR.

4.1.  Reducing Device Responsibilities

   Using a Location URI allows a Device to delegate much of the effort
   involved with providing LI.  In particular, authentication of LRs can
   require processing of encrypted data and interaction with network
   servers, for example Online Certification Status Protocol (OCSP)
   [RFC2560].  For lightweight devices with limited processing
   capabilities, battery dependencies or limited network access, this

Winterbottom, et al.      Expires July 24, 2006                 [Page 7]
Internet-Draft                Location URI                  January 2006

   can be advantageous.  Delegating this responsibility can also reduce
   the complexity of an end device.

   Deciding when LI is required for an application is sometimes
   difficult.  For instance, it is difficult to determine if certain
   telephony services require LI based on dialed digits.  Because a
   Location URI does not necessarily leak any private information, a
   Location URI can be provided in all cases without having to make any
   decision.  This leaves the receiver the choice of whether LI is
   required.  A privacy profile at the LS guarantees that only
   authorized LRs gain access to LI.  If this approach is taken, the
   security implications of this approach need to be considered, see
   Section 6.3.

4.2.  Open Medium Scenarios

   Providing LI by-value over a medium that is accessible to multiple
   parties presents a particular challenge to the Target.  In order to
   ensure that only authorized entities have access to LI, the LO must
   be individually encrypted for those entities.  This also implies that
   those entities are known ahead of time.  For example, this might
   apply for an application where intermediaries are part of a
   transaction with another end point.

   Using a Location URI on such an open medium allows this authorization
   decision to occur at the LS based on a policy.  A Location URI can be
   provided to all parties with only those who are permitted actually
   gaining access to LI, including the other end point if desired.
   Section 6.3.1 covers the implications of this approach with regards
   to theft.

Winterbottom, et al.      Expires July 24, 2006                 [Page 8]
Internet-Draft                Location URI                  January 2006

5.  Device Mobility

   Device mobility, specifically the degree to which devices are able or
   expected to move, has an effect on the applicability of by-value and
   by-reference location.  Some networks have definite mobility
   characteristics; for instance, a cellular network is expected to have
   highly mobile devices, whereas devices in a residential wired access
   network rarely move.

   How frequently devices move is the primary way that mobility affects
   the validity of LI.  LI for a mobile device can become inaccurate in
   a very short period of time.

5.1.  The Cost of Determining Location Information

   One further impact of mobility is the cost of determining location,
   in both processing power consumed and time.  As mobility increases,
   the means of determining a precise location become more complex and

   To take a generic wireless network as an example, a coarse location
   estimate based on the location of a transmitter can be provided
   relatively quickly, however this estimate may not be sufficiently
   precise to be of use to the LR.  More accurate wireless location
   determination methods incur a greater cost, in processing capacity,
   time or both.  For instance, generating a location based on signal
   propagation delays is relatively processing intensive; similarly, a
   significant amount of time can be required to acquire Global
   Positioning System (GPS) signals, which then also require processing
   to derive location.

   Therefore, it can be seen that the usefulness of inexpensive location
   estimates is reduced where network mobility is allowed; conversely,
   the cost of acquiring a sufficiently precise estimate increases.

5.2.  Impact of Mobility on By-Value Location

   In order for LI to be current at the time of use in a network that
   allows for mobility, the LG must ensure that it provides new LI to
   the Target every time it moves.  Since location is practically
   continuous (Planck length notwithstanding) a moving device can
   generate any number of such notifications, limited only by the
   ability of the LG to recognise changes in location and any
   artificially imposed constraints.

   In practice, both time and resolution constraints are used to limit
   the rate of polling that occurs.  Even with these constraints, there
   is still a potential for a substantial proportion of the location

Winterbottom, et al.      Expires July 24, 2006                 [Page 9]
Internet-Draft                Location URI                  January 2006

   determination effort to be wasted.

5.3.  Addressing Mobility

   In more mobile access networks, a Location URI can reduce this
   expenditure of effort.  A Location URI grants the LR some control
   over how and when LI is determined.

   Using a Location URI ensures that the information that the LR
   receives is current, and therefore more accurate; it also reduces the
   cost of polling.

5.4.  Expiry of Location Information

   The inclusion of parameters such as expiry time enables better
   management of the validity of LI.

   For fixed services, expiry times can be moderately lengthy with
   little risk of LI actually being inaccurate.  Fixed services based on
   a wired connection can also detect movement based on detecting the
   physical disconnection and connection of a wire or cable.

   Expiry of LI becomes more important when the Target is mobile.
   Appropriate values for expiry times can limit the chances of LI being
   inaccurate due to movement.  However, if location is provided by-
   value, the Target must provide LI more frequently as expiry times are
   shorter.  Using a Location URI can reduce the impact of this on the

Winterbottom, et al.      Expires July 24, 2006                [Page 10]
Internet-Draft                Location URI                  January 2006

6.  Security Considerations

   RFC 3693 [RFC3693] primarily concentrates on protecting the privacy
   of the Target.  However, much of the security implications of using a
   Location URI arise from location fraud.  The LR, as a consumer of LI,
   requires protection against being provided fraudulent LI, which can
   occur in a number of ways.

6.1.  Authorizing the Source of Location Information

   To protect against fraudulent LI, the LR must be able to authenticate
   the identity of the source of LI, then ensure that the LI has not
   been modified in transit.  In this instance, three potential
   _sources_ of LI are considered: the Target, the LG and the LS.

   Protection against modification can be assured either by guaranteeing
   a secure connection directly between the source and recipient using a
   protocol such as TLS [RFC2246], or by the application of a digital
   signature.  If a secure channel is used, authentication needs to
   applied within that channel.  A digital signature should include
   authentication information for the signer.

   Once an authenticated source of LI has been identified, the LR must
   also determine if it trusts that entity to provide accurate LI.

   o  If the Target is the source of LI, as may be the case when
      location is provided by-value, the LR must authorize the Target.
      Where the LR has a strong need to trust the veracity of the LI,
      the effort involved in establishing this level of authorization
      for each possible Target could be prohibitive.  Situations where
      this might not be appropriate are where there are very large
      numbers of potential Targets and/or where resources are expended
      based on the value of the LI.

   o  For the LS, it is expected that there are fewer Location Servers
      with which an LR needs to establish an adequate trust
      relationship.  Thus, by-reference LI can be used to avoid the
      Target authorization problem.  However, the LR must also trust
      that the LS is not likely to accept fraudulent LI; if the LS
      relies on an LG to generate LI, then the LR must also trust the

   o  The LG can also be considered as a part of either LS or Target, in
      which case, the guidelines for either of those roles apply.

Winterbottom, et al.      Expires July 24, 2006                [Page 11]
Internet-Draft                Location URI                  January 2006

6.2.  Assigning a Location URI

   A Location URI is an identifier generated by an LS so that an LR can
   retrieve LI.  The Location URI must not include any information that
   could be used to identify the Target or any other entity that might
   be associated with the Target, such as the Device.  The Location URI
   can therefore be considered an _unlinked pseudonym_ as defined in
   [RFC3693].  This implies that internal correlation (using a hash-
   table or similar) is the only method that the LS can use to associate
   a Location URI with a particular Target.

   The LS must assign a Location URI and then must maintain a link
   between the assigned URI and the specific Target.  If this
   association can be subverted, an attacker could request a URI using
   fake identification information so that subsequent requests to this
   URI resulted in the location of another Target being determined and
   returned to the LR.  The LS must employ measures to prevent this from

6.3.  Location URI Theft

   The lack of identification information means that a recipient of a
   Location URI cannot be sure to whom the Location URI belongs.  To
   this end, two options are presented: protecting the Location URI from
   theft, and weak Location URI protection with strong identity

6.3.1.  Protecting the Location URI

   This is the simpler approach, the Target ensures that the Location
   URI is only provided to trusted entities.  The Target need only trust
   these entities to not retransmit the Location URI, they need not
   include all such entities in an authorization policy.

   For this reason, a Location URI should always be carried over a
   transport that protects against eavesdropping.

6.3.2.  Strong Identity Association

   One advantage of a Location URI is that it can be used to provide LI
   to an LR, even when untrusted intermediaries are involved in a
   transaction.  The Location URI can be given to these intermediaries,
   but they cannot access LI as long as they are not included in the
   Target's authorization policy.  Note also that because the Location
   URI does not include identification information, the Target could
   also remain anonymous, depending on the application protocol used.

   The disadvantage of using a Location URI in this manner is that it is

Winterbottom, et al.      Expires July 24, 2006                [Page 12]
Internet-Draft                Location URI                  January 2006

   exposed to theft, whereby the intermediaries (or other parties) can
   take the Location URI and use it as if it were their own.  The LR,
   upon receiving the LI cannot know to whom the Location URI belongs.

   To protect against this, the Target can provide the LS with a
   presentity identifier that is also known to the LR.  When the LR
   retrieves the LO from the LS, the LO includes this presentity
   identifier.  In this way the LR can link the LI with the identity of
   the Target.

   This approach requires that the LS authenticate the Target when
   assigning a Location URI.

7.  References

   [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
              RFC 2246, January 1999.

   [RFC2560]  Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
              Adams, "X.509 Internet Public Key Infrastructure Online
              Certificate Status Protocol - OCSP", RFC 2560, June 1999.

   [RFC3693]  Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
              J. Polk, "Geopriv Requirements", RFC 3693, February 2004.

   [RFC3859]  Peterson, J., "Common Profile for Presence (CPP)",
              RFC 3859, August 2004.

   [RFC4119]  Peterson, J., "A Presence-based GEOPRIV Location Object
              Format", RFC 4119, December 2005.

              Thomson, M. and J. Winterbottom, "Revised Civic Location
              Format for PIDF-LO",
              draft-ietf-geopriv-revised-civic-lo-01 (work in progress),
              January 2006.

              Mahy, R., "A Document Format for Filtering and Reporting
              Location Notications in  PIDF-LO",
              draft-mahy-geopriv-loc-filters-00 (work in progress),
              October 2005.

Winterbottom, et al.      Expires July 24, 2006                [Page 13]
Internet-Draft                Location URI                  January 2006

Authors' Addresses

   James Winterbottom
   PO Box U40
   Wollongong University Campus, NSW  2500

   Phone: +61 2 4221 2938

   Martin Thomson
   PO Box U40
   Wollongong University Campus, NSW  2500

   Phone: +61 2 4221 2915

   Jon Peterson
   NeuStar, Inc.
   1800 Sutter St, Suite 570
   Concord, CA  94520

   Phone: +1 925/363-8720

Winterbottom, et al.      Expires July 24, 2006                [Page 14]
Internet-Draft                Location URI                  January 2006

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Winterbottom, et al.      Expires July 24, 2006                [Page 15]