Geopriv                                                        R. Barnes
Internet-Draft                                               M. Lepinski
Updates: 3693, 3694                                     BBN Technologies
(if approved)                                              H. Tschofenig
Intended status: Informational                    Nokia Siemens Networks
Expires: January 15, 2009                                 H. Schulzrinne
                                                     Columbia University
                                                           July 14, 2008


               Additional Location Privacy Considerations
                     draft-barnes-geopriv-lo-sec-03

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 January 15, 2009.

Abstract

   This document discusses security and privacy concerns related to the
   distribution of location information over the Internet.  We clarify
   how privacy rules can be enforced by a location server, and how
   privacy rules should be interpreted in store and forward networks.
   We also describe general mechanisms for providing end-to-end
   assurances about a location object.





Barnes, et al.          Expires January 15, 2009                [Page 1]


Internet-Draft              Location Privacy                   July 2008


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Privacy rule enforcement . . . . . . . . . . . . . . . . . . .  3
     3.1.  Reference model  . . . . . . . . . . . . . . . . . . . . .  4
       3.1.1.  Context identifiers  . . . . . . . . . . . . . . . . .  8
       3.1.2.  Rule sets  . . . . . . . . . . . . . . . . . . . . . . 10
       3.1.3.  Location contexts  . . . . . . . . . . . . . . . . . . 11
     3.2.  Deployment scenarios . . . . . . . . . . . . . . . . . . . 12
       3.2.1.  Location dereference server  . . . . . . . . . . . . . 12
       3.2.2.  Location-enhanced presence server  . . . . . . . . . . 12
       3.2.3.  "On-behalf-of" server  . . . . . . . . . . . . . . . . 13
       3.2.4.  Location configuration . . . . . . . . . . . . . . . . 13
   4.  Location privacy in store-and-forward networks . . . . . . . . 14
   5.  End-to-End Assurances about Location Content and Access  . . . 14
     5.1.  Threats to Location Objects  . . . . . . . . . . . . . . . 15
       5.1.1.  Threats to Location Integrity and Authenticity . . . . 15
       5.1.2.  Threats to Location Privacy  . . . . . . . . . . . . . 17
     5.2.  Required Assurances  . . . . . . . . . . . . . . . . . . . 17
     5.3.  Protocol mechanisms  . . . . . . . . . . . . . . . . . . . 18
     5.4.  Mechanisms within the Location Object Format . . . . . . . 19
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 21
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 21
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
   Intellectual Property and Copyright Statements . . . . . . . . . . 24





















Barnes, et al.          Expires January 15, 2009                [Page 2]


Internet-Draft              Location Privacy                   July 2008


1.  Introduction

   The basic privacy and security model for location distribution over
   the Internet are discussed in RFC 3693 and RFC 3694
   [RFC3693][RFC3694].  RFC 3693 documents describe a set of roles that
   entities play in the location distribution process, and the security
   and privacy requirements that entities in those roles must satisfy.
   RFC 3694 describes a set of threats to the privacy of location
   information and how those threats can be mitigated within the
   framework of RFC 3693.

   RFCs 3693 and 3694 define a very general framework of privacy and
   security requirements.  Since the publication of those documents,
   additional use cases have arisen that require more detailed
   discussion of how privacy mechanisms are to be applied.  This
   document provides additional detail and explanation of privacy and
   security concerns in three areas:

   1.  How privacy rules are enforced by an LS and the role of
       identifiers in this process

   2.  How privacy rules should be interpreted in store-and-forward
       networks, and

   3.  How an LO can be provided security properties end-to-end (between
       creation and ultimate use)

   These topics are addressed in Section 3, Section 4, and Section 5,
   respectively.


2.  Terminology

   This document uses the following terms defined RFC 3693: Location
   Generator (LG), Location Object (LO), Location Recipient (LR),
   Location Server (LS), Target, privacy rule.


3.  Privacy rule enforcement

   One of the critical privacy-preserving components of the Geopriv
   framework is the application of authorization policies by an LS.
   This feature is what enables an LS to store and forward information
   about the location of Targets and still act as a privacy preserving
   entity.  Rule Makers provision the LS with authorization policies,
   and the LS restricts the location information that it transmits over
   its notification interface in order to comply with these rules and
   preserve the privacy of location information accessible through the



Barnes, et al.          Expires January 15, 2009                [Page 3]


Internet-Draft              Location Privacy                   July 2008


   LS.

   In this section, we define an abstract model for the constituent
   parts of the rule enforcement process.  In this model, the
   authorization policies guiding how the LS should provide location are
   represented by logical triples of the form (identifier, rules,
   location).  We discuss the privacy impact of choices for each of
   these three parts.  Finally, we examine how this framework maps onto
   a set of deployment scenarios.

