GeoPriv                                                 R. Marshall, Ed.
Internet-Draft                                                       TCS
Intended status: Informational                         November 28, 2008                         February 26, 2009
Expires: June 1, August 30, 2009

           Requirements for a Location-by-Reference Mechanism
                draft-ietf-geopriv-lbyr-requirements-05
                draft-ietf-geopriv-lbyr-requirements-06

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

   This Internet-Draft is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, submitted to IETF in accordance full conformance with Section 6 the
   provisions of BCP 78 and 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-
   Drafts.

   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
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on June 1, August 30, 2009.

Copyright Notice

   Copyright (c) 2009 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Abstract

   This document defines terminology and provides requirements relating
   to Location-by-Reference approach using a location URI to handle
   location information within signaling and other Internet messaging.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6  7
   3.  Overview of Location-by-Reference  . . . . . . . . . . . . . .  7  8
     3.1.  Location URI Usage . . . . . . . . . . . . . . . . . . . .  9
     3.2.  Location URI Expiration  . . . . . . . . . . . . . . . . .  9
     3.3.  Location URI Authorization Models  . . . . . . . . . . . . 10
     3.4.  Location URI Construction  . . . . . . . . . . . . . . . . 10
   4.  High-Level Requirements  . . . . . . . . . . . . . . . . . . . 10 12
     4.1.  Requirements for a Location Configuration Protocol . . . 10 . 12
     4.2.  Requirements for a Location Dereference Protocol . . . . 12 . 13
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 18
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 18
   Appendix A.  Change log  . . . . . . . . . . . . . . . . . . . . . 19 20
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22
   Intellectual Property and Copyright Statements . . . . . . . . . . 23 24

