[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 draft-ietf-geopriv-arch

GEOPRIV                                                        R. Barnes
Internet-Draft                                               M. Lepinski
Updates: 3693, 3694                                     BBN Technologies
(if approved)                                              H. Tschofenig
Intended status: Informational                    Nokia Siemens Networks
Expires: August 28, 2008                                  H. Schulzrinne
                                                     Columbia University
                                                       February 25, 2008


         Security Requirements for the Geopriv Location System
                     draft-barnes-geopriv-lo-sec-02

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-
   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 August 28, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   Internet protocols that deal with presence-based location objects
   support a wide variety of applications.  However, the dissemination
   of location objects from sources of location to consumers is a common
   feature of all location-based applications.  In order to enable the



Barnes, et al.           Expires August 28, 2008                [Page 1]

Internet-Draft          Location Object Security           February 2008


   development of broadly-applicable security and privacy mechanisms for
   dissemination of location objects, this document describes an end-to-
   end architecture for policy-constrained location distribution.  In
   this architecture, location distribution is accomplished by a set of
   distributed actors.  We describe the assurances that these actors
   require from the architecture, and derive more a more detailed
   description of the security features required to provide those
   assurances.











































Barnes, et al.           Expires August 28, 2008                [Page 2]

Internet-Draft          Location Object Security           February 2008


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  An End-to-end Location Architecture  . . . . . . . . . . . . .  6
     3.1.  Structure of a Location Transmission . . . . . . . . . . .  6
       3.1.1.  Structure of a Location Request  . . . . . . . . . . .  8
       3.1.2.  Location References  . . . . . . . . . . . . . . . . .  9
       3.1.3.  LS Processing of Location Requests . . . . . . . . . . 10
     3.2.  The End-to-end Model and Global Roles  . . . . . . . . . . 11
     3.3.  Usage Scenarios for this Model . . . . . . . . . . . . . . 13
       3.3.1.  RFC 3693 model of transmission . . . . . . . . . . . . 13
       3.3.2.  Location Configuration . . . . . . . . . . . . . . . . 14
       3.3.3.  Location Conveyance by Value . . . . . . . . . . . . . 14
       3.3.4.  Location Conveyance by Reference . . . . . . . . . . . 14
       3.3.5.  Presence Server  . . . . . . . . . . . . . . . . . . . 14
   4.  Required Assurances  . . . . . . . . . . . . . . . . . . . . . 15
     4.1.  Location Transmission  . . . . . . . . . . . . . . . . . . 15
       4.1.1.  Rule Maker . . . . . . . . . . . . . . . . . . . . . . 15
       4.1.2.  Location Server  . . . . . . . . . . . . . . . . . . . 16
       4.1.3.  Location Recipient . . . . . . . . . . . . . . . . . . 16
     4.2.  End-to-end distribution  . . . . . . . . . . . . . . . . . 16
       4.2.1.  Location Generator . . . . . . . . . . . . . . . . . . 16
       4.2.2.  Viewer . . . . . . . . . . . . . . . . . . . . . . . . 17
       4.2.3.  Target . . . . . . . . . . . . . . . . . . . . . . . . 17
     4.3.  Summary of Required Assurances . . . . . . . . . . . . . . 18
   5.  Security Requirements  . . . . . . . . . . . . . . . . . . . . 18
     5.1.  Unauthorized Modification of Rules . . . . . . . . . . . . 19
     5.2.  Unauthorized Exposure of Rules . . . . . . . . . . . . . . 20
     5.3.  Acceptance of Rules from Unauthorized Rule Makers  . . . . 20
     5.4.  Unauthorized Exposure of Location Objects  . . . . . . . . 20
     5.5.  Unauthorized Modification of Location Objects  . . . . . . 23
     5.6.  Assertion of Location Object Origins . . . . . . . . . . . 24
     5.7.  Summary of Security Requirements . . . . . . . . . . . . . 24
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 26
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 26
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 26
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 26
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
   Intellectual Property and Copyright Statements . . . . . . . . . . 29









Barnes, et al.           Expires August 28, 2008                [Page 3]

Internet-Draft          Location Object Security           February 2008


1.  Introduction

   Demand for location-based Internet applications, especially location-
   based Internet calling [I-D.ietf-ecrit-framework], has driven the
   creation of Internet protocols for communicating information about
   the location of Internet end hosts or other entities.  Of interest,
   for example, are protocols for informing hosts of their own location
   (location configuration protocols), transmitting location information
   from one host to another (location conveyance protocols), and
   requesting location information from a server (location dereference
   protocols).

   The first goal of this document is to describe how location
   information is used by these protocols over its entire "life-cycle".
   This life-cycle begins when location information is introduced into
   an IP network via a location configuration protocol, continues
   through one or more transmissions by way of location conveyance and
   dereference protocols, and ultimately ends when the location is
   delivered to an application consumer.

   The Location Objects (LO) described in RFC 3693 and RFC 3694 are
   usually encoded as XML documents in the Presence Information Data
   Format - Location Object (PIDF-LO) schema [RFC4119].  While the
   general trend in the IETF is to require that LOs be in this format,
   certain protocols do not use PIDF-LO, most notably the DHCP
   extensions to carry location in civic [RFC4776] or geospatial
   [RFC3825] format.  In this document, such formats for location
   information are also regarded as LO formats, even though they do not
   comply with the requirements for LO formats in RFC 3693.

   The expansion of scope to include location object formats other than
   those in compliance RFC 3693 is not meant to in any way deprecate or
   supercede the requirements of RFC 3693.  This document is intended to
   treat security aspects of location communication independent of the
   other considerations that RFC 3693 addresses.  Where the two
   documents overlap, we aim to provide greater specificity in guidance
   and requirements.

   A model for the use of Internet protocols to transmit location
   information via a store-and-forward network of Location Servers has
   been described in RFC 3693 [RFC3693].  Privacy concerns and privacy-
   relevant security concerns are described in RFC 3694 [RFC3694].  This
   document extends those documents in three ways: First, we explicitly
   take into account end-to-end properties of the system, through
   multiple location transmissions.  Second, we address security
   concerns not directly related to the privacy of location information
   (of concern for Viewers), such as location integrity and access
   control (of concern to Location Generators).  Third, and most



Barnes, et al.           Expires August 28, 2008                [Page 4]

Internet-Draft          Location Object Security           February 2008


   importantly, we extend these considerations beyond a presence-based
   model to create a general framework for policy-based dissemination of
   location objects.

   Similarly, several policy languages have been developed in the
   context of presence authorization (and for location within that
   context).  RFC 4745 [RFC4745] defines a general framework for
   expressing privacy policies, and RFC 5025 [RFC5025] specializes this
   framework to the case of presence documents (of which PIDF-LO
   location objects are considered a subset).  This document considers
   these sorts of authorization rules in the context of a broader
   location request authorization framework.

   The remainder of this document is structured as follows: After
   relevant terminology is introduced in Section 2, Section 3 describes
   an architecture for the end-to-end distribution of location over the
   Internet.  In particular, this architecture describes a set of
   entities that work together to move location information from source
   to consumer.  Based on the roles they play in the architecture, these
   entities may require certain assurances, and these are described in
   Section 4.  Finally, in Section 5, the technical properties and
   mechanisms required to enable these assurances are reflected in a set
   of requirements for Geopriv security mechanisms.


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].

   The focus of this document is the security properties of two types of
   protocols and two types of data formats:

   o  Policy Conveyance Protocols communicate policy information between
      rule makers and location servers.  These can be dedicated
      protocols (e.g., XCAP [RFC4825]), or, when rules are carried
      within a location object, the location conveyance protocol can act
      as a policy conveyance protocol.

   o  Location Conveyance Protocols communicate location requests and
      responses between the location server and the location recipient
      (e.g., SIP Geolocation, HELD, and Location Dereference Protocols).
      Location configuration protocols [I-D.ietf-geopriv-l7-lcp-ps] and
      location dereference protocols
      [I-D.ietf-geopriv-lbyr-requirements] are special cases of location
      conveyance protocols.




