Network Working Group J. Cuellar
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.
Cuellar, et al. Informational [Page 1]
RFC 3693 Geopriv Requirements February 2004
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
Cuellar, et al. Informational [Page 2]
RFC 3693 Geopriv Requirements February 2004
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.
Cuellar, et al. Informational [Page 3]
RFC 3693 Geopriv Requirements February 2004
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.
Cuellar, et al. Informational [Page 4]
RFC 3693 Geopriv Requirements February 2004
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.
Cuellar, et al. Informational [Page 5]
RFC 3693 Geopriv Requirements February 2004
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.
Cuellar, et al. Informational [Page 6]
RFC 3693 Geopriv Requirements February 2004
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