1.  Introduction

   Since all

   All location-based services rely on ready access to location
   information,
   information.  Within this can accomplished through some direct means, or
   alternatively, through some indirect means as a pointer to document, the use of location
   information.  The direct vs. indirect approach we characterize as
   either Location-by-Value (LbyV), or Location-by-Reference (LbyR).

   While it information
   is the case that within SIP, constrained according to specific policies included in
   [I-D.ietf-geopriv-policy].  Using location information according to
   these policies can be handled done one of two ways, either in a
   direct manner, (i.e., passing direct,
   Location-by-Value (LbyV) approach, or using an indirect, Location-by-
   Reference (LbyR) model.  Despite the actual standard technique of passing
   location information around directly in SIP, in the form of a PIDF-LO*), PIDF-LO, (Presence
   Information Document Format - Location Object, [RFC4119]), there are
   some cases where LbyV is not desirable.  In cases where additional
   location requirements which apply to certain specific applications and/or location
   architectures that are
   architectures, and when can only satisfied be met by specifying an indirect location mechanism.
   mechanism, there is the Location-by-Reference model.  This document puts forth
   provides a set list of requirements for such an indirect location approach, namely, use with the LbyR location
   model. approach, and
   leaves the LbyV model as explicitly out of scope.

   As justification for a LbyR model, consider the following.  In some
   mobile networks it is not efficient for the end host to periodically
   query the LIS for up-to-date location information.  This is
   especially the case when power is a constraint or when a location
   update is not immediately needed.  Furthermore, the end host might
   want to delegate the task of retrieving and publishing location
   information to a third party, such as to a presence server.
   Additionally, in some deployments, the network operator may not want
   to make location information widely available.  These kinds of
   location scenarios, and more, such as whether a Target is mobile and
   whether a mobile device needs to be located on demand or according to
   some pre-determined interval, together form the basis of motivation
   for the LbyR concept.

   The concept of an LbyR mechanism is simple.  It is made up of a
   pointer which makes reference to the actual location information by
   some combination of key value and fully qualified domain name.  This
   combination of data elements, in the form of a URI, is referred to
   specifically as a "location URI".

   A location URI is thought of as a dynamic reference to the current
   location of the Target, yet the location value might remain unchanged
   over specific intervals of time for several reasons:

   - Limitations in the process used to generate location information
   mean that cached location might be used.

   - Policy constraints that may dictate that the location provided
   remains fixed over time for specified Location Recipients.  Without
   additional information, a Location Recipient cannot assume that the
   location information provided by any location URI is static, and will
   never change.

   The LbyR mechanism itself works according to an information lifecycle.
   Within the LbyR mechanism, this lifecycle, location URIs are considered temporary
   identifiers, each undergoing the following uses: Creation;
   Distribution; Conveyance; Dereference; and Termination.  The use of a
   location URI according to these various states is generally applied
   in one of the following ways:

   1.  Creation of a location URI, within a location server, based on
   some request for its creation.

   2.  Distribution of a location URI, via a Location Configuration
   Protocol, between a target and a location server**. server.

   3.  Conveyance, applied to LbyR, in SIP, is the transporting of the
   location URI, in this case, between any successive signaling
   nodes***. nodes.

   4.  Dereference of a location URI, a request/response between a
   client having a location URI and a location server holding the
   location  information that the location URI references.

   5.  Termination of a location URI, either due to expiration or
   cancellation within a location server, and which is based on a target
   cancellation  request or some other action, such as timer
   expiration.

   Note that this document makes no differentiation between a LS, per
   [RFC3693], and a LIS, as shown in [I-D.ietf-geopriv-l7-lcp-ps]), but
   may refer to either of them as a location server interchangeably.

   Location determination, different than location configuration or
   dereferencing, often includes topics related to manual provisioning
   processes, automated location calculations based on a variety of
   measurement techniques, and/or location transformations, (e.g., geo-
   coding), and is beyond the scope of this document.

   *The standard mechanism

   Location Conveyance for either LbyR or LbyV has been as defined around the use of
   the PIDF-LO (Presence Information Document Format - Location Object
   [RFC4119]]), and within SIP
   signaling is explicitly considered out of scope in this document.

   **This document make no differentiation between a LS, per RFC3693,
   and a LIS [ref. draft-ietf-geopriv-l7-lcp-ps], but may refer to
   either of them as a location server interchangeably.

   ***Location Conveyance for either LbyR or LbyV, within SIP signaling
   is considered out of scope for for this document (see
   [I-D.ietf-sip-location-conveyance] for an explanation of location
   conveyance for either LbyR or LbyV scenarios.)

   Except for location conveyance, the above stages in the LbyR
   lifecycle fall into one of two general categories of protocols,
   either a Location Configuration Protocol or a Location Dereference
   Protocol.  The stages of LbyR Creation, Distribution, and
   Termination, are each found within the set of Location Configuration
   Protocols (LCP).  The Dereference stage belongs solely to the set of
   Location Dereference Protocols.

   The issues around location configuration protocols have been
   documented in a location configuration protocol problem statement and
   requirements document [I-D.ietf-geopriv-l7-lcp-ps].  There are
   currently several examples of a location configuration protocols
   currently proposed, including, DHCP, DHCP
   [I-D.ietf-geopriv-dhcp-lbyr-uri-option], LLDP-MED, and HELD
   [I-D.ietf-geopriv-http-location-delivery])
   [I-D.ietf-geopriv-http-location-delivery] protocols.

   For dereferencing of a location URI, depending on the type of
   reference used, such as a HTTP/HTTPS, or SIP Presence URI, different
   operations can be performed.  While an HTTP/HTTPS URI can be resolved
   to location information, a SIP Presence URI provides further benefits
   from the SUBSCRIBE/NOTIFY concept that can additionally be combined
   with location filters [I-D.ietf-geopriv-loc-filters].

   The structure of this document includes terminology, Section 2,
   followed by a discussion of the basic elements that surround how a
   location URI is used.  These elements, or actors, are discussed in an
   overview section, Section 3, accompanied by a graph and graph, associated
   processing steps. steps, and a brief discussion around the use, expiration,
   authorization, and construction of location URIs.

   Requirements are outlined accordingly, separated as location
   configuration requirements, Section 4.1, and location dereference
   requirements, Section 4.2.

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 RFC 2119 [RFC2119].

   This document reuses the terminology of [RFC3693], such as Location
   Server (LS), Location Recipient (LR), Rule Maker (RM), Target,
   Location Generator (LG), Location Object (LO), and Using Protocol:

   Location-by-Value (LbyV):  The mechanism of representing location
      either  Location information in configuration or conveyance protocols, (i.e., the actual
      included location value).

   Location-by-Reference (LbyR):  The mechanism of representing location
      by means format of a
      PIDF-LO (or related encoding).

   Location-by-Reference (LbyR):  A location URI for use in either a location
      configuration, conveyance, or dereferencing protocol, and which
      refers pointing to a fully specified location. location
      information.

   Location Configuration Protocol:  A protocol which is used by a
      client to acquire either location or a location URI from a
      location configuration server, based on information unique to the
      client.

   Location Dereference Protocol:  A protocol which that is used by a client
      to query a location dereference server, based on the location URI input and
      which returns location information.

   Location URI:  An  As defined within this document, an identifier which that
      serves as a pointer to a location
      record on a remote host (e.g., LIS).  Used within an Location-by-
      Reference mechanism, a information.  A location URI is
      provided by a location
      configuration server, and is later used as input by a
      dereference protocol to retrieve location from a dereference server. information.