Barnes, et al.           Expires August 28, 2008                [Page 5]

Internet-Draft          Location Object Security           February 2008


   o  Location Object Formats define how location information and
      ancillary data are encoded; information is passed between distant
      points in the distribution chain by being carried in the LO.

   o  Location Reference Formats define how location references (i.e.,
      request parameters) are encoded for dissemination from an LS to
      LRs.

   The roles played by these protocols are described in Section 3.1, and
   corresponding security requirements are described in Section 5.

   This document re-defines the following terms from RFC 3693 in an
   effort to refine their scope: Rule Maker, Location Server, Location
   Recipient, Location Generator, Viewer.  Full definitions are given in
   Section 3.1 and Section 3.2.


3.  An End-to-end Location Architecture

   In this section, we present an architecture for the end-to-end
   communication of location information.  The overall pattern of
   transmissions involved in this communication is often complex and
   thus such systems are modeled as the composition of atomic building
   blocks.

   In Section 3.1 we describe a single location transmission, and the
   roles played by parties in such a transmission.  A location
   transmission is an atomic unit that models a single movement of
   location information.  In Section 3.2 we describe how multiple
   location transmissions can fit together within an end-to-end system
   and the global roles played by entities in such a composite system.
   Finally, in Section 3.3 we demonstrate how this model maps to common
   location use-cases such as location configuration and point-to-point
   location conveyance.

3.1.  Structure of a Location Transmission

   Location transmission is the basic building block for policy-
   constrained location distribution.  The model we describe here for a
   location transmission is based on the one described for a presence
   server in RFC 4745.  The protocol interactions involved in a location
   transmission are illustrated in Figure 1:

   1.  A Rule Maker informs the Location Server about Privacy Rules
       governing the distribution of Location Objects.

   2.  In some cases, the LR will acquire a location reference (e.g., a
       URI or a domain name for the LS) through an external



Barnes, et al.           Expires August 28, 2008                [Page 6]

Internet-Draft          Location Object Security           February 2008


       dissemination channel; a specification of this channel is outside
       the scope of this document.

   3.  The transmission is initiated either when the LR sends a request
       to the LS, or when the LS is directed to transmit location by
       some other mechanism.  (These two cases roughly correspond to
       Passive and Active Request-Response modes of RFC 4745,
       respectively.)

   4.  The LS determines whether the transmission is permitted by
       currently available policy, and if so, transmits location to the
       LR.  Note that in addition to rules installed by the RM, the LS
       also uses policies contained in the LO itself and policies
       defined by local configuration.

   The policy transaction in step (1) is conducted using a policy
   conveyance protocol.  The reference communicated in step (2) is
   communicated through an unspecified dissemination channel in a given
   location reference format.  The transmission in step (4) is conducted
   using a location conveyance protocol, and when the transmission is
   initiated by the LR, the request uses the location conveyance
   protocol as well.  The LO is transmitted in some location object
   format.

   This model makes two important simplifying assumptions.  First,
   multiple asynchronous responses to a single request are considered
   part of the same transmission.  That is, we do not distinguish
   between the Passive Request-Response and Asynchronous modes of RFC
   4745.  Second, multiple LOs contained within a single response are
   considered as a single response.  (A response containing multiple LOs
   is authorized if and only if all of the LOs in the response would be
   authorized independently.)
                        ............(2)...........
                        .                        .
                        .                        V
                   +---------+<-----(3)-----+---------+
                   |  LS (3) |------(4)---->|   LR    |
                   +---------+              +---------+
                        ^
                        |
                       (1)
                        |
                   +---------+
                   |   RM    |
                   +---------+

                 Figure 1: A single location transmission




Barnes, et al.           Expires August 28, 2008                [Page 7]

Internet-Draft          Location Object Security           February 2008


   There are three roles involved in this transaction, a Location Server
   (LS), a Location Recipient (LR), and a Rule Maker (RM).  A single
   entity may play multiple of these roles within a single transmission
   (see Section Section 3.3 for examples).  The only two roles that are
   necessarily separate are that of the LS and the LR.

   Rule Maker  The Rule Maker is the party who produces the rules
      governing whether a Location Recipient is allowed to receive
      location information and what precision of location information a
      Location Recipient is allowed to receive.  (Formats for these
      rules are described in [RFC4745] and [I-D.ietf-geopriv-policy].)
      The Rule Maker may send rules directly to the Location Server, or
      the Location Server may receive the rules as part of a location
      object as per [RFC4119].  Note that some transmissions may occur
      without a Rule Maker, in which cases the transmission is
      constrained only by policy contained in the LO itself and LS-
      internal policy.

   Location Server  The Location Server is the party who possesses the
      location information at the beginning of the transmission.  The
      Location Server receives rules governing the location information
      as received from the Rule Maker, as part of the location object
      containing the location information, or as part of its internal
      configuration.  The Location Server is responsible for applying
      these rules and as such he may need to reduce the precision of the
      location information or terminate the location transmission if the
      Location Recipient is not authorized to receive the location
      information.  After applying the appropriate rules, the Location
      Server sends the location information to the Location Recipient.

   Location Recipient  The Location Recipient receives the location from
      the Location Server, either by making a request to the LS or as a
      result of an LS-initiated transmission.

   The distinction between LS-initiated and LR-initiated transfers is
   significant, because in the latter case, the LR can influence which
   LO is transmitted.  Additional concerns related to the dissemination
   of references and the interaction between requests and policy make
   the LS policy decision process considerably more complex when
   transmissions are initiated by the LR.  Thus, we treat that case in
   more detail in the below.

