draft-ietf-geopriv-arch-03.txt   rfc6280.txt 
GEOPRIV R. Barnes Internet Engineering Task Force (IETF) R. Barnes
Internet-Draft M. Lepinski Request for Comments: 6280 M. Lepinski
Updates: 3693, 3694 BBN Technologies BCP: 160 BBN Technologies
(if approved) A. Cooper Updates: 3693, 3694 A. Cooper
Intended status: BCP J. Morris Category: Best Current Practice J. Morris
Expires: April 14, 2011 Center for Democracy & ISSN: 2070-1721 Center for Democracy & Technology
Technology
H. Tschofenig H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
H. Schulzrinne H. Schulzrinne
Columbia University Columbia University
October 11, 2010 July 2011
An Architecture for Location and Location Privacy in Internet An Architecture for Location and Location Privacy
Applications in Internet Applications
draft-ietf-geopriv-arch-03
Abstract Abstract
Location-based services (such as navigation applications, emergency Location-based services (such as navigation applications, emergency
services, management of equipment in the field) need geographic services, and management of equipment in the field) need geographic
location information about Internet hosts, their users, and other location information about Internet hosts, their users, and other
related entities. These applications need to securely gather and related entities. These applications need to securely gather and
transfer location information for location services, and at the same transfer location information for location services, and at the same
time protect the privacy of the individuals involved. This document time protect the privacy of the individuals involved. This document
describes an architecture for privacy-preserving location-based describes an architecture for privacy-preserving location-based
services in the Internet, focusing on authorization, security, and services in the Internet, focusing on authorization, security, and
privacy requirements for the data formats and protocols used by these privacy requirements for the data formats and protocols used by these
services. services.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This memo documents an Internet Best Current Practice.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
BCPs is available in Section 2 of RFC 5741.
This Internet-Draft will expire on April 14, 2011. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6280.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................3
1.1. Binding Rules to Data . . . . . . . . . . . . . . . . . . 4 1.1. Binding Rules to Data ......................................4
1.2. Location-Specific Privacy Risks . . . . . . . . . . . . . 5 1.2. Location-Specific Privacy Risks ............................5
1.3. Privacy Paradigms . . . . . . . . . . . . . . . . . . . . 6 1.3. Privacy Paradigms ..........................................6
2. Terminology Conventions . . . . . . . . . . . . . . . . . . . 7 2. Terminology Conventions .........................................7
3. Overview of the Architecture . . . . . . . . . . . . . . . . . 7 3. Overview of the Architecture ....................................7
3.1. Basic Geopriv Scenario . . . . . . . . . . . . . . . . . . 8 3.1. Basic Geopriv Scenario .....................................8
3.2. Roles and Data Formats . . . . . . . . . . . . . . . . . . 10 3.2. Roles and Data Formats ....................................10
4. The Location Life-Cycle . . . . . . . . . . . . . . . . . . . 13 4. The Location Life Cycle ........................................12
4.1. Positioning . . . . . . . . . . . . . . . . . . . . . . . 14 4.1. Positioning ...............................................13
4.1.1. Determination Mechanisms and Protocols . . . . . . . . 14 4.1.1. Determination Mechanisms and Protocols .............14
4.1.2. Privacy Considerations for Positioning . . . . . . . . 16 4.1.2. Privacy Considerations for Positioning .............16
4.1.3. Security Considerations for Positioning . . . . . . . 17 4.1.3. Security Considerations for Positioning ............16
4.2. Location Distribution . . . . . . . . . . . . . . . . . . 17 4.2. Location Distribution .....................................17
4.2.1. Privacy Rules . . . . . . . . . . . . . . . . . . . . 18 4.2.1. Privacy Rules ......................................17
4.2.2. Location Configuration . . . . . . . . . . . . . . . . 20 4.2.2. Location Configuration .............................19
4.2.3. Location References . . . . . . . . . . . . . . . . . 20 4.2.3. Location References ................................20
4.2.4. Privacy Considerations for Distribution . . . . . . . 21 4.2.4. Privacy Considerations for Distribution ............21
4.2.5. Security Considerations for Distribution . . . . . . . 23 4.2.5. Security Considerations for Distribution ...........23
4.3. Location Use . . . . . . . . . . . . . . . . . . . . . . . 24 4.3. Location Use ..............................................24
4.3.1. Privacy Considerations for Use . . . . . . . . . . . . 24 4.3.1. Privacy Considerations for Use .....................25
4.3.2. Security Considerations for Use . . . . . . . . . . . 24 4.3.2. Security Considerations for Use ....................25
5. Security Considerations . . . . . . . . . . . . . . . . . . . 25 5. Security Considerations ........................................25
6. Example Scenarios . . . . . . . . . . . . . . . . . . . . . . 27 6. Example Scenarios ..............................................28
6.1. Minimal Scenario . . . . . . . . . . . . . . . . . . . . . 27 6.1. Minimal Scenario ..........................................28
6.2. Location-based Web Services . . . . . . . . . . . . . . . 28 6.2. Location-Based Web Services ...............................29
6.3. Emergency Calling . . . . . . . . . . . . . . . . . . . . 30 6.3. Emergency Calling .........................................31
6.4. Combination of Services . . . . . . . . . . . . . . . . . 32 6.4. Combination of Services ...................................32
7. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 7. Glossary .......................................................35
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37 8. Acknowledgements ...............................................38
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 9. References .....................................................38
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 9.1. Normative References ......................................38
10.1. Normative References . . . . . . . . . . . . . . . . . . . 37 9.2. Informative References ....................................38
10.2. Informative References . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction 1. Introduction
Location-based services (applications that require information about Location-based services (applications that require information about
the geographic location of an individual or device) are becoming the geographic location of an individual or device) are becoming
increasingly common on the Internet. Navigation and direction increasingly common on the Internet. Navigation and direction
services, emergency services, friend finders, management of equipment services, emergency services, friend finders, management of equipment
in the field and many other applications require geographic location in the field, and many other applications require geographic location
information about Internet hosts, their users, and other related information about Internet hosts, their users, and other related
entities. As the accuracy of location information improves and the entities. As the accuracy of location information improves and the
expense of calculating and obtaining it declines, the distribution expense of calculating and obtaining it declines, the distribution
and use of location information in Internet-based services will and use of location information in Internet-based services will
likely become increasingly pervasive. Ensuring that location likely become increasingly pervasive. Ensuring that location
information is transmitted and accessed in a secure and privacy- information is transmitted and accessed in a secure and privacy-
protective way is essential to the future success of these services, protective way is essential to the future success of these services,
as well as the minimization of the privacy harms that could flow from as well as the minimization of the privacy harms that could flow from
their wide deployment and use. their wide deployment and use.
skipping to change at page 4, line 38 skipping to change at page 4, line 25
which is used to convey both location information about an individual which is used to convey both location information about an individual
or device and user-specified privacy rules governing that location or device and user-specified privacy rules governing that location
information. As location information moves through its life cycle -- information. As location information moves through its life cycle --
positioning, distribution, and use by its ultimate recipient(s) -- positioning, distribution, and use by its ultimate recipient(s) --
Geopriv provides mechanisms to secure the integrity and Geopriv provides mechanisms to secure the integrity and
confidentiality of location objects and to ensure that location confidentiality of location objects and to ensure that location
information is only transmitted in compliance with the user's privacy information is only transmitted in compliance with the user's privacy
rules. rules.
The goals of this document are two-fold: First, the architecture The goals of this document are two-fold: First, the architecture
described revises and expands on the basic Geopriv Requirements described revises and expands on the basic Geopriv Requirements [2]
[2][3], in order to clarify how these privacy concerns and the [3], in order to clarify how these privacy concerns and the Geopriv
Geopriv architecture apply to use cases that have arisen since the architecture apply to use cases that have arisen since the
publication of those documents. Second, this document provides a publication of those documents. Second, this document provides a
general introduction to Geopriv and Internet location-based services, general introduction to Geopriv and Internet location-based services,
and is useful as a good first document for readers new to Geopriv. and is useful as a good first document for readers new to Geopriv.
1.1. Binding Rules to Data 1.1. Binding Rules to Data
A central feature of the Geopriv architecture is that location A central feature of the Geopriv architecture is that location
information is always bound to privacy rules to ensure that entities information is always bound to privacy rules to ensure that entities
that receive location are informed of how they may use it. These that receive location information are informed of how they may use
rules can convey simple directives ("do not share my location with it. These rules can convey simple directives ("do not share my
others"), or more robust preferences ("allow my spouse to know my location with others"), or more robust preferences ("allow my spouse
exact location all of the time, but only allow my boss to know it to know my exact location all of the time, but only allow my boss to
during work hours"). By creating a structure to convey the user's know it during work hours"). By creating a structure to convey the
preferences along with location information, the likelihood that user's preferences along with location information, the likelihood
those preferences will be honored necessarily increases. In that those preferences will be honored necessarily increases. In
particular, no recipient of the location information can disavow particular, no recipient of the location information can disavow
knowledge of users' preferences for how their location may be used. knowledge of users' preferences for how their location may be used.
The binding of privacy rules to location information can convey The binding of privacy rules to location information can convey
users' desire for and expectations of privacy, which in turn helps to users' desire for and expectations of privacy, which in turn helps to
bolster social and legal systems' protection of those expectations. bolster social and legal systems' protection of those expectations.
Binding of usage rules to sensitive information is a common way of Binding of usage rules to sensitive information is a common way of
protecting information. Several emerging schemes for expressing protecting information. Several emerging schemes for expressing
copyright information provide for rules to be transmitted together copyright information provide for rules to be transmitted together
with copyrighted works. The Creative Commons [28] model is the most with copyrighted works. The Creative Commons [28] model is the most
prominent example, allowing an owner of a work to set four types of prominent example, allowing an owner of a work to set four types of
rules ("Attribution," "Noncommercial," "No Derivative Works" and rules ("Attribution", "Noncommercial", "No Derivative Works", and
"ShareAlike") governing the subsequent use of the work. After the "ShareAlike") governing the subsequent use of the work. After the
author sets these rules, the rules are conveyed together with the author sets these rules, the rules are conveyed together with the
work itself, so that every recipient is aware of the copyright terms. work itself, so that every recipient is aware of the copyright terms.
Classification systems for controlling sensitive documents within an Classification systems for controlling sensitive documents within an
organization are another example. In these systems, when a document organization are another example. In these systems, when a document
is created, it is marked with a classification such as "SECRET" or is created, it is marked with a classification such as "SECRET" or
"PROPRIETARY." Each recipient of the document knows from this "PROPRIETARY". Each recipient of the document knows from this
marking that the document should only be shared with other people who marking that the document should only be shared with other people who
are authorized to access documents with that marking. Classification are authorized to access documents with that marking. Classification
markings can also convey other sorts of rules, such as a markings can also convey other sorts of rules, such as a
specification for how long the marking is valid (a declassification specification for how long the marking is valid (a declassification
date). The United States Department of Defense guidelines for date). The United States Department of Defense guidelines for
classification [4] provide one example. classification [4] provide one example.
1.2. Location-Specific Privacy Risks 1.2. Location-Specific Privacy Risks
While location-based services raise some privacy concerns that are While location-based services raise some privacy concerns that are
common to all forms of personal information, many of them are common to all forms of personal information, many of them are
heightened and others are uniquely applicable in the context of heightened, and others are uniquely applicable in the context of
location information. location information.
Location information is frequently generated on or by mobile devices. Location information is frequently generated on or by mobile devices.
Because individuals often carry their mobile devices with them, Because individuals often carry their mobile devices with them,
location data may be collected everywhere and at any time, often location data may be collected everywhere and at any time, often
without user interaction, and it may potentially describe both what a without user interaction, and it may potentially describe both what a
person is doing and where he or she is doing it. For example, person is doing and where he or she is doing it. For example,
location data can reveal the fact that an individual was at a location data can reveal the fact that an individual was at a
particular medical clinic at a particular time. The ubiquity of particular medical clinic at a particular time. The ubiquity of
location information may also increase the risks of stalking and location information may also increase the risks of stalking and
domestic violence if perpetrators are able to use (or abuse) domestic violence if perpetrators are able to use (or abuse)
location-based services to gain access to location information about location-based services to gain access to location information about
their victims. their victims.
Location information is also of particular interest to governments Location information is also of particular interest to governments
and law enforcers around the world. The existence of detailed and law enforcers around the world. The existence of detailed
records of individuals' movements should not automatically facilitate records of individuals' movements should not automatically facilitate
the ability for governments to track their citizens, but in some the ability for governments to track their citizens, but in some
jurisdictions, laws dictating what government agents must do to jurisdictions, laws dictating what government agents must do to
obtain location data are either non-existent or out-of-date. obtain location data are either non-existent or out of date.
1.3. Privacy Paradigms 1.3. Privacy Paradigms
Traditionally, the extent to which data about individuals enjoys Traditionally, the extent to which data about individuals enjoys
privacy protections on the Internet has largely been decided by the privacy protections on the Internet has largely been decided by the
recipients of the data. Internet users may or may not be aware of recipients of the data. Internet users may or may not be aware of
the privacy practices of the entities with whom they share data. the privacy practices of the entities with whom they share data.
Even if they are aware, they have generally been limited to making a Even if they are aware, they have generally been limited to making a
binary choice between sharing data with a particular entity or not binary choice between sharing data with a particular entity or not
sharing it. Internet users have not historically been granted the sharing it. Internet users have not historically been granted the
opportunity to express their own privacy preferences to the opportunity to express their own privacy preferences to the
recipients of their data and to have those preferences honored. recipients of their data and to have those preferences honored.
This paradigm is problematic because the interests of data recipients This paradigm is problematic because the interests of data recipients
are often not aligned with the interests of data subjects. While are often not aligned with the interests of data subjects. While
both parties may agree that data should be collected, used, disclosed both parties may agree that data should be collected, used,
and retained as necessary to deliver a particular service to the data disclosed, and retained as necessary to deliver a particular service
subject, they may not agree about how the data should otherwise be to the data subject, they may not agree about how the data should
used. For example, an Internet user may gladly provide his email otherwise be used. For example, an Internet user may gladly provide
address on a Web site to receive a newsletter, but he may not want his email address on a Web site to receive a newsletter, but he may
the Web site to share his email address with marketers, whereas the not want the Web site to share his email address with marketers,
Web site may profit from such sharing. Neither providing the address whereas the Web site may profit from such sharing. Neither providing
for both purposes nor deciding not to provide it is an optimal option the address for both purposes nor deciding not to provide it is an
from the Internet user's perspective. optimal option from the Internet user's perspective.
The Geopriv model departs from this paradigm for privacy protection. The Geopriv model departs from this paradigm for privacy protection.
As explained above, location information can be uniquely sensitive. As explained above, location information can be uniquely sensitive.
And as siloed location-based services emerge and proliferate, they And as location-based services emerge and proliferate, they
increasingly require standardized protocols for communicating increasingly require standardized protocols for communicating
location information between services and entities. Recognizing both location information between services and entities. Recognizing both
of these dynamics, Geopriv gives data subjects the ability to express of these dynamics, Geopriv gives data subjects the ability to express
their choices with respect to their own location information, rather their choices with respect to their own location information, rather
than allowing the recipients of the information to define how it will than allowing the recipients of the information to define how it will
be used. The combination of heightened privacy risk and the need for be used. The combination of heightened privacy risk and the need for
standardization compelled the Geopriv designers to shift away from standardization compelled the Geopriv designers to shift away from
the prevailing Internet privacy model, instead empowering users to the prevailing Internet privacy model, instead empowering users to
express their privacy preferences about the use of their location express their privacy preferences about the use of their location
information. information.
Geopriv does not, by itself, provide technical means through which it Geopriv does not, by itself, provide technical means through which it
can be guaranteed that users' location privacy rules will be honored can be guaranteed that users' location privacy rules will be honored
by recipients. The privacy protections in the Geopriv architecture by recipients. The privacy protections in the Geopriv architecture
are largely provided by virtue of the fact that recipients of are largely provided by virtue of the fact that recipients of
location are informed of relevant privacy rules, and are expected to location information are informed of relevant privacy rules, and are
only use location in accordance with those rules. The distributed expected to only use location information in accordance with those
nature of the architecture inherently limits the degree to which rules. The distributed nature of the architecture inherently limits
compliance can be guaranteed and verified by technical means. the degree to which compliance can be guaranteed and verified by
Section 5 describes how some security mechanisms can address this to technical means. Section 5 describes how some security mechanisms
a limited extent. can address this to a limited extent.
By binding privacy rules to location information, however, Geopriv By binding privacy rules to location information, however, Geopriv
provides valuable information about users' privacy preferences, so provides valuable information about users' privacy preferences, so
that non-technical forces such as legal contracts, governmental that non-technical forces such as legal contracts, governmental
consumer protection authorities, and marketplace feedback can better consumer protection authorities, and marketplace feedback can better
enforce those privacy preferences. If a commercial recipient of enforce those privacy preferences. If a commercial recipient of
location information, for example, violates the location rules bound location information, for example, violates the location rules bound
to the information, the recipient can in a growing number of to the information, the recipient can in a growing number of
countries be charged with violating consumer or data protection laws. countries be charged with violating consumer or data protection laws.
In the absence of a binding of rules with location information, In the absence of a binding of rules with location information,
consumer protection authorities would be less able to protect consumer protection authorities would be less able to protect
individuals whose location information has been abused. individuals whose location information has been abused.
2. Terminology Conventions 2. Terminology Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1]. document are to be interpreted as described in RFC 2119 [1].
Throughout the remainder of this document, capitalized terms defined
in Section 7 refer to Geopriv-specific roles and formats; the same
terms used in all lowercase refer generically to those terms.
3. Overview of the Architecture 3. Overview of the Architecture
This section provides an overview of the Geopriv architecture for the This section provides an overview of the Geopriv architecture for the
secure and private distribution of location information on the secure and private distribution of location information on the
Internet. We describe the three phases of the "location life cycle" Internet. We describe the three phases of the "location life cycle"
-- positioning, distribution and use -- and discuss how the -- positioning, distribution, and use -- and discuss how the
components of the architecture fit within each phase. The next components of the architecture fit within each phase. The next
section provides additional detail about how each phase can be section provides additional detail about how each phase can be
achieved in a private and secure manner. achieved in a private and secure manner.
The risks discussed in the previous section all arise from The risks discussed in the previous section all arise from
unauthorized disclosure or usage of location information. Thus, the unauthorized disclosure or usage of location information. Thus, the
Geopriv architecture has two fundamental privacy goals: Geopriv architecture has two fundamental privacy goals:
1. Ensure that location information is distributed only to 1. Ensure that location information is distributed only to
authorized entities, and authorized entities, and
skipping to change at page 8, line 27 skipping to change at page 8, line 20
1. Access control rules: Rules that describe which entities may 1. Access control rules: Rules that describe which entities may
receive location information and in what form receive location information and in what form
2. Usage rules: Rules that describe what uses of location 2. Usage rules: Rules that describe what uses of location
information are authorized information are authorized
Within this framework for privacy, security mechanisms provide Within this framework for privacy, security mechanisms provide
support for the application of privacy rules. For example, support for the application of privacy rules. For example,
authentication mechanisms validate the identities of entities authentication mechanisms validate the identities of entities
requesting location (so that authorization and access-control requesting a location (so that authorization and access-control
policies can be applied), and confidentiality mechanisms protect policies can be applied), and confidentiality mechanisms protect
location information en route between privacy-preserving entities. location information en route between privacy-preserving entities.
Security mechanisms can also provide assurances that are outside the Security mechanisms can also provide assurances that are outside the
purview of privacy by, for example, assuring location recipients that purview of privacy by, for example, assuring location recipients that
location information has been faithfully transmitted to them by its location information has been faithfully transmitted to them by its
creator. creator.
3.1. Basic Geopriv Scenario 3.1. Basic Geopriv Scenario
As location information is transmitted among Internet hosts, it goes As location information is transmitted among Internet hosts, it goes
through a "location life-cycle": first, the location is computed through a "location life cycle": first, the location is computed
based on some external information (positioning), then it is based on some external information (positioning), and then it is
transmitted from one host to another (distribution) until finally it transmitted from one host to another (distribution) until finally it
is used by a recipient (use). is used by a recipient (use).
For example, suppose Alice is using a mobile device, she learns of For example, suppose Alice is using a mobile device, she learns of
her location from a wireless location service, and she wishes to her location from a wireless location service, and she wishes to
share her location privately with her friends by way of a presence share her location privately with her friends by way of a presence
service. Alice clearly needs to provide the presence server with her service. Alice clearly needs to provide the presence server with her
location and rules about which friends can be provided with her location and rules about which friends can be provided with her
location. To enable Alice's friends to preserve her privacy, they location. To enable Alice's friends to preserve her privacy, they
need to be provided with privacy rules. Alice may tell some of her need to be provided with privacy rules. Alice may tell some of her
friends the rules directly, or she can have the presence server friends the rules directly, or she can have the presence server
provide the rules to her friends when it provides them with her provide the rules to her friends when it provides them with her
location. In this way, every friend who receives Alice's location is location. In this way, every friend who receives Alice's location is
authorized by Alice to receive it, and every friend who receives it authorized by Alice to receive it, and every friend who receives it
knows the rules. Good friends will obey the rules. If a bad friend knows the rules. Good friends will obey the rules. If a bad friend
breaks them and Alice finds out, the bad friend cannot claim that he breaks them and Alice finds out, the bad friend cannot claim that he
was unaware of the rules. was unaware of the rules.
Some of Alice's friends will be interested in using Alice's location Some of Alice's friends will be interested in using Alice's location
only for their own purposes (to meet up with her or plot her location only for their own purposes, for example, to meet up with her or plot
over time, for example). The usage rules that they receive direct her location over time. The usage rules that they receive direct
them as to what they can or cannot do (for example, Alice might not them as to what they can or cannot do (for example, Alice might not
want them keeping her location for more than, say, two weeks). want them keeping her location for more than, say, two weeks).
Consider one friend, Bob, who wants to send Alice's location to some Consider one friend, Bob, who wants to send Alice's location to some
of his friends. To operate in a privacy-protective way, Bob needs of his friends. To operate in a privacy-protective way, Bob needs
not only usage rules for himself, but also access control rules that not only usage rules for himself, but also access control rules that
describe who he can send information to and rules to give to the describe who he can send information to and rules to give to the
recipients. If the rules he received from the presence server recipients. If the rules he received from the presence server
authorize him to give Alice's location to others, he may do so; authorize him to give Alice's location to others, he may do so;
otherwise, he will require additional rules from Alice before he is otherwise, he will require additional rules from Alice before he is
authorized to distribute her location. If recipients who receive authorized to distribute her location. If recipients who receive
Alice's location from Bob want to distribute the location on further, Alice's location from Bob want to distribute the location information
they must go through the same process as Bob. further, they must go through the same process as Bob.
The whole example is illustrated in the following figure: The whole example is illustrated in the following figure:
+----------+ +----------+
| Wireless | | Wireless |
| Location | | Location |
| Service | Retrieve | Service | Retrieve
+----------+ Access Control Rules +----------+ Access Control Rules
| +-----------------------------------+ | +--------------------------------+
| | +-----------------------------+ | | | +--------------------------+ |
Location | | Access | | Location | | Access | |
| | | Control Rules v | | | | Control Rules v |
| | | +-----+ | | | +-----+
| | | | | | | | | Bob |
| | | | Bob |--> ... | | | |+---+|--> ...
| | | +----->| | | | | +----->||PC ||
v v | | +-----+ ........... v | | ++---++
+----------+ +----------+ | | +------+| +----------+ |
| |Device| |--Location->| Presence |--Location---->| +----------+ | |Mobile|+--Location->| Presence |--Location-->| +----------+
| -------- | | Server | |---->| Friend-1 | | |Phone || | Server | |---->| Friend-1 |
| |---Rules--->| |---Rules------>| +----------+ | +------++---Rules--->| |---Rules---->| +----------+
| Alice | +----------+ | | Alice | +----------+ |
+----------+ | | O | |
| +----------+ | /|\ | | +----------+
+---->| Friend-2 | | / \ | +---->| Friend-2 |
+----------+ `---------' +----------+
Figure 1: Basic Geopriv Scenario Figure 1: Basic Geopriv Scenario
3.2. Roles and Data Formats 3.2. Roles and Data Formats
The above example illustrates the six basic roles in the Geopriv The above example illustrates the six basic roles in the Geopriv
architecture: architecture:
Target: An individual or other entity whose location is sought in Target: An individual or other entity whose location is sought in
the Geopriv architecture. In many cases the Target will be the the Geopriv architecture. In many cases, the Target will be the
human user of a Device, but it can also be an object such as a human user of a Device, but it can also be an object such as a
vehicle or shipping container to which a Device is attached. In vehicle or shipping container to which a Device is attached. In
some instances the Target will be the Device itself. The Target some instances, the Target will be the Device itself. The Target
is the entity whose privacy Geopriv seeks to protect. Alice is is the entity whose privacy Geopriv seeks to protect. Alice is
the Target in Figure 1. the Target in Figure 1.
Device: The technical device whose location is tracked as a proxy Device: The physical device, such as a mobile phone, PC, or
for the location of a Target. Alice's device is the Device in embedded micro-controller, whose location is tracked as a proxy
Figure 1. for the location of a Target. Alice's mobile phone is the Device
in Figure 1.
Rule Maker (RM): Performs the role of creating rules governing Rule Maker (RM): Performs the role of creating rules governing
access to location information for a Target. In some cases the access to location information for a Target. In some cases, the
Target performs the Rule Maker role (as is the case with Alice), Target performs the Rule Maker role (as is the case with Alice),
and in other cases they are separate. For example, a parent may and in other cases they are separate. For example, a parent may
serve as the Rule Maker when the Target is his child, or a serve as the Rule Maker when the Target is his child, or a
corporate security officer may serve as the Rule Maker for devices corporate security officer may serve as the Rule Maker for devices
owned by the corporation but used by employees. The Rule Maker is owned by the corporation but used by employees. The Rule Maker is
also not necessarily the owner of the Device. For example, a also not necessarily the owner of the Device. For example, a
corporation may provide a Device to an employee but permit the corporation may provide a Device to an employee but permit the
employee to serve as the Rule Maker and set her own privacy rules. employee to serve as the Rule Maker and set her own privacy rules.
Location Generator (LG): Performs the roles of initially Location Generator (LG): Performs the roles of initially
determining or gathering the location of the Device and providing determining or gathering the location of the Device and providing
it to Location Servers. Location Generators may be any sort of it to Location Servers. Location Generators may be any sort of
software or hardware used to obtain the Device's location software or hardware used to obtain the Device's location.
(examples include GPS chips and cellular networks). A Device may Examples include Global Positioning System (GPS) chips and
even perform the Location Generator role for itself; Devices cellular networks. A Device may even perform the Location
capable of unassisted satellite-based positioning and Devices that Generator role for itself; Devices capable of unassisted
accept manually entered location information are two examples. satellite-based positioning and Devices that accept manually
The wireless location service plays the Location Generator role in entered location information are two examples. The wireless
Figure 1. location service plays the Location Generator role in Figure 1.
Location Server (LS): Performs the roles of receiving location Location Server (LS): Performs the roles of receiving location
information and rules, applying the rules to the location information and rules, applying the rules to the location
information to determine what other entities, if any, can receive information to determine what other entities, if any, can receive
location information, and providing the location to Location location information, and providing the location to Location
Recpients. Location Servers receive location information from Recipients. Location Servers receive location information from
Location Generators and rules from Rule Makers, and then apply the Location Generators and rules from Rule Makers, and then apply the
rules to the location information. Location Servers may not rules to the location information. Location Servers may not
necessarily be "servers" in the colloquial sense of hosts in necessarily be "servers" in the colloquial sense of hosts in
remote data centers servicing requests. Rather, a Location Server remote data centers servicing requests. Rather, a Location Server
can be any software or hardware component that distributes can be any software or hardware component that distributes
location information. Examples include a server in an access location information. Examples include a server in an access
network, a presence server, or a Web browser or other software network, a presence server, or a Web browser or other software
running on a Device. The above example includes three Location running on a Device. The above example includes three Location
Servers: Alice, the presence service and Bob. Servers: Alice's mobile phone, the presence service, and Bob's PC.
Location Recipient (LR): Performs the role of receiving location Location Recipient (LR): Performs the role of receiving location
information. A Location Recipient may ask for location explicitly information. A Location Recipient may ask for a location
(by sending a query to a Location Server), or it may receive explicitly (by sending a query to a Location Server), or it may
location asynchronously. The presence service, Bob, Friend-1 and receive a location asynchronously. The presence service, Bob,
Friend-2 are Location Recipients in Figure 1. Friend-1, and Friend-2 are Location Recipients in Figure 1.
In general, these roles may or may not be performed by physically In general, these roles may or may not be performed by physically
separate entities, as demonstrated by the entities in Figure 1, many separate entities, as demonstrated by the entities in Figure 1, many
of which perform multiple roles. It is not uncommon for the same of which perform multiple roles. It is not uncommon for the same
entity to perform both the Location Generator and Location Server entity to perform both the Location Generator and Location Server
roles, or both the Location Recipient and Location Server roles. A roles, or both the Location Recipient and Location Server roles. A
single entity may take on multiple roles simply by virtue of its own single entity may take on multiple roles simply by virtue of its own
capabilities and the permissions provided to it. capabilities and the permissions provided to it.
Although in the above example there is only a single Location Although in the above example there is only a single Location
skipping to change at page 12, line 28 skipping to change at page 11, line 46
object being located and its privacy. While in the example above object being located and its privacy. While in the example above
there is a one-to-one relationship between the Target and the Device, there is a one-to-one relationship between the Target and the Device,
Geopriv can also be used to convey location information about a Geopriv can also be used to convey location information about a
device that is not directly linked to a single individual or object, device that is not directly linked to a single individual or object,
such as a Device shared by multiple individuals. such as a Device shared by multiple individuals.
Two data formats are necessary within this architecture: Two data formats are necessary within this architecture:
Location Object (LO): An object used to convey location information Location Object (LO): An object used to convey location information
together with Privacy Rules. Geopriv supports both geodetic together with Privacy Rules. Geopriv supports both geodetic
location data (latitude/longitude/altitude/etc.) and civic location data (latitude, longitude, altitude, etc.) and civic
location data (street/city/state/etc.). Either or both types of location data (street, city, state, etc.). Either or both types
location information may be present in a single LO (see the of location information may be present in a single LO (see the
considerations in [5] for LOs containing multiple locations). considerations in [5] for LOs containing multiple locations).
Location Objects typically include some sort of identifier Location Objects typically include some sort of identifier of the
associated with the Target. Target.
Privacy Rule: A directive that regulates an entity's activities Privacy Rule: A directive that regulates an entity's activities
with respect to location information, including the collection, with respect to location information, including the collection,
use, disclosure, and retention of the location information. use, disclosure, and retention of the location information.
Privacy Rules describe which entities may obtain location Privacy Rules describe which entities may obtain location
information in what form (access control rules) and how location information in what form (access control rules) and how location
information may be used by an entity (usage rules). information may be used by an entity (usage rules).
The whole example, using Geopriv roles and formats, is illustrated in The whole example, using Geopriv roles and formats, is illustrated in
the following figure: the following figure:
skipping to change at page 13, line 32 skipping to change at page 12, line 39
|Device |--------------->| LR |---------------+---->| LR | |Device |--------------->| LR |---------------+---->| LR |
| RM | LO | LS | LO | +----+ | RM | LO | LS | LO | +----+
| LS | +----+ | | LS | +----+ |
+-------+ | +-------+ |
| +----+ | +----+
+---->| LR | +---->| LR |
+----+ +----+
Figure 2: Basic Geopriv Scenario Figure 2: Basic Geopriv Scenario
4. The Location Life-Cycle 4. The Location Life Cycle
The previous section gave an example of how an individual's location The previous section gave an example of how an individual's location
can be distributed through the Internet. In general, the location can be distributed through the Internet. In general, the location
life-cycle breaks down into three phases: life cycle breaks down into three phases:
1. Positioning: A Location Generator determines the Device's 1. Positioning: A Location Generator determines the Device's
location. location.
2. Distribution: Location Servers send location to Location 2. Distribution: Location Servers send location information to
Recipients, which may in turn act as Location Servers and further Location Recipients, which may in turn act as Location Servers
distribute location to other Location Recipients (possibly and further distribute the location to other Location Recipients,
several times). possibly several times.
3. Use: A Location Recipient receives the location and uses it. 3. Use: A Location Recipient receives the location and uses it.
Each of these phases involves a different set of Geopriv roles and Each of these phases involves a different set of Geopriv roles, and
each has a different set of privacy and security implications. The each has a different set of privacy and security implications. The
Geopriv roles are mapped onto the location life-cycle in the figure Geopriv roles are mapped onto the location life cycle in the figure
below. below.
+----------+ +----------+ +----------+
| | | Rule |+ | Rule |+
| Device | | Maker(s)|| | Maker(s)||
| | | || Positioning | ||
+----------+ +----------+| Data +----------+|
^| +----------+ | +----------+
|| Positioning | Rules | | Rules
|| Data | | |
|| | | |
|V V V V
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
|Location | Location | Location |+ LO |Location | |Location | Location | Location |+ LO |Location |
|Generator |--------------->| Server(s)||-------------->|Recipient | |Generator |--------------->| Server(s)||-------------->|Recipient |
| | | || | | | | | || | |
+----------+ +----------+| +----------+ +----------+ +----------+| +----------+
+----------+ +----------+
<-------------------------><---------------------------><-----------> <-------------------------><---------------------------><----------->
Positioning Distribution Use Positioning Distribution Use
Figure 3: Location Life-Cycle Figure 3: Location Life Cycle
4.1. Positioning 4.1. Positioning
Positioning is the process by which the physical location of the Positioning is the process by which the physical location of the
Device is computed, based on some observations about the Device's Device is computed, based on some observations about the Device's
situation in the physical world. (This process goes by several other situation in the physical world. (This process goes by several other
names, including Location Determination or Sighting.) The input to names, including Location Determination or Sighting.) The input to
the positioning process is some information about the Device, and the the positioning process is some information about the Device, and the
outcome is that the LG knows the location of the Device. outcome is that the LG knows the location of the Device.
skipping to change at page 15, line 4 skipping to change at page 14, line 17
While the specific positioning mechanisms that can be applied for a While the specific positioning mechanisms that can be applied for a
given Device are strongly dependent on the physical situation and given Device are strongly dependent on the physical situation and
capabilities of the Device, these mechanisms generally fall into the capabilities of the Device, these mechanisms generally fall into the
three categories described in detail below: three categories described in detail below:
o Device-based o Device-based
o Network-based o Network-based
o Network-assisted o Network-assisted
As suggested by the above names, a positioning scheme can rely on the As suggested by the above names, a positioning scheme can rely on the
Device, an Internet-accessible resource (not necessarily a network Device, an Internet-accessible resource (not necessarily a network
operator), or a combination of the two. For a given scheme, the operator), or a combination of the two. For a given scheme, the
nature of this reliance will dictate the protocol mechanisms needed nature of this reliance will dictate the protocol mechanisms needed
to support it. to support it.
With Device-based positioning mechanisms, the Device is capable of With Device-based positioning mechanisms, the Device is capable of
determining its location by itself. This is the case for manually- determining its location by itself. This is the case for a manually
entered location or for (unassisted) satellite-based positioning entered location or for (unassisted) satellite-based positioning
(using a Global Navigation Satellite System, or GNSS). In these using a Global Navigation Satellite System (GNSS). In these cases,
cases, the Device acts as its own LG, and there are no protocols the Device acts as its own LG, and there are no protocols required to
required to support positioning (since no information needs to be support positioning beyond those that transmit the positioning data
communicated). from the satellite to the user.
In network-based positioning schemes, an external LG (an Internet In network-based positioning schemes, an external LG (an Internet
host other than the Device) has access to sufficient information host other than the Device) has access to sufficient information
about the Device, through out-of-band channels, to establish the about the Device, through out-of-band channels, to establish the
position of the Device. The most common examples of this type of LG position of the Device. The most common examples of this type of LG
are entities that have a physical relationship to the Device (such as are entities that have a physical relationship to the Device (such as
ISPs). In wired networks, wiremap-based location is a network-based ISPs). In wired networks, wiremap-based location is a network-based
technique; in wireless networks, timing and signal-strength based technique; in wireless networks, timing and signal-strength-based
techniques that use measurements from base stations are considered to techniques that use measurements from base stations are considered to
be network-based. Large-scale IP-to-geo databases (for example, be network-based. Large-scale IP-to-geo databases (for example,
those based on WHOIS data or latency measurements) are also those based on WHOIS data or latency measurements) are also
considered to be network-based positioning mechanisms. considered to be network-based positioning mechanisms.
For network-based positioning as for Device-based, no protocols are For network-based positioning as for Device-based, no protocols for
strictly necessary to support positioning, since positioning communication between the Device and the LG are strictly necessary to
information is collected outside of the location distribution system support positioning, since positioning information is collected
(at lower layers of the network stack, for example). This does not outside of the location distribution system (at lower layers of the
rule out the use of other Internet protocols (like SNMP) to collect network stack, for example). This does not rule out the use of other
inputs to the positioning process. Rather, since these inputs can Internet protocols (like the Simple Network Management Protocol
only be used by certain LGs to determine location, they are not (SNMP)) to collect inputs to the positioning process. Rather, since
controlled as private information. Network-based positioning often these inputs can only be used by certain LGs to determine location,
provides location to protocols by which the network informs a Device they are not controlled as private information. Network-based
of its own location (these are known as Location Configuration positioning often provides location information to protocols by which
Protocols, see Section 4.2.2 for further discussion). the network informs a Device of its own location. These are known as
Location Configuration Protocols; see Section 4.2.2 for further
discussion.
Network-assisted systems account for the greatest number and Network-assisted systems account for the greatest number and
diversity of positioning schemes. In these systems, the work of diversity of positioning schemes. In these systems, the work of
positioning is divided between the Device and an external LG via some positioning is divided between the Device and an external LG via
communication (possibly over the Internet), typically in one of two some communication (possibly over the Internet), typically in one of
ways: two ways:
o The Device provides measurements to the LG o The Device provides measurements to the LG, or
o The LG provides assistance data to the Device.
o The LG provides assistance data to the Device
"Measurements" are understood to be observations about the Device's "Measurements" are understood to be observations about the Device's
environment, ranging from wireless signal strengths to the MAC environment, ranging from wireless signal strengths to the Media
address of a first-hop router. "Assistance" is the complement to Access Control (MAC) address of a first-hop router. "Assistance" is
measurement, namely the positioning information that enables the the complement to measurement, namely the positioning information
computation of location based on measurements. A set of wireless that enables the computation of location based on measurements. A
base station locations (or wireless calibration information) would be set of wireless base station locations (or wireless calibration
an assistance datum, as would be a table that maps routers to information) would be an assistance datum, as would be a table that
buildings in a corporate campus. maps routers to buildings in a corporate campus.
For example, wireless and wired networks can serve as the basis for For example, wireless and wired networks can serve as the basis for
network-assisted positioning. In several current 802.11 positioning network-assisted positioning. In several current 802.11 positioning
systems, the Device sends measurements (e.g., MAC addresses and systems, the Device sends measurements (e.g., MAC addresses and
signal strengths) to an LG, and the LG returns a location to the signal strengths) to an LG, and the LG returns a location to the
client. In wired networks, the Device can send its MAC address to client. In wired networks, the Device can send its MAC address to
the LG, which can query the MAC-layer infrastructure to determine the the LG, which can query the MAC-layer infrastructure to determine the
switch and port to which that MAC address is connected, then query a switch and port to which that MAC address is connected, then query a
wire map to determine the location at which the wire connected to wire map to determine the location at which the wire connected to
that port terminates. that port terminates.
As an aside, the common phrase "assisted GPS" ("assisted GNSS" more As an aside, the common phrase "assisted GPS" ("assisted GNSS" more
broadly) actually encompasses techniques that transmit both broadly) actually encompasses techniques that transmit both
measurements and assistance data. Systems in which the Device measurements and assistance data. Systems in which the Device
provides the LG with GNSS measurements are measurement-based, while provides the LG with GNSS measurements are measurement-based, while
those in which the assistance server provide ephemeris or alamanac those in which the assistance server provides ephemeris or almanac
data are assistance-based in the above terminology. (Those familiar data are assistance-based in the above terminology. (Those familiar
with GNSS positioning will note that there are of course cases in with GNSS positioning will note that there are of course cases in
which both of these interactions occur within a single location which both of these interactions occur within a single location
determination protocol, so the categories are not mutually determination protocol, so the categories are not mutually
exclusive.) exclusive.)
Naturally, the exchange of measurement or positioning data between Naturally, the exchange of measurement or positioning data between
the Device and the LG requires a protocol over which the information the Device and the LG requires a protocol over which the information
is carried. The structure of this protocol will depend on which of is carried. The structure of this protocol will depend on which of
the two patterns a network-assisted scheme follows. Conversely, the the two patterns a network-assisted scheme follows. Conversely, the
structure of the protocol will determine which of the two parties structure of the protocol will determine which of the two parties
(the Device, the LG, or both) is aware of the Device's location at (the Device, the LG, or both) is aware of the Device's location at
the end of the protocol interaction. the end of the protocol interaction.
4.1.2. Privacy Considerations for Positioning 4.1.2. Privacy Considerations for Positioning
Positioning is the first point at which location may be associated Positioning is the first point at which location may be associated
with a particular Target's identity. Local identifiers, unlinked with a particular Device and may be associated with the Target's
pseudonyms, or private identifiers that are not linked to the real identity. Local identifiers, unlinked pseudonyms, or private
identity of the Target should be used as forms of identity whenever identifiers that are not linked to the real identity of the Target
possible. This provides privacy protection by disassociating the should be used as forms of identity whenever possible. This provides
location from the Target's identity before it is distributed. privacy protection by disassociating the location from the Target's
identity before it is distributed.
At the conclusion of the positioning process, the entity acting as At the conclusion of the positioning process, the entity acting as
the LG has the Device's location (if the Device is performing the LG the LG has the Device's location. If the Device is performing the LG
role, then they both have it). If the entity acting as the LG also role, then both the Device and LG have it. If the entity acting as
performs the role of LS, the privacy considerations in Section 4.2.4 the LG also performs the role of LS, the privacy considerations in
apply. Section 4.2.4 apply.
In some deployment scenarios, positioning functions and distribution In some deployment scenarios, positioning functions and distribution
functions may need to be provided by separate entities, in which case functions may need to be provided by separate entities, in which case
the LG and LS roles will not be performed by the same entity. In the LG and LS roles will not be performed by the same entity. In
this situation, the LG acts as a "dumb," non-privacy-aware this situation, the LG acts as a "dumb", non-privacy-aware
positioning resource, and the LS provides the privacy logic necessary positioning resource, and the LS provides the privacy logic necessary
to support distribution (possibly with multiple LSes using the same to support distribution (possibly with multiple LSes using the same
LG). In order to allow the privacy-unaware LG to distribute location LG). In order to allow the privacy-unaware LG to distribute location
to these LSes while maintaining privacy, the relationship between the information to these LSes while maintaining privacy, the relationship
LG and its set of LSes MUST be tightly constrained, effectively between the LG and its set of LSes MUST be tightly constrained
"hard-wired." That is, the LG MUST only provide location to a small (effectively "hard-wired"). That is, the LG MUST only provide
fixed set of LSes, and each of these LSes MUST comply with the location information to a small fixed set of LSes, and each of these
requirements of Section 4.2.4. LSes MUST comply with the requirements of Section 4.2.4.
4.1.3. Security Considerations for Positioning 4.1.3. Security Considerations for Positioning
Manipulation of the positioning process can expose location through Manipulation of the positioning process can expose location
two mechanisms: information through two mechanisms:
1) A third party could guess or derive measurements about a specific 1) A third party could guess or derive measurements about a specific
device and use them to get the location of that Device. To mitigate device and use them to get the location of that Device. To mitigate
this risk, the LG SHOULD be able to authenticate and authorize this risk, the LG SHOULD be able to authenticate and authorize
devices providing measurements and, if possible, verify that the devices providing measurements and, if possible, verify that the
presented measurements are likely to be the actual physical values presented measurements are likely to be the actual physical values
measured by that client. These security procedures rely on the type measured by that client. These security procedures rely on the type
of positioning being done, and may not be technically feasible in all of positioning being done, and may not be technically feasible in all
cases. cases.
skipping to change at page 17, line 48 skipping to change at page 17, line 17
Device. To mitigate this risk, protocols used for positioning MUST Device. To mitigate this risk, protocols used for positioning MUST
provide confidentiality and integrity protections in order to prevent provide confidentiality and integrity protections in order to prevent
observation and modification of transmitted positioning data while en observation and modification of transmitted positioning data while en
route between the Target and the LG. route between the Target and the LG.
If an LG or a Target chooses to act as an LS, it inherits the If an LG or a Target chooses to act as an LS, it inherits the
security requirements for an LS, described in Section 4.2.5. security requirements for an LS, described in Section 4.2.5.
4.2. Location Distribution 4.2. Location Distribution
When an entity receives location (from an LG or an LS) and When an entity receives location information (from an LG or an LS)
redistributes it to other entities, it acts as an LS. Location and redistributes it to other entities, it acts as an LS. Location
Distribution is the process by which one or more LSes provide LOs to Distribution is the process by which one or more LSes provide LOs to
LRs in a privacy-preserving manner. LRs in a privacy-preserving manner.
The role of an LS is thus two-fold: First, it must collect location The role of an LS is thus two-fold: First, it must collect location
information and Rules that control access to that information. Rules information and Rules that control access to that information. Rules
can be communicated within an LO, within a protocol that carries LOs, can be communicated within an LO, within a protocol that carries LOs,
or through a separate protocol that carries Rules. Second, the LS or through a separate protocol that carries Rules. Second, the LS
must process requests for location and apply the Rules to these must process requests for location information and apply the Rules to
requests in order to determine whether it is authorized to fulfill these requests in order to determine whether it is authorized to
them by returning location. fulfill them by returning location information.
An LS thus has at least two types of interactions with other hosts, An LS thus has at least two types of interactions with other hosts,
namely receiving and sending LOs. An LS may optionally implement a namely receiving and sending LOs. An LS may optionally implement a
third interaction, allowing Rule Makers to provision it with Rules. third interaction, allowing Rule Makers to provision it with Rules.
The distinction between these two cases is important in practice, The distinction between these two cases is important in practice,
because it determines whether the LS has a direct relationship with a because it determines whether the LS has a direct relationship with a
Rule Maker: An LS that accepts Rules directly from a Rule Maker has Rule Maker: An LS that accepts Rules directly from a Rule Maker has
such a relationship, while an LS that acquires all its Rules through such a relationship, while an LS that acquires all its Rules through
LOs does not. LOs does not.
4.2.1. Privacy Rules 4.2.1. Privacy Rules
Privacy Rules are the central mechanism in Geopriv for maintaining a Privacy Rules are the central mechanism in Geopriv for maintaining a
Target's privacy, because they provide a recipient of an LO (an LS or Target's privacy, because they provide a recipient of an LO (an LS or
LR) with information on how the LO may be used. LR) with information on how the LO may be used.
Throughout the Geopriv architecture, Privacy Rules are communicated Throughout the Geopriv architecture, Privacy Rules are communicated
in rules languages with a defined syntax and semantics. For example, in rules languages with a defined syntax and semantics. For example,
the Common Policy rules language has been defined [6] to provide a the Common Policy rules language has been defined [6] to provide a
framework for broad-based rule specifications. Geopriv Policy [7] framework for broad-based rule specifications. Geopriv Policy [7]
defines a language for creating location-specific rules. XCAP [8] defines a language for creating location-specific rules. The XML
can be used as a protocol to install rules in both of these formats. Configuration Access Protocol (XCAP) [8] can be used as a protocol to
install rules in both of these formats.
Privacy Rules follow a default-deny pattern: an empty set of Rules Privacy Rules follow a default-deny pattern: an empty set of Rules
implies that all requests for location should be denied (other than implies that all requests for location information should be denied,
requests made by the Target itself), with each Rule added to the set except requests made by the Target itself. Each Rule adds to the
granting a specific permission. Adding a Rule can only augment set, granting a specific permission. Adding a Rule can only augment
privacy protections because all Rules are positive grants of privacy protections because all Rules are positive grants of
permission. permission.
The following are examples of Privacy Rules governing location The following are examples of Privacy Rules governing location
distribution: distribution:
o Retransmit location when requested from example.com o Retransmit location information when requested from example.com.
o Retransmit only city and country o Retransmit only city and country.
o Retransmit location with no less than a 100 meter radius of o Retransmit location information with no less than a 100-meter
uncertainty radius of uncertainty.
o Retransmit location only for the next two weeks o Retransmit location information only for the next two weeks.
LSes enforce Privacy Rules in two ways: by denying requests for LSes enforce Privacy Rules in two ways: by denying requests for
location, or by transforming the location information before location information, or by transforming the location information
retransmitting it. before retransmitting it.
LSes may also receive Rules governing location retention, such as LSes may also receive Rules governing location retention, such as
"Retain location only for 48 hours." Such Rules are simply "Retain location only for 48 hours". Such Rules are simply
directives about how long the Target's location information can be directives about how long the Target's location information can be
retained. retained.
Privacy Rules can govern the behavior of both LSes and LRs. Rules Privacy Rules can govern the behavior of both LSes and LRs. Rules
that direct LSes about how to treat a Target's location information that direct LSes about how to treat a Target's location information
are known as Local Rules. Local Rules are used internally by the LS are known as Local Rules. Local Rules are used internally by the LS
to handle requests from LRs. They are not distributed to LRs. to handle requests from LRs. They are not distributed to LRs.
Forwarded Rules, on the other hand, travel inside LOs and direct LSes Forwarded Rules, on the other hand, travel inside LOs and direct LSes
and LRs about how to handle the location information they receive. and LRs about how to handle the location information they receive.
Because the Rules themselves may reveal potentially sensitive Because the Rules themselves may reveal potentially sensitive
information about the Target, only the minimal subset of Forwarded information about the Target, only the minimal subset of Forwarded
Rules necessary to handle the LO is distributed. Rules necessary to handle the LO is distributed.
An example can illustrate the interaction between Local Rules and An example can illustrate the interaction between Local Rules and
Forwarded Rules. Suppose Alice provides the following Local Rules to Forwarded Rules. Suppose Alice provides the following Local Rules to
an LS: an LS:
o The LS may retransmit Alice's precise location to Bob, who in turn o The LS may retransmit Alice's precise location to Bob, who in turn
is permitted to retain the location information for one month is permitted to retain the location information for one month.
o The LS may retransmit Alice's city, state, and country to Steve, o The LS may retransmit Alice's city, state, and country to Steve,
who in turn is permitted to retain the location information for who in turn is permitted to retain the location information for
one hour one hour.
o The LS may retransmit Alice's country to a photo-sharing website, o The LS may retransmit Alice's country to a photo-sharing Web site,
which in turn is permitted to retain the location information for which in turn is permitted to retain the location information for
one year and retransmit it to any requesters one year and retransmit it to any requesters.
When Steve asks for Alice's location, the LS can transmit to Steve When Steve asks for Alice's location, the LS can transmit to Steve
the limited location information (city, state, and country) along the limited location information (city, state, and country) along
with Forwarded Rules instructing Steve to (a) not further retransmit with Forwarded Rules instructing Steve to (a) not further retransmit
Alice's location information, and (b) only retain the location Alice's location information, and (b) only retain the location
information for one hour. By only sending these specifically information for one hour. By only sending these specifically
applicable Forwarded Rules to Steve (as opposed to the full set of applicable Forwarded Rules to Steve (as opposed to the full set of
Local Rules), the LS is protecting Alice's privacy by not disclosing Local Rules), the LS is protecting Alice's privacy by not disclosing
to Steve that (for example) Alice allows Bob to obtain more precise to Steve that (for example) Alice allows Bob to obtain more precise
location information than Alice allows Steve to receive. location information than Alice allows Steve to receive.
Geopriv is designed to be usable even by devices with constrained Geopriv is designed to be usable even by devices with constrained
processing capabilities. To ensure that Forwarded Rules can be processing capabilities. To ensure that Forwarded Rules can be
processed on constrained devices, LOs are required to carry only a processed on constrained devices, LOs are required to carry only a
limited set of Forwarded Rules, with an option to reference a more limited set of Forwarded Rules, with an option to reference a more
robust set of external Rules. The limited Rule set covers two robust set of external Rules. The limited Rule set covers two
privacy aspects: how long the Target's location may be retained privacy aspects: how long the Target's location may be retained
("Retention"), and whether or not the Target's location may be ("Retention"), and whether or not the Target's location may be
retransmitted ("Retransmission"). A LO may contain a pointer to more retransmitted ("Retransmission"). An LO may contain a pointer to
robust Rules, such as those shown in the set of four Rules at the more robust Rules, such as those shown in the set of four Rules at
beginning of this section. the beginning of this section.
4.2.2. Location Configuration 4.2.2. Location Configuration
Some entities performing the LG role are designed only to provide Some entities performing the LG role are designed only to provide
Targets with their own locations (as opposed to distributing a Targets with their own locations, as opposed to distributing a
Target's location to others). The process of providing a Target with Target's location to others. The process of providing a Target with
its own location is known within Geopriv as Location Configuration. its own location is known within Geopriv as Location Configuration.
The term Location Information Server (LIS) is often used to describe The term "Location Information Server" (LIS) is often used to
the entity that performs this function (although a LIS may also describe the entity that performs this function. However, a LIS may
perform other functions, such as providing a Target's location to also perform other functions, such as providing a Target's location
other entities). to other entities.
A Location Configuration Protocol (LCP) [9] is one mechanism that can A Location Configuration Protocol (LCP) [9] is one mechanism that can
be used by a Device to discover its own location from a LIS. LCPs be used by a Device to discover its own location from a LIS. LCPs
provide functions in the way they obtain, transport and deliver provide functions in the way they obtain, transport, and deliver
location requests and responses between a LIS and a Device such that location requests and responses between a LIS and a Device such that
the LIS can trust that the location requests and responses handled the LIS can trust that the location requests and responses handled
via the LCP are in fact from/to the Target. Several LCPs have been via the LCP are in fact from/to the Target. Several LCPs have been
developed within Geopriv [10][11][12][13]. developed within Geopriv [10] [11] [12] [13].
A LIS whose sole purpose is to perform Location Configuration need A LIS whose sole purpose is to perform Location Configuration need
only follow a simple privacy-preserving policy: transmit a Target's only follow a simple privacy-preserving policy: transmit a Target's
location only to the Target itself. This is known as the "LCP location only to the Target itself. This is known as the "LCP
policy." policy".
Importantly, if an LS is also serving in the role of LG and it has Importantly, if an LS is also serving in the role of LG and it has
not been provisioned with Privacy Rules for a particular Target, it not been provisioned with Privacy Rules for a particular Target, it
MUST follow the LCP policy, whether it is a LIS or not. In the MUST follow the LCP policy, whether it is a LIS or not. In the
positioning phase, an entity serving the roles of both LG and LS that positioning phase, an entity serving the roles of both LG and LS that
has not received Privacy Rules must follow this policy. The same is has not received Privacy Rules must follow this policy. The same is
true for any LS in the distribution phase. true for any LS in the distribution phase.
4.2.3. Location References 4.2.3. Location References
The location distribution process occurs through a series of The location distribution process occurs through a series of
transmissions of LOs: transmissions of location "by value." Location transmissions of LOs: transmissions of location "by value". Location
"by value" can be expressed in terms of geodetic location data "by value" can be expressed in terms of geodetic location data
(latitude/longitude/altitude/etc.) and civic location data (street/ (latitude, longitude, altitude, etc.) and civic location data
city/state/etc.). (street, city, state, etc.).
Location can also be distributed "by reference," where a reference is A location can also be distributed "by reference", where a reference
represented by a URI that can be dereferenced to obtain the LO. This is represented by a URI that can be dereferenced to obtain the LO.
document summarizes the properties of location-by-reference that are This document summarizes the properties of location-by-reference that
discussed at length in [14]. are discussed at length in [14].
Distribution of location by reference (distribution of location URIs) Distribution of location-by-reference (distribution of location URIs)
offer several benefits. Location URIs are a more compact way of offers several benefits. Location URIs are a more compact way of
transmitting location, since URIs are usually smaller than LOs. A transmitting location information, since URIs are usually smaller
recipient of location can make multiple requests to a URI over time than LOs. A recipient of location information can make multiple
to receive updated location (if the URI is configured to provide requests to a URI over time to receive updated location information
fresh location rather than a single "snapshot"). if the URI is configured to provide a fresh location rather than a
single "snapshot".
From a positioning perspective, location by reference can offer the From a positioning perspective, location-by-reference can offer the
additional benefit of "just in time" positioning. If location is additional benefit of "just in time" positioning. If a location is
distributed by reference, an entity acting as a combined LG/LS only distributed by reference, an entity acting as a combined LG/LS only
needs to perform positioning operations when a recipient dereferences needs to perform positioning operations when a recipient dereferences
a previously distributed URI. a previously distributed URI.
From a privacy perspective, distributing location as a URI instead of From a privacy perspective, distributing a location as a URI instead
as an LO can help protect privacy by forcing each recipient of the of as an LO can help protect privacy by forcing each recipient of the
location to request location from the referenced LS, which can then location to request location information from the referenced LS,
apply access controls individually to each recipient. But the which can then apply access controls individually to each recipient.
benefit provided here is contingent on the LS applying access But the benefit provided here is contingent on the LS applying access
controls. If the LS does not apply an access control policy to controls. If the LS does not apply an access control policy to
requests for a location URI (in other words, if it enforces the requests for a location URI (in other words, if it enforces the
"possession model" defined in [14]), then transmitting a location URI "possession model" defined in [14]), then transmitting a location URI
presents the same privacy risks as transmitting the LO itself. presents the same privacy risks as transmitting the LO itself.
Moreover, the use of location URIs without access controls can Moreover, the use of location URIs without access controls can
introduce additional privacy risks: If URIs predictable, an attacker introduce additional privacy risks: If URIs are predictable, an
to whom the URI has not been sent may be able to guess the URI and attacker to whom the URI has not been sent may be able to guess the
use it to obtain the referenced LO. To mitigate this, location URIs URI and use it to obtain the referenced LO. To mitigate this,
without access controls need to be constructed so that they contain a location URIs without access controls need to be constructed so that
random component with sufficient entropy to make guessing infeasible. they contain a random component with sufficient entropy to make
guessing infeasible.
4.2.4. Privacy Considerations for Distribution 4.2.4. Privacy Considerations for Distribution
Location information MUST be accompanied by Rules throughout the Location information MUST be accompanied by Rules throughout the
distribution process. Otherwise, a recipient will not know what uses distribution process. Otherwise, a recipient will not know what uses
are authorized, and will not be able to use the LO. Consequently, are authorized, and will not be able to use the LO. Consequently,
LOs MUST be able to express Rules that convey appropriate LOs MUST be able to express Rules that convey appropriate
authorizations. authorizations.
An LS MUST only accept Rules from authorized Rule Makers. For an LS An LS MUST only accept Rules from authorized Rule Makers. For an LS
skipping to change at page 22, line 13 skipping to change at page 21, line 45
LS MUST be configurable with an RM authorization policy. An LS LS MUST be configurable with an RM authorization policy. An LS
SHOULD define a prescribed set of RMs that may provide Rules for a SHOULD define a prescribed set of RMs that may provide Rules for a
given Target or LO. For example, an LS may only allow the Target to given Target or LO. For example, an LS may only allow the Target to
set Rules for itself, or it might allow an RM to set Rules for set Rules for itself, or it might allow an RM to set Rules for
several Targets (e.g., a parent for children, or a corporate security several Targets (e.g., a parent for children, or a corporate security
officer for employees). officer for employees).
No matter how Rules are provided to an LS, for each LO it receives, No matter how Rules are provided to an LS, for each LO it receives,
it MUST combine all Rules that apply to the LO into a Rule set that it MUST combine all Rules that apply to the LO into a Rule set that
defines which transmissions are authorized, and it MUST transmit defines which transmissions are authorized, and it MUST transmit
location only in ways that are authorized by these Rules. location information only in ways that are authorized by these Rules.
An LS that receives Rules exclusively through LOs MUST examine the An LS that receives Rules exclusively through LOs MUST examine the
Rules that accompany a given LO in order to determine how the LS may Rules that accompany a given LO in order to determine how the LS may
use the LO (if any Rules are included by reference, the LS SHOULD use the LO. If any Rules are included by reference, the LS SHOULD
attempt to download them). If the LO includes no Rules that allow attempt to download them. If the LO includes no Rules that allow the
the LS to transmit the LO to another entity, then the LS MUST NOT LS to transmit the LO to another entity, then the LS MUST NOT
transmit the LO. If the LO contains no Rules at all (if it is in a transmit the LO. If the LO contains no Rules at all -- for example,
format with no Rules syntax, for example), then the LS MUST delete it if it is in a format with no Rules syntax -- then the LS MUST delete
(emergency services provide an exception in that Rules can be implicit, it. Emergency services provide an exception in that Rules can be
see [15]). If the LO included Rules by reference, but these Rules implicit; see [15]). If the LO included Rules by reference, but
were not obtained for any reason, the LS MUST NOT transmit the LO and these Rules were not obtained for any reason, the LS MUST NOT
MUST delete it. transmit the LO and MUST adhere to the provided value in the
retention-expires field.
An LS that receives Rules both directly from one or more Rule Makers An LS that receives Rules both directly from one or more Rule Makers
and through LOs MUST combine the Rules in a given LO with Rules it and through LOs MUST combine the Rules in a given LO with Rules it
has received from the RMs. The strategy the LS uses to combine these has received from the RMs. The strategy the LS uses to combine these
sets of Rules is a matter for local policy, depending on the relative sets of Rules is a matter for local policy, depending on the relative
priority that the LS grants to each source of Rules. Some example priority that the LS grants to each source of Rules. Some example
policies: policies are:
Union: A transmission of location is authorized if it is authorized Union: A transmission of location information is authorized if it
by either a rule in the LO or an RM-provided rule. is authorized by either a rule in the LO or an RM-provided rule.
Intersection: A transmission of location is authorized if it is Intersection: A transmission of location information is authorized
authorized by both a rule in the LO and an RM-provided rule. if it is authorized by both a rule in the LO and an RM-provided
rule.
RM Override: A transmission of location is authorized if it is RM Override: A transmission of location information is authorized
authorized by an RM-provided rule (regardless of the LO Rules). if it is authorized by an RM-provided rule, regardless of the LO
Rules.
LO Override: A transmission of location is authorized if it is LO Override: A transmission of location information is authorized
authorized by an LO-provided rule (regardless of the RM Rules). if it is authorized by an LO-provided rule, regardless of the RM
Rules.
The default combination policy for an LS that receives multiple rule
sets is to combine them according to procedures in Section 10 of
RFC 4745 [6]. Privacy rules always grant access; i.e., the default
is to deny access, and rules specify conditions under which access is
allowed. Thus, when an LS is provided more than one policy document
that applies to a given LO, it has been instructed to provide access
when any of the rules apply. That is, the "Union" policy is the
default policy for an LS with multiple sources of policy. An LS MAY
choose to apply a more restrictive policy by ignoring some of the
grants of permission in the privacy rules provided. The
"Intersection" policy and both "Override" policies listed above are
of this latter character.
Protocols that are used for managing rules should allow an RM to
retrieve from the LS the set of rules that will ultimately be
applied. For example, in the basic HTTP-based protocol defined in
[16], an RM can use a GET request to retrieve the policy being
applied by the LS and a PUT request to specify new rules.
Different policies may be applicable in different scenarios. In Different policies may be applicable in different scenarios. In
cases where an external RM is more trusted than the source of the LO, cases where an external RM is more trusted than the source of the LO,
the "RM Override" policy may be suitable (for example, if the the "RM Override" policy may be suitable (for example, if the
external RM is the Target, and the LO is provided by a third party). external RM is the Target and the LO is provided by a third party).
Conversely, the "LO Override" policy is better suited to cases where Conversely, the "LO Override" policy is better suited to cases where
the LO provider is more trused than the RM (for example, if the RM is the LO provider is more trusted than the RM, for example, if the RM
the user of a mobile device LS and the LO contains Rules from the is the user of a mobile device LS and the LO contains Rules from the
RM's parents or corporate security office). The "Intersection" RM's parents or corporate security office. The "Intersection" policy
policy takes the strictest view of the permission grants, giving takes the strictest view of the permission grants, giving equal
equal weight to all RMs (including the LO creator). weight to all RMs (including the LO creator).
Each of these policies will also have different privacy consequences. Each of these policies will also have different privacy consequences.
Following the "Intersection" policy ensures that the most privacy- Following the "Intersection" policy ensures that the most privacy-
protective subset of all RMs' rules will be followed. The "Union" protective subset of all RMs' rules will be followed. The "Union"
policy and both "Override" policies may defy the expectations of any policy and both "Override" policies may defy the expectations of any
RM (including, potentially, the Target) whose policy is not followed. RM (including, potentially, the Target) whose policy is not followed.
For example, if a Target acting as an RM sets Rules and those Rules For example, if a Target acting as an RM sets Rules and those Rules
are overridden by the application of a more permissive LO Override are overridden by the application of a more permissive LO Override
policy that has been set by the Target's parent or employer acting as policy that has been set by the Target's parent or employer acting as
an RM, the retransmission or retention of the Target's data may come an RM, the retransmission or retention of the Target's data may come
as a surprise to the Target. For this reason, it is RECOMMENDED that as a surprise to the Target. For this reason, it is RECOMMENDED that
LSes provide a way for RMs to be able to find out which policy will LSes provide a way for RMs to be able to find out which policy will
be applied to the distribution of a given LO. be applied to the distribution of a given LO.
4.2.5. Security Considerations for Distribution 4.2.5. Security Considerations for Distribution
An LS's decisions about how to transmit location are based on the An LS's decisions about how to transmit a location are based on the
identities of entities requesting information and other aspects of identities of entities requesting information and other aspects of
requests for location. In order to ensure that these decisions are requests for a location. In order to ensure that these decisions are
made properly, the LS needs assurance of the reliability of made properly, the LS needs assurance of the reliability of
information on the identities of the entities with which the LS information on the identities of the entities with which the LS
interacts (including LRs, LSes, and RMs) and other information in the interacts (including LRs, LSes, and RMs) and other information in the
request. request.
Protocols to convey LOs and protocols to convey Rules MUST provide Protocols to convey LOs and protocols to convey Rules MUST provide
information on the identity of the recipient of location and the information on the identity of the recipient of location information
identity of the RM, respectively. In order to ensure the validity of and the identity of the RM, respectively. In order to ensure the
this information, these protocols MUST allow for mutual validity of this information, these protocols MUST allow for mutual
authentication of both parties, and MUST provide integrity protection authentication of both parties, and MUST provide integrity protection
for protocol messages. These security features ensure that the LG for protocol messages. These security features ensure that the LG
has sufficient information (and sufficiently reliable information) to has sufficient information (and sufficiently reliable information) to
make privacy decisions. make privacy decisions.
As they travel through the Internet, LOs necessarily pass through a As they travel through the Internet, LOs necessarily pass through a
sequence of intermediaries, ranging from layer-2 switches to IP sequence of intermediaries, ranging from layer-2 switches to IP
routers to application-layer proxies and gateways. The ability of an routers to application-layer proxies and gateways. The ability of an
LS to protect privacy by making access control decisions is reduced LS to protect privacy by making access control decisions is reduced
if these intermediaries have access to an LO as it travels between if these intermediaries have access to an LO as it travels between
privacy-preserving entities. privacy-preserving entities.
Ideally, LOs SHOULD be transmitted with confidentiality protection Ideally, LOs SHOULD be transmitted with confidentiality protection
end-to-end between an LS that transmits location and the LR that end-to-end between an LS that transmits location information and the
receives it. In some cases, the protocol conveying an LO provides LR that receives it. In some cases, the protocol conveying an LO
confidentiality protection as a built-in security solution for its provides confidentiality protection as a built-in security solution
signaling (and potentially its data traffic). In this case, carrying for its signaling (and potentially its data traffic). In this case,
an unprotected LOs within such an encrypted channel is sufficient. carrying an unprotected LO within such an encrypted channel is
Many protocols, however, are offering communication modes where sufficient. Many protocols, however, are offering communication
messages are either unprotected or protected on a hop-by-hop basis modes where messages are either unprotected or protected on a hop-by-
(for example, between intermediaries in a store-and-forward hop basis (for example, between intermediaries in a store-and-forward
protocol). In such a case it is RECOMMENDED that the protocol allows protocol). In such a case, it is RECOMMENDED that the protocol allow
for the use of encrypted LOs, or for the transmission of a reference for the use of encrypted LOs, or for the transmission of a reference
to location in place of an LO [14]. to a location in place of an LO [14].
4.3. Location Use 4.3. Location Use
The primary privacy requirement of an LR is to constrain its usage of The primary privacy requirement of an LR is to constrain its usage of
location to the set of uses authorized by the Rules in an LO. If an location information to the set of uses authorized by the Rules in an
LR only uses an LO in ways that have minimal privacy impact -- LO. If an LR only uses an LO in ways that have minimal privacy
specifically, if it does not transmit the LO to any other entity, and impact -- specifically, if it does not transmit the LO to any other
does not retain the LO for longer than is required to complete its entity, and does not retain the LO for longer than is required to
interaction with the LS -- then no further action is necessary for complete its interaction with the LS -- then no further action is
the LR to comply with Geopriv requirements. necessary for the LR to comply with Geopriv requirements.
As an example of this simplest case, if an LR (a) receives a As an example of this simplest case, if an LR (a) receives a
location, (b) immediately provides to the Target information or a location, (b) immediately provides to the Target information or a
service based on the location, (c) does not retain the information, service based on the location, (c) does not retain the information,
and (d) does not retransmit the location to any other entity, then and (d) does not retransmit the location to any other entity, then
the LR will comply with any set of Rules that are permissible under the LR will comply with any set of Rules that are permissible under
Geopriv. Thus, a service that, for example, only provides directions Geopriv. Thus, a service that, for example, only provides directions
to the closest bookstore in response to an input of location, and to the closest bookstore in response to an input of a location, and
promptly then discards the input location, will be in compliance with promptly then discards the input location, will be in compliance with
any Geopriv Rule set. any Geopriv Rule set.
LRs that make other uses of an LO (e.g., those that store LOs, or LRs that make other uses of an LO (e.g., those that store LOs or send
send them to other service providers to obtain location-based them to other service providers to obtain location-based services)
services) MUST meet the requirements below to assure that these uses MUST meet the requirements below to assure that these uses are
are authorized. authorized.
4.3.1. Privacy Considerations for Use 4.3.1. Privacy Considerations for Use
The principal privacy requirement for LRs is to follow usage rules. The principal privacy requirement for LRs is to follow usage rules.
Any LR that wants to retransmit or retain the LO is REQUIRED to Any LR that wants to retransmit or retain the LO is REQUIRED to
examine the rules included with that LO. Any usage the LR makes of examine the rules included with that LO. Any usage the LR makes of
the LO MUST be explicitly authorized by these Rules. Since Rules are the LO MUST be explicitly authorized by these Rules. Since Rules are
positive grants of permission, any action not explicitly authorized positive grants of permission, any action not explicitly authorized
is denied by default. is denied by default.
4.3.2. Security Considerations for Use 4.3.2. Security Considerations for Use
Since the LR role does not involve transmission of location, there Since the LR role does not involve transmission of location
are no protocol security considerations required to support privacy information, there are no protocol security considerations required
(other than ensuring that data does not leak unintentionally caused to support privacy, other than ensuring that data does not leak
by security breaches). unintentionally due to security breaches.
Aside from privacy, LRs often require some assurance that an LO is Aside from privacy, LRs often require some assurance that an LO is
reliable (assurance of the integrity, authenticity, and validity of reliable (assurance of the integrity, authenticity, and validity of
an LO), since LRs use LOs in order to deliver location-based an LO), since LRs use LOs in order to deliver location-based
services. Threats against this reliability and corresponding services. Threats against this reliability, and corresponding
mitigations are discussed in the Security Considerations below. mitigations, are discussed in "Security Considerations" below.
5. Security Considerations 5. Security Considerations
Security considerations related to the privacy of LOs are discussed Security considerations related to the privacy of LOs are discussed
throughout this document. In this section we summarize those throughout this document. In this section, we summarize those
concerns and consider security risks not related to privacy. concerns and consider security risks not related to privacy.
The life-cycle of an LO often consists of a series of location The life cycle of an LO often consists of a series of location
transmissions. Protocols that carry location can provide strong transmissions. Protocols that carry location information can provide
assurances, but only for a single segment of the LO's life cycle. In strong assurances, but only for a single segment of the LO's life
particular, a protocol can provide integrity protection and cycle. In particular, a protocol can provide integrity protection
confidentiality for the data exchanged, and mutual authentication of and confidentiality for the data exchanged, and mutual authentication
the parties involved in the protocol, by using a secure transport of the parties involved in the protocol, by using a secure transport
such as IPSec [16] or TLS [17]. such as IPSec [17] or Transport Layer Security (TLS) [18].
Additionally, if (1) the protocol provides mutual authentication for Additionally, if (1) the protocol provides mutual authentication for
every segment, and (2) every entity in the location distribution every segment, and (2) every entity in the location distribution
chain exchanges information only with entities with whom it has a chain exchanges information only with entities with whom it has a
trust relationship, entities can transitively obtain assurances trust relationship, entities can transitively obtain assurances
regarding the origin and ultimate destination of the LO. Of course, regarding the origin and ultimate destination of the LO. Of course,
direct assurances are always preferred over assurances requiring direct assurances are always preferred over assurances requiring
transitive trust, since they require fewer assumptions. transitive trust, since they require fewer assumptions.
Using protocol mechanisms alone, the entities can receive assurances Using protocol mechanisms alone, the entities can receive assurances
only about a single hop in the distribution chain. For example, only about a single hop in the distribution chain. For example,
suppose that an LR receives location from an LS over an integrity- suppose that an LR receives location information from an LS over an
and confidentiality-protected channel. The LR knows that the integrity- and confidentiality-protected channel. The LR knows that
transmitted LO has not been modified or observed en route. However, the transmitted LO has not been modified or observed en route.
the assurances provided by the protocol do not guarantee that the However, the assurances provided by the protocol do not guarantee
transmitted LO was not corrupted before it was sent to the LS (by a that the transmitted LO was not corrupted before it was sent to the
previous LS, for example). Likewise, the LR can verify that the LO LS (by a previous LS, for example). Likewise, the LR can verify that
was transmitted by the LS, but cannot verify the origin of the LO if the LO was transmitted by the LS, but cannot verify the origin of the
it did not originate with the LS. LO if it did not originate with the LS.
Security mechanisms in protocols are thus unable to provide direct Security mechanisms in protocols are thus unable to provide direct
assurances over multiple transmissions of an LO. However, the assurances over multiple transmissions of an LO. However, the
transmission of location "by reference" can be used to effectively transmission of a location "by reference" can be used to effectively
turn multi-hop paths into single-hop paths. If the multiple turn multi-hop paths into single-hop paths. If the multiple
transmissions of an LO are replaced by multiple transmissions of a transmissions of an LO are replaced by multiple transmissions of a
URI (a multi-hop dissemination channel), the LO need only traverse a URI (a multi-hop dissemination channel), the LO need only traverse a
single hop, namely the dereference transaction between the LR and the single hop, namely the dereference transaction between the LR and the
dereference server. The requirements for securing location passed by dereference server. The requirements for securing a location passed
reference [14] are applicable in this case. by reference [14] are applicable in this case.
The major threats to the security of LOs can be grouped into two The major threats to the security of LOs can be grouped into two
categories. First, threats against the integrity and authenticity of categories. First, threats against the integrity and authenticity of
LOs can expose entities that rely on LOs. Second, threats against LOs can expose entities that rely on LOs. Second, threats against
the confidentiality of LOs can allow unauthorized access to location the confidentiality of LOs can allow unauthorized access to location
information. information.
An LO contains four essential types of information: identifiers for An LO contains four essential types of information: identifiers for
the described Target, location information, time- stamps, and Rules. the described Target, location information, timestamps, and Rules.
By grouping values of these various types together within a single By grouping values of these various types together within a single
structure, an LO encodes a set of bindings among them. That is, the structure, an LO encodes a set of bindings among them. That is, the
LO asserts that the identified Target was present at the given LO asserts that the identified Target was present at the given
location at the given time and that the given Rules express the location at the given time and that the given Rules express the
Target's desired policy at that time for the distribution of his Target's desired policy at that time for the distribution of his
location. Below, we provide a description of the assurances required location. Below, we provide a description of the assurances required
by each party involved in the location distribution in order to by each party involved in the location distribution in order to
mitigate the possible attacks on these bindings. mitigate the possible attacks on these bindings.
Rule Maker: The Rule Maker is responsible for creating the Target's Rule Maker: The Rule Maker is responsible for creating the Target's
skipping to change at page 26, line 41 skipping to change at page 27, line 9
rule-tampering attacks. In many circumstances, the privacy policy rule-tampering attacks. In many circumstances, the privacy policy
of the Target may itself be sensitive information; in these cases, of the Target may itself be sensitive information; in these cases,
the Rule Maker also requires the assurance that the binding the Rule Maker also requires the assurance that the binding
between the Target's identity and the Target's Privacy Rules are between the Target's identity and the Target's Privacy Rules are
not deducible by anyone other than an authorized LS. not deducible by anyone other than an authorized LS.
Location Server: The Location Server is responsible for enforcing Location Server: The Location Server is responsible for enforcing
the Target's Privacy Rules. The first assurance required by the the Target's Privacy Rules. The first assurance required by the
LS is that the binding between the Target's Privacy Rules and the LS is that the binding between the Target's Privacy Rules and the
Target's identity is authentic. Authenticating and authorizing Target's identity is authentic. Authenticating and authorizing
the Rule Maker who creates, updates and deletes the Privacy Rules the Rule Maker who creates, updates, and deletes the Privacy Rules
prevents rule-tampering attacks. The LS has to ensure that the prevents rule-tampering attacks. The LS has to ensure that the
authorization policies are not exposed to third parties, if so authorization policies are not exposed to third parties, if so
desired by the Rule Maker (when the rules themselves are privacy- desired by the Rule Maker and when the rules themselves are
sensitive). privacy-sensitive.
Location Recipient: The Location Recipient is the consumer of the Location Recipient: The Location Recipient is the consumer of the
LO. The LR thus requires assurances about the authenticity of the LO. The LR thus requires assurances about the authenticity of the
bindings between the Target's location, the Target's identity and bindings between the Target's location, the Target's identity, and
the time. Ensuring the authenticity of these bindings helps to the time. Ensuring the authenticity of these bindings helps to
prevent various attacks, such falsifying the location, modifying prevent various attacks, such as falsifying the location,
the time-stamp, faking the identity, replaying LOss. modifying the timestamp, faking the identity, and replaying LOs.
Location Generator: The primary assurance required by the Location Location Generator: The primary assurance required by the Location
Generator is that the LS to which the LO is initially published is Generator is that the LS to which the LO is initially published is
one that is trusted to enforce the Target's Privacy Rules. one that is trusted to enforce the Target's Privacy Rules.
Authenticating the trusted LS mitigates the risk of server Authenticating the trusted LS mitigates the risk of server
impersonation attacks. Additionally, the LG is responsible for impersonation attacks. Additionally, the LG is responsible for
the location determination process, which is also sensible from a the location determination process, which is also sensible from a
security perspective because wrong input provided by external security perspective because wrong input provided by external
entites can lead to undesireable disclosure or access to location entities can lead to undesirable disclosure or access to location
information. information.
Assurances as to the integrity and confidentiality of a Location Assurances as to the integrity and confidentiality of a Location
Object can be provided directly through the LO format. RFC 4119 [18] Object can be provided directly through the LO format. RFC 4119 [19]
provides a description for usage of S/MIME to integrity and provides a description for the usage of Secure/Multipurpose Internet
confidentiality protection. Although such direct, end-to-end Mail Extensions (S/MIME) to integrity and confidentiality protection.
assurances are desirable, and these mechanisms should be used Although such direct, end-to-end assurances are desirable, and these
whenever possible, there are many deployment scenarios where directly mechanisms should be used whenever possible, there are many
securing an LO is impractical. For example, in some deployment deployment scenarios where directly securing an LO is impractical.
scenarios a direct trust relationship may not exist between the For example, in some deployment scenarios a direct trust relationship
creator of the Location Object and the recipient. Additionally, in a may not exist between the creator of the Location Object and the
scenario where many recipients are authorized to receive a given LO, recipient. Additionally, in a scenario where many recipients are
the creator of the LO cannot guarantee end-to-end confidentiality authorized to receive a given LO, the creator of the LO cannot
without knowing precisely which recipient will receive the LO. Many guarantee end-to-end confidentiality without knowing precisely which
of these cases can, however, be addressed by the usage of a Location- recipient will receive the LO. Many of these cases can, however, be
by-Reference (possibly combined with an LO). addressed by the usage of a location-by-reference mechanism, possibly
combined with an LO.
6. Example Scenarios 6. Example Scenarios
This section contains a set of example of how the Geopriv This section contains a set of examples of how the Geopriv
architecture can be deployed in practice. These examples are meant architecture can be deployed in practice. These examples are meant
to illustrate key points of the architecture, rather than to form an to illustrate key points of the architecture, rather than to form an
exhaustive set of use cases. exhaustive set of use cases.
For convenience and clarity in these examples, we assume that the For convenience and clarity in these examples, we assume that the
Privacy Rules that an LO carries are equivalent to those in a PIDF-LO Privacy Rules that an LO carries are equivalent to those in a
(namely, that the principal Rules that can be set are limits on the Presence Information Data Format Location Object (PIDF-LO) [19] --
retransmission and retention of the LO). While these two Rules are namely, that the principal Rules that can be set are limits on the
retransmission and retention of the LO. While these two Rules are
the most well-known and important examples, the specific types of the most well-known and important examples, the specific types of
Rules an LS or LR must consider will in general depend on the types Rules an LS or LR must consider will in general depend on the types
of LO it processes. of LOs it processes.
6.1. Minimal Scenario 6.1. Minimal Scenario
One of the simplest scenarios in the Geopriv architecture is when a One of the simplest scenarios in the Geopriv architecture is when a
Device determines its own location and uses that LO to request a Device determines its own location and uses that LO to request a
service (e.g., by including the LO in an HTTP POST request [19] or service (e.g., by including the LO in an HTTP POST request [20] or
SIP INVITE message [20]), and the server delivers that service SIP INVITE message [21]), and the server delivers that service
immediately (e.g., in a 200 OK response in HTTP or SIP), without immediately (e.g., in a 200 OK response in HTTP or SIP), without
retaining or retransmitting the Device's location. The Device acts retaining or retransmitting the Device's location. The Device acts
as an LG by using a Device-based positioning algorithm (e.g., manual as an LG by using a Device-based positioning algorithm (e.g., manual
entry) and as an LS by interpreting the rule and transmitting the LO. entry) and as an LS by interpreting the rule and transmitting the LO.
The Target acts as a Rule Maker by specifying that the location The Target acts as a Rule Maker by specifying that the location
should be sent to the server. The server acts as an LR by receiving should be sent to the server. The server acts as an LR by receiving
and using the LO. and using the LO.
In this case, the privacy of location information is maintained in In this case, the privacy of location information is maintained in
two steps: The first step is that location is only transmitted as two steps: The first step is that the location is only transmitted as
directed by the single Rule Maker, namely the Target. The second directed by the single Rule Maker, namely the Target. The second
step is simply the fact that the server, as LR, does not do anything step is simply the fact that the server, as LR, does not do anything
that creates a privacy risk -- it does not retain or retransmit that creates a privacy risk -- it does not retain or retransmit the
location. Because the server limits its behavior in this way, it location. Because the server limits its behavior in this way, it
does not need to read the Rules in the LO (even though they were does not need to read the Rules in the LO, even though they were
provided) -- no Rule would prevent it from using location in this provided -- no Rule would prevent it from using the location in this
safe manner. safe manner.
The following outline summarizes this scenario: The following outline summarizes this scenario:
o Positioning: Device-based, Device=LG o Positioning: Device-based, Device=LG
o Distribution hop 1: HTTP UA --> Ephemeral web service, privacy via o Distribution hop 1: HTTP User Agent (UA) --> Ephemeral Web
user indication service, privacy via user indication
o Use: Ephemeral web service delivers response without retaining or o Use: Ephemeral Web service delivers response without retaining or
retransmitting location retransmitting location
o Key points: o Key point:
* LRs that do not behave in ways that risk privacy are Geopriv- * LRs that do not behave in ways that risk privacy are Geopriv-
compliant by default. No further action is necessary. compliant by default. No further action is necessary.
6.2. Location-based Web Services 6.2. Location-Based Web Services
Many location-based services are delivered over the Web, using Many location-based services are delivered over the Web, using
Javascript code to orchestrate a series of HTTP requests for location Javascript code to orchestrate a series of HTTP requests for
specific information. To support these applications, browser location-specific information. To support these applications,
extensions have been developed that support Device-based positioning browser extensions have been developed that support Device-based
(manual entry and Global Positioning System (GPS)) and network- positioning (manual entry and Global Positioning System (GPS)) and
assisted positioning (via Assisted GPS (AGPS), and multilateration network-assisted positioning (via Assisted GPS (AGPS), and
with 802.11 and cellular signals), exposing location to web pages multilateration with 802.11 and cellular signals), exposing a
through Javascript APIs. location to Web pages through Javascript APIs.
In this scenario, we consider a Target that uses a browser with a In this scenario, we consider a Target that uses a browser with a
network-assisted positioning extension. When the Target uses this network-assisted positioning extension. When the Target uses this
browser to request location-based services from a web page, the browser to request location-based services from a Web page, the
browser prompts the user to grant the page permission to access the browser prompts the user to grant the page permission to access the
user's location. If the user grants permission, the browser user's location. If the user grants permission, the browser
extension sends 802.11 signal strength measurements to a positioning extension sends 802.11 signal strength measurements to a positioning
server, which then returns the position of the host. The extension server, which then returns the position of the host. The extension
constructs an LO with this location and Rules set by the user, then constructs an LO with this location and Rules set by the user, then
passes the LO to the page through its Javascript API. The page then passes the LO to the page through its Javascript API. The page then
obtains location-relevant information using an XMLHttpRequest [21] to obtains location-relevant information using an XMLHttpRequest [22] to
a server in the same domain as the page and renders this information a server in the same domain as the page and renders this information
to the user. to the user.
At first blush, this scenario seems much more complicated than the At first blush, this scenario seems much more complicated than the
minimal scenario above. However, most of the privacy considerations minimal scenario above. However, most of the privacy considerations
are actually the same. are actually the same.
The positioning phase in this scenario begins when the browser The positioning phase in this scenario begins when the browser
extension contacts the positioning server. The positioning server extension contacts the positioning server. The positioning server
acts as an LG. acts as an LG.
The distribution phase actually occurs entirely within the Target The distribution phase actually occurs entirely within the Target
host. This phase begins when the positioning server, now acting as host. This phase begins when the positioning server, now acting as
LS, follows the LCP policy by providing location only to the Target. an LS, follows the LCP policy by providing the location only to the
The next hop in distribution occurs when the browser extension (an Target. The next hop in distribution occurs when the browser
entity under the control of the Target) passes an LO to the web page extension (an entity under the control of the Target) passes an LO to
(an entity under the control of its author). In this phase, the the Web page (an entity under the control of its author). In this
browser extension acts as an LS, with the Target as the sole Rule phase, the browser extension acts as an LS, with the Target as the
Maker; the user interface for rule-making is effectively a protocol sole Rule Maker; the user interface for rule-making is effectively a
for conveying Rules, and the extension's API effectively defines a protocol for conveying Rules, and the extension's API effectively
way to communicate LOs and an LO Format. The web site acts as an LR defines a way to communicate LOs and an LO format. The Web site acts
when the web page accepts the LO. as an LR when the Web page accepts the LO.
The use phase encompasses the web site's use of the LO. In this The use phase encompasses the Web site's use of the LO. In this
context, the phrase "web site" encompasses not only the web page, but context, the phrase "Web site" encompasses not only the Web page, but
also the dedicated supporting logic behind it. Considering the also the dedicated supporting logic behind it. Considering the
entire web site as a recipient, rather than a single page, it becomes entire Web site as a recipient, rather than a single page, it becomes
clear that sending the LO in an XMLHttpRequest to a back-end server clear that sending the LO in an XMLHttpRequest to a back-end server
is like passing it to a separate component of the LR (as opposed to is like passing it to a separate component of the LR, as opposed to
retransmitting it to another entity). Thus, even in this case, where retransmitting it to another entity. Thus, even in this case, where
location-relevant information is obtained from a back-end server, the location-relevant information is obtained from a back-end server, the
LR does not retain or retransmit location, so its behavior is LR does not retain or retransmit the location, so its behavior is
"privacy-safe" -- it doesn't need to interpret the Rules in the LO. "privacy-safe" -- it doesn't need to interpret the Rules in the LO.
However, consider a variation on this scenario where the web page However, consider a variation on this scenario where the Web page
requests additional information (a map, for instance) from a third- requests additional information (a map, for instance) from a third-
party site. In this case, since location is being transmitted to a party site. In this case, since location information is being
third party, the web site (either in the web page or in a back-end transmitted to a third party, the Web site (either in the Web page or
server) would need to verify that this transmission is allowed by the in a back-end server) would need to verify that this transmission is
LO's Privacy Rules. Similarly, if the site wanted to log the user's allowed by the LO's Privacy Rules. Similarly, if the site wanted to
location information, then it would need to examine the LO to log the user's location information, then it would need to examine
determine how long this information can be retained. In such a case, the LO to determine how long this information can be retained. In
if the LR needs to do something that is not allowed by the Rules, it such a case, if the LR needs to do something that is not allowed by
may have to deny service to the user (hopefully providing a message the Rules, it may have to deny service to the user, while hopefully
with the reason). Nonetheless, if the Rules permit retention or providing a message with the reason. Nonetheless, if the Rules
retransmission (even if this retransmission is limited by access permit retention or retransmission, even if this retransmission is
control rules), then the LR may do so to the extent the Rules allow. limited by access control rules, then the LR may do so to the extent
the Rules allow.
The following outline summarizes this scenario: The following outline summarizes this scenario:
o Positioning: Network-assisted, positioning server=LG o Positioning: Network-assisted, positioning server=LG
o Rule installation: RM (=Target) gives permission to sites and sets o Rule installation: RM (=Target) gives permission to sites and sets
LO Rules LO Rules
o Distribution hop 1: positioning server=LS --> Target, privacy via o Distribution hop 1: positioning server=LS --> Target, privacy via
LCP policy LCP policy
skipping to change at page 30, line 31 skipping to change at page 31, line 8
o Distribution hop 2: Browser=LS --> Web site=LR, privacy via user o Distribution hop 2: Browser=LS --> Web site=LR, privacy via user
confirmation confirmation
o Use: Back-end server delivers location-relevant information o Use: Back-end server delivers location-relevant information
without further retransmission, then deletes location; privacy via without further retransmission, then deletes location; privacy via
safe behavior safe behavior
o Key points: o Key points:
* Privacy in this scenario is provided by a combination of * Privacy in this scenario is provided by a combination of
explicit user direction and Rules in an LO explicit user direction and Rules in an LO.
* Distribution can occur within a host, between mutually * Distribution can occur within a host, between components that
untrusting components do not trust each other.
* Some transmissions of location are actually internal to an LR * Some transmissions of the location are actually internal to
an LR.
* LRs that do things that might be constrained by Rules need to * LRs that do things that might be constrained by Rules need to
verify that these actions are allowed for a particular LO verify that these actions are allowed for a particular LO.
6.3. Emergency Calling 6.3. Emergency Calling
Support for emergency calls by Voice-over-IP devices is a critical Support for emergency calls by Voice-over-IP devices is a critical
use case for location information about Internet hosts. The details use case for location information about Internet hosts. The details
of the Internet architecture for emergency calling are described in of the Internet architecture for emergency calling are described in
[22][23]. In this architecture, there are three critical steps in [23] [24]. In this architecture, there are three critical steps in
the placement of an emergency call, each involving location the placement of an emergency call, each involving location
information: information:
1. Determine the location of the caller 1. Determine the location of the caller.
2. Determine the proper Public Safety Answering Point (PSAP) for the 2. Determine the proper Public Safety Answering Point (PSAP) for the
caller's location caller's location.
3. Send a SIP INVITE message (including the caller's location) to 3. Send a SIP INVITE message, including the caller's location, to
the PSAP the PSAP.
The first step in an emergency call is to determine the location of The first step in an emergency call is to determine the location of
the caller. This step is the positioning phase of the location life- the caller. This step is the positioning phase of the location life
cycle. Location is determined by whatever means are available to the cycle. The location is determined by whatever means are available to
caller's device, or to the network, if this step is being done by a the caller's device, or to the network, if this step is being done by
proxy. Whichever entity does the positioning (either the caller or a a proxy. The entity doing the positioning, whether the caller or a
proxy) acts as an LS, preserving the privacy of location information proxy, acts as an LS, preserving the privacy of location information
by only including it in emergency calls. by only including it in emergency calls.
The second step in an emergency call encompasses location The second step in an emergency call encompasses location
distribution and use. The entity that is routing the emergency call distribution and use. The entity that is routing the emergency call
sends location though the LoST protocol [15] to a mapping server. In sends location information through the Location-to-Service
this role, the routing entity acts as an LS and the LoST server acts Translation (LoST) Protocol [15] to a mapping server. In this role,
as an LR. The LO format within LoST does not allow Rules to be sent the routing entity acts as an LS and the LoST server acts as an LR.
along with location, but because LoST is an application-specific The LO format within LoST does not allow Rules to be sent along with
protocol, the sending of location within a LoST message authorizes the location, but because LoST is an application-specific protocol,
the LoST server to use the location to complete the protocol, namely the sending of the location within a LoST message authorizes the LoST
to route the message as necessary through the LoST mapping server to use the location to complete the protocol, namely to route
architecture [24]. That is, the LoST server is authorized to the message as necessary through the LoST mapping architecture [25].
complete the LoST protocol, but to do nothing else. That is, the LoST server is authorized to complete the LoST protocol,
but to do nothing else.
The third step in an emergency call is again a combination of The third step in an emergency call is again a combination of
distribution and use. The caller (or another entity that inserts the distribution and use. The caller, or another entity that inserts the
caller's location) acts as an LS and the PSAP acts as an LR. In this caller's location, acts as an LS, and the PSAP acts as an LR. In
specific example, the caller's location is transmitted either as a this specific example, the caller's location is transmitted either as
PIDF-LO object or as a reference that returns a PIDF-LO (or both); in a PIDF-LO or as a reference that returns a PIDF-LO, or both; in the
the latter case, the reference should be appropriately protected so latter case, the reference should be appropriately protected so that
that only the PSAP has access. In any case, the receipt of an LO only the PSAP has access. In any case, the receipt of an LO implies
implies that the PSAP should obey the Rules in those LOs in order to that the PSAP should obey the Rules in those LOs in order to preserve
preserve privacy. Depending on the regulatory environment, the PSAP privacy. Depending on the regulatory environment, the PSAP may have
may have the option to ignore those constraints in order to respond the option to ignore those constraints in order to respond to an
to an emergency, or it may be bound to respect these Rules (in spite emergency, or it may be bound to respect these Rules in spite of the
of the emergency situation). emergency situation.
The following outline summarizes this scenario: The following outline summarizes this scenario:
o Positioning: Any o Positioning: Any
o Distribution/use hop 1: Target=LS --> LoST infrastructure (no o Distribution/use hop 1: Target=LS --> LoST infrastructure (no
Rules), privacy via authorization implicit in protocol Rules), privacy via authorization implicit in protocol
o Distribution/use hop 2: Target=LS --> PSAP, privacy via Rules in o Distribution/use hop 2: Target=LS --> PSAP, privacy via Rules
LO in LO
o Use: PSAP uses location to deliver emergency services o Use: PSAP uses location to deliver emergency services
o Key points: o Key points:
* Privacy in this scenario is provided by a combination of * Privacy in this scenario is provided by a combination of
explicit user direction, implicit authorization particular to a explicit user direction, implicit authorization particular to a
protocol, and Rules in an LO protocol, and Rules in an LO.
* LRs may be constrained to respect or ignore Privacy Rules by * LRs may be constrained to respect or ignore Privacy Rules by
local regulation local regulation.
6.4. Combination of Services 6.4. Combination of Services
In modern Internet applications, users frequently receive information In modern Internet applications, users frequently receive information
via one channel and broadcast it via another. In this sense, both via one channel and broadcast it via another. In this sense, both
users and channels (e.g., web services) become LSess. Here we users and channels (e.g., Web services) become LSes. Here we
consider a more complex example that illustrates this pattern across consider a more complex example that illustrates this pattern across
multiple logical hops. multiple logical hops.
Suppose Alice (the Target) subscribes to a wireless ISP that Suppose Alice as the Target subscribes to a wireless ISP that
determines her location using a network-based positioning technique determines her location using a network-based positioning technique,
(e.g., via the location of the base station serving the Target), and e.g., via the location of the base station serving the Target, and
provides that information directly to a location-enhanced presence provides that information directly to a location-enhanced presence
provider (which might use SIP, XMPP [25], or another protocol). The provider. This presence provider might use SIP, the Extensible
location-enhanced presence provider allows Alice to specify Rules for Messaging and Presence Protocol (XMPP) [26], or another protocol).
how this location is distributed: which friends should receive The location-enhanced presence provider allows Alice to specify Rules
for how this location is distributed: which friends should receive
Alice's location and what Rules they should get with it. Alice uses Alice's location and what Rules they should get with it. Alice uses
a few other location-enhanced services as well, so she sends Rules a few other location-enhanced services as well, so she sends Rules
that allow her location to be shared with those services, and allow that allow her location to be shared with those services, and that
those services to retain and retransmit her location. allow those services to retain and retransmit her location.
Bob is one of Alice's friends, and he receives her location via this Bob is one of Alice's friends, and he receives her location via this
location-enhanced presence service. Noting that she's at their location-enhanced presence service. Noting that she's at their
favorite coffee shop, Bob wants to upload a photo of the two of them favorite coffee shop, Bob wants to upload a photo of the two of them
at the coffee shop to a photo-sharing site, along with an LO that at the coffee shop to a photo-sharing site, along with an LO that
marks the location. Bob checks the Rules in Alice's LO and verifies marks the location. Bob checks the Rules in Alice's LO and verifies
that the photo sharing site is one of the services that Alice that the photo-sharing site is one of the services that Alice
authorized. Seeing that Alice has authorized him to give the LO to authorized. Seeing that Alice has authorized him to give the LO to
the photo-sharing site, he attaches it to the photo and uploads it. the photo-sharing site, he attaches it to the photo and uploads it.
Once the geo-tagged photo is uploaded, the photo sharing site reads Once the geo-tagged photo is uploaded, the photo-sharing site reads
the Rules in the LO and verifies that the site is authorized to store the Rules in the LO and verifies that the site is authorized to store
the photo and to share it with others. Since Alice has allowed the the photo and to share it with others. Since Alice has allowed the
site to retransmit and retain without any constraints, the site site to retransmit and retain without any constraints, the site
fulfills Bob's request to make the geo-tagged photo publicly fulfills Bob's request to make the geo-tagged photo publicly
accessible. accessible.
Eve, another user of the photo sharing site, downloads the photo of Eve, another user of the photo-sharing site, downloads the photo of
Alice and Bob at the coffee shop and receives Alice's LO along with Alice and Bob at the coffee shop and receives Alice's LO along with
it. Eve posts the photo and location to her public page on a social it. Eve posts the photo and location to her public page on a social
networking site without checking the Rules, even though the LO networking site without checking the Rules, even though the LO
doesn't allow Eve to send the location anywhere else. The social doesn't allow Eve to send the location anywhere else. The social
networking site, however, observes that no retransmission or networking site, however, observes that no retransmission or
retention are allowed (both of which it needs for a public posting), retention are allowed, both of which it needs for a public posting,
and rejects the upload. and rejects the upload.
In terms of the location life-cycle, this scenario consists of a In terms of the location life cycle, this scenario consists of a
positioning step, followed by four distribution hops and use. positioning step, followed by four distribution hops and use.
Positioning is the simplest step: An LG in Alice's ISP monitors her Positioning is the simplest step: An LG in Alice's ISP monitors her
location and transmits it to the presence service, maintaining location and transmits it to the presence service, maintaining
privacy by only transmitting location to a single entity (to which privacy by only transmitting the location information to a single
Alice has delegated privacy responsibilities). entity to which Alice has delegated privacy responsibilities.
The first distribution hop occurs when the presence server sends The first distribution hop occurs when the presence server sends the
location to Bob. In this transaction, the presence server acts as an location to Bob. In this transaction, the presence server acts as an
LS, Alice acts as an RM, and Bob acts as an LR. The privacy of this LS, Alice acts as an RM, and Bob acts as an LR. The privacy of this
transaction is assured by the fact that Alice has installed Rules on transaction is assured by the fact that Alice has installed Rules on
the presence server that dictate who it may allow to access her the presence server that dictate who it may allow to access her
location. The second distribution hop is when Bob uploads the LO to location. The second distribution hop is when Bob uploads the LO to
the photo-sharing site. Here Bob acts as an LS, preserving the the photo-sharing site. Here Bob acts as an LS, preserving the
privacy of location information by verifying that the Rules in the LO privacy of location information by verifying that the Rules in the LO
allow him to upload it. The third distribution hop is when the allow him to upload it. The third distribution hop is when the
photo-sharing site sends the LO to Eve, likewise following the Rules photo-sharing site sends the LO to Eve, likewise following the Rules
-- but a different set of Rules than Bob, since an LO can specify -- but a different set of Rules than for Bob, since an LO can specify
different Rule sets for different LSes. different Rule sets for different LSes.
Eve is the fourth LS in the chain, and fails to comply with Geopriv Eve is the fourth LS in the chain, and fails to comply with Geopriv
by not checking the Rules in the LO prior to uploading the LO to the by not checking the Rules in the LO prior to uploading the LO to the
social networking site. The site, however, is a responsible LR -- it social networking site. The site, however, is a responsible LR -- it
checks the Rules in the LO, sees that they don't allow it to use the checks the Rules in the LO, sees that they don't allow it to use the
location as it needs to, and discards the LO. location as it needs to, and discards the LO.
The following outline summarizes this scenario: The following outline summarizes this scenario:
o Positioning: Network-based, LG in network, privacy via exclusive o Positioning: Network-based, LG in network, privacy via exclusive
relationship with presence service relationship with presence service
o Distribution/use hop 1: Presence server --> Bob, privacy via o Distribution/use hop 1: Presence server --> Bob, privacy via
Alice's access control rules Alice's access control rules
o Distribution/use hop 2: Bob --> photo sharing site, privacy via o Distribution/use hop 2: Bob --> photo-sharing site, privacy via
Rules for Bob in LO Rules for Bob in LO
o Distribution/use hop 3: Photo sharing site --> Eve, privacy via o Distribution/use hop 3: Photo-sharing site --> Eve, privacy via
Rules for site in LO Rules for site in LO
o Distribution/use hop 4: Eve --> Social networking site, violates o Distribution/use hop 4: Eve --> Social networking site, violates
privacy by retransmitting privacy by retransmitting
o Use: Social networking site, privacy via checking Rules and o Use: Social networking site, privacy via checking Rules and
discarding discarding
o Key points: o Key points:
* Privacy can be preserved through multiple hops * Privacy can be preserved through multiple hops.
* A LO can specify different Rules for different entities * An LO can specify different Rules for different entities.
* An LS can still disobey the Rules, but even then, the * An LS can still disobey the Rules, but even then, the
architecture still works in some cases architecture still works in some cases.
7. Glossary 7. Glossary
Various security-related terms not defined here are to be understood Various security-related terms not defined here are to be understood
in the sense defined in RFC 4949 [26]. in the sense defined in RFC 4949 [27].
$ Access Control Rule $ Access Control Rule
A rule that describe which entities may receive location A rule that describes which entities may receive location
information and in what form. information and in what form.
$ civic location $ civic location
The geographic position of an entity in terms of a postal address The geographic position of an entity in terms of a postal address
or civic landmark. Examples of such data are room number, street or civic landmark. Examples of such data are room number, street
number, street name, city, ZIP code, county, state and country. number, street name, city, postal code, county, state, and
country.
$ Device $ Device
The physical device whose location is tracked as a proxy for the The physical device, such as a mobile phone, PC, or embedded
micro-controller, whose location is tracked as a proxy for the
location of a Target. location of a Target.
$ geodetic location $ geodetic location
The geographic position of an entity in a particular coordinate The geographic position of an entity in a particular coordinate
system (for example, a latitude-longitude pair). system, for example, a latitude-longitude pair.
$ Local Rule $ Local Rule
A Privacy Rules that directs a Location Server about how to treat A Privacy Rule that directs a Location Server about how to treat a
a Target's location information. Local Rules are used internally Target's location information. Local Rules are used internally by
by a Location Server to handle requests from Location Recipients. a Location Server to handle requests from Location Recipients.
They are not distributed to Location Recipients. They are not distributed to Location Recipients.
$ Location Generator (LG) $ Location Generator (LG)
Performs the role of initially determining or gathering the Performs the role of initially determining or gathering the
location of a Target. Location Generators may be any sort of location of a Target. Location Generators may be any sort of
software or hardware used to obtain a Target's location (examples software or hardware used to obtain a Target's location. Examples
include GPS chips and cellular networks). include GPS chips and cellular networks.
$ Location Information Server (LIS) $ Location Information Server (LIS)
An entity responsible for providing devices within an access An entity responsible for providing devices within an access
network with information about their own locations. A Location network with information about their own locations. A Location
Information Server uses knowledge of the access network and its Information Server uses knowledge of the access network and its
physical topology to generate and distribute location information physical topology to generate and distribute location information
to devices. to devices.
$ Location Object (LO) $ Location Object (LO)
A data unit that conveys location information together with A data unit that conveys location information together with
Privacy Rules within the Geopriv architecture. A Location Object Privacy Rules within the Geopriv architecture. A Location Object
may convey geodetic location data (latitiude/longitude/altitude), may convey geodetic location data (latitude, longitude, altitude),
civic location data (street/city/state/etc.), or both. civic location data (street, city, state, etc.), or both.
$ Location Recipient (LR) $ Location Recipient (LR)
An ultimate end point entity to which a Location Object is An ultimate end-point entity to which a Location Object is
distributed. Location Recipients request location information distributed. Location Recipients request location information
about a particular Target from a Location Server. If allowed by about a particular Target from a Location Server. If allowed by
the appropriate Privacy Rules, a Location Recipient will receive the appropriate Privacy Rules, a Location Recipient will receive
Location Objects describing the Target's location from the Location Objects describing the Target's location from the
Location Server. Location Server.
$ Location Server (LS) $ Location Server (LS)
An entity that receives Location Objects from Location Generators, An entity that receives Location Objects from Location Generators,
Privacy Rules from Rule Makers, and location requests from Privacy Rules from Rule Makers, and location requests from
Location Recipients. A Location Server applies the appropriate Location Recipients. A Location Server applies the appropriate
Privacy Rules to a Location Object received from a Location Privacy Rules to a Location Object received from a Location
Generator and may disclose the Location Object, in compliance with Generator and may disclose the Location Object, in compliance with
the Rules, to Location Recipients. the Rules, to Location Recipients.
Location Servers may not necessarily be "servers" in the Location Servers may not necessarily be "servers" in the
colloquial sense of hosts in remote data centers servicing colloquial sense of hosts in remote data centers servicing
requests. Rather, a Location Server can be any software or requests. Rather, a Location Server can be any software or
hardware component that receives and distributes location hardware component that receives and distributes location
information. Examples include a positioning server (with a information. Examples include a positioning server (with a
location interface) in an access network, a presence server, or a location interface) in an access network, a presence server, or
Web browser or other software running on a Target's device. a Web browser or other software running on a Target's device.
$ Privacy Rule $ Privacy Rule
A directive that regulates an entity's activities with respect to A directive that regulates an entity's activities with respect to
a Target's location information, including the collection, use, a Target's location information, including the collection, use,
disclosure, and retention of the location information. Privacy disclosure, and retention of the location information. Privacy
Rules describe how location information may be used by an entity, Rules describe how location information may be used by an entity,
the level of detail with which location information may be the level of detail with which location information may be
described to an entity, and the conditions under which location described to an entity, and the conditions under which location
information may be disclosed to an entity. Privacy Rules are information may be disclosed to an entity. Privacy Rules are
communicated from Rule Makers to Location Servers and conveyed in communicated from Rule Makers to Location Servers and conveyed in
Location Objects throughout the Geopriv architecture. Location Objects throughout the Geopriv architecture.
$ Rule $ Rule
See Privacy Rule. See Privacy Rule.
$ Rule Maker (RM) $ Rule Maker (RM)
An individual or entity that is authorized to set Privacy Rules An individual or entity that is authorized to set Privacy Rules
for a Target. In some cases a Rule Maker and a Target will be the for a Target. In some cases, a Rule Maker and a Target will be
same individual or entity, and in other cases they will be the same individual or entity, and in other cases they will be
separate. For example, a parent may serve as the Rule Maker when separate. For example, a parent may serve as the Rule Maker when
the Target is his child. The Rule Maker is also not necessarily the Target is his child. The Rule Maker is also not necessarily
the owner of a Target device. For example, a corporation may own the owner of a Target device. For example, a corporation may own
a device that it provides to an employee but permit the employee a device that it provides to an employee but permit the employee
to serve as the Rule Maker and set her own Privacy Rules. Rule to serve as the Rule Maker and set her own Privacy Rules. Rule
Makers provide the Privacy Rules associated with a Target to Makers provide the Privacy Rules associated with a Target to
Location Servers. Location Servers.
$ Forwarded Rule $ Forwarded Rule
skipping to change at page 36, line 47 skipping to change at page 37, line 47
Rules direct Location Recipients about how to handle the location Rules direct Location Recipients about how to handle the location
information they receive. Because the Forwarded Rules themselves information they receive. Because the Forwarded Rules themselves
may reveal potentially sensitive information about a Target, only may reveal potentially sensitive information about a Target, only
the minimal subset of Forwarded Rules necessary for a Location the minimal subset of Forwarded Rules necessary for a Location
Recipient to handle a Location Object is distributed to the Recipient to handle a Location Object is distributed to the
Location Recipient. Location Recipient.
$ Target $ Target
An individual or other entity whose location is sought in the An individual or other entity whose location is sought in the
Geopriv architecture. In many cases the Target will be the human Geopriv architecture. In many cases, the Target will be the human
user of a Device, or it may be an object such as a vehicle or user of a Device, or it may be an object such as a vehicle or
shipping container to which a Device is attached. In some shipping container to which a Device is attached. In some
instances the Target will be the Device itself. The Target is the instances, the Target will be the Device itself. The Target is
entity whose privacy Geopriv seeks to protect. the entity whose privacy Geopriv seeks to protect.
$ Usage Rule $ Usage Rule
A rule that describe what uses of location information are A rule that describes what uses of location information are
authorized. authorized.
8. Acknowledgements 8. Acknowledgements
Section 5 is largely based on the security investigations conducted Section 5 is largely based on the security investigations conducted
as part of the Geopriv Layer-7 Location Configuration Protocol design as part of the Geopriv Layer-7 Location Configuration Protocol design
team, which produced [9]. We would like to thank all the members of team, which produced [9]. We would like to thank all the members of
the design team. the design team.
We would also like to thank Marc Linsner and Martin Thomson for their We would also like to thank Marc Linsner and Martin Thomson for their
contributions regarding terminology and LCPs. contributions regarding terminology and LCPs.
9. IANA Considerations 9. References
This document makes no request of IANA.
10. References
10.1. Normative References 9.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
10.2. Informative References 9.2. Informative References
[2] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. [2] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J.
Polk, "Geopriv Requirements", RFC 3693, February 2004. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[3] Danley, M., Mulligan, D., Morris, J., and J. Peterson, "Threat [3] Danley, M., Mulligan, D., Morris, J., and J. Peterson, "Threat
Analysis of the Geopriv Protocol", RFC 3694, February 2004. Analysis of the Geopriv Protocol", RFC 3694, February 2004.
[4] U.S. Department of Defense, "National Industrial Security [4] U.S. Department of Defense, "National Industrial Security
Program Operating Manual", DoD 5220-22M, January 1995. Program Operating Manual", DoD 5220-22M, January 1995.
[5] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV [5] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
Presence Information Data Format Location Object (PIDF-LO) Presence Information Data Format Location Object (PIDF-LO)
Usage Clarification, Considerations, and Recommendations", Usage Clarification, Considerations, and Recommendations",
RFC 5491, March 2009. RFC 5491, March 2009.
[6] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk, [6] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk,
J., and J. Rosenberg, "Common Policy: A Document Format for J., and J. Rosenberg, "Common Policy: A Document Format for
Expressing Privacy Preferences", RFC 4745, February 2007. Expressing Privacy Preferences", RFC 4745, February 2007.
[7] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., and [7] Schulzrinne, H., Ed., Tschofenig, H., Ed., Morris, J., Cuellar,
J. Polk, "Geolocation Policy: A Document Format for Expressing J., and J. Polk, "Geolocation Policy: A Document Format for
Privacy Preferences for Location Information", Expressing Privacy Preferences for Location Information", Work
draft-ietf-geopriv-policy-21 (work in progress), January 2010. in Progress, March 2011.
[8] Rosenberg, J., "The Extensible Markup Language (XML) [8] Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)", RFC 4825, May 2007. Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[9] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location [9] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location
Configuration Protocol: Problem Statement and Requirements", Configuration Protocol: Problem Statement and Requirements",
RFC 5687, March 2010. RFC 5687, March 2010.
[10] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host [10] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
Configuration Protocol Option for Coordinate-based Location Configuration Protocol Option for Coordinate-based Location
Configuration Information", RFC 3825, July 2004. Configuration Information", RFC 3825, July 2004.
[11] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 [11] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4
and DHCPv6) Option for Civic Addresses Configuration and DHCPv6) Option for Civic Addresses Configuration
Information", RFC 4776, November 2006. Information", RFC 4776, November 2006.
[12] Polk, J., "Dynamic Host Configuration Protocol (DHCP) IPv4 and [12] Polk, J., "Dynamic Host Configuration Protocol (DHCP) IPv4 and
IPv6 Option for a Location Uniform Resource Identifier (URI)", IPv6 Option for a Location Uniform Resource Identifier (URI)",
draft-ietf-geopriv-dhcp-lbyr-uri-option-08 (work in progress), Work in Progress, February 2011.
July 2010.
[13] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC 5985, [13] Barnes, M., Ed., "HTTP-Enabled Location Delivery (HELD)",
September 2010. RFC 5985, September 2010.
[14] Marshall, R., "Requirements for a Location-by-Reference [14] Marshall, R., Ed., "Requirements for a Location-by-Reference
Mechanism", RFC 5808, May 2010. Mechanism", RFC 5808, May 2010.
[15] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, [15] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig,
"LoST: A Location-to-Service Translation Protocol", RFC 5222, "LoST: A Location-to-Service Translation Protocol", RFC 5222,
August 2008. August 2008.
[16] Kent, S. and K. Seo, "Security Architecture for the Internet [16] Barnes, R., Thomson, M., Winterbottom, J., and H. Tschofenig,
"Location Configuration Extensions for Policy Management", Work
in Progress, June 2011.
[17] Kent, S. and K. Seo, "Security Architecture for the Internet
Protocol", RFC 4301, December 2005. Protocol", RFC 4301, December 2005.
[17] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) [18] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
Protocol Version 1.2", RFC 5246, August 2008. Protocol Version 1.2", RFC 5246, August 2008.
[18] Peterson, J., "A Presence-based GEOPRIV Location Object [19] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005. Format", RFC 4119, December 2005.
[19] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., [20] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999. HTTP/1.1", RFC 2616, June 1999.
[20] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [21] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[21] World Wide Web Consortium, "The XMLHttpRequest Object", W3C [22] World Wide Web Consortium, "The XMLHttpRequest Object", W3C
document http://www.w3.org/TR/XMLHttpRequest/, April 2008. document http://www.w3.org/TR/XMLHttpRequest/, August 2010.
[22] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, "Framework
for Emergency Calling using Internet Multimedia",
draft-ietf-ecrit-framework-11 (work in progress), July 2010.
[23] Rosen, B. and J. Polk, "Best Current Practice for
Communications Services in support of Emergency Calling",
draft-ietf-ecrit-phonebcp-15 (work in progress), July 2010.
[24] Schulzrinne, H., "Location-to-URL Mapping Architecture and [23] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, "Framework
Framework", draft-ietf-ecrit-mapping-arch-04 (work in for Emergency Calling Using Internet Multimedia", Work
progress), March 2009. in Progress, October 2010.
[25] Saint-Andre, P., Ed., "Extensible Messaging and Presence [24] Rosen, B. and J. Polk, "Best Current Practice for
Protocol (XMPP): Core", RFC 3920, October 2004. Communications Services in support of Emergency Calling", Work
in Progress, March 2011.
[26] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, [25] Schulzrinne, H., "Location-to-URL Mapping Architecture and
August 2007. Framework", RFC 5582, September 2009.
[27] Polk, J. and B. Rosen, "Location Conveyance for the Session [26] Saint-Andre, P., "Extensible Messaging and Presence Protocol
Initiation Protocol", draft-ietf-sip-location-conveyance-13 (XMPP): Core", RFC 6120, March 2011.
(work in progress), March 2009.
URIs [27] Shirey, R., "Internet Security Glossary, Version 2", FYI 36,
RFC 4949, August 2007.
[28] <http://creativecommons.org/> [28] <http://creativecommons.org/>
Authors' Addresses Authors' Addresses
Richard Barnes Richard Barnes
BBN Technologies BBN Technologies
9861 Broken Land Pkwy, Suite 400 9861 Broken Land Pkwy, Suite 400
Columbia, MD 21046 Columbia, MD 21046
USA USA
Phone: +1 410 290 6169 Phone: +1 410 290 6169
Email: rbarnes@bbn.com EMail: rbarnes@bbn.com
Matt Lepinski Matt Lepinski
BBN Technologies BBN Technologies
10 Moulton St 10 Moulton St.
Cambridge, MA 02138 Cambridge, MA 02138
USA USA
Phone: +1 617 873 5939 Phone: +1 617 873 5939
Email: mlepinski@bbn.com EMail: mlepinski@bbn.com
Alissa Cooper Alissa Cooper
Center for Democracy & Technology Center for Democracy & Technology
1634 I Street NW, Suite 1100 1634 I Street NW, Suite 1100
Washington, DC Washington, DC
USA USA
Email: acooper@cdt.org EMail: acooper@cdt.org
John Morris John Morris
Center for Democracy & Technology Center for Democracy & Technology
1634 I Street NW, Suite 1100 1634 I Street NW, Suite 1100
Washington, DC Washington, DC
USA USA
Email: jmorris@cdt.org EMail: jmorris@cdt.org
Hannes Tschofenig Hannes Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
Linnoitustie 6 Linnoitustie 6
Espoo 02600 Espoo 02600
Finland Finland
Phone: +358 (50) 4871445 Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@gmx.net EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at URI: http://www.tschofenig.priv.at
Henning Schulzrinne Henning Schulzrinne
Columbia University Columbia University
Department of Computer Science Department of Computer Science
450 Computer Science Building 450 Computer Science Building
New York, NY 10027 New York, NY 10027
US US
Phone: +1 212 939 7004 Phone: +1 212 939 7004
Email: hgs@cs.columbia.edu EMail: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu URI: http://www.cs.columbia.edu
 End of changes. 209 change blocks. 
555 lines changed or deleted 586 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/