3.1.  Reference model

   Protocols that implement the notification interface for an LS can
   generally be decomposed into messages that request location (sent
   from LR to LS) and messages that respond to location requests (sent
   from LS to LR).  This distinction is natural for a synchronous
   request/response protocol.  In an asynchronous publish/subscribe
   pattern, the request messages are requests for subscriptions and the
   responses are publications for those subscriptions.  (In the case
   where the transmission is initiated by another entity than the LR, an
   implicit request by the initiating entity is assumed.)  The process
   of applying authorization policies is thus the process that tells the
   LS what, if any, location to return in response to a given request.

   The overall privacy-enhanced location distribution process is
   illustrated in Figure 1 (an expanded view of Figure 1 in RFC 3693).
   A location server is configured with a set of location information
   sources (LGs) that provide information to location contexts.
   Authorization contexts are created on the LS by Rule Makers.
   Location Recipients access location by means of these contexts, in
   compliance with the specified policies.




















Barnes, et al.          Expires January 15, 2009                [Page 4]


Internet-Draft              Location Privacy                   July 2008


   (preamble)

                                              +-------Req-------+
                                              |                 |
                      +--Location Server------|-----+           |
                      |                       V     |           |
                      |  +--------+     +--------+  |           |
      +---------+     |  |Context1|     |ContextN|  |       +---------+
      |Location |     |  |========|     |========|  |       |Location |
      |Generator|--+  |  |Ident.  | ... |Ident.  |---Resp-->|Recipient|
      +---------+  |  |  |Rules   |     |Rules   |  |       +---------+
                   +----->LO Ctxt |     |LO Ctxt |  |
                      |  +--------+     +--------+  |
                      |     ^              ^        |
                      +-----|--------------|--------+
                            |              |
                         +--------+     +--------+
                         |  Rule  |     |  Rule  |
                         |  Maker |     |  Maker |
                         +--------+     +--------+


   A privacy-preserving location server

                                 Figure 1

   The input to the a given decision is a location request.  While the
   specific semantics available in requests will vary according to the
   protocol, all requests will contain two general data:

   1.  An identifier for the desired location object(s)

   2.  A set of parameters that describe acceptable responses

   Many requests will also contain an identifier for the requesting LR,
   such as an IP address or SIP URI (such identification may be required
   in some authorization scenarios).

   For example, in a SIP SUBSCRIBE request [RFC3265], the desired LO is
   identified by the Request URI, and any parameters are described in
   the body of the message; the LR is identified by the authenticated
   identity of the subscriber.  In the HELD location configuration
   protocol [I-D.ietf-geopriv-http-location-delivery], the source IP
   address of request is used to identify the LO to be returned (as well
   as the recipient), and the request body can specify whether the
   returned LO should be in geodetic or civic form (among other
   parameters).




Barnes, et al.          Expires January 15, 2009                [Page 5]


Internet-Draft              Location Privacy                   July 2008


   In order to respond to a request, an LS must first decide whether the
   request is authorized, and second, if authorized, construct an LO to
   be sent in response.  The actions the LS takes in this process are
   defined by "authorization contexts", consisting of three elements:

   1.  An identifier for the context

   2.  A set of privacy rules

   3.  A location context

   The identifier in the context is the one that LRs use in their
   requests, and uniquely identifies the context within the scope of the
   LS.  The privacy rules describe constraints on the request, on the
   returned LO, and on the context itself.  The location context
   describes how the LS is to construct the base LO (which will be
   returned after being transformed by the privacy rules).  Each of
   these elements is discussed in more detail in their respective
   sections below.

   Having been provisioned with a set of authorization contexts, the LS
   constructs its response to a location request in three steps:

   1.  Retrieve the context with the identifier specified in the request
       (if none, reject request).

   2.  Match the request against the privacy rules in the authorization
       context.  If authorized, proceed; otherwise, reject the request.

   3.  Retrieve the base LO from the location context in the
       authorization context.  Transform according to privacy rules and
       request parameters.

   These steps are illustrated in Figure 2.

















Barnes, et al.          Expires January 15, 2009                [Page 6]