3.1.1.  Structure of a Location Request

   Logically, a location request is a message sent from an LR to an LS
   that requests that the LS send an LO (or set of LOs) to the LR.  This
   means that the request must contain at least two types of data:




Barnes, et al.           Expires August 28, 2008                [Page 8]

Internet-Draft          Location Object Security           February 2008


   1.  A description of the LO to be returned

   2.  An identifier for the LR to which it should be delivered

   Depending on the individual protocol and the individual request, the
   internal structure of these data can vary.  For example, the
   identifier for the LR can be a source IP address or a SIP URI.  The
   description of the LO to be returned could be a detailed set of
   parameters, or an opaque identifier; it could even be implicit, being
   inferred from the LR's identity.  In general, we consider the
   identifier for the LR as a single datum, while the description of the
   LO is considered as logically consisting of a set of parameters, e.g:

   o  Identity of the target

   o  Time of sighting / timestamp

   o  Format of desired LO

   o  Positioning mechanism used in sighting

   The LS may accept these parameters in "clear" or "opaque" form, i.e.,
   in the form that can be readily matched against authorization rules
   or in the form of a random token that maps to a clear value in a way
   known only to the LS).  In order to be considered "opaque", the
   values assigned by the LS MUST have sufficient entropy that they are
   difficult to guess without prior knowledge.  Note also that the LS
   may choose to map a single opaque token to a collection of clear
   values.

   Implicit in the representation of parameter values by opaque tokens
   is that these tokens have a lifetime, namely, the period of time for
   which the LS retains a mapping between the opaque token and one or
   more clear parameter values.

3.1.2.  Location References

   A location reference is a data structure that provides information on
   how to make a request for location.  In order to be useful at all, a
   reference must contain contact information (e.g., a domain name) for
   an LS.  Additionally, the reference may contain parameter values that
   describe an LO.  The request that is generated from a reference has
   the indicated parameter values filled into appropriate fields, and is
   sent to the indicated LS.

   References are the mechanism whereby values for opaque parameters are
   distributed.  An LS constructs a reference containing opaque values
   which is then distributed to LRs through some dissemination channel.



Barnes, et al.           Expires August 28, 2008                [Page 9]

Internet-Draft          Location Object Security           February 2008


   Every reference that conveys opaque parameter values has a validity
   lifetime, which is the intersection of the validity intervals of the
   opaque values it conveys.

   To say this another way: Suppose that whenever an LS creates a
   reference it creates a new set of values for all opaque parameters
   (or, equivalently, creates a single opaque token that maps to a set
   of clear values), all with the same validity interval.  Then the
   reference is valid over the same interval as the opaque tokens, and
   the LS can render the reference unusable by deleting the associated
   mapping(s).

   More concretely, location references are often encoded as URIs.  For
   example, if there were an HTTP request protocol defined, the URI
   <http://ls.example.net/134245> would indicate that an HTTP request
   should be sent to ls.example.net, with the value "/134245" (or
   "http://lis.example.net/134245") as the Request URI (and in other
   fields as specified by the protocol).  The validity lifetime of this
   URI is the lifetime for which the LS will store a mapping between the
   opaque value "134245" and a set of clear parameters.

   A location reference logically refers to a set of LOs, namely the set
   of LOs that the indicated LS will return to authorized requestors in
   response to requests with the indicated parameter values.  When the
   reference does not specify all available parameters, this set
   contains LOs for all possible parameter values.  Even when all
   parameters are set, the set of referenced LOs contains all values
   that are returned over time.

   The size of the referenced LO set determines the sensitivity of the
   reference.  A reference that refers to a single LO can only expose
   that LO; i.e., its sensitivity is at most the sensitivity of the
   referenced LO (less if the LS applies access control).  On the other
   hand, a reference that can be used to obtain a large set of locations
   can allow the holder of the reference track a target over time or to
   gather the LOs for many targets.

3.1.3.  LS Processing of Location Requests

   An LS determines whether to return an LO in response to a request,
   and which LO to return, based on three types of policy:

   1.  A policy specifying which parameters are accepted in clear form
       (and how these should be formatted) and which are accepted in
       opaque form (these sets need not be disjoint).  (The LS also
       maintains list of mappings of opaque tokens to clear values,
       which acts as a validation of opaque tokens.)




Barnes, et al.           Expires August 28, 2008               [Page 10]

Internet-Draft          Location Object Security           February 2008


   2.  A set of authorization rules of the form specified in RFC 4745.

   3.  A decision function for choosing which among multiple LOs to
       return.

   The second of these three, can be populated from any of three
   sources: (1) Rule Makers, (2) Received LOs, and (3) internal
   configuration.  The first and last are internal policies of the LS.
   When the LS receives a request, it applies these policies in the same
   order they are presented above:

   1.  The LS verifies that clear parameters are properly formatted and
       that the values of opaque parameters are known tokens (i.e.,
       tokens with currently valid mappings to clear values).  Valid
       opaque parameters are translated into clear values.

   2.  The LS applies authorization rules to information provided in the
       request to determine the set of LOs that it is authorized to
       return.  (Note: this set may not be explicitly enumerated, but
       rather expressed as a set of criteria.)

   3.  If any of the authorized LOs are compliant with the request, then
       the LS applies the decision function to decide which LO(s) to
       return to the LR.

3.2.  The End-to-end Model and Global Roles

   The life-cycle of a Location Object typically consists of multiple
   location transmissions.  For example, location might first be
   acquired via a location configuration protocol and then conveyed via
   a location conveyance protocol.  This end-to-end distribution process
   can be described as a "chaining together" of the individual
   transmissions described above; different transmissions are connected
   by an entity that acts as an LR in one transmission and an LS in the
   next.  This process is illustrated in Figure 2.  Note that although
   Figure 2 depicts a single "path", a single LS may transmit location
   to multiple LRs over time; grouping these paths together forms a
   logical distribution tree, with the LG as the root node and Viewers
   as leaf nodes.












