draft-ietf-geopriv-arch-00.txt   draft-ietf-geopriv-arch-01.txt 
GEOPRIV R. Barnes GEOPRIV R. Barnes
Internet-Draft M. Lepinski Internet-Draft M. Lepinski
Updates: 3693, 3694 BBN Technologies Updates: 3693, 3694 BBN Technologies
(if approved) A. Cooper (if approved) A. Cooper
Intended status: BCP J. Morris Intended status: BCP J. Morris
Expires: January 10, 2010 Center for Democracy & Expires: April 29, 2010 Center for Democracy &
Technology Technology
H. Tschofenig H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
H. Schulzrinne H. Schulzrinne
Columbia University Columbia University
July 9, 2009 October 26, 2009
An Architecture for Location and Location Privacy in Internet An Architecture for Location and Location Privacy in Internet
Applications Applications
draft-ietf-geopriv-arch-00 draft-ietf-geopriv-arch-01
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 2, line 5 skipping to change at page 2, line 5
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 10, 2010. This Internet-Draft will expire on April 29, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 14 skipping to change at page 3, line 14
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
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. Overview of the Architecture . . . . . . . . . . . . . . . . . 7 2. Overview of the Architecture . . . . . . . . . . . . . . . . . 7
2.1. Basic Geopriv Scenario . . . . . . . . . . . . . . . . . . 8 2.1. Basic Geopriv Scenario . . . . . . . . . . . . . . . . . . 8
2.2. Roles and Data Formats . . . . . . . . . . . . . . . . . . 9 2.2. Roles and Data Formats . . . . . . . . . . . . . . . . . . 9
2.3. Relationships Between Geopriv Roles . . . . . . . . . . . 12 3. The Location Life-Cycle . . . . . . . . . . . . . . . . . . . 12
3. The Location Life-Cycle . . . . . . . . . . . . . . . . . . . 13 3.1. Positioning . . . . . . . . . . . . . . . . . . . . . . . 13
3.1. Positioning . . . . . . . . . . . . . . . . . . . . . . . 14 3.1.1. Determination Mechanisms and Protocols . . . . . . . . 13
3.1.1. Determination Mechanisms and Protocols . . . . . . . . 14 3.1.2. Privacy Considerations for Positioning . . . . . . . . 15
3.1.2. Privacy Considerations for Positioning . . . . . . . . 16 3.1.3. Security Considerations for Positioning . . . . . . . 16
3.1.3. Security Considerations for Positioning . . . . . . . 17 3.2. Location Distribution . . . . . . . . . . . . . . . . . . 16
3.2. Location Distribution . . . . . . . . . . . . . . . . . . 17 3.2.1. Privacy Rules . . . . . . . . . . . . . . . . . . . . 17
3.2.1. Privacy Rules . . . . . . . . . . . . . . . . . . . . 18 3.2.2. Location Configuration . . . . . . . . . . . . . . . . 19
3.2.2. Location Configuration . . . . . . . . . . . . . . . . 20
3.2.3. Location References . . . . . . . . . . . . . . . . . 20 3.2.3. Location References . . . . . . . . . . . . . . . . . 20
3.2.4. Privacy Considerations for Distribution . . . . . . . 21 3.2.4. Privacy Considerations for Distribution . . . . . . . 20
3.2.5. Security Considerations for Distribution . . . . . . . 22 3.2.5. Security Considerations for Distribution . . . . . . . 22
3.3. Location Use . . . . . . . . . . . . . . . . . . . . . . . 23 3.3. Location Use . . . . . . . . . . . . . . . . . . . . . . . 23
3.3.1. Privacy Considerations for Use . . . . . . . . . . . . 24 3.3.1. Privacy Considerations for Use . . . . . . . . . . . . 23
3.3.2. Security Considerations for Use . . . . . . . . . . . 24 3.3.2. Security Considerations for Use . . . . . . . . . . . 23
4. Security Considerations . . . . . . . . . . . . . . . . . . . 24 4. Security Considerations . . . . . . . . . . . . . . . . . . . 24
4.1. Threats to Location Objects . . . . . . . . . . . . . . . 24 5. Example Scenarios . . . . . . . . . . . . . . . . . . . . . . 26
4.1.1. Threats to Location Integrity and Authenticity . . . . 25 5.1. Minimal Scenario . . . . . . . . . . . . . . . . . . . . . 26
4.1.2. Threats to Location Privacy . . . . . . . . . . . . . 26 5.2. Location-based Web Services . . . . . . . . . . . . . . . 27
4.2. Required Assurances . . . . . . . . . . . . . . . . . . . 26 5.3. Emergency Calling . . . . . . . . . . . . . . . . . . . . 29
4.3. Protocol mechanisms . . . . . . . . . . . . . . . . . . . 28 5.4. Combination of Services . . . . . . . . . . . . . . . . . 31
4.4. Mechanisms within the Location Object . . . . . . . . . . 28 6. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5. Example Scenarios . . . . . . . . . . . . . . . . . . . . . . 29 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36
5.1. Minimal Scenario . . . . . . . . . . . . . . . . . . . . . 30 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
5.2. Location-based Web Services . . . . . . . . . . . . . . . 30 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.3. Emergency Calling . . . . . . . . . . . . . . . . . . . . 33 9.1. Normative References . . . . . . . . . . . . . . . . . . . 36
5.4. Combination of Services . . . . . . . . . . . . . . . . . 34 9.2. Informative References . . . . . . . . . . . . . . . . . . 36
6. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39
9.1. Normative References . . . . . . . . . . . . . . . . . . . 39
9.2. Informative References . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
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
skipping to change at page 8, line 31 skipping to change at page 8, line 31
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.
2.1. Basic Geopriv Scenario 2.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), 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 learns of her location from a wireless For example, suppose Alice is using a mobile device, she learns of
location service and wishes to share it privately with her friends by her location from a wireless location service, and she wishes to
way of a presence service. Alice clearly needs to provide the share her location privately with her friends by way of a presence
presence server with her location and rules about which friends can service. Alice clearly needs to provide the presence server with her
be provided with her location. To enable Alice's friends to preserve location and rules about which friends can be provided with her
her privacy, they need to be provided with privacy rules. Alice may location. To enable Alice's friends to preserve her privacy, they
tell some of her friends the rules directly, or she can have the need to be provided with privacy rules. Alice may tell some of her
presence server provide the rules to her friends when it provides friends the rules directly, or she can have the presence server
them with her location. In this way, every friend who receives provide the rules to her friends when it provides them with her
Alice's location is authorized by Alice to receive it, and every location. In this way, every friend who receives Alice's location is
friend who receives it knows the rules. Good friends will obey the authorized by Alice to receive it, and every friend who receives it
rules. If a bad friend breaks them and Alice finds out, the bad knows the rules. Good friends will obey the rules. If a bad friend
friend cannot claim that he was unaware of the rules. breaks them and Alice finds out, the bad friend cannot claim that he
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 (to meet up with her or plot her location
over time, for example). The usage rules that they receive direct over time, for example). 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 on further,
they must go through the same process as Bob. 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 |--> ...
| | | +----->| | | | | +----->| |
v v | | +-----+ v v | | +-----+
+-------+ +----------+ | +----------+ +----------+ |
| |--Location->| Presence |--Location---->| +----------+ | |Device| |--Location->| Presence |--Location---->| +----------+
| Alice | | Server | |---->| Friend-1 | | -------- | | Server | |---->| Friend-1 |
| |---Rules--->| |---Rules------>| +----------+ | |---Rules--->| |---Rules------>| +----------+
+-------+ +----------+ | | Alice | +----------+ |
| +----------+ |
| +----------+ | +----------+
+---->| Friend-2 | +---->| Friend-2 |
+----------+ +----------+
Figure 1: Basic Geopriv Scenario Figure 1: Basic Geopriv Scenario
2.2. Roles and Data Formats 2.2. Roles and Data Formats
The above example illustrates the five 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. The Target is the entity whose privacy the Geopriv architecture. In many cases the Target will be the
Geopriv seeks to protect. Alice is the Target in Figure 1. 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
some instances the Target will be the Device itself. The Target
is the entity whose privacy Geopriv seeks to protect. Alice is
the Target in Figure 1.
Device: The technical device whose location is tracked as a proxy
for the location of a Target. Alice's device 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 a Target 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 Target 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 Target's location software or hardware used to obtain the Device's location
(examples include GPS chips and cellular networks). A Target may (examples include GPS chips and cellular networks). A Device may
even perform the Location Generator role for itself; devices even perform the Location Generator role for itself; Devices
capable of unassisted satellite-based positioning and devices that capable of unassisted satellite-based positioning and Devices that
accept manually entered location information are two examples. accept manually entered location information are two examples.
The wireless location service plays the Location Generator role in The wireless location service plays the Location Generator role in
Figure 1. 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 Recpients. 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 Target's device. The above example includes three running on a Device. The above example includes three Location
Location Servers: Alice, the presence service and Bob. Servers: Alice, the presence service and Bob.
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 location explicitly
(by sending a query to a Location Server), or it may receive (by sending a query to a Location Server), or it may receive
location asynchronously. The presence service, Bob, Friend-1 and location asynchronously. The presence service, Bob, Friend-1 and
Friend-2 are Location Recipients in Figure 1. 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 LG and LS roles, or both the LR and LS entity to perform both the LG and LS roles, or both the LR and LS
roles. A single entity may take on multiple roles simply by virtue roles. A single entity may take on multiple roles simply by virtue
of its own capabilities and the permissions provided to it. of its own capabilities and the permissions provided to it.
Although in the above example there is only a single Location
Generator and a single Rule Maker, in some cases a Location Server
may receive Location Objects from multiple Location Generators or
Rules from multiple Rule Makers. Likewise, a single Location
Generator may publish location information to multiple Location
Servers, and a single Location Recipient may receive Location Objects
from multiple Location Servers.
There is a close relationship between a Target and its Device. The
term "Device" is used when discussing protocol interactions, whereas
the term "Target" is used when discussing generically the person or
object being located and its privacy. While in the example above
there is a one-to-one relationship between the Target and the Device,
Geopriv can also be used to convey location information about a
device that is not directly linked to a single individual or object,
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 of
location information may be present in a single LO. Location location information may be present in a single LO. Location
Objects typically include some sort of identifier associated with Objects typically include some sort of identifier associated with
the Target. the Target.
skipping to change at page 12, line 22 skipping to change at page 12, line 22
| |
Positioning Positioning
Data Data
| |
| +------------Privacy Rules------------------>+----+ | +------------Privacy Rules------------------>+----+
| | +---->| LR |--> ... | | +---->| LR |--> ...
| | | | LS | | | | | LS |
v | | +----+ v | | +----+
+-------+ | +-------+ |
|Target | +----+ | +----+ |Target | +----+ | +----+
| RM |--------------->| LR |---------------+---->| LR | |Device |--------------->| LR |---------------+---->| LR |
| LS | LO | LS | LO | +----+ | RM | LO | LS | LO | +----+
| | +----+ | | LS | +----+ |
+-------+ | +-------+ |
| +----+ | +----+
+---->| LR | +---->| LR |
+----+ +----+
Figure 2: Basic Geopriv Scenario Figure 2: Basic Geopriv Scenario
2.3. Relationships Between Geopriv Roles
Although in the above example there is only a single Location
Generator and a single Rule Maker, in some cases a Location Server
may receive Location Objects from multiple Location Generators or
Rules from multiple Rule Makers. Likewise, a single Location
Generator may publish location information to multiple Location
Servers, and a single Location Recipient may receive Location Objects
from multiple Location Servers.
The term "Target" may refer not only to an individual whose location
is described by a LO, but also to that individual's device, since the
device engages in protocol interactions, not the individual. For the
remainder of this document, the term "Target" refers to the device.
Geopriv can also be used to convey location information about a
device that is not directly linked to a single individual, such as a
package or product containing a location-capable sensor, or a device
linked to multiple individuals.
3. The Location Life-Cycle 3. 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 Target'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 to Location
Recipients, which may in turn act as Location Servers and further Recipients, which may in turn act as Location Servers and further
distribute location to other Location Recipients (possibly distribute location to other Location Recipients (possibly
several times) 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 |+
| Target | | Maker(s)|| | Device | | Maker(s)||
| | | || | | | ||
+----------+ +----------+| +----------+ +----------+|
^| +----------+ ^| +----------+
|| Positioning | Rules || Positioning | Rules
|| Data | || Data |
|| | || |
|V V |V V
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
|Location | Location | Location |+ LO |Location | |Location | Location | Location |+ LO |Location |
|Generator |--------------->| Server(s)||-------------->|Recipient | |Generator |--------------->| Server(s)||-------------->|Recipient |
skipping to change at page 14, line 8 skipping to change at page 13, line 29
+----------+ +----------+| +----------+ +----------+ +----------+| +----------+
+----------+ +----------+
<-------------------------><---------------------------><-----------> <-------------------------><---------------------------><----------->
Positioning Distribution Use Positioning Distribution Use
Figure 3: Location Life-Cycle Figure 3: Location Life-Cycle
3.1. Positioning 3.1. Positioning
Positioning is the process by which the physical location of the Positioning is the process by which the physical location of the
Target is computed, based on some observations about the Target'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 Target, and the the positioning process is some information about the Device, and the
outcome is that the Location Generator knows the location of the outcome is that the Location Generator knows the location of the
Target. Device.
In this section, we give a brief taxonomy of current positioning In this section, we give a brief taxonomy of current positioning
systems, their requirements for protocol support, and the privacy and systems, their requirements for protocol support, and the privacy and
security requirements for positioning. security requirements for positioning.
3.1.1. Determination Mechanisms and Protocols 3.1.1. Determination Mechanisms and Protocols
While the specific positioning mechanisms that can be applied for a While the specific positioning mechanisms that can be applied for a
given Target are strongly dependent on the physical situation and given Device are strongly dependent on the physical situation and
capabilities of the Target, 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 Target-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
Target, 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 Target-based positioning mechanisms, the Target 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 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, or GNSS). In these
cases, the Target acts as its own Location Generator, and there are cases, the Device acts as its own Location Generator, and there are
no protocols required to support positioning (since no information no protocols required to support positioning (since no information
needs to be communicated). needs to be communicated).
In network-based positioning schemes, an external Location Generator In network-based positioning schemes, an external Location Generator
(an Internet host other than the Target) has access to sufficient (an Internet host other than the Device) has access to sufficient
information about the Target, through out-of-band channels, to information about the Device, through out-of-band channels, to
establish the position of the Target. The most common examples of establish the position of the Device. The most common examples of
this type of LG are entities that have a physical relationship to the this type of LG are entities that have a physical relationship to the
Target (such as ISPs). In wired networks, wiremap-based location is Device (such as ISPs). In wired networks, wiremap-based location is
a network-based technique; in wireless networks, timing and signal- a network-based technique; in wireless networks, timing and signal-
strength based techniques that use measurements from base stations strength based techniques that use measurements from base stations
are considered to be network-based. Large-scale IP-to-geo databases are considered to be network-based. Large-scale IP-to-geo databases
(for example, those based on WHOIS data or latency measurements) are (for example, those based on WHOIS data or latency measurements) are
also considered to be network-based positioning mechanisms. also considered to be network-based positioning mechanisms.
For network-based positioning as for Target-based, no protocols are For network-based positioning as for Device-based, no protocols are
strictly necessary to support positioning, since positioning strictly necessary to support positioning, since positioning
information is collected outside of the location distribution system information is collected outside of the location distribution system
(at lower layers of the network stack, for example). This does not (at lower layers of the network stack, for example). This does not
rule out the use of other Internet protocols (like SNMP) to collect rule out the use of other Internet protocols (like SNMP) to collect
inputs to the positioning process. Rather, since these inputs can inputs to the positioning process. Rather, since these inputs can
only be used by certain Location Generators to determine location, only be used by certain Location Generators to determine location,
they are not controlled as private information. Network-based they are not controlled as private information. Network-based
positioning often provides location to protocols by which the network positioning often provides location to protocols by which the network
informs a Target device of its own location (these are known as informs a Device of its own location (these are known as Location
Location Configuration Protocols, see Section 3.2.2 for further Configuration Protocols, see Section 3.2.2 for further discussion).
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 Target and an external Location positioning is divided between the Device and an external Location
Generator via some communication (possibly over the Internet), Generator via some communication (possibly over the Internet),
typically in one of two ways: typically in one of two ways:
o The Target provides measurements to the LG o The Device provides measurements to the LG
o The LG provides assistance data to the Device
o The LG provides assistance data to the Target
"Measurements" are understood to be observations about the Target'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 MAC
address of a first-hop router. "Assistance" is the complement to address of a first-hop router. "Assistance" is the complement to
measurement, namely the information that enables the computation of measurement, namely the information that enables the computation of
location based on measurements. A set of wireless base station location based on measurements. A set of wireless base station
locations (or wireless calibration information) would be an locations (or wireless calibration information) would be an
assistance datum, as would be a table that maps routers to buildings assistance datum, as would be a table that maps routers to buildings
in a corporate campus. 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 Target sends measurements (e.g., MAC addresses and systems, the Device sends measurements (e.g., MAC addresses and
signal strengths) to a Location Generator, and the Location Generator signal strengths) to a Location Generator, and the Location Generator
returns a location to the client. In wired networks, the Target can returns a location to the client. In wired networks, the Device can
send its MAC address to the Location Generator, which can query the send its MAC address to the Location Generator, which can query the
MAC-layer infrastructure to determine the switch and port to which MAC-layer infrastructure to determine the switch and port to which
that MAC address is connected, then query a wire map to determine the that MAC address is connected, then query a wire map to determine the
location at which the wire connected to that port terminates. location at which the wire connected to 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 Target measurements and assistance data. Systems in which the Device
provides the Location Generator with GNSS measurements are provides the Location Generator with GNSS measurements are
measurement-based, while those in which the assistance server provide measurement-based, while those in which the assistance server provide
ephemeris or alamanac data are assistance-based in the above ephemeris or alamanac data are assistance-based in the above
terminology. (Those familiar with GNSS positioning will note that terminology. (Those familiar with GNSS positioning will note that
there are of course cases in which both of these interactions occur there are of course cases in which both of these interactions occur
within a single location determination protocol, so the categories within a single location determination protocol, so the categories
are not mutually exclusive.) are not mutually exclusive.)
Naturally, the exchange of measurement or positioning data between Naturally, the exchange of measurement or positioning data between
the Target 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 Target, the LG, or both) is aware of the Target'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.
3.1.2. Privacy Considerations for Positioning 3.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 Target's identity. Local identifiers, unlinked
pseudonyms, or private identifiers that are not linked to the real pseudonyms, or private identifiers that are not linked to the real
identity of the Target should be used as forms of identity whenever identity of the Target should be used as forms of identity whenever
possible. This provides privacy protection by disassociating the possible. This provides privacy protection by disassociating the
location from the Target's identity before it is distributed. 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 Target's location (if the Target 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 they both have it). If the entity acting as the LG also
performs the role of LS, the privacy considerations in Section 3.2.4 performs the role of LS, the privacy considerations in Section 3.2.4
apply. 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 to these LSes while maintaining privacy, the relationship between the
LG and its set of LSes MUST be tightly constrained, effectively LG and its set of LSes MUST be tightly constrained, effectively
"hard-wired." That is, the LG MUST only provide location to a small "hard-wired." That is, the LG MUST only provide location to a small
fixed set of LSes, and each of these LSes MUST comply with the fixed set of LSes, and each of these LSes MUST comply with the
requirements of Section 3.2.4. requirements of Section 3.2.4.
3.1.3. Security Considerations for Positioning 3.1.3. Security Considerations for Positioning
Manipulation of the positioning process can expose location through Manipulation of the positioning process can expose location through
two mechanisms: If a third party can guess measurements that a given two mechanisms:
Target would send and use them to get the location of that Target, or
if a third party can obtain assistance data that indicate the rough 1) A third party could guess or derive measurements about a specific
position of the Target. To mitigate this risk, the LG should be able device and use them to get the location of that Device. To mitigate
to authenticate positioning clients (the Target or other information this risk, the LG should be able to authenticate and authorize
sources) in the sense of verifying that measurements presented by a devices providing measurements and, if possible, verify that the
client are likely to be the actual physical values measured by that presented measurements are likely to be the actual physical values
client (and likewise, that the requested assistance data are measured by that client. These security procedures rely on the type
consistent with the client's actual rough position). These of positioning being done, and may not be technically feasible in all
authentication mechanisms will necessarily rely on the nature of the
positioning being done, and may not be technically feasible in all
cases. cases.
In any case, protocols used for positioning must provide 2) By eavesdropping, a third party may be able to obtain measurements
confidentiality and integrity protections in order to prevent sent by the Device itself that indicate the rough position of the
Device. To mitigate this risk, protocols used for positioning must
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 positioning client and the LG. route between the Target and the LG.
If a Location Generator or a Target chooses to act as a Location If a Location Generator or a Target chooses to act as a Location
Server, it inherits the security requirements for an LS, described in Server, it inherits the security requirements for an LS, described in
Section 3.2.5. Section 3.2.5.
3.2. Location Distribution 3.2. Location Distribution
When an entity receives location (from an LG or an LS) and When an entity receives location (from an LG or an LS) and
redistributes it to other entities, it acts as a Location Server. redistributes it to other entities, it acts as a Location Server.
Location Distribution is the process by which one or more Location Location Distribution is the process by which one or more Location
Servers provide LOs to Location Recipients in a privacy-preserving Servers provide LOs to Location Recipients in a privacy-preserving
manner. manner.
The role of a Location Server is thus two-fold: First, it must The role of a Location Server is thus two-fold: First, it must
collect location information and Rules that control access to that collect location information and Rules that control access to that
information. Rules can be communicated within a Location Object, information. Rules can be communicated within a Location Object,
within a protocol that carries LOs, or through a separate protocol within a protocol that carries LOs, or through a separate protocol
that carries Rules. Second, the Location Server must process that carries Rules. Second, the Location Server must process
requests for location and apply the Rules to these requests in order requests for location and apply the Rules to these requests in order
skipping to change at page 20, line 11 skipping to change at page 19, line 26
retransmitted ("Retransmission"). A LO may contain a pointer to more retransmitted ("Retransmission"). A LO may contain a pointer to more
robust Rules, such as those shown in the set of four Rules at the robust Rules, such as those shown in the set of four Rules at the
beginning of this section. beginning of this section.
3.2.2. Location Configuration 3.2.2. Location Configuration
Some performing the Location Generator role are designed only to Some performing the Location Generator role are designed only to
provide Targets with their own locations (as opposed to distributing provide Targets with their own locations (as opposed to distributing
a Target's location to others). The process of providing a Target a Target's location to others). The process of providing a Target
with its own location is known within Geopriv as Location with its own location is known within Geopriv as Location
Configuration, and the LG that provides such location is often Configuration. The term Location Information Server (LIS) is often
described as a Location Information Server (LIS). Protocols used used to describe the entity that performs this function (although a
exclusively to communicate location from a LIS to a Target are known LIS may also perform other functions, such as providing a Target's
as Location Configuration Protocols [8]. Several such protocols have location to other entities).
been developed within Geopriv [9][10][11][12].
By definition, a LIS needs only to follow a simple privacy-preserving A Location Configuration Protocol (LCP) [8] is one mechanism that can
policy: transmit a Target's location only to the Target itself. This be used by a Device to discover its own location from a LIS. LCPs
is known as the "LCP policy." provide functions in the way they obtain, transport and deliver
location requests and responses between a LIS and a Device such that
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
developed within Geopriv [9][10][11][12].
A LIS whose sole purpose is to perform Location Configuration need
only follow a simple privacy-preserving policy: transmit a Target's
location only to the Target itself. This is known as the "LCP
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.
3.2.3. Location References 3.2.3. Location References
skipping to change at page 23, line 10 skipping to change at page 22, line 40
identity of the RM, respectively. In order to ensure the validity of identity of the RM, respectively. In order to ensure the validity of
this information, these protocols MUST allow for mutual 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, Location Objects necessarily As they travel through the Internet, Location Objects necessarily
pass through a sequence of intermediaries, ranging from layer-2 pass through a sequence of intermediaries, ranging from layer-2
switches to IP routers to application-layer proxies and gateways. switches to IP routers to application-layer proxies and gateways.
The ability of an LS to protect privacy by making access-control The ability of an LS to protect privacy by making access control
decisions is reduced if these intermediaries have access to a decisions is reduced if these intermediaries have access to a
Location Object as it travels between privacy-preserving entities. Location Object as it travels between privacy-preserving entities.
Protocols carrying LOs MUST provide end-to-end confidentiality Ideally, Location Objects should be transmitted with confidentiality
between an LS that transmits location and the LR that receives it. protection end-to-end between an LS that transmits location and the
When the protocol itself is protected end-to-end between the LS and LR that receives it. In some cases, the protocol conveying an LO
the recipient, carrying an unprotected Location Object within this provides confidentiality protection as a built-in security solution
encrypted channel is sufficient. When the protocol has a mode in for its signaling (and potentially its data traffic). In this case,
which messages are either unprotected or protected on a hop-by-hop carrying an unprotected Location Object within such an encrypted
basis (e.g., between intermediaries in a store-and-forward protocol), channel is sufficient. Many protocols, however, are offering
the protocol SHOULD allow the use of encrypted LOs, or for the communication modes where messages are either unprotected or
protected on a hop-by-hop basis (for example, between intermediaries
in a store-and-forward protocol). In such a case it is RECOMMENDED
that the protocol allows for the use of encrypted LOs, or for the
transmission of a reference to location in place of a LO [13]. transmission of a reference to location in place of a LO [13].
3.3. Location Use 3.3. Location Use
The primary privacy requirement of a Location Recipient is to The primary privacy requirement of a Location Recipient is to
constrain its usage of location to the set of uses authorized by the constrain its usage of location to the set of uses authorized by the
Rules in a LO. If an LR only uses a LO in ways that have minimal Rules in a LO. If an LR only uses a LO in ways that have minimal
privacy impact -- specifically, if it does not transmit the LO to any privacy impact -- specifically, if it does not transmit the LO to any
other entity, and does not retain the LO for longer than is required other entity, and does not retain the LO for longer than is required
to complete its interaction with the LS -- then no further action is to complete its interaction with the LS -- then no further action is
skipping to change at page 24, line 18 skipping to change at page 23, line 46
follow usage rules. When an LR receives a LO, it is REQUIRED to follow usage rules. When an LR receives a LO, it 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.
3.3.2. Security Considerations for Use 3.3.2. Security Considerations for Use
Since the Location Recipient role does not involve transmission of Since the Location Recipient role does not involve transmission of
location, there are no protocol security considerations required to location, there are no protocol security considerations required to
support privacy. support privacy (other than ensuring that data does not leak
unintentionally caused by security breaches).
Aside from privacy, Location Recipients often require some assurance Aside from privacy, Location Recipients often require some assurance
that a LO is reliable (assurance of the integrity, authenticity, and that a LO is reliable (assurance of the integrity, authenticity, and
validity of an LO), since LRs use LOs in order to deliver location- validity of an LO), since LRs use LOs in order to deliver location-
based services. Threats against this reliability and corresponding based services. Threats against this reliability and corresponding
mitigations are discussed in the Security Considerations below. mitigations are discussed in the Security Considerations below.
4. Security Considerations 4. Security Considerations
Security considerations related to the privacy of Location Objects Security considerations related to the privacy of Location Objects
are discussed throughout this document. In this section we summarize are discussed throughout this document. In this section we summarize
those concerns and consider security risks not related to privacy. those concerns and consider security risks not related to privacy.
The life-cycle of a Location Object often consists of a series of The life-cycle of a Location Object often consists of a series of
location transmissions. In a scenario where some intermediaries are location transmissions. Protocols that carry location can provide
untrusted, a location recipient may desire additional assurances that strong assurances, but only for a single segment of the Location
the LO was generated by a trusted LG, and not modified by these Object's life cycle. In particular, a protocol can provide integrity
untrusted entities. In this section, we first consider threats and protection and confidentiality for the data exchanged, and mutual
possible attacks against a Location Object throughout its entire life authentication of the parties involved in the protocol, by using a
cycle. We then describe the assurances that various parties require secure transport such as IPsec or TLS.
to mitigate these threats. Finally, we discuss possible mechanisms
that protocols or Location Object formats should make available to
provide such assurances.
4.1. Threats to Location Objects Additionally, if (1) the protocol provides mutual authentication for
every segment, and (2) every entity in the location distribution
chain exchanges information only with entities with whom it has a
trust relationship, entities can transitively obtain assurances
regarding the origin and ultimate destination of the Location Object.
Of course, direct assurances are always preferred over assurances
requiring transitive trust, since they require fewer assumptions.
The major threats to the end-to-end security of Location Objects can Using protocol mechanisms alone, the entities can receive assurances
be grouped into two categories: First, threats against the integrity only about a single hop in the distribution chain. For example,
and authenticity of Location Objects can expose entities that rely on suppose that an LR receives location from an LS over an integrity-
Location Objects to many types of fraud. Second, threats against the and confidentiality-protected channel. The LR knows that the
confidentiality of Location Objects can allow unauthorized access to transmitted LO has not been modified or observed en route. However,
location information. the assurances provided by the protocol do not guarantee that the
transmitted LO was not corrupted before it was sent to the LS (by a
previous LS, for example). Likewise, the LR can verify that the LO
was transmitted by the LS, but cannot verify the origin of the LO if
it did not originate with the LS.
4.1.1. Threats to Location Integrity and Authenticity Security mechanisms in protocols are thus unable to provide direct
assurances over multiple transmissions of a LO. However, the
transmission of location "by reference" can be used to effectively
turn multi-hop paths into single-hop paths. If the multiple
transmissions of a LO are replaced by multiple transmissions of a URI
(a multi-hop dissemination channel), the LO need only traverse a
single hop, namely the dereference transaction between the LR and the
dereference server.
The major threats to the security of Location Objects can be grouped
into two categories. First, threats against the integrity and
authenticity of Location Objects can expose entities that rely on
Location Objects. Second, threats against the confidentiality of
Location Objects can allow unauthorized access to location
information.
A Location Object contains four essential types of information: A Location Object contains four essential types of information:
Identifiers for the described Target, location information, time- identifiers for the described Target, location information, time-
stamps, and Rules. By grouping values of these various types stamps, and Rules. By grouping values of these various types
together within a single structure, a Location Object encodes a set together within a single structure, a Location Object encodes a set
of bindings among them. That is, the Location Object asserts that of bindings among them. That is, the Location Object asserts that
the identified Target was present at the given location at the given the identified Target was present at the given location at the given
time and that the given Rules express the Target's desired policy at time and that the given Rules express the Target's desired policy at
that time for the distribution of his location. Below, we provide a that time for the distribution of his location. Below, we provide a
set of attacks that a malicious party (an intermediate LS, an description of the assurances required by each party involved in the
eavesdropper on the path between LS and LR, or the Target himself) location distribution in order to mitigate the possible attacks on
might conduct to falsify one or more of the bindings asserted by the these bindings.
Location Object.
In all cases the Target identity provided in a Location Object should
be based on an authentication between the Target and the Location
Generator (an explicit authentication based on a shared secret, or an
implicit authentication based on the ability to receive a message,
for example). Therefore, the identity binding in a received Location
Object is only as strong as the authentication between the Target and
the Location Generator (that is, the Location Object can only attest
to the fact that someone at the given location is capable of
authenticating as the given identity). It is vital to the
authenticity of location information that this authentication be as
strong as is feasible in any deployment scenario. However,
mechanisms within a Geopriv Location Object or protocol can provide
no protection from attacks against this authentication mechanism and
thus we do not explicitly consider such attacks.
Place Shifting: Falsifying the location in an otherwise valid
Location Object. For example, Alice pretends that she is
currently in a location that she has never previously visited.
Time Shifting: Falsifying the time-stamp in an otherwise valid
Location Object. For example, Alice pretends that she is
currently in a location that she has not visited since last year.
Location Theft: Falsifying the identity in an otherwise valid
Location Object. For example, a malicious intermediary sees a
valid Location Object for Alice and produces a Location Object
asserting that Bob is at the given location at the given time.
Location-Identity Theft: Replaying a stale Location Object as though
it were current. For example, a malicious intermediary sees a
valid Location Object for Alice and replays it later to make it
seem that Alice has not moved.
Location Swapping: Two malicious Targets conspire to produce two
Location Objects asserting that each Target is at the other's
location. For example, Alice pretends that she is at Bob's
location and Bob pretends that he is at Alice's location. (Note
that this attack cannot be prevented if the two attackers are
willing to exchange authentication credentials. Because the
identity assertions in a Location Object are only as strong as the
Target authentication, the goal of Geopriv protocols is to ensure
that this attack is not possible unless both Alice and Bob can
successfully authenticate as the other.)
4.1.2. Threats to Location Privacy
In the Geopriv model, the privacy of location information is
protected by the application of Privacy Rules specified by authorized
Rule Makers and by confidentiality protection en route. (For more
information on Privacy Rule enforcement, see Section 3.2.4). Below,
we provide a set of attacks that a malicious party might conduct to
allow distribution of a Location Object to unauthorized parties.
Eavesdropping: An unauthorized party observes the Location Object in
transit. For example, a device on the path between a trusted LS
and an authorized LR observes a Location Object sent in the clear.
Rule Tampering: A malicious party modifies a Target's Privacy Rules
and thus causes a trusted LS to unknowingly distribute the
Location Object to unauthorized parties. For example, a device on
the path between an LG and a trusted LS deletes the Privacy Rules
contained in a Location Object and replaces them with a new set of
Rules authorizing all parties to receive the Location Object.
Server Impersonation: A malicious party impersonates a trusted
Location Server and then knowingly disregards the Privacy Rules.
For example, a man-in-the-middle between the LG and the trusted LS
pretends to be the trusted LS, and then proceeds to distribute the
Location Object to unauthorized entities.
4.2. Required Assurances
We now describe the assurances required by each party involved in
location distribution in order to mitigate the attacks described in
the previous two sections:
Rule Maker: The Rule Maker is responsible for distributing the Rule Maker: The Rule Maker is responsible for creating the Target's
Target's Privacy Rules to the location servers. The primary Privacy Rules and for uploading them to the location servers. The
assurance required by the Rule Maker is thus that the binding primary assurance required by the Rule Maker is that the Target's
between the Target's Privacy Rules and the Target's identity is Privacy Rules are correctly associated with the Target's identity
correctly conveyed to each location server that handles the when they are conveyed to each location server that handles the
Location Object. Ensuring the integrity of the Privacy Rules Location Object. Ensuring the integrity of the Privacy Rules
distributed to the location servers prevents rule-tampering distributed to the location servers prevents rule-tampering
attacks. In many circumstances, the privacy policy of the Target attacks. In many circumstances, the privacy policy of the Target
may itself be sensitive information; in these cases, the Rule may itself be sensitive information; in these cases, the Rule
Maker also requires the assurance that the binding between the Maker also requires the assurance that the binding between the
Target's identity and the Target's Privacy Rules are not deducible Target's identity and the Target's Privacy Rules are not deducible
by anyone other than an authorized Location Server. by anyone other than an authorized Location Server.
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
Location Server is that the binding between the Target's Privacy Location Server is that the binding between the Target's Privacy
Rules and the Target's identity is authentic. Authenticating the Rules and the Target's identity is authentic. Authenticating and
Rule Maker who created the Privacy Rules prevents rule-tampering authorizing the Rule Maker who creates, updates and deletes the
attacks. The second assurance required by the Location Server is Privacy Rules prevents rule-tampering attacks. The Location
that the binding between the Target's identity and the Target's Server has to ensure that the authorization policies are not
location are not deducible by any entity except as allowed the exposed to third parties, if so desired by the Rule Maker (when
Target's Privacy Rules. Ensuring the confidentiality of these the rules themselves are privacy-sensitive).
bindings prevents eavesdropping attacks. (Note that ensuring the
confidentiality of the Location Object also helps to mitigate
location-theft and location-identity-theft attacks, since it makes
it more difficult for an attacker to obtain a valid Location
Object to replay.)
Location Recipient: The Location Recipient is the consumer of the Location Recipient: The Location Recipient is the consumer of the
Location Object. The Location Recipient thus requires assurances Location Object. The Location Recipient thus requires assurances
about the authenticity of the bindings between the Target's about the authenticity of the bindings between the Target's
location, the Target's identity and the time. Ensuring the location, the Target's identity and the time. Ensuring the
authenticity of these bindings prevents place-shifting, time- authenticity of these bindings helps to prevent various attacks,
shifting, location-theft, and location-identity-theft attacks and such falsifying the location, modifying the time-stamp, faking the
mitigates location-swapping attacks to the greatest possible identity, replaying location objects.
extent.
Location Generator: The Location Generator shares responsibility for
protecting the Target's privacy. The primary assurance required
by the Location Generator is that the Location Server to which the
Location Object is initially published is one that is trusted to
enforce the Target's Privacy Rules. Authenticating the trusted
Location Server mitigates the risk of server impersonation
attacks. Additionally, in some scenarios, there may be no
Location Server which can be trusted to sufficiently safe-guard
the Target's location information, in which case the Location
Generator may require assurance that intermediate Location Servers
are unable to deduce the binding between the Target's identity and
the Target's location.
4.3. Protocol mechanisms
Protocols that carry location can provide strong assurances, but only
for a single segment of the Location Object's life cycle. In
particular, a protocol can provide integrity protection and
confidentiality for the data exchanged, and mutual authentication of
the parties involved in the protocol, by using a secure transport
such as IPsec or TLS.
Additionally, if (1) the protocol provides mutual authentication for
every segment; and (2) every entity in the location distribution
chain exchanges information only with entities with whom it has a
trust relationship, then entities can transitively obtain assurances
regarding the origin and ultimate destination of the Location Object.
Of course, direct assurances are always preferred over assurances
requiring transitive trust, since they require fewer assumptions.
Using protocol mechanisms alone, the entities can receive assurances
only about a single hop in the distribution chain. For example,
suppose that an LR receives location from an LS over an integrity-
and confidentiality-protected channel. The LR knows that the
transmitted LO has not been modified or observed en route. However,
the assurances provided by the protocol do not guarantee that the
transmitted LO was not corrupted before it was sent to the LS (by a
previous LS, for example). Likewise, the LR can verify that the LO
was transmitted by the LS, but cannot verify the origin of the LO if
it did not originate with the LS.
Security mechanisms in protocols are thus unable to provide direct
assurances over multiple transmissions of an LO. However, it should
be noted that the transmission of location "by reference" can be used
to effectively turn multi-hop paths into single-hop paths. If the
multiple transmissions of a LO are replaced by multiple transmissions
of URI (a multi-hop dissemination channel), then the LO need only
traverse a single hop, namely the dereference transaction between the
LR and the dereference server.
4.4. Mechanisms within the Location Object Location Generator: The primary assurance required by the Location
Generator is that the Location Server to which the Location Object
is initially published is one that is trusted to enforce the
Target's Privacy Rules. Authenticating the trusted Location
Server mitigates the risk of server impersonation attacks.
Additionally, the Location Generator is responsible for the
location determination process, which is also security sensible as
wrong input provided by external entites can lead to undesireable
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 Location Object format. Object can be provided directly through the Location Object format.
Additionally, the Location Object format can be used to authenticate RFC 4119 provides a description for usage of S/MIME to integrity and
the originator of a Location Object. In particular, integrity and confidentility protection. Although such direct, end-to-end
origin authentication can be assured by signing a Location Object assurances are desirable, and these mechanisms should be used
(e.g., using S/MIME or XMLSIG), and confidentiality can be assured by whenever possible, there are many deployment scenarios where directly
encrypting the Location Object using a public encryption key securing a Location Object is impractical. For example, in some
belonging to the intended recipient (e.g. using S/MIME). Recipients deployment scenarios a direct trust relationship may not exist
of Location Objects secured in this fashion can obtain assurance as between the creator of the Location Object and the recipient.
to the integrity and authenticity of the Location Object even after Additionally, in a scenario where many recipients are authorized to
it has been handled by untrusted intermediaries. Similarly, a receive a given Location Object, the creator of the Location Object
Location Server (or Location Generator) that guarantees cannot guarantee end-to-end confidentiality without knowing precisely
confidentiality in this fashion can be assured that the Location which recipient will receive the Location Object. Many of these
Object is protected from unauthorized viewing even in the presence of cases can, however, be addressed by the usage of a Location-by-
untrusted intermediaries. Reference (possibly combined with a location object).
Although such direct, end-to-end assurances are desirable, and these
mechanisms should be used whenever possible, there are many
deployment scenarios where directly securing a Location Object is
impractical. In particular, in some deployment scenarios a direct
trust relationship may not exist between the creator of the Location
Object and the recipient. Additionally, in a scenario where many
recipients are authorized to receive a given Location Object, the
creator of the Location Object cannot guarantee end-to-end
confidentiality without knowing precisely which recipient will
receive the Location Object.
An additional challenge in providing end-to-end authenticity
guarantees through signing of the Location Object is that in many
deployments different entities may assert different bindings within
the same Location Object. Consider, for example, a scenario where a
Location Generator produces a Location Object that asserts a binding
between a time, a location, and a pseudonym for the Target.
Additionally, a Rule Maker creates a binding between a set of Privacy
Rules and a public Target identity. A Location Server receives the
Rules binding from Rule Maker and the Location Object from the
Location Generator. The Location Server then generates a new
Location Object binding together the time, the location, the public
Target identity and the Privacy Rules. In such a scenario there is
no single entity who can directly assert the validity of the entire
Location Object. In such a case, a mechanism is needed within the
Location Object format that allows multiple originators to jointly
assert various components of the Location Object bindings.
5. Example Scenarios 5. Example Scenarios
This section contains a set of example of how the Geopriv This section contains a set of example 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 a LO carries are equivalent to those in a PIDF-LO Privacy Rules that a LO carries are equivalent to those in a PIDF-LO
Location Object (namely, that the principal Rules that can be set are Location Object (namely, that the principal Rules that can be set are
limits on the retransmission and retention of the LO). While these limits on the retransmission and retention of the LO). While these
two Rules are the most well-known and important examples, the two Rules are the most well-known and important examples, the
specific types of Rules an LS or LR must consider will in general specific types of Rules an LS or LR must consider will in general
depend on the types of LO it processes. depend on the types of LO it processes.
5.1. Minimal Scenario 5.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
Target 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 or SIP service (e.g., by including the LO in an HTTP POST request or SIP
INVITE message), and the server delivers that service immediately INVITE message), and the server delivers that service immediately
(e.g., in a 200 OK response in HTTP or SIP), without retaining or (e.g., in a 200 OK response in HTTP or SIP), without retaining or
retransmitting the Target's location. The Target acts as an LG by retransmitting the Device's location. The Device acts as an LG by
using a Target-based positioning algorithm (e.g., manual entry), as a using a Device-based positioning algorithm (e.g., manual entry) and
Rule Maker by specifying that the location should be sent to the as a Location Server by interpreting the rule and transmitting the
server, and as a Location Server by interpreting the rule and LO. The Target acts as a Rule Maker by specifying that the location
transmitting the LO. The server acts as a Location Recipient by should be sent to the server. The server acts as a Location
receiving and using the LO. Recipient by receiving 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 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
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 location in this
safe manner. safe manner.
The following outline summarizes this scenario: The following outline summarizes this scenario:
o Positioning: Target-based, Target=LG o Positioning: Device-based, Device=LG
o Distribution hop 1: HTTP UA --> Ephemeral web service, privacy via o Distribution hop 1: HTTP UA --> Ephemeral web service, privacy via
user indication 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 points:
* 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.
5.2. Location-based Web Services 5.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 location
specific information. To support these applications, browser specific information. To support these applications, browser
extensions have been developed that support Target-based positioning extensions have been developed that support Device-based positioning
(manual entry and GPS) and network-assisted positioning (via AGPS, (manual entry and GPS) and network-assisted positioning (via AGPS,
and multilateration with 802.11 and cellular signals), exposing and multilateration with 802.11 and cellular signals), exposing
position to web pages through Javascript APIs. position 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
skipping to change at page 31, line 35 skipping to change at page 28, line 26
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 a Location Generator. acts as a Location Generator.
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. LS, follows the LCP policy by providing location only to the Target.
The next hop in distribution occurs when the browser extension (an The next hop in distribution occurs when the browser extension (an
entity under the control of the Target) passes a LO to the web page entity under the control of the Target) passes a LO to the web page
(an entity under the control of its author). In this phase, the (an entity under the control of its author). In this phase, the
browser extension acts as an LS, with the user/Target as the sole browser extension acts as an LS, with the Target as the sole Rule
Rule Maker; the user interface for rule-making is effectively a Maker; the user interface for rule-making is effectively a protocol
protocol for conveying Rules, and the extension's API effectively for conveying Rules, and the extension's API effectively defines a a
defines a a way to communicate LOs and a LO Format. The web site way to communicate LOs and a LO Format. The web site acts as
acts as Location Recipient when the web page accepts the LO. Location Recipient 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 location, so its behavior is
skipping to change at page 32, line 23 skipping to change at page 29, line 13
if the LR needs to do something that is not allowed by the Rules, it if the LR needs to do something that is not allowed by the Rules, it
may have to deny service to the user (hopefully providing a message may have to deny service to the user (hopefully providing a message
with the reason). Nonetheless, if the Rules permit retention or with the reason). Nonetheless, if the Rules permit retention or
retransmission (even if this retransmission is limited by access retransmission (even if this retransmission is limited by access
control rules), then the LR may do so to the extent the Rules allow. 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/user) gives permission to sites and o Rule installation: RM (=Target) gives permission to sites and sets
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
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
skipping to change at page 37, line 5 skipping to change at page 33, line 34
A rule that describe which entities may receive location A rule that describe 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, ZIP code, county, state and country.
$ Device
The technical device whose location is tracked as a proxy for the
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 Rules that directs a Location Server about how to treat
a Target's location information. Local Rules are used internally a Target's location information. Local Rules are used internally
by a Location Server to handle requests from Location Recipients. by a Location Server to handle requests from Location Recipients.
skipping to change at page 39, line 14 skipping to change at page 35, line 46
A Privacy Rule that travels inside a Location Object. Forwarded A Privacy Rule that travels inside a Location Object. Forwarded
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 described by a An individual or other entity whose location is sought in the
Location Object. The Target is the entity whose privacy Geopriv Geopriv architecture. In many cases the Target will be the human
seeks to protect. 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
instances the Target will be the Device itself. The Target is 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 describe what uses of location information are
authorized. authorized.
7. Acknowledgements 7. Acknowledgements
Section 4 is largely based on the security investigations conducted Section 4 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 [8]. We would like to thank all the members of team, which produced [8]. 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
contributions regarding terminology and LCPs.
8. IANA Considerations 8. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
9. References 9. References
9.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.
skipping to change at page 40, line 15 skipping to change at page 36, line 49
[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] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk, [5] 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.
[6] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., and [6] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., and
J. Polk, "Geolocation Policy: A Document Format for Expressing J. Polk, "Geolocation Policy: A Document Format for Expressing
Privacy Preferences for Location Information", Privacy Preferences for Location Information",
draft-ietf-geopriv-policy-20 (work in progress), February 2009. draft-ietf-geopriv-policy-21 (work in progress), July 2009.
[7] Rosenberg, J., "The Extensible Markup Language (XML) [7] Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)", RFC 4825, May 2007. Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[8] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location [8] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location
Configuration Protocol; Problem Statement and Requirements", Configuration Protocol; Problem Statement and Requirements",
draft-ietf-geopriv-l7-lcp-ps-09 (work in progress), draft-ietf-geopriv-l7-lcp-ps-10 (work in progress), July 2009.
February 2009.
[9] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host [9] 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.
[10] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 [10] 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.
[11] Polk, J., "Dynamic Host Configuration Protocol (DHCP) IPv4 and [11] 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-04 (work in progress), draft-ietf-geopriv-dhcp-lbyr-uri-option-06 (work in progress),
March 2009. September 2009.
[12] Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, "HTTP [12] Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, "HTTP
Enabled Location Delivery (HELD)", Enabled Location Delivery (HELD)",
draft-ietf-geopriv-http-location-delivery-15 (work in draft-ietf-geopriv-http-location-delivery-16 (work in
progress), June 2009. progress), August 2009.
[13] Marshall, R., "Requirements for a Location-by-Reference [13] Marshall, R., "Requirements for a Location-by-Reference
Mechanism", draft-ietf-geopriv-lbyr-requirements-07 (work in Mechanism", draft-ietf-geopriv-lbyr-requirements-08 (work in
progress), February 2009. progress), September 2009.
[14] World Wide Web Consortium, "The XMLHttpRequest Object", W3C [14] World Wide Web Consortium, "The XMLHttpRequest Object", W3C
document http://www.w3.org/TR/XMLHttpRequest/, April 2008. document http://www.w3.org/TR/XMLHttpRequest/, April 2008.
[15] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, "Framework [15] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, "Framework
for Emergency Calling using Internet Multimedia", for Emergency Calling using Internet Multimedia",
draft-ietf-ecrit-framework-09 (work in progress), March 2009. draft-ietf-ecrit-framework-10 (work in progress), July 2009.
[16] Rosen, B. and J. Polk, "Best Current Practice for [16] Rosen, B. and J. Polk, "Best Current Practice for
Communications Services in support of Emergency Calling", Communications Services in support of Emergency Calling",
draft-ietf-ecrit-phonebcp-11 (work in progress), June 2009. draft-ietf-ecrit-phonebcp-13 (work in progress), July 2009.
[17] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, [17] 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.
[18] Schulzrinne, H., "Location-to-URL Mapping Architecture and [18] Schulzrinne, H., "Location-to-URL Mapping Architecture and
Framework", draft-ietf-ecrit-mapping-arch-04 (work in Framework", draft-ietf-ecrit-mapping-arch-04 (work in
progress), March 2009. progress), March 2009.
[19] Peterson, J., "A Presence-based GEOPRIV Location Object [19] Peterson, J., "A Presence-based GEOPRIV Location Object
 End of changes. 83 change blocks. 
412 lines changed or deleted 300 lines changed or added

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