One document matched: draft-barnes-geopriv-lo-sec-04.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
]>
<?xml-stylesheet type='text/xsl' href='rfc2629toFO.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-barnes-geopriv-lo-sec-04" ipr="trust200811"
updates="3693, 3694">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<title abbrev="Location Privacy">Additional Location Privacy
Considerations</title>
<author fullname="Richard Barnes" initials="R." surname="Barnes">
<organization>BBN Technologies</organization>
<address>
<postal>
<street>9861 Broken Land Pkwy, Suite 400</street>
<city>Columbia</city>
<region>MD</region>
<code>21046</code>
<country>USA</country>
</postal>
<phone>+1 410 290 6169</phone>
<email>rbarnes@bbn.com</email>
</address>
</author>
<author fullname="Matt Lepinski" initials="M." surname="Lepinski">
<organization>BBN Technologies</organization>
<address>
<postal>
<street>10 Moulton St</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>USA</country>
</postal>
<phone>+1 617 873 5939</phone>
<email>mlepinski@bbn.com</email>
</address>
</author>
<author fullname="Hannes Tschofenig" initials="H." surname="Tschofenig">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>Linnoitustie 6</street>
<city>Espoo</city>
<code>02600</code>
<country>Finland</country>
</postal>
<phone>+358 (50) 4871445</phone>
<email>Hannes.Tschofenig@gmx.net</email>
<uri>http://www.tschofenig.priv.at</uri>
</address>
</author>
<author fullname="Henning Schulzrinne" initials="H." surname="Schulzrinne">
<organization>Columbia University</organization>
<address>
<postal>
<street>Department of Computer Science</street>
<street>450 Computer Science Building</street>
<city>New York</city>
<region>NY</region>
<code>10027</code>
<country>US</country>
</postal>
<phone>+1 212 939 7004</phone>
<email>hgs@cs.columbia.edu</email>
<uri>http://www.cs.columbia.edu</uri>
</address>
</author>
<date year="2009" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Real-time Applications and Infrastructure</area>
<workgroup>Geopriv</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The basic privacy and security model for location distribution over
the Internet are discussed in RFC 3693 and RFC 3694 <xref
target="RFC3693"></xref><xref target="RFC3694"></xref>. 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.</t>
<t>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: <list style="numbers">
<t>How privacy rules are enforced by an LS and the role of
identifiers in this process</t>
<t>How privacy rules should be interpreted in store-and-forward
networks, and</t>
<t>How an LO can be provided security properties end-to-end (between
creation and ultimate use)</t>
</list>These topics are addressed in <xref target="priv-sec"></xref>,
<xref target="sip-sec"></xref>, and <xref target="e2e-sec"></xref>,
respectively.</t>
</section>
<section anchor="term-sec" title="Terminology">
<t>This document uses the following terms defined RFC 3693: Location
Generator (LG), Location Object (LO), Location Recipient (LR), Location
Server (LS), Target, privacy rule.</t>
</section>
<section anchor="priv-sec" title="Privacy rule enforcement">
<t>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.</t>
<t>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.</t>
<section title="Reference model">
<t>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.</t>
<t>The overall privacy-enhanced location distribution process is
illustrated in <xref target="config-fig"></xref> (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.</t>
<figure anchor="config-fig">
<preamble>(preamble)</preamble>
<artwork><![CDATA[
+-------Req-------+
| |
+--Location Server------|-----+ |
| V | |
| +--------+ +--------+ | |
+---------+ | |Context1| |ContextN| | +---------+
|Location | | |========| |========| | |Location |
|Generator|--+ | |Ident. | ... |Ident. |---Resp-->|Recipient|
+---------+ | | |Rules | |Rules | | +---------+
+----->LO Ctxt | |LO Ctxt | |
| +--------+ +--------+ |
| ^ ^ |
+-----|--------------|--------+
| |
+--------+ +--------+
| Rule | | Rule |
| Maker | | Maker |
+--------+ +--------+
]]></artwork>
<postamble>A privacy-preserving location server</postamble>
</figure>
<t>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:<list
style="numbers">
<t>An identifier for the desired location object(s)</t>
<t>A set of parameters that describe acceptable responses</t>
</list>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).</t>
<t>For example, in a SIP SUBSCRIBE request <xref
target="RFC3265"></xref>, 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 <xref
target="I-D.ietf-geopriv-http-location-delivery"></xref>, 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).</t>
<t>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:
<list style="numbers">
<t>An identifier for the context</t>
<t>A set of privacy rules</t>
<t>A location context</t>
</list> 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.</t>
<t>Having been provisioned with a set of authorization contexts, the
LS constructs its response to a location request in three steps: <list
style="numbers">
<t>Retrieve the context with the identifier specified in the
request (if none, reject request).</t>
<t>Match the request against the privacy rules in the
authorization context. If authorized, proceed; otherwise, reject
the request.</t>
<t>Retrieve the base LO from the location context in the
authorization context. Transform according to privacy rules and
request parameters.</t>
</list>These steps are illustrated in <xref
target="ac-fig"></xref>.</t>
<figure anchor="ac-fig">
<preamble>(preamble)</preamble>
<artwork><![CDATA[ +---------+----------+
| Request | Response |
+---------+----------+
| ^
| |
V (1) |
+----------+ |
|Identifier| |
+----------+ |
| |
V (2) |
+--------------------+
| Privacy Rules |
+--------------------+
| ^
V (3) |
+--------------------+
| Location Context |
+--------------------+
]]></artwork>
<postamble>(postamble)</postamble>
</figure>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<section title="Context identifiers">
<t>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:</t>
<t><list style="hanging">
<t hangText="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)</t>
<t hangText="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.</t>
</list>(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.)</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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: <list style="symbols">
<t>Public identifiers:<list style="symbols">
<t>Published SIP AoR:
<sip:asd887f9dfkk76690@example.com></t>
<t>Location URI with a public identifier:
<held://lis.example.com/context/alice;use=lbyr></t>
<t>IP address: 192.0.2.34</t>
<t>MAC address: 00-B0-D0-86-BB-F7</t>
</list></t>
<t>Private identifiers:<list style="symbols">
<t>Temporary GRUU <xref target="I-D.ietf-sip-gruu"></xref>:
<sip:asd887f9dfkk76690@example.com;gr></t>
<t>Location URI with a private identifier:
<held://lis.example.com/context/f5kc85O1djUZK0nx;use=lbyr></t>
<t>Undisclosed SIP AoR: <sip:bob@example.net></t>
</list></t>
</list></t>
<t>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.</t>
</section>
<section title="Rule sets">
<t>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:<list style="symbols">
<t>[request] Grant only requests from the subnet 19.0.2.0/24</t>
<t>[request] Grant only requests made by
<sip:alice@example.com> and
<sip:bob@example.net></t>
<t>[LO] Grant access only to geodetic location</t>
<t>[LO] Grant access only to location accurate to within 100
meters.</t>
<t>[context] Grant access only to the first three requests for
this authorization context</t>
<t>[context] Grant access only to requests for this
authorization context before midnight on December 31, 2008</t>
</list></t>
<t>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).</t>
<t>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.</t>
<t>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 <xref target="RFC4745"></xref> describes a
broad framework for rule specifications, and Geopriv policy defines
a language for location-specific rules.</t>
<t>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.</t>
</section>
<section title="Location contexts">
<t>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).</t>
<t>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.</t>
</section>
</section>
<section title="Deployment scenarios">
<t>In this section, we illustrate how several common location
distribution scenarios map onto the Geopriv model for policy-based
control of location information.</t>
<section title="Location dereference server">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Location-enhanced presence server">
<t>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.</t>
<t>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.</t>
</section>
<section title=""On-behalf-of" server">
<t>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.</t>
<t>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).</t>
</section>
<section title="Location configuration">
<t>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).</t>
<t>When a LIS distributes location by value, the location
configuration scenario is a reduced version of the general model of
<xref target="config-fig"></xref>. 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.</t>
<t>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.</t>
<t>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.</t>
<t>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).</t>
</section>
</section>
</section>
<section anchor="sip-sec"
title="Location privacy in store-and-forward networks">
<t>[To be completed: This section will incorporate the key ideas from
draft-peterson-geopriv-regransmission]</t>
</section>
<section anchor="e2e-sec"
title="End-to-End Assurances about Location Content and Access">
<t>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 <xref target="end-to-end"></xref>). 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.</t>
<t>(Note that although <xref target="end-to-end"></xref> 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.)</t>
<figure anchor="end-to-end" title="End-to-End Location Distribution">
<preamble></preamble>
<artwork><![CDATA[+----+ +----+ +----+----+ +----+----+ +----+
| LG |--->| LS |--->| LR | LS |--->| LR | LS |--->| LR |
+----+ +----+ +----+----+ +----+----+ +----+
| | |
+----+ +----+ +----+
| RM | | RM | | RM |
+----+ . +----+ +----+]]></artwork>
<postamble>The end-to-end life-cycle of a location object</postamble>
</figure>
<t>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.</t>
<section title="Threats to Location Objects">
<t>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.</t>
<section title="Threats to Location Integrity and Authenticity">
<t>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.</t>
<t>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.<list
style="hanging">
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="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.)</t>
</list></t>
</section>
<section title="Threats to Location Privacy">
<t>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 <xref
target="priv-sec"></xref>).) Below, we provide a set of attacks that
a malicious party might conduct to allow distribution of a location
object to unauthorized parties. <list style="hanging">
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="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.</t>
</list></t>
</section>
</section>
<section title="Required Assurances">
<t>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:<list style="hanging">
<t hangText="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).</t>
<t hangText="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.)</t>
<t hangText="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.</t>
<t hangText="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.)</t>
</list></t>
</section>
<section title="Protocol mechanisms">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Mechanisms within the Location Object Format">
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
</section>
<section anchor="Security" title="Security Considerations">
<t>The focus of this document is the security of location objects. As
such, security concerns are discussed throughout.</t>
</section>
<section title="Acknowledgements">
<t>This work was based on the security investigations conducted as part
of the Geopriv Layer-7 Location Configuration Protocol design team,
which produced <xref target="I-D.ietf-geopriv-l7-lcp-ps"></xref>. We
would like to thank all the members of the design team.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document makes no request of IANA.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
</references>
<references title="Informative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-ecrit-framework.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-http-location-delivery.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-policy.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sip-gruu.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-l7-lcp-ps.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-lbyr-requirements.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.winterbottom-geopriv-held-context.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3265.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3693.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3694.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3825.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4119.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4745.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4825.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5025.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4776.xml"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 06:59:27 |