3.  Overview of Location-by-Reference

   This section describes the entities and interactions involved in the
   LbyR model.

                    +-----------+  Geopriv

            +---------+---------+   Location    +-----------+
            |         |  Location         |  Dereference  | Location  |
            |   LIS   -    LS   +---------------+ Recipient |
            |         |  Dereference  |         |
                    +-+---+-----+   Protocol    |           |
            +----+----+----+----+      (3) +----+------+
                     *      +-----+-----+
                 |                        --
         Rulemaker           *                        | Geopriv              --
                 |      Policy *                      |
        Location           -- |      Exchange *                    |
   Configuration    --
            (1b) |        (*)      *                  | Location
        Protocol       --
                * | (1a)         --      Geopriv
               *              +----+----+           |            --        Using Protocol
     + - - - -*- - - - - -|- - - -+  --          (e.g., SIP)
     |+------+----+ +-----+-----+ |--            (2) Conveyance
           (1)   | Rulemaker              |  Rule   | Target /  |--
     ||  / owner           | Protocol
                 | End Host  +              |  Maker  |           |    (2)
            +----+----+         +---------+           |
            |         |
     |+-----------+ +-----------+                               |
            |       User of Target  +-------------------------------+
            |
     + - - - - - - - - - - - - - -+         |
            +---------+

          Figure 1: Location Reference Entities and Interactions

   Figure 1 shows the assumed communication model for both a layer 7
   location configuration protocol and a location dereference protocol.

   (1a).

   1.  The Target requests (a Device) uses a Location Configuration Protocol to
   acquire a location reference from server; and receives back, a
   location URI in server response

   (1b).  Rulemaker policy LIS, which acts as (or is consulted (interface out of scope)

   (2). able to
   access) an LS.

   In the case where the Target conveys reference is also a Rule Maker, the location
   configuration protocol can be used to recipient (out convey policy information.  In
   the case where possession of scope)

   (3).  Recipient dereferences location URI, by a choice location URI is the only required form
   of methods,
   including authorization, (see, Section 3.3), a request/response (e.g., HTTP) or publish/subscription
   (e.g., SIP SUBSCRIBE/NOTIFY)

   Note A. There policy is no requirement for implied whereby any
   requester is granted access to location information.  This does not
   preclude other means of providing authorization policies.

   A Target could also acquire a location URI from the LS directly using
   alternative means, for example, the acquisition of a presence AoR to
   be used for location information, in which case, it could be regarded
   as a location URI.

   2.  The Target conveys the location URI to the Location Recipient
   (interface out of scope).

   3.  The Location Recipient dereferences the location URI to acquire
   location information from the LS.

   The LS controls access to location information based on the policy
   provided by the Rule Maker.

   Note A. There is no requirement for using the same protocol in (1a) (1)
   and (3).

   Note B. Figure 1 includes the interaction between the owner of the
   Target and the LIS to establish Rulemaker obtain Rule Maker policies.  This is
   communications path (1b).  This interaction
   needs to be done happen before the LIS will authorize anything other than
   what is allowed based on default policies in order to a dereference request for a
   location request of the Target.  This is communications path, (*),
   out of scope for this document.

   Note C. The Target may might take on the role of the Location Recipient
   whereby Recipient,
   in which case it would could attempt to dereference the location URI
   itself, in order to obtain its own location information.

3.1.  Location URI Usage

   An example scenario of how this the above might work, is where the Target
   obtains a location URI in the form of a subscription URI (e.g., a SIP
   URI) via HELD (a Geopriv layer 7 a location configuration protocol). protocol.  In this case, the Target
   is the same as the Recipient, therefore the Target can subscribe to
   the URI in order to be notified of its current location based on
   subscription parameters.  In the example, parameters are set up for a
   specific Target/Recipient along with an expressed geospatial
   boundary, so that the Target/Recipient receives an updated location
   notification once the boundary is crossed (see
   [I-D.ietf-geopriv-loc-filters]).