Barnes, et al.           Expires August 28, 2008               [Page 11]

Internet-Draft          Location Object Security           February 2008


          .              .              .
     +----+----+    +----+----+    +----+----+    +----+--------+
     | LG | LS |--->| LR | LS |--->| LR | LS |--->| LR | Viewer |
     +----+----+    +----+----+    +----+----+    +----+--------+
          .  |           .  |           .  |
          . +----+       . +----+       . +----+
          . | RM |       . | RM |       . | RM |
          . +----+       . +----+       . +----+

                Figure 2: End-to-end location distribution

   In addition to the roles within a particular location transmission,
   there are also three additional global roles within the larger
   composite system.  As described in Section 3, a given party may need
   particular assurances based on the global role that it plays.

   Location Generator  The Location Generator is the party that
      initially introduces location information into the Internet.  The
      LG may be (but need not be) the entity that performs the sighting
      of the Target.  The LG may be the same as the target when
      mechanisms such as GPS are used, but in many settings the location
      generator is a separate entity.

   Viewer  The Viewer is the party that ultimately makes use of the
      location information; in particular, the Viewer does not transmit
      location further.  The Viewer is the Location Recipient in the
      final location transmission.

   Target  The Target is the party whose location is described by the
      transmitted LO.  Although the Target does not explicitly play a
      role in the model above, every LO has a Target, and the Target can
      participate in the distribution process by playing other roles.

   It is common for a party to play different roles within the different
   transmissions.  For example, the Target might be the Location
   Recipient during location configuration, then act as Location Server
   when transmitting the LO to a presence server, then act as a Rule
   Maker by providing the presence server rules for further
   dissemination of the LO.  In some cases, the Target may be a Location
   Generator or a Viewer; obviously, we assume that the roles of the LG
   and the Viewer are played by different entities.

   It is assumed that the only information passed from one transmission
   to another is the LO itself, so that information that is communicated
   across multiple hops is encoded in the LO.  In particular, mechanisms
   for providing security across multiple location transmissions must
   define a new LO format, e.g., a PIDF-LO document encapsulated with
   the Cryptographic Message Syntax instead of an unencapsulated



Barnes, et al.           Expires August 28, 2008               [Page 12]

Internet-Draft          Location Object Security           February 2008


   PIDF-LO.

3.3.  Usage Scenarios for this Model

   In order to make the meaning of the above model clearer, this section
   describes how several common use cases can be described using the
   model.  In addition, we describe how the transmission model described
   in RFC 3693 maps into the model described above.

3.3.1.  RFC 3693 model of transmission

   Section 4 of RFC 3693 depicts the relationships of the primary
   Geopriv entities, in which the Location Server acts as a relay
   between a Location Generator and a Location Recipient, with rules
   provided by a Rule Holder.  In this document, we take a more limited
   view of three of these roles: Here an Location Server is simply an
   entity that transmits location (relying on a separate associated
   Location Recipient for input), a Location Generator is simply a
   distinguished Location Server, and Rule Holders are omitted from the
   discussion because they simply act as intermediaries for Rule Makers.
   The omission of Rule Holders is not meant to claim that Rule Holders
   do not exist (for instance, RMs may transmit rules to the LS via a
   store-and-forward network, in which the nodes would be RHs); however,
   they do not have application-level significance.

   In exchange for using these more limited roles, the single "T"-shaped
   diagram of RFC 3693 maps onto a chain of two transmissions, as
   illustrated in Figure 3 below.  The first transmission is from the LG
   (in this case, just another LS) to the LR that acts as the receiving
   component of the Location Server (in the sense of RFC 3693).  The
   second transmission is from the LS acting as the sending component of
   the RFC 3693 Location Server to the LR, as dictated by rules supplied
   by the RM.
                              .
                              .
                       +-------------+
                       |     LS      |
          +----+----+  | +----+----+ |  +----+
          | LG | LS |--->| LR | LS |--->| LR |
          +----+----+  | +----+----+ |  +----+
                 .     +--------|----+
                 .            . |
               ......         . +----+
               . RM .         . | RM |
               ......         . +----+
                              .

                Figure 3: The model of RFC 3693, Section 4



Barnes, et al.           Expires August 28, 2008               [Page 13]

Internet-Draft          Location Object Security           February 2008


3.3.2.  Location Configuration

   Location configuration protocols, such as HELD
   [I-D.ietf-geopriv-http-location-delivery], that require a device to
   specifically "pull" location can be modeled as a location
   transmission as follows: The LCP server discovery mechanism is the
   dissemination channel, in that the discovery mechanism sends the
   endpoint the identity of the LCP server, e.g. the HELD LIS.  The
   endpoint is the Location Recipient and the Target, and the initiator
   of the transmission.  Upon receiving the identity of the LIS, the
   endpoint makes an LCP query to the LIS requesting location.  The LCP
   server is the Location Server and has been internally configured with
   policy (there is no independent Rule Maker in this scenario).  The
   LCP server applies the rules and returns a location object to the
   endpoint.

3.3.3.  Location Conveyance by Value

   A protocol, such as SIP, that conveys a location object by value can
   be modeled as a location transmission as follows.  The calling device
   is the Location Server, and initiates the transmission.  The calling
   device possesses a location object that contains the rules governing
   the location information.  The called device is the Location
   Recipient.  The calling device applies the rules within the location
   object and then sends the location object to the called device (e.g.
   in the body of a SIP INVITE).

3.3.4.  Location Conveyance by Reference

   A protocol, such as SIP, that conveys a location object by reference
   can be modeled as a location transmission as follows.  In this case,
   SIP is the dissemination channel, over which a URI pointing to
   location is conveyed.  The calling device sends the location
   reference, containing both the identity of an LS and the identity of
   the location information, to the called party (e.g. in the header of
   a SIP INVITE).  The called party is the Location Recipient.  Upon
   receiving the location reference, the called party sends a
   dereference request, containing a description of the desired LO, to
   the IS.  The LS is naturally the Location Server, and has been
   previously provisioned with rules by the Rule Maker (likely the
   Target).  The LS applies the appropriate rules for the location
   information and returns a location object to the called party.

3.3.5.  Presence Server

   The subscription to location information on a presence server can be
   modeled as a location transmission as follows.  The presence watcher
   is the Location Recipient, and initiates the transmission.  Through



Barnes, et al.           Expires August 28, 2008               [Page 14]