Internet-Draft              Location Privacy                   July 2008


   (preamble)
                         +---------+----------+
                         | Request | Response |
                         +---------+----------+
                              |        ^
                              |        |
                              V  (1)   |
                         +----------+  |
                         |Identifier|  |
                         +----------+  |
                              |        |
                              V  (2)   |
                         +--------------------+
                         |   Privacy Rules    |
                         +--------------------+
                              |        ^
                              V  (3)   |
                         +--------------------+
                         |  Location Context  |
                         +--------------------+

   (postamble)

                                 Figure 2

   Note that all three parts of an authorization context are
   independent, and can be combined in a many-to-many fashion: For
   example, a single rule set can be applied to many authorization
   contexts, a single location context can have many different rule sets
   associated with it in different authorization contexts, and the same
   (rule set, location context) pair may be the basis for several
   independent authorization contexts.  The identifier, however, must
   uniquely identify a context within the scope of the LS.

   Authorization contexts are specified and provisioned to the LS by
   Rule Makers, not necessarily in the form described above (i.e., some
   parts may be implicitly specified).  For example, when a presentity
   provisions a presence server with a rule set for its location-
   enhanced presence, it has implicitly created an authorization context
   with its presence URI, its location-enhanced presence, and the
   specified rule set.  Other policy provisioning protocols may allow
   RMs to explicitly specify all three attributes.  As in the model of
   RFC 3693, many different parties can be Rule Makers, including, for
   example, the Target of the LOs being presented (or third-parties
   acting on their behalf), or the operator of the LS.  The LS
   ultimately decides which entities are authorized to be Rule Makers by
   granting or denying the ability to create or manipulate authorization
   contexts.



Barnes, et al.          Expires January 15, 2009                [Page 7]


Internet-Draft              Location Privacy                   July 2008


   In constructing its response to a request, the LS uses each element
   of an authorization context in turn.  First, in order for a request
   to be valid, the LO identifier in the request must match the
   identifier for some authorization context on the LS.  This is the
   authorization context the LS uses for the remainder of the process;
   if no context is found, the request fails.  Second, the LS determines
   whether the constraints that the rule set places on the request and
   the context are satisfied.  If these constraints are not satisfied,
   the request fails.  If the constrains are satisfied, then the LS
   constructs a location object as described by the location context,
   transforms it to meet the requirements of the rule set, and returns
   the resulting LO.

3.1.1.  Context identifiers

   The first step in the process of responding to a location request is
   to use an identifier from the request to identify the authorization
   context to be used to respond to the request.  If no authorization
   context matches the identifier in the request, then no location is
   returned by the LS.  The privacy of this identifiers is thus a first
   control on the privacy of the referenced location information.
   Identifiers can be either public or private:

   Public Identifier:  An identifier that is generally available, or
      which can be guessed by an LR based only on public information
      (such as the identity of the LS or a public identifier of the
      Target)

   Private Identifier:  An identifier that is not public.  A private
      identifier may be derived in part from public information, but
      must contain sufficient non-public components that guessing the
      entire identifier would require significant effort by an entity
      not already in possession of the identifier.

   (The distinction between "public" and "private" identifiers is
   closely related to the distinction between linked and unlinked
   pseudonyms.  For example, an unlinked pseudonym can be used as a
   private identifier for a context that refers to that entity's
   location.  We avoid those terms here, however, because context
   identifiers identify authorization contexts, not necessarily
   endpoints or Targets.)

   Whether an identifier is private or public is determined by the set
   of entities that have access to it, not by its contents.  Even if a
   URI is constructed to be difficult to guess, it can still be public
   if it is exposed to public access (e.g., by posting on an open web
   page).  In order to an identifier to stay private, it must be
   communicated only to authorized entities over confidentiality-



Barnes, et al.          Expires January 15, 2009                [Page 8]


Internet-Draft              Location Privacy                   July 2008


   protected channels, and it must be difficult for a third party to
   guess based on public information.

   Because private identifiers are known initially only to the LS and
   RM, in order to be used to retrieve location, they must be sent to
   LRs over some dissemination channel (possibly composed of several
   steps using different protocols).  The security properties of this
   channel influence how strongly the privacy of an identifier is
   protected.  All entities that can observe the identifier through the
   dissemination channel are able to request LOs within its scope
   (assuming that they can find the correct LS to query).  In order to
   mitigate the privacy risks introduced in this way, private
   identifiers should always be sent over authenticated,
   confidentiality-protected channels.

   The requirement that a private identifier be difficult to guess means
   that the identifier must contain a component that is randomly
   generated by the LS or the RM (where the randomness is from the
   perspective of an outside third party).  The required amount of
   randomness in the random component (its entropy, corresponding to the
   length of a string of randomly-chosen bits) will vary by application.
   In applications where an LR can make many guesses, the entropy will
   need to be correspondingly large.  In applications where the LS
   limits the number of guesses an LR can make, or the rate at which it
   can make them, the entropy may be lower (in some such applications,
   it may even be acceptable to use public identifiers under this
   constraint).  As a baseline suitable for nearly all applications
   using private identifiers, this document recommends the incorporation
   of a 128-bit string chosen at random by the LS or the RM.

   Randomness, however, is neither necessary nor sufficient for an
   identifier to be private.  Some identifiers that seem random, such as
   IP addresses and MAC addresses, must be considered public because the
   can easily be observed in network traffic.  The following are
   examples of public and private identifiers:

   o  Public identifiers:

      *  Published SIP AoR: <sip:asd887f9dfkk76690@example.com>

      *  Location URI with a public identifier:
         <held://lis.example.com/context/alice;use=lbyr>

      *  IP address: 192.0.2.34

      *  MAC address: 00-B0-D0-86-BB-F7