3.2.  Location URI Expiration

   Location URIs may have an expiry associated with them, primarily for
   security considerations, and generally so that the LIS is able to
   keep track of the location URIs that have been handed out, to know
   whether a location URI is still valid once the LIS receives it in a
   request, and in order for a recipient of such a URI from being able
   to (in some cases) permanently track a host.  Expiration of a
   location URI limits the time that accidental leaking of a location
   URI introduces.  Other justifications for expiration of location URIs
   include the ability for a LIS to do garbage collection.

   Because a location URI is a pointer to the Target's location, it is
   important that it be constructed in such a way that it does not
   unintentionally reveal any usable information about the Target it
   represents.  For example, it is important to prevent adversaries from
   obtaining any information that may be revealed about a Target by
   direct examination of the location URI itself, (e.g., names,
   identifiers, etc.), some determinable pattern or syntax (e.g.,
   sequence of numbers), or guessable codes (e.g., weak encryption).
   Therefore, each location

3.3.  Location URI must be constructed with security
   safeguards in mind. Authorization Models

   How a location URI is will ultimately be used within the dereference
   step is an important consideration at the time that the location URI
   is requested via a location configuration protocol.  Since
   dereferencing of location URIs could be done according to one of two
   authorization models, either an "access control authorization model"
   or a "possession authorization model" (see definitions, below), model", it is important that location
   configuration protocols indicate the type of a location URI that is
   being requested, (and also as well as which type is returned).

   1.  Access control authorization model: Control Authorization.

      Access to the location URI is limited by policy.  In this case, model it
      is assumed that the Rule Maker (owner/Target) is
      able to provide provides authorization policies to
      the LIS during this
      stage, or through some other parallel mechanism (e.g., interface
      1b., Figure 1.).  Policies and these policies are attached to a location URI through
      an (undisclosed) mechanism. and
      control the dereferencing process.

   2.  Possession authorization model: Authorization.

      The possession authorization model is described as not having no authentication and/or
      authorization requirement
      policies associated to the location URI aside from only possessing
      the location URI itself.  In this case, possession implies
      authorization.  Access to the location URI is limited by
      distribution only.  Whoever possesses the location URI has the
      ability to dereference it.  Possession authorization models may be
      used within specified domains only, or might be used across wide
      open public networks.

   In either of the above cases,

3.4.  Location URI Construction

   Depending on local policy, a location URI needs to may be constructed
   is in such
   a way as to make it difficult to guess.  The  Accordingly, the form of the
   URI is then constrained by the degree of randomness and uniqueness
   applied to it.  It is  In this case, it may be important to protect the
   actual location information from inspection by an intermediate node (despite the fact that node.
   Construction of a location URI in such a way as to not reveal any
   domain, user, or device specific information, with the possession model
   there would goal of making
   the location URI appear bland, uninteresting, and generic, may be nothing
   helpful to prevent an interceptor from seeking some degree in order to
   dereference the keep location URI).  Obfuscating information more
   difficult to detect.  Thus, obfuscating the location URI
   safeguards in this way
   may provide some level of safeguard against the undetected stripping
   off of what would otherwise be evident location information, since it
   forces a dereference operation by at the location dereference server, an
   important step for the purpose of providing statistics, audit trails,
   and general logging for many different kinds of location based
   services.

   Where local policy explicitly relaxes the limitations around the
   information provided within the structure of the location URI itself,
   default restrictions may not exist.  Under such conditions, it may be
   reasonable, for example, to have the location URI be the AoR itself.

4.  High-Level Requirements

   This document outlines the requirements for an Location by Reference
   mechanism which can be used by a number of underlying protocols.
   Requirements here address two general types of such protocols, a
   general location configuration protocol, and a general location
   dereferencing protocol.  Each of these two general protocols has
   multiple specific protocol implementations.  Location configuration
   protocols include, HELD, DHCP, and LLDP-MED, whereas current location
   dereferencing protocols include HELD Deref, HTTP GET, and SIP
   SUBSCRIBE/NOTIFY.  Because each of these specific protocol
   implementations has its own unique client and server interactions,
   the requirements here are not intended to state what a client or
   server is expected to do, but rather which requirements must be met
   separately by any location configuration protocol or location
   dereference protocol, for the purposes of using a location URI.

   The requirements are broken into two sections.