Internet-Draft          Location Object Security           February 2008


   some dissemination mechanism (e.g. a business card) the watcher
   learns the identity of a presence server and the identity of a target
   whose presence is stored on the server.  The presence subscriber
   sends a subscription request, containing the identity of the target
   (which identifies the desired LO), to the presence server.  The
   presence server has previously been provisioned with rules by the
   Rule Maker (in this case, most likely the target).  The presence
   server applies the rules and constructs a location object which it
   then sends to the presence subscriber.


4.  Required Assurances

   Each of the entities in the above model has expectations about how
   the system works, which may or may not be valid in a given situation.
   Depending on the needs of the entities, they may require assurances
   that their expectations are valid in a given situation.  The goal of
   Geopriv security and privacy mechanisms is to provide such
   assurances.  In order to determine requirements for Geopriv security
   mechanisms, then, we need to understand the assurances required by
   participants in the architecture.

4.1.  Location Transmission

   As described above, there are generally three logical roles in a
   single location transmission.  In some cases, the same entity may
   play multiple roles within a transmission.  In that case, the set of
   assurances required by that entity is the union of the assurances
   required by the roles it fulfills.

4.1.1.  Rule Maker

   The goal of the Rule Maker is provide the LS with policies to apply
   to transmissions, and to ensure that the rules clearly specify how
   the LS should execute them.  The first assurance of relevance to the
   RM is to assure that rules are faithfully transmitted to the correct
   destination: Since policy documents can themselves be sensitive, the
   RM must verify that they are delivered only to the LS it intends,
   i.e., it must authenticate the identity of the LS and verify that the
   authenticated identity belongs to the desired LS.  And since changes
   to a policy document can affect many subsequent transmissions, the RM
   requires assurance that rules are not modified en route to the LS.
   Second, in order to assure that policy is correctly executed, the
   transmitted rules must define an unambiguous mapping from requests to
   allowable LOs.  The RM is further assured that the rules will be
   executed when the LS can provide confirmation that it is able to
   process the supplied rules at the time that the RM transmits them.




Barnes, et al.           Expires August 28, 2008               [Page 15]

Internet-Draft          Location Object Security           February 2008


4.1.2.  Location Server

   The goal of the Location Server is to transmit location in compliance
   with relevant policy.  Thus, the primary assurances the LS requires
   are related to the question of whether a given transmission is
   authorized by policy.  The LS must determine whether the LR is
   authorized to receive location.  As a pre-requisite, the LS must also
   verify that policy is valid, i.e., that the Rule Maker is authorized
   to dictate policy.  All of these authorization decisions require that
   the server authenticate the identities of the parties requesting
   access, the identity of the LR requesting location and the RM
   requesting modifications to policy.  Note that the manner in which
   these authorization policies are installed on the LS and applied to
   specific transmissions is a matter of local configuration.

4.1.3.  Location Recipient

   The goal of the Location Recipient is to acquire the desired LO.  In
   general, this assurance can be decomposed into assuring that the LS
   is the one intended to deliver the LO and that the LO is faithfully
   transmitted from the LS to the LR; the LS is trusted by the LR to
   deliver the proper LO.  When the transmission is initiated by the LS,
   the LR may not have information about the LS or the LO prior to the
   transmission, so it must also trust that the LS delivering location
   was properly instructed to do so.  When the LR initiates a
   transmission, the LR knows the identity of the LS and relevant
   properties of the LO, so the LR can be assured that the LS from which
   it receives location is the proper one by authenticating the identity
   of the LS.  In both cases, the LR requires assurance that the LO is
   not modified while en route between the LS and the LR.

4.2.  End-to-end distribution

   In addition to the three transmission entities described above, we
   also consider three distinguished entities in an end-to-end
   distribution scenario.  They require assurances about the entire
   distribution chain, or the entire distribution tree.

4.2.1.  Location Generator

   The Location Generator is the Location Server at the root of the
   distribution tree.  The LG thus offers the valuable service of acting
   as an Internet-accessible source of location information, and its
   primary interest is in controlling the use of this service,
   especially controlling access to it.  In terms of the model, the LG
   is interested in controlling the set of Viewers that are able to
   interpret and use the LO.  There are two basic approaches to
   achieving this control: First, the LG may distribute LOs that are



Barnes, et al.           Expires August 28, 2008               [Page 16]

Internet-Draft          Location Object Security           February 2008


   encrypted in such a way that only the Viewers that are authorized to
   access the location encoded in the LO.  Second, the LG may distribute
   location references (i.e., it may support a dissemination channel),
   and only provide an LO in response to a dereference query by an
   authorized LR.  (Because these references are not valuable by
   themselves, the LG can allow them to be distributed by parties that
   may not be authorized to access the location they refer to.)  In
   order for the Viewer to obtain the referenced location, it has to
   engage in a transmission in which the LG is the LS; as part of this
   transmission, the LG can authenticate the LR and verify directly that
   the Viewer is authorized to receive the location.

4.2.2.  Viewer

   The Viewer is the ultimate consumer of a Location Object.  As a
   consumer, the Viewer requires assurance that the LO it receives is
   correct.  In most situations, it is not possible to verify the
   correctness of location directly.  Rather, a Viewer can receive
   assurance that a location is correct by virtue of assurance as to the
   identity of the source of the LO (i.e., the LG that provided it), and
   assurance that the LO was not modified en route to the Viewer.  That
   is, the Viewer can have more confidence in the correctness of an LO
   when it can verify that the location was provided by a source that it
   trusts to provide correct location.  As with LG access control, this
   verification can be done either through the object itself or through
   the LS that provides it.  If the LO itself provides a verifiable
   assertion as to its origin, then the Viewer receives assurance about
   its correctness even if it receives the LO via an untrusted channel.
   On the other hand, if the LS that provides the LO is trusted to
   provide correct location, then the Viewer receives assurance about
   the LO's correctness even if the ultimate origin of the LO (i.e., the
   LG) remains unknown to the Viewer.

4.2.3.  Target

   The interests of the Target are discussed at length in RFC 3693 and
   RFC 3694.  The Target by itself has no technical involvement in the
   distribution process; in order to affect how its location is
   distributed, it must take on one of the roles described above.  For
   instance, the Target will commonly act as an LS to explicitly control
   how location is transmitted, or as a Rule Maker to control
   distribution by a third-party LS.  Much like the LG, the main concern
   of the Target is controlling access to its location.  If the Target
   acts as an LS, then the assurances and mechanisms available to it are
   essentially the same as those available to the LG.