Barnes, et al.          Expires January 15, 2009                [Page 9]


Internet-Draft              Location Privacy                   July 2008


   o  Private identifiers:

      *  Temporary GRUU [I-D.ietf-sip-gruu]:
         <sip:asd887f9dfkk76690@example.com;gr>

      *  Location URI with a private identifier:
         <held://lis.example.com/context/f5kc85O1djUZK0nx;use=lbyr>

      *  Undisclosed SIP AoR: <sip:bob@example.net>

   By choosing the types of identifiers they use for contexts, RMs can
   create a coarse-grained access control.  Allowing the use of a public
   identifier essentially makes all LOs within the scope of the
   associated location context available for public use, and allowing
   the use of a private identifier grants access only to entities that
   have access to the identifier.  This means that when the only control
   on access to a context is the privacy of the identifier (i.e., when
   the rules grant all requests), the privacy of the LO is essentially
   the privacy of the identifier.

3.1.2.  Rule sets

   The rule set contained in a context define constraints on when the LS
   may grant requests and when it must deny them.  These constraints are
   placed on three things: The requests themselves, the LO to be
   returned, and the context itself.  The following are some example
   rules of all three types:

   o  [request] Grant only requests from the subnet 19.0.2.0/24

   o  [request] Grant only requests made by <sip:alice@example.com> and
      <sip:bob@example.net>

   o  [LO] Grant access only to geodetic location

   o  [LO] Grant access only to location accurate to within 100 meters.

   o  [context] Grant access only to the first three requests for this
      authorization context

   o  [context] Grant access only to requests for this authorization
      context before midnight on December 31, 2008

   Rules enter into contexts in two ways: Through the RM, or through the
   LO.  "Local" rules are installed by RMs, and are a fixed part of the
   context.  "Sticky" rules are attached to the base LO returned by the
   location context, and travel along with the LO from LS to LR.  Local
   rules are applied as part of the initial authorization of the request



Barnes, et al.          Expires January 15, 2009               [Page 10]


Internet-Draft              Location Privacy                   July 2008


   (step 2 in the model above), while sticky rules must be applied after
   the base LO has been provided by the location context (step 3).

   Rules can be enforced in two ways: By denying queries or by
   transforming the LO prepared by the location context before returning
   it.  (In the language of Common Policy, these two actions are
   specified by conditions and transformations.)  For example, the third
   rule above could be enforced either by rejecting requests that
   require geodetic location or by transforming the returned LO to
   remove non-geodetic location.  These two types of enforcement are
   equivalent, in the sense that a transformation can remove all
   unauthorized parts of the LO; if the whole LO is removed, then the
   request is effectively denied.

   Rules are communicated from an RM to an LS (or, for sticky rules,
   from LG to LS) in a rules language that defines a syntax and
   semantics for describing specific rules.  For example, the Common
   Policy rules language [RFC4745] describes a broad framework for rule
   specifications, and Geopriv policy defines a language for location-
   specific rules.

   In order to minimize the probability that rules will lead to
   unintentionally allowed access, a rule syntax must follow a default-
   deny pattern: A rule set with no rules denies access to all requests,
   and the rules in the rule set grant specific accesses.  This is the
   pattern followed by the example rules above, and by the common policy
   framework.

3.1.3.  Location contexts

   The location context within an authorization context tells the LS how
   it should construct the base location object, which will be
   transformed by privacy rules before being returned.  For example, the
   location context might specify that the base LO is a single fixed LO
   for all time (a "snapshot" context), or it may specify that the
   location of the Target should be determined anew for every request,
   using a specific positioning method (a "tracking" context).

   Since the transformations applied to the returned LO by the privacy
   rules can only remove information from the LO (they do not add new
   location information), the location context sets the maximum amount
   of information available to LRs.  If the location context returns a
   snapshot, then an LR cannot access location for another time even if
   it would be allowed by policy.  Thus, when specifying location
   contexts, RMs should give them the minimum scope that is required by
   the application.





Barnes, et al.          Expires January 15, 2009               [Page 11]


Internet-Draft              Location Privacy                   July 2008


3.2.  Deployment scenarios

   In this section, we illustrate how several common location
   distribution scenarios map onto the Geopriv model for policy-based
   control of location information.