4.1.  Requirements for a Location Configuration Protocol

   Below, we summarize high-level design requirements needed for a
   location-by-reference mechanism as used within the location
   configuration protocol.

   C1. Location URI support:  The location configuration protocol MUST
      support a location reference in URI form.

      Motivation: It is helpful to have a consistent form of key for the
      LbyR mechanism. A standardized location reference mechanism increases
      interoperability.

   C2. Location URI expiration:  When a location URI has a limited
      validity interval, its lifetime MUST be indicated.

      Motivation: A location URI may not intend to represent a location
      forever, and the identifier eventually may need to be recycled, or
      may be subject to a specific window of validity, after which the
      location reference fails to yield a location, or the location is
      determined to be kept confidential.

   C3. Location URI cancellation:  The location configuration protocol
      MUST support the ability to request a cancellation of a specific
      location URI.

      Motivation: If the client determines that in its best interest to
      destroy the ability for a location URI to effectively be used to
      dereference a location, then there should be a way to nullify the
      location URI.

   C4. Location Information Masking:  The location URI form MUST, through
      randomization and uniqueness, ensure that any location
      specific information embedded within the location URI itself is
      kept obscure during does
      not contain location configuration. information specific components.

      Motivation: It is important to keep any location information
      masked from a casual observing node.

   C5. User Identity Protection:  The location URI MUST NOT contain any
      user identifying
      information that identifies the user, device user or
      address of record, (e.g., which includes device.  Examples include
      phone extensions, badge numbers, first or last names, etc.), within the URI form. names.

      Motivation: It is important to protect caller identity or contact
      address from being included in the form of the location URI itself
      when it is generated.

   C6. Reuse indicator:  There SHOULD be a way to allow a client to
      control whether a location URI can be resolved once only, or
      multiple times.

      Motivation: The client requesting a location URI may request a
      location URI which has a 'one-time-use' only characteristic, as
      opposed to a location URI having multiple reuse capability.

   C7. Validity Interval Indication:  A Selective disclosure:  The location configuration protocol MUST
      provide an indication of the location URI validity interval
      (i.e., expiry time) when present.

      Motivation: It is important to be able to determine how long a
      location URI is to remain useful for, and when it must be
      refreshed.

   C8. Location only:  The location URI MUST NOT point mechanism to any control what information is being disclosed
      about the Target other than it's location. Target.

      Motivation: A user should have the option The Rule Maker has to be in control of how much
      information is revealed about them.  This provides that control by
      not forcing during the inclusion dereferencing step as part of other information with location,
      (e.g., to not include any identification information in
      the
      location URI.)

   C9. privacy features.

   C8. Location URI Not guessable:  Where location URIs are used
      publicly, any  As a default, the location URI
      configuration protocol MUST be constructed using properties of
      uniqueness and cryptographically random sequences so that it is
      not guessable.  (Note that the number of bits depends to some
      extent on the number of active return location URIs that might exist at are random
      and unique throughout the one time; 128-bit indicated lifetime.  A location URI with
      128-bits of randomness is most likely enough for the near term.) RECOMMENDED.

      Motivation: Location URIs need to guard against any observing node
      or individual stripping off meaningful information about should be constructed in such a way that
      an adversary cannot guess them and dereference them without having
      ever obtained them from the Target.

   C10.

   C9. Location URI Optional:  In the case of user-provided
      authorization policies, where anonymous or non-guessable location
      URIs are not warranted, the location configuration protocol MAY
      support optional location URI forms. forms, (such as embedded location
      information within the location URI).

      Motivation: Users don't always have such strict privacy
      requirements, but may opt to specify their own location URI, or
      components thereof.

   C11.

4.2.  Requirements for a Location Dereference Protocol

   Below, we summarize high-level design requirements needed for a
   location-by-reference mechanism as used within the location
   dereference protocol.

   D1. Location URI Authorization Model: support:  The location configuration dereference protocol SHOULD indicate whether the requested MUST
      support a location reference in URI
      conforms to the access control authorization model or the
      possession authorization model. form.

      Motivation: Downstream dereference clients and servers need to
      know whether a location URI provided by the location configuration
      protocol conforms to an access control authorization model or a
      possession authorization model.

   C12.  Location URI Lifetime:  A location URI SHOULD have an
      associated expiration lifetime (i.e., validity interval), and MUST
      have an validity interval if used with the possession
      authorization model.

      Motivation: If a location URI is unintentionally leaked, then the
      amount of time that the reference can be potentially used by an
      unknown attacker (or, casual observer) needs to be limited.

