Request for Comments: 3693 Siemens AG
Category: Informational J. Morris
Center for Democracy & Technology
D. Mulligan
Samuelson Law, Technology & Public Policy Clinic
J. Peterson
NeuStar
J. Polk
Cisco
February 2004
Geopriv Requirements
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
Location-based services, navigation applications, emergency services,
management of equipment in the field, and other location-dependent
services need geographic location information about a Target (such as
a user, resource or other entity). There is a need to securely
gather and transfer location information for location services, while
at the same time protect the privacy of the individuals involved.
This document focuses on the authorization, security and privacy
requirements for such location-dependent services. Specifically, it
describes the requirements for the Geopriv Location Object (LO) and
for the protocols that use this Location Object. This LO is
envisioned to be the primary data structure used in all Geopriv
protocol exchanges to securely transfer location data.
Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in this Document. . . . . . . . . . . . . . . 4
3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Primary Geopriv Entities . . . . . . . . . . . . . . . . . . . 6
5. Further Geopriv Terminology. . . . . . . . . . . . . . . . . . 7
5.1. Location Information and Sighting. . . . . . . . . . . . 7
5.2. The Location Object and Using Protocol . . . . . . . . . 9
5.3. Trusted vs. Non-trusted Data Flows . . . . . . . . . . . 10
5.4. Further Geopriv Principals . . . . . . . . . . . . . . . 10
5.5. Privacy Rules. . . . . . . . . . . . . . . . . . . . . . 12
5.6. Identifiers, Authentication and Authorization. . . . . . 13
6. Scenarios and Explanatory Discussion . . . . . . . . . . . . . 15
7. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1. Location Object. . . . . . . . . . . . . . . . . . . . . 19
7.2. The Using Protocol . . . . . . . . . . . . . . . . . . . 21
7.3. Rule based Location Data Transfer. . . . . . . . . . . . 21
7.4. Location Object Privacy and Security . . . . . . . . . . 22
7.4.1. Identity Protection. . . . . . . . . . . . . . . 22
7.4.2. Authentication Requirements. . . . . . . . . . . 23
7.4.3. Actions to be secured. . . . . . . . . . . . . . 23
7.5. Non-Requirements . . . . . . . . . . . . . . . . . . . . 24
8. Security Considerations. . . . . . . . . . . . . . . . . . . . 24
8.1. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 24
8.2. Securing the Privacy Rules . . . . . . . . . . . . . . . 24
8.3. Emergency Case . . . . . . . . . . . . . . . . . . . . . 24
8.4. Identities and Anonymity . . . . . . . . . . . . . . . . 25
8.5. Unintended Target. . . . . . . . . . . . . . . . . . . . 26
9. Protocol and LO Issues for later Consideration . . . . . . . . 26
9.1. Multiple Locations in one LO . . . . . . . . . . . . . . 26
9.2. Translation Fields . . . . . . . . . . . . . . . . . . . 26
9.3. Truth Flag . . . . . . . . . . . . . . . . . . . . . . . 27
9.4. Timing Information Format. . . . . . . . . . . . . . . . 27
9.5. The Name Space of Identifiers. . . . . . . . . . . . . . 27
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
11.1. Normative Reference . . . . . . . . . . . . . . . . . . 28
11.2. Informative References . . . . . . . . . . . . . . . . . 28
12. Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . 29
13. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 30
1. Overview
Location-based services (applications that require geographic
location information as input) are becoming increasingly common. The
collection and transfer of location information about a particular
Target can have important privacy implications. A key goal of the
protocol described in this document is to facilitate the protection
of privacy pursuant to Privacy Rules set by the "user/owner of the
Target" (or, more precisely in the terminology of this document given
in Section 3 and 5.4 below, the "Rule Maker").
The ability to gather and generate a Target’s location, and access to
the derived or computed location, are key elements of the location-
based services privacy equation. Central to a Target’s privacy are
(a) the identity of entities that have access to raw location data,
derive or compute location, and/or have access to derived or computed
location information, and (b) whether those entities can be trusted
to know and follow the Privacy Rules of the user.
The main principles guiding the requirements described in this
document are:
1) Security of the transmission of Location Object is essential to
guarantee the integrity and confidentiality of the location
information. This includes authenticating the sender and receiver
of the Location Object, and securing the Location Object itself.
2) A critical role is played by user-controlled Privacy Rules, which
describe the restrictions imposed or permissions given by the
"user" (or, as defined below, the "Rule Maker"). The Privacy
Rules specify the necessary conditions that allow a Location
Server to forward Location Information to a Location Recipient,
and the conditions and purposes for which the Location Information
can be used.
3) One type of Privacy Rules specify how location information should
be filtered, depending on who the recipient is. Filtering is the
process of reducing the precision or resolution of the data. A
typical rule may be of the form: "my location can only be
disclosed to the owner of such credentials in such precision or
resolution" (e.g., "my co-workers can be told the city I am
currently in").
4) The Location Object should be able to carry a limited but core set
of Privacy Rules. The exact form or expressiveness of those Rules
in the core set or in the full set is not further discussed in
this document, but will be discussed more extensively in future
documents produced by this working group.
5) Whenever appropriate, the location information should not be
linked to the real identity of the user or a static identifier
easily linked back to the real identity of the user (i.e.,
Personally Identifiable Information such as a name, mailing
address, phone number, social security number, or email address or
username). Rather, the user should be able to specify which local
identifier, unlinked pseudonym, or private identifier is to be
bound to the location information.
6) The user may want to hide the real identities of himself and his
partners, not only to eavesdroppers but also to other entities
participating in the protocol.
Although complete anonymity may not be appropriate for some
applications because of legal constraints or because some location
services may in fact need explicit identifications, most often the
location services only need some type of authorization information
and/or perhaps anonymous identifiers of the entities in question.
2. Conventions Used in this Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Note that the requirements discussed here are requirements on the
generic Location Object and on using protocols for location services.
Thus, for the most part, the requirements discussed in this document
refer to capabilities that are mandatory-to-implement. For example,
requiring that implementations support integrity is not the same
thing as requiring that all protocol traffic be authenticated. In
contrast, an example of a mandatory-to-use (not just mandatory-to-
implement) requirement might be one that states that the user always
receives a notice when his location data was not authenticated. This
practice is mandatory-to-use, not just to implement.
3. Glossary
For easy reference and readability, below are basic terms that will
be defined more formally and fully later in this document.
Location Generator (LG): The entity that initially determines or
gathers the location of the Target and creates Location Objects
describing the location of the Target.
Location Object (LO): An object conveying location information
(and possibly privacy rules) to which Geopriv security
mechanisms and privacy rules are to be applied.
Location Recipient (LR): The entity that receives location
information. It may have asked for this location explicitly
(by sending a query to a location server), or it may receive
this location asynchronously.
Location Server (LS): The entity to which a LG publishes location
objects, the recipient of queries from location receivers, and
the entity that applies rules designed by the rule maker.
Precision: The number of significant digits to which a value has
been reliably measured.
Principal: The holder/subject of the credentials, e.g., a
workstation user or a network server.
Resolution: The fineness of detail that can be distinguished in a
measured area. Applied to Geopriv this means the finite area
within provided and closed borders (ex. Latitude and Longitude
boundaries).
Rule Holder: The entity that provides the rules associated with a
particular target for the distribution of location information.
It may either ’push’ rules to a location server, or a location
server may ’pull’ rules from the Rule Holder.
Rule Maker: The authority that creates rules governing access to
location information for a target (typically, this it the
target themselves).
Rule, or Privacy Rule: A directive that regulates an entity’s
activities with respect to location information, including the
collection, use, disclosure, and retention of location
information.
Target: A person or other entity whose location is communicated by
a Geopriv Location Object.
Using Protocol: A protocol that carries a Location Object.
Viewer: A Principal that consumes location information that is
communicated by a Geopriv Location Object, but does not pass
this information further.
Resolution and Precision are very close terms. Either quality can be
’reduced’ to coarsen location information: ’resolution’ by defining a
off-center perimeter around a user’s location or otherwise enlarging
the area in consideration (from state to country, say) and
’precision’ by discarding significant digits of positioning
information (rounding off longitude and latitude from seconds to
minutes, say). Another WG document discusses this topic in much more
detail.
4. Primary Geopriv Entities
The following picture shows the primary Geopriv entities in a simple
and basic architecture, without claim of completeness or any
suggestion that the entities identified must in all cases be
physically separate entities.
+----------+
| Rule |
| Holder |
| |
+----+-----+
|
rule|interface
V
+----------+ +----------+ +----------+
|Location | publication | Location | notification |Location |
|Generator +-------------->| Server +-------------->|Recipient |
| | interface | | interface | |
+----------+ +----------+ +----------+
The four primary Entities are described as follows:
Location Generator (LG): The entity that initially determines or
gathers the location of the Target and creates Location Objects
describing that location. LGs publish Location Objects to
Location Servers. The manner in which the Location Generator
learns of Location Information is outside the scope of the
Geopriv Protocol.
Location Server (LS): The LS is an element that receives
publications of Location Objects from Location Generators and
may receive subscriptions from Location Recipients. The LS
applies the rules (which it learns from the Rule Holder) to LOs
it receives from LGs, and then notifies LRs of resulting LOs as
necessary.
Location Recipient (LR): The LR is an element that receives
notifications of Location Objects from Location Servers. The
LR may render these LOs to a user or automaton in some fashion.
Rule Holder (RH): The RH is an element that houses Privacy Rules
for receiving, filtering and distributing Location Objects for
specific Targets. An LS may query an RH for a set of rules, or
rules may be pushed from the RH to an LS. The rules in the
Rule Holder are populated by the Rule Maker.
Thus Location Generation is the process of gathering Location
Information, perhaps from multiple sources, at an IP-based Geopriv
Entity, the LG, which communicates with other Geopriv Entities.
Rules MUST be authenticated and protected. How this is done and in
particular how to distribute the keys to the RM and other authorities
is outside of the scope of this document. See also Section 8.2,
"Securing the Privacy Rules".
The interfaces between the Geopriv entities are not necessarily
protocol interfaces; they could be internal interfaces within a
single composed device. In some architectures, the Location
Generator, Rule Holder, and Location Server might all be implemented
in the same device. There may be several Rule Holders that enforce
the Privacy Rules at a particular Location Server.
5. Further Geopriv Terminology
The terminology and definitions detailed below include both terms
that, besides the primary Geopriv entities, (1) are used in the
requirements section of this document, and (2) provide additional
detail about the usage model envisioned for the Geopriv Location
Object. These latter terms will be utilized in a separate scenarios
document and elsewhere.
5.1. Location Information and Sighting
The focus of the Geopriv working group is on information about a
Target’s location that is NOT based on generally or publicly
available sources, but instead on private information provided or
created by a Target, a Target’s Device, or a Target’s network or
service provider. Notwithstanding this focus on private location
information, the Geopriv Location Object could certainly be used to
convey location information from publicly available sources.
Location Information: A relatively specific way of describing
where a Device is located.
This Location Information may have been determined in many different
ways, including:
(a) derived or computed from information generally not available to
the general public (such as information mainly available to a network
or service provider), (b) determined by a Device that may not be
generally publicly addressable or accessible, or (c) input or
otherwise provided by a Target.
As examples, the Location Information could include (a) information
calculated by triangulating on a wireless signal with respect to cell
phone towers, (b) longitude and latitude information determined by a
Device with GPS (global positioning satellite) capabilities, (c)
information manually entered into a cell phone or laptop by a Target
in response to a query, or (d) automatically delivered by some other
IP protocol, such as at device configuration via DHCP.
Excluded from this definition is the determination of location
information wholly without the knowledge or consent of the Target (or
the Target’s network or access service provider), based on generally
available information such as an IP or e-mail address. In some
cases, information like IP address can enable someone to estimate (at
least roughly) a location. Commercial services exist that provide
rough location information based on IP addresses. Currently, this
type of location information is typically less precise than the type
of location information addressed in this document. Although this
type of location computation still raises significant potential
privacy and public privacy concerns, such scenarios are generally
outside the scope of this document.
Within any given location-based transaction, the INITIAL
determination of location (and thus the initial creation of Location
Information) is termed a Sighting:
Sighting:
The initial determination of location based on non-public
information (as discussed in the definition of Location
Information), and the initial creation of Location Information.
Some variant of the sighting information is included in the Location
Object. Abstractly, it consists of two separate data fields:
(Identifier, Location)
where Identifier is the identifier assigned to a Target being
sighted, and Location is the current position of that Target being
sighted. Not all entities may have access to exactly the same piece
of sighting information. A sighting may be transformed to a new
sighting pair:
(Identifier-1, Location-1)
before it is provided by a Location Generator or Location Server to
Location Recipient. In this case, Identifier-1 may be a Pseudonym,
and Location-1 may have less precision or resolution than the
original value.
5.2. The Location Object and Using Protocol
A main goal of the Geopriv working group is to define a Location
Object (LO), to be used to convey both Location Information and basic
privacy-protecting instructions:
Location Object (LO): This data contains the Location Information
of the Target, and other fields including an identity or
pseudonym of the Target, time information, core Privacy Rules,
authenticators, etc. Most of the fields are optional,
including the Location Information itself.
Nothing is said about the semantics of a missing field. For
instance, a partially filled object MAY be understood implicitly as a
request to complete it. Or, if no time information is included, this
MAY implicitly mean "at the current time" or "at a very recent time",
but it could be interpreted in a different way, depending on the
context.
The "using protocol" is the protocol that uses (reads or modifies)
the Location Object. A protocol that just transports the LO as a
string of bits, without looking at them (like an IP storage protocol
could do), is not a using protocol, but only a transport protocol.
Nevertheless, the entity or protocol that caused the transport
protocol to move the LO is responsible for the appropriate
distribution, protection, usage, retention, and storage of the LO
based on the rules that apply to that LO.
The security and privacy enhancing mechanisms used to protect the LO
are of two types: First, the Location Object definition MUST include
the fields or mechanisms used to secure the LO as such. The LO MAY
be secured, for example, using cryptographic checksums or encryption
as part of the LO itself. Second, the using protocol may also
provide security mechanisms to securely transport the Location
Object.
When defining the LO, the design should observe that the security
mechanisms of the Location Object itself are to be preferred. Thus
the definition of the LO MUST include some minimal crypto
functionality (Req. 14 and 15). Moreover, if the RM specifies the
use of a particular LO security mechanism, it MUST be used (Req. 4).
5.3. Trusted vs. Non-trusted Data Flows