3.2.1.  Location dereference server

   A location dereference server is a Location Server at the center of
   the "location by reference" model for location distribution: Rather
   than distributing location objects directly, entities that want to
   communicate location information distribute "references" to location
   objects.  (In the model above, references are identifiers for
   authorization contexts.)  In order to obtain a location object, an LR
   sends a request to the proper LS that includes the reference, and the
   LS returns location according to the corresponding authorization
   context.

   A location deference server receives location objects from a Location
   Generator; in some situations, this LG is the Target of the LOs
   provided, in others, the LG is a generic, automated positioning
   function.  The location context within an authorization context will
   specify the source of location for the context.

   Authorization contexts (privacy rules in particular) are provisioned
   on the LS by authorized Rule Makers, either via an automated
   provisioning protocol (e.g.  XCAP) or via an out-of-band provisioning
   mechanism (e.g. a web interface or a contractual arrangement with the
   target).  These privacy rules may specify a policy allowing public
   identifiers, requiring private identifiers, or some combination of
   the two.

   The scenario in which a dereference server is deployed will influence
   what types of rules it can practically apply.  For instance, if
   references are to be distributed widely, so that the LS will not be
   able to authenticate the identities of LRs, then the LS will not be
   able to apply rules based on the identity of the LR.

3.2.2.  Location-enhanced presence server

   A location-enhanced presence server is a special case of a location
   dereference server in which the dereference protocol is SIP Presence.
   Authorization contexts are created when the Target (the presentity)
   provides rules to the presence server: The identifier for the context
   is the presence URI of the presentity, the rules are those provided,
   and the location context specifies that the base LO is the most
   recent one received in a PUBLISH request.




Barnes, et al.          Expires January 15, 2009               [Page 12]


Internet-Draft              Location Privacy                   July 2008


   In contrast to the general location-by-reference scenario, Location
   Recipients served by a presence server generally possess credentials
   for authenticating themselves to the presence server.  Therefore,
   policies that rely heavily on identity-based access controls and the
   use of public identifiers are generally well-suited to the presence
   environment.

3.2.3.  "On-behalf-of" server

   An "On Behalf Of" (OBO) server is a special case of a location
   dereference server where the reference identifiers are public.  OBO
   is a mechanism for LRs to obtain location information by reference,
   without requiring the reference to be distributed to the LR.  For
   this reason, OBO servers are often used to support legacy target
   devices that lack location capabilities.  And since devices that are
   not location-aware are unlikely to support automated rules processes,
   rule provisioning for an OBO server is generally done in a non-
   automated fashion (such as a contractual arrangement with the target,
   or a web interfaces), though this does not preclude the use of an
   automated mechanism.

   In the OBO scenario, the use of identity-based rules is particularly
   important, since the identifiers used purposely do not constrain
   access.  In order to ensure that location is only provided to
   authorized entities, an OBO server must authenticate all LRs that
   submit requests, and authorize these requestors according to policy
   provided by the Target (through an automated or out-of-band
   mechanism).

3.2.4.  Location configuration

   A Location Information Server (LIS) is an entity that provides a
   location configuration service: It provides endpoints with access to
   their own location, often as a function of the local network to which
   the endpoint is attached.  A LIS can provide access to location in
   two ways: By value, providing LOs directly, and by reference,
   providing identifiers (commonly URIs).

   When a LIS distributes location by value, the location configuration
   scenario is a reduced version of the general model of Figure 1.  The
   Location Server is the same as the Location Generator and the Rule
   Maker, and the Location Recipient is always the Target.  In this
   case, there is a logical authorization context for each endpoint: The
   identifier is an identifier for the client (e.g., an IP address), the
   rules specify that only the client is authorized (though the LS can
   make additional constraints), and the location context provides the
   location of the client.  In practice, an LIS can implement this using
   a single rule that simply provides each requestor with its own



Barnes, et al.          Expires January 15, 2009               [Page 13]


Internet-Draft              Location Privacy                   July 2008


   location.

   Note that since the LIS only provides location to the target (the
   primary rule-maker), it does not require a rules provisioning
   interface.  Indeed, a common use-case if for the target, after
   receiving the location object from the LIS, to modify the location
   object to add additional privacy rules prior to publishing the object
   to a subsequent location server.

   When a LIS distributes location by reference, it is not acting as a
   Geopriv principal, since it is not distributing a location object.
   Rather, it is acting as part of the dissemination channel that
   distributes a context identifier to authorized LRs.  Such a LIS acts
   on behalf of a location dereference server by provides references to
   the target's location.

   In the some location-by-reference scenarios, the LIS is unable accept
   rules from the Target.  In these cases, the LIS must use only private
   identifiers as references, and must these provide these references
   only to the target himself.  (In this case, the location-by-reference
   LIS has identical privacy properties to the location-by-value LIS).
   When the LIS is able to accept privacy rules from the target (either
   via on automated provisioning protocol, or via an out-of-band
   mechanism), it may provide private identifiers to parties as
   specified by the target's privacy policy, and additionally my provide
   public identifiers if allowed by the privacy policy (and supported by
   the associated dereference server).