4.2.  Requirements for a  Location Dereference Protocol

   Below, we summarize high-level design requirements needed for a
   location-by-reference mechanism as used within the location
   dereference protocol.

   D1. Location URI support:  The location dereference protocol MUST
      support a location reference in URI form.

      Motivation: It is required that there be consistency of use
      between It is required that there be consistency of use
      between location URI formats used in an configuration protocol and
      those used by a dereference protocol.

   D2. Validity Interval Indication:  A location dereference protocol
      MUST provide an indication of the location URI validity interval
      (i.e., expiry time) when present.

      Motivation: It is important to be able to determine how long a
      location URI is to remain useful for, and what time it will no
      longer be usable.

   D3. Authentication:  The location dereference protocol MUST include
      mechanisms to authenticate both the client and the server.

      Motivation: Although the implementations must support
      authentication of both parties, any given transaction has the
      option not to authenticate one or both parties.

   D4.

   D3.  Dereferenced Location Form:  The value returned by the
      dereference protocol MUST contain a well-formed PIDF-LO document.

      Motivation: This is in order to ensure that adequate privacy rules
      can be adhered to, since the PIDF-LO format comprises the
      necessary structures to maintain location privacy.

   D5.

   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.

      Motivation: Through dereference server configuration, for example,
      it may be useful to not only allow more than one dereference
      request, but, in some cases, to also limit the number of
      dereferencing attempts by a client.

   D6. Validity Interval Indication:  A dereference protocol MUST
      provide an indication of the location URI validity interval (i.e.,
      expiry time) when present.

      Motivation: It is important to be able to determine how long a
      location URI is to remain useful for, and when it must be
      refreshed.

   D7. Location URI anonymized:  Any location URI whose dereference will
      not be subject to authentication and access control MUST be
      anonymized.

      Motivation: The dereference protocol must define an anonymized
      format for location URIs.  This format must identify the desired
      location information via a random token with at least 128 bits of
      entropy (rather than some kind of explicit identifier, such as an
      IP address).

   D8. Location Information Masking:  The location URI form MUST,
      through randomization and uniqueness, ensure that any location
      specific information embedded within the location URI itself is
      kept obscure during location URI dereferencing.

      Motivation: It is important to keep any location information
      masked from a casual observing node, requiring instead a discrete
      dereference operation in order to return location information.

   D9. Location Privacy:  The location dereference protocol MUST support
      the application of privacy rules to the dissemination of a
      requested location object.

      Motivation: The dereference server must obey all provisioned
      privacy rules that apply to a requested location object.

   D10.

   D5. Location Confidentiality:  The location dereference protocol MUST
      support encryption confidentiality protection of messages sent between the location
      dereference client
      Location Recipient and the location dereference server, and MAY
      alternatively provide messaging unencrypted. server.

      Motivation: Environmental and local configuration policy will
      guide the requirement for encryption for certain transactions.  In
      some cases, encryption may be the rule, in others, it may be
      acceptable to send and receive messages without encryption.

   D11.  Location URI Authorization Model: The location dereference
      protocol SHOULD indicate whether the requested location URI
      conforms to the access control authorization model or the
      possession authorization model.

      Motivation: Downstream dereference clients need indicates what type of security
      protocol has to know whether be provided.  An example is a location URI provided by the location configuration protocol
      conforms to an access control authorization model or using a possession
      authorization model in order to save time processing dereference
      attempts.
      HTTPS URI scheme.

5.  Security Considerations

   A

   The method of constructing the location URI to include randomized
   components helps to prevent adversaries from obtaining location
   information without ever retrieving a location URI.  In the
   possession model, a location URI, regardless of its construction, if public, by itself,
   made publically available, implies no safeguard against anyone being
   able to dereference and get the location.  The method of constructing the  Care has to be paid when
   distribution such a location URI form to
   include randomization along with encryption does help prevent some
   potential pattern guessing.  In the case of one time use trusted location
   URIs, (referred to as a pawn ticket), recipients.
   When this aspect is of concern then the argument can authorization model has to be made
   chosen.  Even in this model care has to be taken on how to construct
   the authorization policies to ensure that
   possession implies permission, and only those parties have
   access to location URIs information that are public are
   protected only by privacy rules enforced at considered trustworthy enough
   to enforce the dereference server. basic rule set that is attached to location
   information in a PIDF-LO document.

   Any location URI, by necessity, indicates the server (name) that
   hosts the location information.  Knowledge of the server in some
   specific domain could therefore reveal something about the location
   of the Target.  This kind of threat may be mitigated somewhat by
   introducing another layer of indirection: namely the use of a
   (remote) presence server.

6.  IANA Considerations

   This document does not require actions by the IANA.

