GEOPRIV WG M. Danley
Internet-Draft D. Mulligan
Expires: April 28, 2003 UC Berkeley
J. Morris
CDT
J. Peterson
NeuStar
October 28, 2002
Threat Analysis of the GEOPRIV Protocol
draft-danley-geopriv-threat-analysis-00
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 April 28, 2003.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This document provides some analysis of threats against the GEOPRIV
protocol architecture. It focuses on protocol threats, threats that
result from the storage of data by entities in the architecture, and
threats posed by the abuse of informaion yielded by geopriv. Some
security properties that meet these threats are enumerated as a
reference for GEOPRIV requirements.
Danley, et al. Expires April 28, 2003 [Page 1]
Internet-Draft Threat Analysis of the GEOPRIV Protocol October 2002
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Habitat of the GEOPRIV Protocol . . . . . . . . . . . . . . 3
3. Motivations of Attackers of GEOPRIV . . . . . . . . . . . . 4
4. Representative Attacks on GEOPRIV . . . . . . . . . . . . . 5
4.1 Protocol Attacks . . . . . . . . . . . . . . . . . . . . . . 5
4.1.1 Eavesdropping and/or Interception . . . . . . . . . . . . . 5
4.1.2 Identity Spoofing . . . . . . . . . . . . . . . . . . . . . 6
4.1.3 Information Gathering . . . . . . . . . . . . . . . . . . . 7
4.1.4 Denial of Service . . . . . . . . . . . . . . . . . . . . . 8
4.2 Host Attacks . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2.1 Data Stored at Servers . . . . . . . . . . . . . . . . . . . 9
4.2.2 Data Stored in Devices . . . . . . . . . . . . . . . . . . . 9
4.2.3 Data Stored with the Ultimate Location Recipient . . . . . . 10
4.2.4 Information Contained in Policies . . . . . . . . . . . . . 10
4.3 Usage Attacks . . . . . . . . . . . . . . . . . . . . . . . 11
4.3.1 Threats Posed by Overcollection . . . . . . . . . . . . . . 11
5. Countermeasures for Usage Violations . . . . . . . . . . . . 11
5.1 Fair Information Practices . . . . . . . . . . . . . . . . . 11
6. Security Properties of the GEOPRIV Protocol . . . . . . . . 13
6.1 Policies as Counter-Measures . . . . . . . . . . . . . . . . 13
6.1.1 Rule Maker Should Define Policies . . . . . . . . . . . . . 13
6.1.2 GEOPRIV Should Have Default Policies . . . . . . . . . . . . 13
6.1.3 Location Recipient Should Not Be Aware of All Policies . . . 14
6.1.4 Certain Policies Should Travel With the LO . . . . . . . . . 14
6.2 Protection of Identities . . . . . . . . . . . . . . . . . . 14
6.2.1 Short-Lived Identifiers May Protect Target's Identity . . . 15
6.2.2 Unlinked Pseudonyms May Protect the Location Recipients'
Identity . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.3 Security During Transmission of Data . . . . . . . . . . . . 15
6.3.1 Policies May Disallow a Certain Frequency of Requests . . . 15
6.3.2 Mutual End-Point Authentication . . . . . . . . . . . . . . 15
6.3.3 Data Object Integrity & Confidentiality . . . . . . . . . . 16
6.3.4 Replay Protection . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16
Informative References . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16
Full Copyright Statement . . . . . . . . . . . . . . . . . . 18
Danley, et al. Expires April 28, 2003 [Page 2]
Internet-Draft Threat Analysis of the GEOPRIV Protocol October 2002
1. Introduction
The proliferation of location-based services that integrate tracking
and navigation capabilities gives rise to significant privacy and
security concerns. Such services allow users to identify their own
location as well as determine the location of others. In certain
peer-to-peer exchanges, device identification takes place
automatically within a defined location perimeter, informing peer
devices of a given user's identity and availability. Additionally,
records of location exchanges can reveal significant information
about the habits, whereabouts, and associations of individual users.
The GEOPRIV requirements allow the Location Object (LO) to support a
wide variety of uses of Location Information (LI); the GEOPRIV object
itself is intended to be technology-neutral, allowing a wide variety
of devices to provide LI in the form of LO. GEOPRIV also requires
that many classes of Ultimate Location Recipients (ULRs) be capable
of requesting LI from a Target (in some cases directly and in others
through a Location Server). The GEOPRIV requirements account for
circumstances in which the Target has a contractual relationship with
the entities that transmit and receive LI and those in which no
contract exists. Requiring the GEOPRIV object to support any
technology, Target-ULR relationship, or underlying legal framework
governing LI, complicates the protection of privacy and the security
of LI.
This document analyzes threats to LI in transmission and storage.
The actions possible due to the compromises of LI through these
threats vary depending on the circumstances. A server selling
location information to potential marketers poses a distinct (and
lower) risk from an outside individual intercepting a Target's
present location to commit a physical attack. It is important that
these threats are considered as we work towards defining the LO.
Some of the threats discussed in this document may be outside of the
scope of the GEOPRIV charter, e.g., threats arising from failure to
meet contractual obligations. Nevertheless, a comprehensive
discussion of threats is necessary to identify desirable security
properties and counter-measures that will improve the security of the
LO, and thereby better protect LI.
2. Habitat of the GEOPRIV Protocol
The GEOPRIV architecture will be deployed in the open Internet - in a
security environment in which potential attackers can inspect packets
on the wire, spoof Internet addresses, and launch large-scale denial-
of-service attacks. In some architectures, portions of GEOPRIV
traffic (especially traffic between the Location Sighter and an
Danley, et al. Expires April 28, 2003 [Page 3]
Internet-Draft Threat Analysis of the GEOPRIV Protocol October 2002
initial Location Server) may occur over managed networks that do not
interface with the public Internet.
The protocol itself assumes interaction between a number of logical
roles, many of which will commonly be implemented in distributed
network devices (for a full list of GEOPRIV roles and entities, see
[1]). The endpoints of the common GEOPRIV transactions are the
Location Sighter (the source of location information from the
perspective of the network) and the Ultimate Location Recipient (ULR)
(the destination of data), which can be viewed as a special case of a
Location Seeker. Both a Location Sighter and a Location Seeker may
have a relationship with a Location Server; the Location Sighter
publishes data to a Location Server (which may provide a grooming/
filtration function for location information), and the Location
Seeker requests and receives information from the Location Server.
This provides two points where GEOPRIV information could require
protection across the wire. Policies can also be provisioned in the
Location Server by a Rule-Maker over the network; this provides
another point where the architecture requires security.
It is important to note that Location Sighters, and to a lesser
degree Location Seekers, may be implemented on low-cost devices for
which strong cryptographic security is currently prohibitively
expensive computationally.
3. Motivations of Attackers of GEOPRIV
The most obvious motivation for an attacker of GEOPRIV is to learn
the location of a subject who wishes to keep their position private,
or even for authorized Seekers to ascertain location information with
a greater degree of precision than the Rule-Maker desires. However,
there are several other potential motivations that are causes for
concern. Attackers might also wish to prevent a target's location
from being distributed, or to modify or corrupt location information
in order to misrepresent the location of the target, or to redirect
the target's location information to a third party that is not
authorized to know this information. Attackers may want to identify
the associates of a target, or learn the habit or routines of a
target. Attackers might want to learn the identity of all of the
parties that are in a certain location. Finally, some attackers may
simply want to halt the operation of the entire system through
denial-of-service attacks.
There is also a class of attackers who may be authorized as
legitimate participants in a GEOPRIV protocol exchange but who abuse
location information. This includes the distribution or accumulation
of location information outside the parameters of agreements between
the principals, possibly for commercial purposes or as an act of
Danley, et al. Expires April 28, 2003 [Page 4]
Internet-Draft Threat Analysis of the GEOPRIV Protocol October 2002
unlawful surveillance.
4. Representative Attacks on GEOPRIV
4.1 Protocol Attacks
4.1.1 Eavesdropping and/or Interception
Imagine a location-based computer game, based on traditional hide-
and-seek, in which a centralized server provides hints as to the
location of the 'hider' to a set of 'seekers'. Seekers are given
access to very coarse location data, whereas a single referee is
given access to unfiltered and precise location information of the
hider. Each seeker has a wireless device (in the GEOPRIV
architecture, a Location Seeker) that feeds them coarse positioning
data from the Location Server. The hider carries a device (a
Location Sighter implemented by embedded GPS) that transmits location
information to the Location Server.
If one of the seekers wished to cheat by attacking the GEOPRIV
protocol, there are a number of ways they could mount such an attack
in order to learn the precise location of the hider. They might
eavesdrop on one of two network connections - either the connection
between the Location Sighter and the Location Server, or the
connection between the Location Server and the referee's Location
Seeker (which receives precise information). They might also attempt
to impersonate the referee to the Location Server, in order to
receive unfiltered Location Information. Alternatively, they could
impersonate the Location Server to the Location Sighter carried by
the hider, which would also give them access to precise location
information. Finally, the cheater could attempt to act as the Rule-
Maker, and to insert policies into the Location Server that would
enable the cheater's Location Seeker access to uncoarsened location
information.
From these threats, we can derive a need for several security
properties of the architecture.
o Confidentiality is required on both the connection between the
Location Sighter and the Location Server, as well as the
connection between the Location Server and any given Location
Seeker.
o Location Servers must be capable of authenticating and authorizing
Location Seekers to prevent impersonation.
Danley, et al. Expires April 28, 2003 [Page 5]
Internet-Draft Threat Analysis of the GEOPRIV Protocol October 2002
o Similarly, Location Sighters must be capable of authenticating and
authorizing Location Servers in order to prevent impersonation.
o Finally, the Location Server must be able to authenticate Rule-
Makers, to make sure that unauthorized parties cannot change
rules.
4.1.2 Identity Spoofing
Consider a case in which the same boss employs two rivals. One goes
on a business trip to Cleveland. Both rivals carry devices that are
tracked by a Location Sighter (such as cell phones on which the cell
carrier can triangulate), and both rivals allow their boss access to
their (coarse) location information. The rival that remained home
wants to hack the GEOPRIV protocol to make it appear that the
traveling rival is actually goofing off in South Beach rather than
attending a dull technology conference in Cleveland. How would such
an attack be mounted?
The attacker might attempt to spoof network traffic from the Location
Sighter to the Location Server (especially if, through some other
means such as a denial-of-service attack, the Location Sighter became
unable to issue its own reports). The goal of the attacker may be to
provide falsified location information appropriate for someone in
Miami, or perhaps even to replay a genuine location object from a
previous visit of the rival to Miami. The attacker might also try to
spoof traffic from the Location Server to the boss' Location Seeker.
From these threats we can derive a need for several security
properties of the architecture.
o There is a need for the Location Server to authenticate Location
Sighters.
o Location Seekers must be capable of authenticating Location
Servers.
o Location information must be protected from replay attacks.
Identity spoofing may create additional threats when the protocol is
attacked. In many circumstances, the identity of the Location
Requester and the Location Recipient are the basis for controlling
whether LI is revealed and, if so, how that LI is filtered. If the
identity of those entities is compromised, privacy is threatened.
Anyone inside or outside the transaction that is capable of
impersonating an authorized entity can gain access to confidential
information, or initiate false transmissions in the authorized
Danley, et al. Expires April 28, 2003 [Page 6]
Internet-Draft Threat Analysis of the GEOPRIV Protocol October 2002
entity's name. The ability to spoof the identity of the Location
Recipient, for example, would create the risk of an unauthorized
entity accessing both the identity and the location of the Target at
the moment the LO was sent.
4.1.3 Information Gathering
Eavesdropping and interception can also create traffic analysis
threats as the interceptor collects more data over time. Traffic
analysis threats generally create the risk that an eavesdropper will
be able to determine, from the very fact of the transmission, a
relationship between the various entities involved. If an employer
requests to send the location of an employee to a customer, an
eavesdropper could determine that three entities are somehow
interacting with one another. If eavesdropping continues over time,
each interaction would involve the employer, employee, and several
customers. Such a log of information would reveal that the employer
and employee frequently were associated with one another, and would
reveal which clients more frequently dealt with the pair. Thus, the
traffic analysis threat creates the risk of eavesdroppers determining
the Target's associates.
Traffic analysis might also allow an eavesdropper to ascertain the
identity or characteristics of targets in a particular location. By
observing transmissions between Location Sighters in a particular
location and Location Servers (perhaps by eavesdropping on a wireless
or wireline LAN scoped to the location in question), and then
possibly following the data to various Location Recipients, an
attacker may be able to learn the associates, including the employer,
of targets in that location, and perhaps to extrapolate further
identity information.
If the eavesdropper is able to intercept not only the LO, but the LI
itself, other threats are raised. Let's return to the above example
of the employer requesting an employee's location information. In
this instance, the interception of one such past transaction may
reveal the identities and/or locations of all three parties involved,
in addition to revealing the fact of their association. In
circumstances where there is a log of this data, however, analysis
could reveal any regular route that the employee may travel in
visiting customers, a general area that the employee works in, the
identities and location of the employee's entire customer base, and
information about how the entities relate.
Threats based on traffic analysis are difficult to meet with protocol
security measures, but they are important to note.
From these threats we can derive a need for several security
Danley, et al. Expires April 28, 2003 [Page 7]
Internet-Draft Threat Analysis of the GEOPRIV Protocol October 2002
properties of the architecture.
o The Rule Maker must be able to define policies regarding the use
of their LI.
o The connection between the Location Sighter and Location Server,
as well as the connection between the Location Server and Location
Seeker must remain confidential.
o Location Servers and Location Sighters must be capable of
authenticating Location Seekers to prevent impersonation.
o Location Servers must be able to authenticate Rule Makers to
ensure that unauthorized entities cannot change rules.
4.1.4 Denial of Service
Parties who wish to deprive entire networks of GEOPRIV service,
rather than just targeting particular users, would probably focus
their efforts on the Location Server. Since in many scenarios the
Location Server plays the central role of managing access to location
information for many devices, it is in such architectures a natural
single point of failure.
The GEOPRIV protocol appears to have some opportunities for
amplification attacks. When the Location Sighter reports
information, the Location Server acts as an exploder, potentially
delivering this information to numerous targets. If the Location
Sighter were to provide very rapid updates of position (as many as
link speed could accommodate, especially in high-bandwidth wireless
environments), then were the Location Server to proxy information to
Seekers at a similar rate, this could become problematic when large
numbers of Seekers are tracking the same user.
Also note that most operations associated with the Location Server
probably require cryptographic authentication. Cryptographic
operations entail a computational expense on the part of the Location
Server. This could provide an attractive means for attackers to
flood the Location Server with dummied GEOPRIV information that is
spoofed to appear to come from a Location Sighter, Location Seeker,
or the Rule-Maker. Because the Location Server has to expend
resources to verify credentials presented by these GEOPRIV messages,
floods of GEOPRIV information could have greater impact than denial-
of-service attacks based on generic packet flooding.
Danley, et al. Expires April 28, 2003 [Page 8]
Internet-Draft Threat Analysis of the GEOPRIV Protocol October 2002
4.2 Host Attacks
4.2.1 Data Stored at Servers
LI maintained at a server is subject to many potential risks. First,
there may be accidental misuse of LI by the server. Whether by
negligence, carelessness, or lack of knowledge, the server may
accidentally release LI to the wrong Location Recipients, or fail to
properly filter the LI that is sent out. Second, the server may
intentionally misuse LI. A server may decide to sell a "profile" it
has compiled of a Target or Location Seeker despite provisions to the
contrary in the Rule Maker's Policy. Alternatively, an individual
working for the server may, for personal gain, misuse access to the
server to obtain LI. Third, even with the most secure and trusted
server, there is the risk that someone outside the system will hack
into it in order to retrieve LI. Last, there is always the potential
that someone would use the legal system to subpoena an individual's
records from a Server. Such a process would likely result in the
revelation of the Target's location information without notice to the
Target or the Target's consent.
Data stored at the server may reveal the Target's present location if
the data is used or intercepted at or near the moment of
transmission. If a Target requests a map from their present location
to a nearby store, and the server sends that information to the wrong
Location Recipient, that Recipient could know the identity of the
Target, the Target's current location, and the location where the
Target might be headed.
Data stored at the Location Server can also create many of the
traffic analysis threats discussed in Section 4.1 above. If access
is gained not only to the fact of the LO transmission, but also to
the LI transmitted, anyone with access to that information can put
together a history of where that Target has been, for how long, and
with whom.
4.2.2 Data Stored in Devices
Because GEOPRIV is required to work with any given type of technology
or Device, it is difficult to determine the particular threat
potential of individual devices. For example, any device that
maintains a log of Location Requests sent, or LOs received, would
pose a similar threat to the information maintained at a Location
Server, discussed above. A court subpoena or warrant for an
individual's device could additionally reveal a similar log.
Additionally, depending on the device, there is always the potential
for data to be compromised in some way. For a Device with a screen,
Danley, et al. Expires April 28, 2003 [Page 9]
Internet-Draft Threat Analysis of the GEOPRIV Protocol October 2002
there is always the potential that another individual will have the
opportunity to view the Device display without the user's knowledge.
A Device that provides verbal feedback (i.e. to give directions to
the blind) creates additional potential for LI to be compromised. If
the Target is sitting in a public place and requests directions from
the Target's home to another location, anyone who can see the Device
output may be able to determine the Target's identity, their
residence, and possibly the location to which they are headed.
In addition, if the device retained location information and the
Device were lost or stolen, someone other than the Policy Maker could
potentially access information regarding who LI was sent to and when,
as well as potentially the location of the Target during each
transaction. Such information could enable an entity to determine
significant private information based on who the owner of the Device
has associated with in the past, as well as each location where the
Target has been and for how long.
4.2.3 Data Stored with the Ultimate Location Recipient
The threats posed here are similar to those discussed above in
relation to Location Servers and Devices. The main purpose of
separating out threats posed by data stored at the ULR is to show
that, depending on the complexity of the transaction and the other
entities involved, data storage at various points in the transaction
can bring rise to the same types of privacy risks.
4.2.4 Information Contained in Policies
In many instances, the policies a Rule Maker creates will reveal
information either about the Rule Maker or the Target. A rule that
degrades all information sent out by approximately 25 miles might
tell an interceptor how to determine the Target's true location. A
policy that states, "Tell my boss what room I'm in when I'm in the
building, but when I'm outside the building between 9 a.m. and 5
p.m. tell him I'm in the building," would reveal a lot more
information than most employees would desire. Any boss who was the
Location Seeker who received LI that specified "in the building"
would then realize that the employee was elsewhere.
In addition, if an entity had access to a log of data at the Location
Server or at a Device, knowledge of the content of Policies would
enable a sort of "decoding" of the location information of the device
to something more accurate. Thus, my boss could not only tell where
I am at this minute, but could tell how many times over the last year
I had been outside the building between 9 a.m. and 5 p.m.
The policies themselves may also reveal information about the Target.
Danley, et al. Expires April 28, 2003 [Page 10]
Internet-Draft Threat Analysis of the GEOPRIV Protocol October 2002
A rule such as the one above would clearly reveal the employment
relationship between the two individuals as well as the fact that the
employee was hiding something from the employer.
In combination with other information the location information may
enable the identification of the Target.
4.3 Usage Attacks
4.3.1 Threats Posed by Overcollection
Weak or absent default privacy rules would also compromise LI.
Without default policies for LOs, it is likely that a large number of
Devices would reveal LI by default. Privacy rules should control the
collection, use, disclosure, and retention of Location Information.
These rules must comply with fair information practices-these
practices are further discussed in Section 5.1.
While technically savvy Device users may create privacy rules to
protect their LI, many individuals will lack the skill or motivation
to do so. Thus, left to their own devices many individuals would
likely be left without privacy rules for their LI. This in turn
would leave these users' LI entirely vulnerable to various attacks.
Default rules are necessary to address this problem.
Without default rules, for example, a device might signal out to
anyone nearby at regular intervals, respond to anyone nearby who
queried it, or send signals out to unknown entities.
The lack of a default rule of "Do not re-distribute," would allow the
Location Server to pass the Target's location information on to
others. Lack of a default rule limiting the retention of LI could
increase the risk posed by inappropriate use and access to stored
data.
While defining default privacy rules is beyond the scope of this
document, default rules are necessary to limit the privacy risks
posed by the use of services and devices using LI.
5. Countermeasures for Usage Violations
5.1 Fair Information Practices
Principles of fair information practices require entities that handle
personal information to meet certain obligations with respect to its
collection, use, maintenance and security, and give individuals
whose personal information is collected certain due process-like
Danley, et al. Expires April 28, 2003 [Page 11]
Internet-Draft Threat Analysis of the GEOPRIV Protocol October 2002
rights in the handling of their information. Fair information
practices are designed to prevent specific threats posed by the
collection of personal information about individuals. For this
reason, fair information practices are "countermeasures" that should
be reflected in technical systems that handle personal information
and the policies that govern their use. A brief discussion of fair
information practices may be beneficial in formulating requirements
for the LO.
There are seven main principles of fair information practices:
1. Openness: The existence of a record-keeping system for personal
information must be known, along with a description of the main
purpose and uses of the data. Thus any entity that collects LI
should inform individuals that this information is being
collected and inform them about what the LI is being used for.
Openness is designed to prevent the creation of secret systems.
2. Individual Participation: Individuals should have a right to view
all information collected about them, and to be able to correct
or remove data that is not timely, accurate, relevant, or
complete. The practice of individual participation acknowledges
that sometimes information that is collected may be inaccurate or
inappropriate.
3. Collection Limitation: Data should be collected by lawful and
fair means and should be collected, where appropriate, with the
knowledge or consent of the subject. Data collection should be
minimized to that which is necessary to support the transaction.
Placing limits on collection helps protect individuals from the
dangers of overcollection-both in terms of collecting too much
information, or of collecting information for too long of a time
period.
4. Data Quality: Personal data should be relevant to the purposes
for which it is collected and used; personal information should
be accurate, complete, and timely. The requirement of data
quality is designed to prevent particular kinds of harms that can
flow from the use (appropriate or inappropriate) of personal
information.
5. Finality: There should be limits to the use and disclosure of
personal data: data should be used only for purposes specified at
the time of collection; data should not be otherwise used or
disclosed without the consent of the data subject or other legal
authority. A consumer who provides LI to a business in order to
receive directions, for example, does not provide that
information for any other purpose. The business should then only
Danley, et al. Expires April 28, 2003 [Page 12]
Internet-Draft Threat Analysis of the GEOPRIV Protocol October 2002
use that LI to provide directions, and not for other purposes.
6. Security: Personal Data should be protected by reasonable
security safeguards against such risks as loss, unauthorized
access, destruction, use, modification, or disclosure. While
some security measures may take place outside of the LO-i.e.
limiting employee access to Location Servers-other measures may
be done through the LO or LO applications.
7. Accountability: Record keepers should be accountable for
complying with fair information practices. It will typically be
easier for an individual to enforce these practices if they are
explicitly written-either in the policies written by the Rule
Maker, or in contracts between the individual and a trusted
entity.
6. Security Properties of the GEOPRIV Protocol
The countermeasures suggested below reflect the threats discussed in
this document. There is thus some overlap between the proposed
security properties listed below, and the requirements in [1].
6.1 Policies as Counter-Measures
The sections below are designed to illustrate that in many instances
threats to LI can be limited through clear, unavoidable rules
determined by Rule Makers.
6.1.1 Rule Maker Should Define Policies
The Rule Maker for a given Device will generally be either the user
of, or owner of, the device. In certain circumstances, the Rule
Maker may be both of these entities. Depending on the device the
Rule Maker may or may not be the individual most closely aligned with
the Target. For instance a child carrying a cell phone may be the
Target, but the parent of that child would likely be the Rule Maker
for the Device. Giving the Rule Maker control is a potential
opportunity to buttress the consent component of the collection
limitation and finality principles discussed above.
6.1.2 GEOPRIV Should Have Default Policies
Because some Rule Makers may not be informed about the role Policies
play in the disclosure of their LI, GEOPRIV should include default
policies. The Rule Maker is, of course, always free to change his or
her policies to provide more or less protection. To protect privacy
and physical safety, default policies should, at a minimum, limit
Danley, et al. Expires April 28, 2003 [Page 13]
Internet-Draft Threat Analysis of the GEOPRIV Protocol October 2002
disclosure and retention of LI..
Default policies are also necessary for so-called "dumb" Location
Sighters (LoSi). If a LoSi is unable to determine the Policies set
by the Rule Maker before passing the LO on to a Location Seeker, it
is important that some default policies protect that LO in transit,
and ensure that the LO is only sent to authorized Location Seekers.
These default LoSi policies would help prevent many of the threats
discussed in this document. The Rule Maker should be able to
determine the content of these default policies at any time.
6.1.3 Location Recipient Should Not Be Aware of All Policies
An Ultimate Location Recipient should not be aware of the full
policies defined by the Rule Maker. The ULR will only need to be
aware of those Policies it must obey-i.e. those regarding its use
and retention of the LI. Other policies, such as those specifying
the accuracy or filtering of the LI, or rules that do not cover the
given interaction should not be revealed to the ULR. This
countermeasure is consistent with the minimization component of the
collection limitation principle and ensures that the Rule Maker
reveals only what he intends to.
6.1.4 Certain Policies Should Travel With the LO
Security of LI at the device level is a bit complicated, as the Rule
Maker has no real control over what is done with the LI once it
arrives at the Device of the Location Seeker. If certain Policies
travel with the LO, the Rule Maker can encourage ULR compliance with
its policies. Potentially, a Policy could travel with the LO
indicating when it was time to purge the data, preventing the
compilation of a "log" of the Target's LI on any Device involved in
the transmission of the LO. Allowing policies to travel with the LO
has the potential to limit the opportunity for traffic analysis
attacks.
6.2 Protection of Identities
Identities are an extremely important component of the LO. While, in
many instances, some form of identification of the Target, LS, and
ULR will be necessary for authentication, there are various methods
to separate these authentication "credentials" from the true identity
of these devices. These countermeasures are particularly useful in
that compromise of a log of LI, no matter where the source, is less
threatening to privacy when the Target's identity is stripped.
Danley, et al. Expires April 28, 2003 [Page 14]
Internet-Draft Threat Analysis of the GEOPRIV Protocol October 2002
6.2.1 Short-Lived Identifiers May Protect Target's Identity
Short-Lived identifiers would allow the using protocol to hide the
true identity of the Rule Maker and the Target from Location Servers
or Location Recipients. These identifiers would still allow
authentication, ensuring that only appropriate Location Recipients
received the LO. At the same time, however, making these identifiers
short-lived helps prevent any association of a true identity of a
Target with particular habits and associates.
6.2.2 Unlinked Pseudonyms May Protect the Location Recipients' Identity
Unlinked pseudonyms would protect the identity of the Location
Recipients in much the same manner as short-lived identifiers would
protect the Target's identity. When using both, any record that a
Location Server had of a transaction would have two "credentials"
associated with a LI transmission-one linked to the Target and one
linked to the Location Recipient. These credentials would allow the
Location Server to authenticate the transmission without ever
acquiring knowledge of the true identities of the individuals
associated with each side of the transaction.
6.3 Security During Transmission of Data
The attacks describe in this document motivate the following security
properties for the connections between the Location Sighter and
Location Server, the Location Server and Rule-Maker, and the Location
Server and Location Seeker:
6.3.1 Policies May Disallow a Certain Frequency of Requests
The Rule Maker might be able to set a policy that disallows a certain
number of requests made within a specific period of time. This type
of arrangement would allow the Rule Maker to somewhat prevent the
ability to average randomly coarsened data. To an "untrusted"
Location Recipient, for example, to whom the Rule Maker only wants to
reveal LI that is coarsened to the level of a city, only one request
might be honored every 2 hours. This would prevent Location
Recipients from sending repeated requests to gain more accurate
presence information.
6.3.2 Mutual End-Point Authentication
Authentication is crucial to the security of LI during transmission.
The Location Server must be capable of authenticating Location
Seekers to prevent impersonation. Location Sighters must be capable
of authenticating Location Servers to ensure that raw location
information is not sent to improper entities. Additionally, Location
Danley, et al. Expires April 28, 2003 [Page 15]
Internet-Draft Threat Analysis of the GEOPRIV Protocol October 2002
Servers must be able to authenticate Rule-Makers to ensure that
unauthorized entities cannot change Policies.
6.3.3 Data Object Integrity & Confidentiality
The LO must maintain integrity at all points of communication between
Location Servers and Location Seekers. Confidentiality is required
on both the connection between the Location Sighter and the Location
Server, as well as on the connection between the Location Server and
any given Location Seeker.
6.3.4 Replay Protection
Replay protection prevents an attacker from capturing a particular
picee of location information and replaying it at a later time in
order to convince ULRs of an erroneous location for the target. Both
Location Seekers and Location Servers, depending on their
capabilities, may need replay protection.
7. Security Considerations
This informational document characterizes potential security threats
targeting the GEOPRIV architecture.
8. IANA Considerations
This document introduces no additional considerations for IANA.
Informative References
[1] Cuellar, J., Morris, J. and D. Mulligan, "Geopriv requirements",
draft-ietf-geopriv-reqs-01 (work in progress), October 2002.
Authors' Addresses
Michelle Engelhardt Danley
Samuelson Law, Technology and Public Policy Clinic, Boalt Hall School of Law
University of California
Berkeley, CA 94720
USA
EMail: mre213@nyu.edu
Danley, et al. Expires April 28, 2003 [Page 16]
Internet-Draft Threat Analysis of the GEOPRIV Protocol October 2002
Deirdre Mulligan
Samuelson Law, Technology and Public Policy Clinic, Boalt Hall School of Law
University of California
Berkeley, CA 94720
USA
EMail: dmulligan@law.berkeley.edu
John B. Morris, Jr.
Center for Democracy and Technology
1634 I Street NW
Suite 1100
Washington, DC 20006
USA
EMail: jmorris@cdt.org
URI: http://www.cdt.org
Jon Peterson
NeuStar, Inc.
1800 Sutter St
Suite 570
Concord, CA 94520
USA
Phone: +1 925/363-8720
EMail: jon.peterson@neustar.biz
URI: http://www.neustar.biz/
Danley, et al. Expires April 28, 2003 [Page 17]
Internet-Draft Threat Analysis of the GEOPRIV Protocol October 2002
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Danley, et al. Expires April 28, 2003 [Page 18]