4.  Location privacy in store-and-forward networks

   [To be completed: This section will incorporate the key ideas from
   draft-peterson-geopriv-regransmission]


5.  End-to-End Assurances about Location Content and Access

   The life-cycle of a location object often consists of a series of
   location transmissions in which the location recipient in given
   transmission acts as a location server in the following transmission
   (see Figure 3).  For example, location might initially be published
   to a location configuration server which then transmits the location
   to the target (who acts as the location recipient in this
   transmission).  The target may then act as a location server and
   convey this location to a service provider (who acts as location
   recipient in this transmission) to facilitate some location-based
   service.




Barnes, et al.          Expires January 15, 2009               [Page 14]


Internet-Draft              Location Privacy                   July 2008


   (Note that although Figure 3 depicts a single "path", a single
   location server may transmit location to multiple location recipients
   over time; groups these paths together forms a logical distribution
   tree, with the location generator as the root node.)

   +----+    +----+    +----+----+    +----+----+    +----+
   | LG |--->| LS |--->| LR | LS |--->| LR | LS |--->| LR |
   +----+    +----+    +----+----+    +----+----+    +----+
              |             |              |
             +----+        +----+         +----+
             | RM |        | RM |         | RM |
             +----+      . +----+         +----+
   The end-to-end life-cycle of a location object

                Figure 3: End-to-End Location Distribution

   This end-to-end model for location distribution gives rise to
   additional security concerns.  For example, in a scenario where some
   intermediate location servers are untrusted, a location recipient may
   desire additional assurances that the LO was generated by a trusted
   LG, and not modified by these untrusted entities.  In this section,
   we first consider threats and possible attacks against a location
   object throughout its entire life cycle.  We then describe the
   assurances that various parties require to mitigate these threats.
   Finally, we discuss possible mechanisms that protocols or location
   object formats should make available to provide such assurances.

5.1.  Threats to Location Objects

   The major threats to the end-to-end security of location objects can
   be grouped into two categories: First, threats against the integrity
   and authenticity of location objects can expose entities that rely on
   location objects to many types of fraud.  Second, threats against the
   confidentiality of location objects can reduce the ability of
   location servers to control access to location.

5.1.1.  Threats to Location Integrity and Authenticity

   A location object contains four essential types of information:
   Identifiers for the described target, location information, time-
   stamps, and rules.  By grouping values of these various types
   together within a single structure, a location object encodes a set
   of bindings among them.  That is, the location object asserts that
   the identified target was present at the given location at the given
   time; and that the given rules express the target's desired policy,
   at the given time, for the distribution of his location.  Below, we
   provide a set of attacks that a malicious party (e.g. an intermediate
   LS, an eavesdropper on the path between LS and LR, or the target



Barnes, et al.          Expires January 15, 2009               [Page 15]


Internet-Draft              Location Privacy                   July 2008


   himself) might conduct to falsify one or more of the bindings
   asserted by the location object.

   Note that in all cases the target identity provided in a location
   object should be based on an authentication between the target and
   the location generator (e.g. an explicit authentication based on a
   shared secret, or an implicit authentication based on the ability to
   receive a message).  Therefore, the identity binding in a received
   location object is only as strong as the authentication between the
   target and the location generator (that is, the location object can
   only attest to the fact that someone at the given location is capable
   of authenticating as the given identity).  It is vital to the
   authenticity of location information that this authentication be as
   strong as is feasible in any deployment scenario.  However,
   mechanisms within a Geopriv location object or protocol can provide
   no protection from attacks against this authentication mechanism and
   thus we do not explicitly consider such attacks.

   Place Shifting  Falsifying the location in an otherwise valid
      location object.  For example, Alice pretends to that she is
      currently in a location that she has never previously visited.

   Time Shifting  Falsifying the time-stamp in an otherwise valid
      location object.  For example, Alice pretends that she is
      currently in a location that she has not visited since last year.

   Location Theft  Falsifying the identity in an otherwise valid
      location object.  For example, a malicious intermediary sees a
      valid location object for Alice and produces a location object
      asserting that Bob is the given location at the given time.

   Location-Identity Theft  An attacker replays a stale location object
      as though it were current.  For example, a malicious intermediary
      sees a valid location object for Alice and replays it later to
      make it seem that Alice has not moved.

   Location Swapping  Two malicious targets conspire to produce two
      location objects asserting that each target is at the other's
      location.  For example, Alice pretends that she is at Bob's
      location and Bob pretends that he is at Alice's location.  (Note
      that this attack cannot be prevented if the two attackers are
      willing to exchange authentication credentials.  Because the
      identity assertions in a location object are only as strong as the
      target authentication, the goal of Geopriv protocols is to ensure
      that this attack is not possible unless both Alice and Bob can
      successfully authenticate as the other.)