7.  Acknowledgements

   I would like to thank the present IETF GEOPRIV working group chairs,
   Robert Sparks and Richard Barnes for their continued support in
   progressing this document along, as well, I wish to thank Barnes, past chairs, Andy Newton, Allison
   Mankin and Randall Gellens, for creating establishing the design team which
   initiated this requirements work.  I'd also like to thank those
   original design team participants for their inputs, comments, and
   insightful reviews.  The design team included the following folks:
   Richard Barnes; Martin Dawson; Keith Drage; Randall Gellens; Ted
   Hardie; Cullen Jennings; Marc Linsner; Rohan Mahy; Allison Mankin;
   Roger Marshall; Andrew Newton; Jon Peterson; James M. Polk; Brian
   Rosen; John Schnizlein; Henning Schulzrinne; Barbara Stark; Hannes
   Tschofenig; Martin Thomson; and James Winterbottom.

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.

8.2.  Informative References

   [I-D.ietf-geopriv-dhcp-lbyr-uri-option]
              Polk, J., "Dynamic Host Configuration Protocol (DHCP)
              Option for a Location Uniform  Resource Identifier (URI)",
              draft-ietf-geopriv-dhcp-lbyr-uri-option-03 (work in
              progress), November 2008.

   [I-D.ietf-geopriv-http-location-delivery]
              Barnes, M., Winterbottom, J., Thomson, M., and B. Stark,
              "HTTP Enabled Location Delivery (HELD)",
              draft-ietf-geopriv-http-location-delivery-10
              draft-ietf-geopriv-http-location-delivery-12 (work in
              progress), October 2008. January 2009.

   [I-D.ietf-geopriv-l7-lcp-ps]
              Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
              Location Configuration Protocol; Problem Statement and
              Requirements", draft-ietf-geopriv-l7-lcp-ps-08 draft-ietf-geopriv-l7-lcp-ps-09 (work in
              progress), June 2008. February 2009.

   [I-D.ietf-geopriv-loc-filters]
              Mahy, R. and B. Rosen, "A Document Format for Filtering
              and Reporting Location Notications in the  Presence
              Information Document Format Location Object (PIDF-LO)",
              draft-ietf-geopriv-loc-filters-03 (work in progress),
              November 2008.

   [I-D.ietf-geopriv-policy]
              Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J.,
              and J. Polk, "Geolocation Policy: A Document Format for
              Expressing Privacy Preferences for  Location Information",
              draft-ietf-geopriv-policy-17
              draft-ietf-geopriv-policy-20 (work in progress),
              June 2008.
              February 2009.

   [I-D.ietf-sip-location-conveyance]
              Polk, J. and B. Rosen, "Location Conveyance for the
              Session Initiation Protocol",
              draft-ietf-sip-location-conveyance-12 (work in progress),
              November 2008.

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

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

Appendix A.  Change log
              Session Initiation Protocol",
              draft-ietf-sip-location-conveyance-12 (work in progress),
              November 2008.

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

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

