One document matched: draft-barnes-geopriv-lo-sec-03.txt
Differences from draft-barnes-geopriv-lo-sec-02.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-22 09:22:32 |