Barnes, et al.          Expires January 15, 2009               [Page 16]


Internet-Draft              Location Privacy                   July 2008


5.1.2.  Threats to Location Privacy

   In the Geopriv model, the privacy of location information is
   protected by the application of privacy rules specified by authorized
   rule makers, and by confidentiality protection en route.  (For more
   information on privacy rule enforcement, see Section 3).)  Below, we
   provide a set of attacks that a malicious party might conduct to
   allow distribution of a location object to unauthorized parties.

   Eavesdropping  An unauthorized party observes the location object in
      transit.  For example, a device on the path between a trusted LS
      and an authorized LR observes a location object sent in the clear.

   Rule Tampering  A malicious party modifies a target's privacy rules
      and thus causes a trusted LS to unknowingly distribute the
      location object to unauthorized parties.  For example, a device on
      the path between an LG and a trusted LS deletes the privacy rules
      contained in a location object and replaces them with a new set of
      rules authorizing all parties to receive the location object.

   Sever Impersonation  A malicious party impersonates a trusted
      location server and then knowingly disregards the privacy rules.
      For example, a man-in-the-middle between the LG and the trusted LS
      pretends to be the trusted LS, and then proceeds to distribute the
      location object to unauthorized entities.

5.2.  Required Assurances

   We now describe the assurances required by each party involved in
   location distribution in order to mitigate the attacks described in
   the previous two sections:

   Rule Maker  The rule maker is responsible for distributing the
      target's privacy rules to the location servers.  The primary
      assurance required by the Rule Maker is thus that the binding
      between the target's privacy rules and the target's identity is
      correctly conveyed to each location server that handles the
      location object.  Ensuring the integrity of the privacy rules
      distributed to the location servers prevents rule-tampering
      attacks.  (Note that in many circumstances, the privacy policy of
      the target may itself be sensitive information, in these cases the
      Rule Maker also requires the assurance that the binding between
      the target's identity and the target's privacy rules are not
      deducible by anyone other than an authorized location server).







Barnes, et al.          Expires January 15, 2009               [Page 17]


Internet-Draft              Location Privacy                   July 2008


   Location Server  The Location Server is responsible for enforcing the
      target's privacy policy.  The first assurance required by the
      location server is that the binding between the target's privacy
      rules and the target's identity is authentic.  Authenticating the
      rule-maker who created the privacy rules prevents rule-tampering
      attacks.  The second assurance required by the location server is
      that the binding between the target's identity and the target's
      location are not deducible by any entity except as allowed the
      target's privacy policy.  Ensuring the confidentiality of these
      bindings prevents eavesdropping attacks.  (Note that ensuring the
      confidentiality of the location object also helps to mitigate
      location-theft and location-identity-theft attacks, since it makes
      it more difficult for an attacker to obtain a valid location
      object to replay.)

   Location Recipient  The Location Recipient is the end consumer of the
      location object.  The location recipient thus requires assurances
      about the authenticity of the bindings between the target's
      location, the target's identity and the time.  Ensuring the
      authenticity of these bindings prevents place-shifting, time-
      shifting, location-theft, and location-identity-theft attacks; and
      mitigates location-swapping attacks to the greatest possible
      extent.

   Location Generator  The Location Generator shares responsibility for
      ensuring that the target's privacy policy is enforced.  The
      primary assurance required by the Location Generator is that the
      Location Server to which the Location Object is initially
      published is one that is trusted to enforce the target's privacy
      policy.  Authenticating the trusted Location Server mitigates the
      risk of server impersonation attacks.  (Additionally, in some
      scenarios, there may be no Location Server which can be trusted to
      sufficiently safe-guard the target's location information, in
      which case the Location Generator may require assurance that
      intermediate location servers are unable to deduce the binding
      between the target's identity and the target's location.)

5.3.  Protocol mechanisms

   Protocols that carry location can provide strong assurances, but only
   for a single segment of the location object's life cycle.  In
   particular, a protocol can provide integrity protection and
   confidentiality for the data exchanged, and mutual authentication of
   the parties involved in the protocol, by using a secure transport
   such as IPsec or TLS.

   Additionally, note that if (1) the protocol provides mutual
   authentication for every segment; and (2) every entity in the



Barnes, et al.          Expires January 15, 2009               [Page 18]