Appendix A.  Change log

   Changes to this draft in comparison to the previous version (-06 vs.
   -05):

   1. replaced diagram (Thomson).

   2. redefined term, "Location-by-Value" (1/08/2009, Tschofenig).

   3. redefined term, "Location-by-Reference" (Tschofenig).

   4. redefined term, "Location Dereference Protocol" (Tschofenig).

   5. reworded term, "Location URI" (Tschofenig).

   6. modified steps, text, Figure 1 (Tschofenig).

   7. deleted redundant text in paragraph, "Because a location URI..."
   (Tschofenig).

   8. modified Authorization model text paragraphs, (Tschofenig).

   9. added qualifying sentence before sentence, "Thus, obfuscating the
   location URI..."  (Marshall based on question from Tschofenig).

   10. replaced diagram with one that contains both "LIS - LS" labeling
   (Martin).

   11. added text to Introduction that a location URI is dynamic and may
   change over time (Martin, 2/23/09).

   12. section 3 text changed to make the makeup of a location URI less
   stringent as to being guessable, etc.  (Martin, 2/23/09).

   13. reordered "C" requirements from those remaining: C8-->C7;
   C9-->C8; C10-->C9.

   14. reordered "D" requirements: D3-->D2; D4-->D3; D5-->D4; D10-->D5.

   15. section-ized the overview, (section 3), for pointing to (Martin,
   2/23/09)

   16. edited section 3.4 to make clear that some default requirements
   may be relaxed ONLY if explicit local policy exists.  (RSM based on
   Martin, 2/23/09).

   17. added an citation for the geopriv-policy draft reference.

   18. reworded first couple of paragraphs of Introduction for
   readability.

   Changes to this draft in comparison to the previous version (-05 vs.
   -04):

   1.  Fixed minor spelilng errors.

   Changes to this draft in comparison to the previous version (-04 vs.
   -03):

   1.  Changed wording of section 1 "Introduction", (Thomson ~ 7/09/08
   list comments).

   1.  Relocated text in section 3 "Overview of Location-by-Reference"
   to section 1 (Intro), (Thomson comments).

   2.  (Sect. 3, con't) Fixed Figure 1.  Label, based on (Thomson
   comments).

   3.  Fixed minor spelling errors, incl.  Note B., Note C., etc., based
   on (Thomson comments).

   4.  Added some qualifying text (security) around possession model,
   based on (Thomson comments).

   5.  Replaced "use type" labels with "authorization models", "access
   authorization model", and "possession authorization model", (Thomson
   comments).

   6.  Changed the entity role of applying security from LIS (Server-
   side authentication), to the Rule-Maker Rule Maker (owner/Target) providing
   policies to the LIS, (Thomson comments).

   7.  Changed requirement C3 to a MUST, (Thomson comments).

   8.  Added new requirement, C12, "C12.  Location URI Lifetime:" as a
   SHOULD for all, and MUST for possession auth model, (Thomson
   comments).

   9.  Changed name of requirement C8 to "Location Only", (Thomson
   comments).

   10.  Reworded C7 and D6 to be less implementation specific, (Thomson
   comments).

   11.  Changed requirements C11, D11 to SHOULD, (Thomson comments).

   12.  (Section 5:) Removed lead in sentence for readibility, (Thomson
   comments).

   13.  Remove "pawn ticket" reference - replaced with "possession
   authorization model", (Thomson comments).

   14.  Added new paragraph to the security section (Thomson, 7/09/08
   comments).

   15.  Corrected other minor spelling and wording errors and
   deficiencies (refer to diff 04/03) (-Editor).

   Changes to this draft in comparison to the previous version (-03 vs.
   -02):

   1.  Changed wording of section 3 "Overview of Location-by-Reference"
   (Polk, Thomson, Winterbottom ~ 4/1/08 list comments).

   2.  Added new requirement C4.  "Location Information Masking:", based
   on (Thomson ~4/1/08 list comment).

   3.  Added new requirement C11.  "Location URI Use Type:", based on
   (~4/1/08 list comments).

   4.  Added new requirement D11.  "Location URI Use Type:", for deref.
   based on (~4/1/08 list comments).

   5.  Replaced requirement D8.  "Location URI Non-Anonymized" with
   "Location Information Masking:".

   Changes to this draft in comparison to the previous version (-02 vs.
   -01):

   1.  Reworded Introduction (Barnes 12/6 list comments).

   2.  Changed name of "Basic Actors" section to "Overview of Location
   by Reference" (Barnes).

   3.  Keeping the LCP term away (for now) since it is used as Link
   Control Protocol elsewhere (IETF).

   4.  Changed formatting of Terminology section (Barnes).

   5.  Requirement C2. changed to indicate that if the URI has a
   lifetime, it has to have an expiry (Barnes)

   6.  C7.  Changed title and wording based on suggested text and dhcp-
   uri-option example (Polk).

   7.  The new C2 req. describing valid-for, was also added into the
   deref section, as D6

   8.  Changed C4 based on much list discussion - replaced by 3 new
   requirements...

   9.  Reworded C5 based on the follow-on C4 thread/discussion on list
   (~2/18).

   10.  Changed wording of D3 based on suggestion (Barnes).

   11.  Reworded D4 per suggestion (Barnes).

   12.  Changed D5 based on comment (Barnes), and additional title and
   text changes for clarity.

   13.  Added D9 and D10 per Richard Barnes suggestions - something
   needed in addition to his own security doc.

   14.  Deleted reference to individual Barnes-loc-sec draft per wg list
   suggestion (Barnes), but need more text for this draft's security
   section.

Author's Address

   Roger Marshall (editor)
   TeleCommunication Systems, Inc.
   2401 Elliott Avenue
   2nd Floor
   Seattle, WA  98121
   US

   Phone: +1 206 792 2424
   Email: rmarshall@telecomsys.com
   URI:   http://www.telecomsys.com

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   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
   http://www.ietf.org/ipr.

   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
   ietf-ipr@ietf.org.