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

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/