Network Working Group R. Barnes
Internet-Draft M. Lepinski
Intended status: Standards Track BBN Technologies
Expires: October 3, 2007 H. Tschofenig
Nokia Siemens Networks
H. Schulzrinne
Columbia University
April 2007
Threats to GEOPRIV Location Objects
draft-barnes-geopriv-lo-sec-00
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 October 3, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
Presence-based location objects used by Internet protocols encode
bindings of location information to identities of a presentity, with
associated rules for the handling and usage of the location object.
Parties that make use of location objects rely on the accuracy of
Barnes, et al. Expires October 3, 2007 [Page 1]
Internet-Draft LO Threats April 2007
these bindings to ensure their proper function, and the entities that
they describe rely on the proper application of the included rules to
ensure their privacy. This document describes the space of attacks
against location objects.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Integrity and Authenticity Threats . . . . . . . . . . . . . . 5
2.1. Location and Time . . . . . . . . . . . . . . . . . . . . 5
2.2. Location and Identity . . . . . . . . . . . . . . . . . . 6
2.2.1. Spoofing . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.2. Theft and Swapping . . . . . . . . . . . . . . . . . . 6
2.2.3. Levels of Identity . . . . . . . . . . . . . . . . . . 7
2.3. Tuples and Rules . . . . . . . . . . . . . . . . . . . . . 7
3. Confidentiality and Privacy Threats . . . . . . . . . . . . . 8
3.1. Eavesdropping . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Anonymity . . . . . . . . . . . . . . . . . . . . . . . . 8
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Normative References . . . . . . . . . . . . . . . . . . . 9
6.2. Informative References . . . . . . . . . . . . . . . . . . 9
Appendix A. An Appendix . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 11
Barnes, et al. Expires October 3, 2007 [Page 2]
Internet-Draft LO Threats April 2007
1. Introduction
RFC 4119 defines the PIDF-LO location object format, which extends
the Presence Information Document Format [ref:RFC3863] to carry
location information and rules regarding transmission and processing
of that location information. A PIDF-LO document contains four
essential types of information: Identifiers for the described
presentity, location information, time-stamps, and rules. By
grouping values of these various types together within an XML
structure, a PIDF-LO document encodes a set of bindings among them.
For instance, consider the following PIDF-LO document (copied from
RFC 4119):
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="urn:opengis:specification:gml:schema-xsd:feature:v3.0"
entity="pres:meaningless-F32AC8D@example.com">
<tuple id="sg89ae">
<status>
<gp:geopriv>
<gp:location-info>
<gml:location>
<gml:Point gml:id="point1" srsName="epsg:4326">
<gml:coordinates>37:46:30N 122:25:10W</gml:coordinates>
</gml:Point>
</gml:location>
</gp:location-info>
<gp:usage-rules>
<gp:retransmission-allowed>no</gp:retransmission-allowed>
<gp:retention-expiry>2003-06-23T04:57:29Z</gp:retention-expiry>
</gp:usage-rules>
</gp:geopriv>
</status>
<contact>sip:geotarget@example.com</contact>
<timestamp>2003-06-22T20:57:29Z</timestamp>
</tuple>
</presence>
Figure 1: A sample PIDF-LO Location Object
This document asserts that the presentity identified as
"sip:geotarget@example.com" was located at the point described in the
<gp:location-info> element at the time indicated in the <timestamp>
element; the content of this encoded statement is subject to the
usage rules described in the <gp:usage-rules> element. For purposes
of discussion, we will consider this as a pair of bindings: First,
identity, location, and time are tied to each other (the "sighting
binding"), and second, these are bound to a set of rules (the "rule
Barnes, et al. Expires October 3, 2007 [Page 3]
Internet-Draft LO Threats April 2007
binding").
Different entities require different assurances about these bindings.
Location Recipients (LRs, as defined in [ref:RFC3693]) are primarily
concerned with the integrity of the sighting binding (or a subset of
it). In order to ensure that actions taken on the bases of the LO
are correct, the LR must be assured that the information has not been
altered in transit. On the other hand, the entity whose position is
described in the LO (a Target per RFC 3693), may be more concerned
that the usage rules cannot be removed or modified, so that he can
rely on the fact that his privacy rules have been faithfully
communicated.
Different bindings are typically asserted by different entities as
well. The entities best equipped to provide sighting bindings, for
instance, will often be Location Servers within an access network,
while the entity that will provide the rule binding (in RFC 3693, the
Rule Maker) will most commonly be the target of the LO. These
distinctions are important when one allows the possibility that
bindings will be verifiably attested via digital signatures, possibly
created with two different keys.
In order to ensure that the LO provides the necessary assurances to
relying parties (e.g., Targets and Location Recipients), one must
consider the entire "life-cycle" of the LO as it is constructed,
forwarded, and finally received. In general, this life-cycle
consists of three high-level parts: The creation of sighting
bindings, the binding of rules to the LO, and the conveyance of the
LO from one party to another. As a particular LO is constructed,
these steps may be interspersed and repeated; for example, the
following could be the life-cycle of an LO:
1. (Sighting) A sighting function creates a sighting binding that
ties a location to the target's MAC address
2. (Conveyance) The sighting function conveys the initial LO to the
target
3. (Rule binding) The target adds a set of usage rules to the LO
4. (Conveyance) The target conveys the LO to a Location Server
5. (Sighting) The Location Server creates a second sighting binding,
this time including a "sip:" URI to identify the Target
6. (Conveyance) The Location Server delivers the LO to a Location
Recipient
Barnes, et al. Expires October 3, 2007 [Page 4]
Internet-Draft LO Threats April 2007
Security mechanisms can be added at any of these points. Bindings
can be verifiably asserted via digital signatures. Conveyance
protocols can provide confidentiality and integrity to LOs. An
important point to keep in mind, however, is that relying on a
mechanism that adds security at a given point on this chain
implicitly assumes that everything before that point is trusted. For
example, providing TLS on the final conveyance step only provides an
overall guarantee of confidentiality if one assumes that all relays
that the LO has traversed before the last one are trusted to have
properly handled the LO.
A note on trust: Security is fundamentally based on trust
relationships. The goal of this document is to state requirements on
mechanisms for USING trust relationships to give assurances about
LOs. Nothing in this document requires a given trust model to be
implemented; however, certain assurances have de facto trust
requirements. For instance, if the user of a location object
requires assurance that the location information provided has not
been tampered with, then he must have a trust relationship with the
entity that initially provided the location information, either
directly or through an intermediary (such as a Certificate Authority
in a PKI or simply another entity authorized to vouch for location).
This document is presents an analysis of threats GEOPRIV Location
Objects, much as RFC 3693 and RFC 3694 do. However, this document
differs from prior documents in significant ways. This document
presents a more thorough and detailed security analysis than RFC
3693; in particular, it specifies which attacks involve which data
elements and bindings within an LO, so that security features
provided to the LO can be matched against threats. The threat model
we describe focuses on how location objects can be misused or
corrupted across its entire life-cycle, a more general type of threat
than is addressed in RFC 3694, which focuses on a single hop in a
putative store-and-forward system.
2. Integrity and Authenticity Threats
Parties that use location information need assurances that the
bindings encoded in an LO are valid. In this section we discuss
threats related to falsification of various bindings asserted by the
LO and the potential impact of these threats.
2.1. Location and Time
This threat, often referred to as time-shifting, occurs when the
adversary pretends to currently be a location that she previously
occupied. For example, Alice has possession of a valid location
Barnes, et al. Expires October 3, 2007 [Page 5]
Internet-Draft LO Threats April 2007
object asserting that she was in Chicago, IL on March 22, 2007, and
she uses this to construct a valid location object asserting that
Alice is in Chicago, IL on July 22, 2007, when in truth Trudy is in
San Francisco, CA.
Note that certain applications will not regard time-shifting as a
threat, as old location is often good enough. However, an entity
that receives a location object should be able to determine how old
the object is, and make its own determination as to whether the
information is fresh enough to be of use.
2.2. Location and Identity
This threat has two parts: binding a different location to a valid
identity, often referred to as location spoofing, and binding a
different identity to a valid location, often referred to as location
theft or location swapping (depending on whether the owner of the
original identity participates in the attack). Additionally, some
applications have multiple layers of identifiers, which need to be
bound together in order to ensure the overall validity of the LO. In
such cases, falsifying the binding between lower-layer and higher-
layer identities introduces another variation of the location
swapping threat.
2.2.1. Spoofing
This threat occurs when the adversary pretends to be in an arbitrary
location of her choosing. For example, Alice has possession of a
valid location object asserting that she is currently in San
Francisco, CA, and she uses this to construct a valid location object
asserting that Alice is in Miami, FL.
2.2.2. Theft and Swapping
This threat has two parts. In location theft, the adversary observes
a location object for an honest user, and replays that location as
her own. For example, Alice operates a SIP proxy in Chicago, IL and
eavesdrops on a SIP message which contains a location object
asserting that Bob is in Miami, FL. Alice then uses this to
construct a valid location object asserting that she is in Miami, FL.
In location swapping, a pair of adversaries conspire and each pretend
to be at the other's location. For example, Alice is in Chicago, IL
and receives a message from Trudy, her co-conspirator, which (among
other things) includes a location object asserting that Trudy is in
Miami, FL. Alice then uses this information from Trudy to construct
a valid location object asserting that she is in Miami, FL.
Barnes, et al. Expires October 3, 2007 [Page 6]
Internet-Draft LO Threats April 2007
Note that no protocol can prevent location swapping. Since all
identifiers and credentials are digital, if a pair of adversaries are
willing to share everything (even secret passwords and keys), then
Alice can always masquerade as Trudy and vice versa. The best one
can hope for is to maximize the difficultly of location swapping and
require that the adversaries must exchange secrets to execute a
location-swapping attack.
2.2.3. Levels of Identity
In an application where entities have multiple layers of identifiers,
this threat presents an additional variation on location swapping.
Two adversaries obtain location objects that bind locations to their
low-layer identifiers, and then bind these lower-layer identifiers to
the other's higher-layer identifier. For example, Trudy obtains a
location object that binds her location to her physical-layer MAC
address. She then sends this object (perhaps along with some
additional information) to Alice. Alice then uses this information
to construct a valid location object that binds her SIP AOR to
Trudy's location and MAC address.
As with location swapping, this attack cannot be prevented if Alice
and Trudy are willing to exchange all of their secret information.
However, when seeking to maximize the difficulty of location
swapping, one must also consider this type of multi-layer swapping
attack. Indeed, this threat is more likely to arise that other forms
of location swapping, since it's rare that the same entity can
authenticate both a low layer identifier (necessary for location
determination) and a higher-layer identifier (e.g., one used for
identification within the conveyance protocol).
2.3. Tuples and Rules
This threat occurs, when the adversary obtains a location object with
a certain set of privacy rules and produces a location object with
the same identity and location, but with a different set of rules.
For example, Alice receives Bob's location object which includes the
rule that the location object cannot be retransmitted. Alice
modifies the object to indicate that retransmission is allowed, and
then transmits the modified object to Eve. Since Eve receives a valid
location object that allows for retransmission, she may in turn send
Bob's location to a variety of other parties.
Thus far, the threats in this section have focused primarily on the
capabilities of malicious location targets. However, in most
systems, it is acceptable for the location target to modify the rules
for her own location object. Therefore, in this threat we are
primarily concerned with the ability of a third party adversary to
Barnes, et al. Expires October 3, 2007 [Page 7]
Internet-Draft LO Threats April 2007
modify the rules in an honest user's location object.
3. Confidentiality and Privacy Threats
Locations and identifiers by themselves are not sensitive
information, but a location object providing a binding between them
is. The rule syntax defined in RFC 4119 and RFC 4745 can be used to
specify the proper handling of such sensitive information. However,
further mechanisms are necessary to make sure that such rules are
followed, and to ensure the confidentiality of the location object as
it is transmitted in accordance with such rules.
3.1. Eavesdropping
Eavesdropping is the threat in which an adversary observes a location
object that she is not authorized to view. There are two variations
of this threat, the first is where the adversary is required the
conveyance protocol to forward the location object, but is not
authorized to learn the bindings in the object. For example, the
adversary runs a SIP proxy (which does not perform location-based
routing) eavesdrops on all location objects passing through the
proxy. The second variation is where the adversary has no legitimate
reason to handle the location object. For example, the adversary has
a wireless receiver and eavesdrops on all location objects that are
transmitted by a nearby wireless access point.
Note that the latter threat is the easier one to mitigate. Indeed,
store-and-forward conveyance protocols can employ hop-by-hop security
mechanisms to prevent the second form of eavesdropping. However,
preventing the first form of eavesdropping requires end-to-end
security mechanism (and thus requires a trust relationship between
the end-points).
3.2. Anonymity
Note that in some settings confidentiality may only be required for
certain bindings within the location object. For example, the rules
associated with a location object might indicate that certain
entities have the right to see the time and the location information,
but not the identity of the location target. Alternatively, an
entity might need to determine that two location objects both
correspond to the same location target, and yet have no need to know
the true identity of the target.
In such examples, there is a threat that an adversary who has the
right to see certain bindings of the location object could violate
the anonymity of the target. Such a threat can be mitigated through
Barnes, et al. Expires October 3, 2007 [Page 8]
Internet-Draft LO Threats April 2007
the use of pseudonyms within the location object in place of the
target's true identity. Such pseudonyms might be a truly random
string, in the case where no one is authorized to learn the target's
true identity, or an encrypted string, in the case where only holders
of a particular cryptographic key are authorized to learn the
target's true identity.
4. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
5. Security Considerations
The focus of this document is the security of location objects. As
such, security concerns are discussed throughout.
6. References
6.1. Normative References
6.2. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3683] Rose, M., "A Practice for Revoking Posting Rights to IETF
mailing lists", BCP 83, RFC 3683, February 2004.
[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.
[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.
Barnes, et al. Expires October 3, 2007 [Page 9]
Internet-Draft LO Threats April 2007
Appendix A. An Appendix
Authors' Addresses
Richard Barnes
BBN Technologies
9861 Broken Land Pkwy, Suite 400
Columbia, MD 21046
US
Phone: +1 410 290 6169
Email: rbarnes@bbn.com
URI: http://www.bbn.com/
Matt Lepinski
BBN Technologies
10 Moulton St.
Cambridge, MA 01238
US
Phone: +1 617 873 5939
Email: mlepinski@bbn.com
URI: http://www.bbn.com/
Hannes Tschofenig
Nokia Siemens Networks
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
Email: Hannes.Tschofenig@nsn.com
URI: http://www.tschofenig.com
Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
US
Phone: +1 212 939 7004
Email: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu
Barnes, et al. Expires October 3, 2007 [Page 10]
Internet-Draft LO Threats April 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Barnes, et al. Expires October 3, 2007 [Page 11]