Barnes, et al.           Expires August 28, 2008               [Page 17]

Internet-Draft          Location Object Security           February 2008


4.3.  Summary of Required Assurances

   o  Rules must be protected against unauthorized modification en
      route.

   o  Rules must be protected against exposure to unauthorized parties.

   o  Location servers must accept rules only from authorized rule
      makers, as determined by local policy.

   o  Location objects must be exposed only to location recipients
      authorized by the associated rules (i.e. the rules contained in
      the location object, obtained from an authorized rule maker, or
      pre-configured on the location server in accordance with local
      policy).

   o  Location objects must be protected against unauthorized
      modification en route.

   o  Location generators must be able to assert that they have created
      a particular location object.

   o  Location viewers must be able to determine that a location object
      has passed unchanged through a chain of location servers and
      (intermediate) location recipients.


5.  Security Requirements

   In order to enable the GEOPRIV location distribution system to
   provide assurances discussed in Section 4, the constituent protocols
   must make certain security mechanisms available to the parties
   involved.  In this section, we describe which security mechanisms are
   necessary to achieve each the assurances described in Section 4.3,
   and then provide requirements for such security mechanisms.  In so
   doing, we provide requirements for three types of protocols:

   o  Policy Conveyance Protocols communicate policy information between
      rule makers and location servers.  These can be dedicated
      protocols (e.g., XCAP), or, when rules are carried within a
      location object, the location conveyance protocol can act as a
      policy conveyance protocol.

   o  Location Conveyance Protocols communicate location requests and
      responses between the location server and the location recipient
      (e.g., SIP Geolocation, HELD, and Location Dereference Protocols)





Barnes, et al.           Expires August 28, 2008               [Page 18]

Internet-Draft          Location Object Security           February 2008


   o  Location Object Formats define how location information and
      ancillary data are encoded; information is passed between distant
      points in the distribution chain by being carried in the LO.

   o  Location Reference Formats define how location references (i.e.,
      request parameters) are encoded for dissemination from an LS to
      LRs.

   The term "Location Conveyance Protocol" is similar to the term "using
   protocol" introduced in RFC 3693, and used in RFC 4745, et al.  The
   distinction between a Location Conveyance Protocol and other
   protocols that may incidentally carry location information (e.g., IP
   or TCP) is that a Location Conveyance Protocol makes a normative
   requirement on the LS (i.e., the party that transmits the LO) to
   apply policy.  Note that in some cases, the LOs carried by a location
   conveyance protocol will themselves carry rules.  When a location
   conveyance protocol supports the transmission of such LOs, it is also
   considered a policy conveyance protocol.

   The requirements described below are not strict requirements: They
   are lists of security features that must be present in order to
   support a certain set of assurances.  A protocol specification can be
   in compliance with this document either by explaining how the
   protocol meets the security requirements for each assurance, or by
   explicitly disclaiming its ability to provide assurances for which it
   does not fulfill the requirements.

   Note also that the security features listed below need not be
   provided by cryptographic means in all cases.  The primary example of
   non-cryptographic protection is the use of appropriate policy at an
   LS.  As an additional example, protocols that are restricted to a
   local network (such as DHCP or LLDP-MED) may derive security
   properties from the physical security of the network.

5.1.  Unauthorized Modification of Rules

   Rules are exposed to the risk to unauthorized modification en route
   when they are transmitted from a rule maker to a location server.  A
   policy conveyance protocol can protect rules from unauthorized
   modification in two ways.  First, the policy conveyance protocol can
   allow rules to be transmitted within an integrity-preserving
   encapsulation, such as CMS or S/MIME; this includes the use of an
   integrity-preserving LO format.  Second, the policy conveyance
   protocol can allow a mode of operation in which it is carried over an
   integrity-protected channel, such as TLS.






Barnes, et al.           Expires August 28, 2008               [Page 19]

Internet-Draft          Location Object Security           February 2008


   REQ-1  A policy conveyance protocol MUST either support the provision
      of rules in an integrity-preseving encapsulation, or else it must
      offer a mode of operation in which rules are only transmitted over
      an integrity-protected channel.

5.2.  Unauthorized Exposure of Rules

   Rules can be exposed to unauthorized parties in two ways.  Either the
   RM transmits the rules to a party who is not authorized by the RM to
   act as a location server; or else an unauthorized party is able to
   access the rules en route from the RM to a location server.  A
   mechanism that addresses both risks of exposure is to encapsulate the
   rules inside an encrypted object that can only be read by an
   authorized location server (e.g.  CMS or S/MIME).  Alternatively, the
   first risk can be mitigated by authenticating the location server to
   the rule maker; and the second risk can be mitigated by transmitting
   the rules only over confidentiality-protected channel.

   REQ-2  A policy conveyance protocol MUST either support the
      encapsulation of rules in an encrypted object format, or else it
      must provide mechanisms for the RM to authenticate the LS, and to
      the RM to transmit rules only over a confidentiality-protected
      channel.

5.3.  Acceptance of Rules from Unauthorized Rule Makers

   A location server must not accept rules from parties who are not
   authorized by local policy to update the set of rules used by the
   location server.  This risk can be mitigated in two ways.  By
   encapuslating the rules inside an object that is signed by the
   authorized rule maker, or by allowing authenticate the LS to
   authenticate the RM within the policy-handling protocol.

   REQ-3  A policy conveyance protocol MUST either support the signing
      of rules by the rule maker, or else the policy conveyance protocol
      must provide a mechanism for the LS to authenticate the identity
      of the RM.

5.4.  Unauthorized Exposure of Location Objects

   A location object can be exposed to unauthorized parties via a
   location transmission in two ways.  Either a party other than the
   location recipient in a transmission is able to access the location
   object en route between the LS and the LR; or else the location
   server transmits the location object to an unauthorized location
   recipient.  The former risk can be mitigated by transmitting the
   location object only over an encrypted channel.  Mitigation of the
   latter risk differs depending on whether it is the location server or



Barnes, et al.           Expires August 28, 2008               [Page 20]

