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

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

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

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

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

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

This Internet-Draft will expire on August 3, 2009.

Copyright Notice

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

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.

Table of Contents

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

1.  Introduction

The basic privacy and security model for location distribution over the Internet are discussed in RFC 3693 and RFC 3694 [RFC3693] (Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, “Geopriv Requirements,” February 2004.)[RFC3694] (Danley, M., Mulligan, D., Morris, J., and J. Peterson, “Threat Analysis of the Geopriv Protocol,” February 2004.). 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 (Privacy rule enforcement), Section 4 (Location privacy in store-and-forward networks), and Section 5 (End-to-End Assurances about Location Content and Access), 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 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.

(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

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] (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.), 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] (Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, “HTTP Enabled Location Delivery (HELD),” August 2009.), 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).

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.

(preamble)

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

(postamble)

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.

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-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:

• 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
• Private identifiers:
  • Temporary GRUU [I‑D.ietf‑sip‑gruu] (Rosenberg, J., “Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP),” October 2007.): <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:

• [request] Grant only requests from the subnet 19.0.2.0/24
• [request] Grant only requests made by <sip:alice@example.com> and <sip:bob@example.net>
• [LO] Grant access only to geodetic location
• [LO] Grant access only to location accurate to within 100 meters.
• [context] Grant access only to the first three requests for this authorization context
• [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 (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] (Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk, J., and J. Rosenberg, “Common Policy: A Document Format for Expressing Privacy Preferences,” February 2007.) 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.

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.

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 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 (End-to-End Location Distribution)). 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.

(Note that although Figure 3 (End-to-End Location Distribution) 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

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

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 (Privacy rule enforcement)).) 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).

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 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 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] (Tschofenig, H. and H. Schulzrinne, “GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and Requirements,” July 2009.). 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

9.2. Informative References

Authors' Addresses