Internet-Draft              Location Privacy                   July 2008


   location distribution exchanges information only with entities with
   whom it has a trust relationship, then entities can transitively
   obtain assurances regarding the origin and ultimate destination of
   the location object.  Of course, direct assurances are always
   preferred over assurances requiring transitive trust, since they
   require fewer assumptions.

   Using protocol mechanisms alone, the entities can receive assurances
   only about a single hop in the distribution chain.  For example,
   suppose that an LR retrieves location from an LS over an integrity-
   and confidentiality-protected channel.  The LR knows that the
   transmitted LO has not been modified or observed en route.  However,
   the assurances provided by the protocol do not guarantee that the
   transmitted LO was not corrupted before it was sent (e.g., by a
   previous LS).  Likewise, the LR can verify that the LO was
   transmitted by the LS, but cannot verify the origin of the LO if it
   is different from the LS.

   Security mechanisms in protocols are thus unable to provide direct
   assurances over multiple transmissions of an LO.  However, it should
   be noted that the transmission of location "by reference" can be used
   to effectively turn multi-hop paths into single-hop paths.  If the
   multiple transmissions of an LO are replaced by multiple
   transmissions of an identifier (a multi-hop dissemination channel),
   then the LO need only traverse a single hop, namely the dereference
   transaction between the LR and the dereference server.

5.4.  Mechanisms within the Location Object Format

   Assurances as to the integrity and confidentiality of a location
   object can be provided directly through the location object format.
   Additionally, the location object format can be used to authenticate
   the originator of a location object.  In particular, integrity and
   origin authentication can be assured by signing a location object
   (e.g., using S/MIME or XMLSIG), and confidentiality can be assured by
   encrypting the location object using a public encryption key
   belonging to the intended recipient (e.g. using S/MIME).  Recipients
   of location objects secured in this fashion can obtain assurance as
   to the integrity and authenticity of the location object even after
   it has been handled by untrusted intermediaries.  Similarly, a
   Location Server (or Location Generator) that guarantees
   confidentiality in this fashion can be assured that the location
   object is protected from unauthorized viewing even in the presence of
   untrusted intermediaries.

   Although such direct, end-to-end assurances are desirable, and these
   mechanisms should be used whenever possible, there are many
   deployment scenarios where directly securing a location object is



Barnes, et al.          Expires January 15, 2009               [Page 19]


Internet-Draft              Location Privacy                   July 2008


   impractical.  In particular, in some deployment scenarios a direct
   trust relationship may not exist between the creator of the location
   object and the ultimate recipient.  Additionally, in a scenario where
   many recipients are authorized to receive a given location object,
   the creator of the location object cannot guarantee end-to-end
   confidentiality without knowing precisely which recipient will
   receive the location object.

   An additional challenge in providing end-to-end authenticity
   guarantees by signing the location object is that in many deployments
   different entities may assert different bindings within the same
   location object.  Consider, for example, a scenario where a Location
   Generator produces a location object that asserts a binding between a
   time, a location, and a pseudonym for the target.  Additionally, a
   Rule Maker creates a binding between a set of privacy rules and a
   public target identity.  A presence server receives the rules binding
   from Rule Maker and the location object from the Location Generator.
   The presence server then generates a new location object binding
   together the time, the location, the public target identity and the
   privacy rules.  In such a scenario there is no single entity who can
   directly assert the validity of the entire location object.  In such
   a case, a mechanism is needed within the location object format that
   allows multiple originators to jointly assert various components of
   the location object bindings.


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





Barnes, et al.          Expires January 15, 2009               [Page 20]


Internet-Draft              Location Privacy                   July 2008


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-06 (work in
              progress), July 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-08 (work in
              progress), July 2008.

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

   [I-D.ietf-geopriv-lbyr-requirements]
              Marshall, R., "Requirements for a Location-by-Reference
              Mechanism", draft-ietf-geopriv-lbyr-requirements-03 (work
              in progress), July 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 (work in progress),
              June 2008.

   [I-D.ietf-sip-gruu]
              Rosenberg, J., "Obtaining and Using Globally Routable User
              Agent (UA) URIs (GRUU) in the  Session Initiation Protocol
              (SIP)", draft-ietf-sip-gruu-15 (work in progress),
              October 2007.

   [I-D.winterbottom-geopriv-held-context]
              Winterbottom, J., Tschofenig, H., and M. Thomson, "HELD
              Protocol Context Management Extensions",
              draft-winterbottom-geopriv-held-context-02 (work in
              progress), February 2008.



Barnes, et al.          Expires January 15, 2009               [Page 21]


Internet-Draft              Location Privacy                   July 2008


   [RFC3265]  Roach, A., "Session Initiation Protocol (SIP)-Specific
              Event Notification", RFC 3265, June 2002.

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


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








Barnes, et al.          Expires January 15, 2009               [Page 22]


Internet-Draft              Location Privacy                   July 2008


   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
   Linnoitustie 6
   Espoo  02600
   Finland

   Phone: +358 (50) 4871445
   Email: Hannes.Tschofenig@gmx.net
   URI:   http://www.tschofenig.priv.at


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

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




















Barnes, et al.          Expires January 15, 2009               [Page 23]


Internet-Draft              Location Privacy                   July 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.











Barnes, et al.          Expires January 15, 2009               [Page 24]