Internet-Draft          Location Object Security           February 2008


   the location recipient who initiates the location transmission (i.e.,
   the "push" case vs. the "pull" case).  However, note that the
   mechanisms discussed in this section need not be applied in the case
   where distribution of a location object is unconstrained, i.e., when
   the authorization policy of the location server indicates that all
   possible location recipients are authorized to receive a particular
   location object.

   When the location server initiates the transmission, the LS must
   apply the authorization policy contained in the appropriate rules
   (i.e. the rules contained in the location object, obtained from an
   authorized rule maker, or locally configured on the LS) to determine
   if the location recipient is authorized to receive the given location
   object.  In order to have a reliable identity on which to base these
   authorization decisions, the location server must either authenticate
   the location recipient within the location conveyance protocol, or
   else encapsulate the location object in a secure format so that it is
   accessible only to the authorized recipient.

   The case where the location recipient initiates the transaction is
   further sub-divided depending on whether the location server receives
   parameters in a "clear" or "opaque" form, as discussed in Section
   3.1.2.  If the location server receives parameters in a "clear" form,
   then parameters themselves cannot provide any authentication.  In
   this case, the location server MUST authenticate the identity of the
   location recipient and then apply authorization policy to determine
   if the location recipient is authorized to receive the requested
   location object.

   If the location server receives parameters in "opaque" form, then the
   location server may be able to derive some assurance about the
   location recipient based on the fact that the location recipient
   possesses the opaque token(s) presented in a request.  In some cases,
   policy may indicate that the possession of these tokens is be
   sufficient for the location sever to determine that the location
   recipient is authorized to receive a given location object.  Note
   however, that because these opaque parameters are intended to be used
   by multiple requestors, they are not bound to the identity of any
   given watcher and thus MUST NOT be used to satisfy a requirement to
   authenticate the LR via a shared secret (as in RFC 5025).  When
   policy does not allow the use of these opaque tokens as authorization
   credentials, the location server MUST authenticate and explicitly
   authorize the location recipient as in the "clear" case above.

   Opaque parameters are to LRs via a dissemination channel (the dotted
   line in Figure 1), in the form of location references in a location
   reference format.  In formulating policy that determines whether an
   opaque token suffices for authenticate, rule makers and LS operators



Barnes, et al.           Expires August 28, 2008               [Page 21]

Internet-Draft          Location Object Security           February 2008


   should keep in mind that the utility of opaque parameters for
   authentication is inherently limited by the security of the
   dissemination channel.  An opaque token is a reliable authenticator
   only if it is only known to authorized location recipients.  So a
   token used as authenticator MUST be provided confidentiality
   protection by the dissemination channel, and it MUST contain enough
   entropy that it is difficult to guess, a minimum of 128 bits.

   Dissemination channels can take many different forms, from the SIP
   Geolocation header to SMTP message bodies to business cards.  Because
   of this diversity, this document does not place requirements on the
   security features of dissemination protocols, but instead provides
   recommendations for which protocols should be used as dissemination
   channels.  In particular, it is RECOMMENDED protocols used as
   dissemination channels provide confidentiality, authenticity, and
   integrity protection.  Conversely, because these properties cannot be
   guaranteed, it is RECOMMENDED that an LS minimize the risk introduced
   by this exposure by minimizing the set of LOs to which a location
   reference refers, when that reference is not subject to
   authentication and access control.

   Finally, it may be the case that some LSs along a distribution path
   are unauthorized to access an LO that they transmit.  In this case,
   an LO must be encapsulated in an encrypted LO format so that it is
   only accessible by authorized viewers.  This encapsulation may be
   applied by the LG or by an intermediate LS.

   Second, opaque tokens can be retransmitted.  Therefore, unless an
   opaque token format is able to encode retransmission rules,
   possession of an opaque token is never sufficient to authorize a
   party to receive a location object for which retransmission is
   forbidden.

   REQ-4  A location conveyance protocol MUST either support the
      encapsulation of LOs in an encrypted object format, or else it
      must provide mechanisms for the LS to authorize the LR, and to the
      LS to transmit LOs only over a confidentiality-protected channel.
      Input to the authorization process might be the authenticated
      identity or an opaque token (as a form of proof of possession).

   REQ-5  An LS MUST apply authentication and authorization policy to
      requests in which all parameters are in clear form.  When a
      request contains opaque parameters, it is RECOMMENDED that the
      same process be followed.







Barnes, et al.           Expires August 28, 2008               [Page 22]

Internet-Draft          Location Object Security           February 2008


   REQ-6  A location reference format MUST define a format for
      references that requires a cryptographically random component with
      a minimum entropy of 128 bits.

   REQ-7  An LS that does not apply identity-based authorization policy
      to requests for some references (e.g., for opaque references) MUST
      minimize the set of locations to which those references refer by
      setting a restrictive default policy.  Additional rules provided
      by RMs MAY modify this default policy to make it more or less
      permissive.

   REQ-8  In order to support the prevention of unauthorized exposure to
      intermediate LSs, a location object format MUST include a format
      in which the LO is encrypted.

5.5.  Unauthorized Modification of Location Objects

   Location Objects are at risk of unauthorized modification en route
   when they are transmitted from the location server to the location
   recipient.  Location objects can be protected against such
   unauthorized modification if the location conveyance protocol
   transmits location objects in an integrity-protected format or over
   an integrity-protected channel.  Additionally, a Location Recipient
   risks receipt of a modified (or fabricated) location object if it
   does not authenticate that the location object was transmitted by an
   entity that is authorized (by local policy) to act as a location
   server.

   Note that these protections by the location conveyance protocol need
   not be used if the location object itself is signed (either by the
   location generator or by the location server); provided that the
   location recipient is able to verify this signature.  However, when
   the location recipient is not the location viewer, then the location
   recipient may be unable to verify a signature intended to provide
   end-to-end (or middle-to-end) integrity.

   REQ-9  A location conveyance protocol MUST either support the
      conveyance of LOs in an integrity-preseving encapsulation, or else
      it must offer a mode of operation in which LOs are only
      transmitted over an integrity-protected channel.

   REQ-10  A location conveyance protocol MUST allow the LR to
      authenticate the LS.








Barnes, et al.           Expires August 28, 2008               [Page 23]

Internet-Draft          Location Object Security           February 2008


5.6.  Assertion of Location Object Origins

   A location generator can assert that it created a particular location
   object by generating a cryptographic signature over the location
   object.  Such an assertion allows a location viewer to identify the
   party that created a location object or that participated in its
   distribution, and thus make local policy decisions based on the
   origin or intermediate provenance of a location object.
   Additionally, such a signature can provide end-to-end integrity
   protection for the portion of the location object covered by the
   signature.

   Likewise, an LS can sign an object to assert that it was included
   along the distribution path of the LO.  The mechanisms discussed in
   Section 5.5 enable a location recipient to determine that a location
   object was not modified en route from the most recent location
   server.  However, in a setting where a location object traverses a
   chain of multiple location servers and location recipients, the
   ultimate location viewer may not trust every location server in the
   chain.  When a location viewer has a trust relationship with a
   particular location server in the chain, that server can sign the
   object tp assure the integrity of the location object through
   multiple transmissions (i.e., to provide middle-to-end integrity
   protection).

   REQ-11  In order to support assertion of the origin and distribution
      of LOs, and end-to-end or middle-to-end integrity protection, a
      location object format must enable an LG or LS to
      cryptographically sign a location object.

5.7.  Summary of Security Requirements

   The following security requirements apply to a policy conveyance
   protocol:

   REQ-1  A policy conveyance protocol MUST either support the provision
      of rules in an integrity-preseving encapsulation, or else it must
      offer a mode of operation in which rules are only transmitted over
      an integrity-protected channel.

   REQ-2  A policy conveyance protocol MUST either support the
      encapsulation of rules in an encrypted object format, or else it
      must provide mechanisms for the RM to authenticate the LS, and to
      the RM to transmit rules only over a confidentiality-protected
      channel.






Barnes, et al.           Expires August 28, 2008               [Page 24]

Internet-Draft          Location Object Security           February 2008


   REQ-3  A policy conveyance protocol MUST either support the signing
      of rules by the rule maker, or else the policy conveyance protocol
      must provide a mechanism for the LS to authenticate the identity
      of the RM.

   The following security requirements apply to a location conveyance
   protocol:

   REQ-4  A location conveyance protocol MUST either support the
      encapsulation of LOs in an encrypted object format, or else it
      must provide mechanisms for the LS to authenticate the LR, and to
      the LS to transmit LOs only over a confidentiality-protected
      channel.

   REQ-9  A location conveyance protocol MUST either support the
      conveyance of LOs in an integrity-preseving encapsulation, or else
      it must offer a mode of operation in which LOs are only
      transmitted over an integrity-protected channel.

   REQ-10  A location conveyance protocol MUST allow the LR to
      authenticate the LS.

   The following security requirements apply to a secure location object
   format:

   REQ-8  In order to support the prevention of unauthorized exposure to
      intermediate LSs, a location object format MUST include a format
      in which the LO is encrypted.

   REQ-11  In order to support assertion of the origin and distribution
      of LOs, and end-to-end or middle-to-end integrity protection, a
      location object format must enable an LG or LS to
      cryptographically sign a location object.

   The following security requirements apply to a location reference
   format:

   REQ-6  A location reference format MUST define a format for
      references that requires a cryptographically random component with
      a minimum entropy of 128 bits.

   In addition, the following are recommended practices for LS policy:

   REQ-4  An LS MUST apply authentication and authorization policy to
      requests in which all parameters are in clear form.  When a
      request contains opaque parameters, it is RECOMMENDED that the
      same process be followed.




Barnes, et al.           Expires August 28, 2008               [Page 25]

Internet-Draft          Location Object Security           February 2008


   REQ-7  An LS that does not apply authentication and authorization
      policy to requests for some references MUST minimize the set of
      locations to which those references refer.


6.  Security Considerations

   The focus of this document is the security of location objects.  As
   such, security concerns are discussed throughout.


7.  Acknowledgements

   This work was based on the security investigations conducted as part
   of the GEOPRIV Layer-7 Location Configuration Protocol design team,
   which produced [I-D.ietf-geopriv-l7-lcp-ps].  We would like to thank
   all the members of the design team.


8.  IANA Considerations

   This document makes no request of IANA.


9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

9.2.  Informative References

   [I-D.ietf-ecrit-framework]
              Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
              "Framework for Emergency Calling using Internet
              Multimedia", draft-ietf-ecrit-framework-04 (work in
              progress), November 2007.

   [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-05 (work in
              progress), February 2008.

   [I-D.ietf-geopriv-l7-lcp-ps]
              Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
              Location Configuration Protocol; Problem Statement and



Barnes, et al.           Expires August 28, 2008               [Page 26]

Internet-Draft          Location Object Security           February 2008


              Requirements", draft-ietf-geopriv-l7-lcp-ps-06 (work in
              progress), November 2007.

   [I-D.ietf-geopriv-lbyr-requirements]
              Marshall, R., "Requirements for a Location-by-Reference
              Mechanism", draft-ietf-geopriv-lbyr-requirements-01 (work
              in progress), October 2007.

   [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-14 (work in progress),
              February 2008.

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

   [RFC3694]  Danley, M., Mulligan, D., Morris, J., and J. Peterson,
              "Threat Analysis of the Geopriv Protocol", RFC 3694,
              February 2004.

   [RFC3825]  Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
              Configuration Protocol Option for Coordinate-based
              Location Configuration Information", RFC 3825, July 2004.

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

   [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.

   [RFC4776]  Schulzrinne, H., "Dynamic Host Configuration Protocol
              (DHCPv4 and DHCPv6) Option for Civic Addresses
              Configuration Information", RFC 4776, November 2006.

   [RFC4825]  Rosenberg, J., "The Extensible Markup Language (XML)
              Configuration Access Protocol (XCAP)", RFC 4825, May 2007.

   [RFC5025]  Rosenberg, J., "Presence Authorization Rules", RFC 5025,
              December 2007.








Barnes, et al.           Expires August 28, 2008               [Page 27]

Internet-Draft          Location Object Security           February 2008


Authors' Addresses

   Richard Barnes
   BBN Technologies
   9861 Broken Land Pkwy, Suite 400
   Columbia, MD  21046
   USA

   Phone: +1 410 290 6169
   Email: rbarnes@bbn.com


   Matt Lepinski
   BBN Technologies
   10 Moulton St
   Cambridge, MA  02138
   USA

   Phone: +1 617 873 5939
   Email: mlepinski@bbn.com


   Hannes Tschofenig
   Nokia Siemens Networks
   Otto-Hahn-Ring 6
   Munich, Bavaria  81739
   Germany

   Email: Hannes.Tschofenig@nsn.com
   URI:   http://www.tschofenig.com


   Henning Schulzrinne
   Columbia University
   Department of Computer Science
   450 Computer Science Building
   New York, NY  10027
   US

   Phone: +1 212 939 7004
   Email: hgs@cs.columbia.edu
   URI:   http://www.cs.columbia.edu









Barnes, et al.           Expires August 28, 2008               [Page 28]

Internet-Draft          Location Object Security           February 2008


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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Barnes, et al.           Expires August 28, 2008               [Page 29]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/