Hi,
here is the preliminary -02 version of the geopriv-reqs:
draft-ietf-geopriv-reqs-02.txt
The changes to -01 are relatively minor and try to reflect the
discussions in Atlanta.
If you have comments (or text you would like to see!),
please send them as soon as possible.
I would like to submit the draft still in this year :)
Best wishes for next year!
Jorge
-----------------------cut here-----------------------------
Internet Draft J. Cuellar
Document: draft-ietf-geopriv-reqs-02.txt Siemens AG
John B. Morris, Jr.
Center for Democracy and Technology
D. Mulligan
Samuelson Law, Technology, and Public Policy Clinic
Expires in six months December 2002
Geopriv requirements
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2001). 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 protecting the privacy of the
individuals involved.
Cuellar, Morris, Mulligan 1
Geopriv Requirements Dec 2002
This document focuses on the authorization, integrity and privacy
requirements for such location-dependent services. Specifically, it
describes the requirements for the geopriv Location Object (used to
securely transfer location data and other privacy-enabling
information) and for the protocols that use this Location Object.
Table of Contents
1. Overview........................................................3
2. Conventions used in this document...............................4
3. Terminology.....................................................4
3.1. Foundational Definitions...................................4
3.1.1. Location Information (LI) and Sighting................4
3.1.2. The Location Object...................................6
3.1.3. Location Object vs. Using Protocol....................6
3.1.4. Trusted vs. Non-trusted Data Flows....................6
3.2. Geopriv Entities and Functions.............................7
3.2.1. Primary Geopriv Entities..............................7
3.2.2. Secondary Geopriv Entities............................8
3.2.3. Geopriv Data Storage Functions........................9
3.3. Privacy Policies and Rules.................................9
3.4. Identifiers, Authentication and Authorization.............10
4. Scenarios and Explanatory Discussion...........................11
4.1. Scenarios of Data Flow....................................11
5. Requirements...................................................14
5.1. Location Object...........................................15
5.2. The Using Protocol........................................16
5.3. Policy based Location Data Transfer.......................17
5.4. Location Object Privacy and Security......................18
5.5. Identity Protection.......................................18
5.6. Authentication Requirements...............................18
5.7. Actions to be secured.....................................18
5.8. Non-Requirements..........................................19
6. Security Considerations........................................19
6.1. Traffic Analysis..........................................19
6.2. Securing the Privacy Policies.............................19
6.3. Emergency Case............................................20
6.4. Identities and Anonymity..................................20
6.5. Unintended Target.........................................21
7. Acknowledgements...............................................21
8. References.....................................................21
9. Protocol and LO Issues for later Consideration.................22
9.1. Multiple Locations in one LO..............................22
9.2. Translation Fields........................................22
9.3. Specifying Desired Accuracy in a Request..................22
9.4. Truth Flag................................................22
Cuellar, Morris, Mulligan 2
Geopriv Requirements Dec 2002
9.5. Timing Information Format.................................22
9.6. The Name Space of Identifiers.............................22
10. Author's Addresses............................................23
11. Full Copyright Statement......................................23
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 Device and/or Target can have important privacy
implications. A key goal of the protocols described in this
document is to facilitate the protection of privacy pursuant to
privacy policies set by the "user" (or, more precisely in the
terminology of this document defined in Section 3 below, the "Rule
Maker").
The ability to derive or compute a Device'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 policy 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 policies, which
describe the restrictions imposed or permissions given by the
"user" (or, as defined below, the "Rule Maker"). The policies
specify the necessary conditions that allow a Location Server to
forward Location Information to a Location Recipient, and the
conditions under which and purposes for which the Location
Information can be used.
3) The Location Object should be able to carry a limited but core
set of privacy policies. The exact form or expressiveness of
policies in the core set or in the full set is not further
discussed in this paper, but is discussed more extensively in a
separate document.
4) 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 (e.g., the
phone number). Rather, the user should be able to specify which
Cuellar, Morris, Mulligan 3
Geopriv Requirements Dec 2002
local identifier, unlinked pseudonym, or private identifier is to
be bound to the location information.
5) 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, in most cases
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 the using protocols for location
services. Thus the requirements discussed in this document mostly
refer to the 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 other cases, the requirement may be that the user always obtains
a notice when his location data was not authenticated. This practice
is mandatory-to-use, not just to implement.
3. Terminology
The terminology and definitions detailed below include both (1)
terms used in the requirements section of this document, and (2)
terms that provide additional detail about the usage model
envisioned for the geopriv Location Object. These latter terms will
be utilized in a separate scenarios document.
3.1. Foundational Definitions
3.1.1. Location Information (LI) 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:
Location Information (LI):
A relatively specific way of describing where a Device is
located and that is (a) derived or computed from information
generally not available to the general public (such as
Cuellar, Morris, Mulligan 4
Geopriv Requirements Dec 2002
information mainly available to a network or service
provider), (b) determined by a Device that may be not
generally publicly addressable or accessible, or (c) input or
otherwise provided by a Target.
As examples, LI 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, or (c)
information manually entered into a cell phone or laptop by a Target
in response to a query.
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 offer to provide rough location information based on IP
address. Currently, this type of location information is typically
less accurate and has a coarser granularity than the type of
location information addressed in this document. Although this type
of location computation still raises significant potential privacy
and public policy 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 Sighter or Location Server to
another Location Recipient (for instance, another Location Server).
Cuellar, Morris, Mulligan 5
Geopriv Requirements Dec 2002
In this case, Identifier-1 may be Pseudonym, and Location-1 may have
less accuracy or granularity than the original value.
3.1.2. The Location Object
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
policies, 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
the 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.
3.1.3. Location Object vs. Using Protocol
The "using protocol" is the protocol that uses (creates, 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 of the correct
distribution, protection, usage, retention, and storage of the LO.
The security and privacy enhancing mechanisms used to protect the LO
are of two types: First, the Location Object definition MUST
include (optional) 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.
The security mechanisms of the Location Object itself are to be
preferred.
3.1.4. Trusted vs. Non-trusted Data Flows
Location information can be used in very different environments. In
some cases the participants will have longstanding relationships,
while in others participants may have discrete interactions with no
prior contractual or other contact.
The different relationships raise different concerns for the
implementation of privacy rules, including the need to communicate
Cuellar, Morris, Mulligan 6
Geopriv Requirements Dec 2002
privacy policies. A public Rule Repository, for example, may be
unnecessary in a trusted environment where more efficient methods of
addressing privacy issues exist. The following terms distinguish
between the two basic types of data flows:
Trusted Data Flow:
A data flow that is governed by a pre-existing contractual
relationship that addresses location privacy.
Non-trusted Data Flow:
The data flow is not governed by a pre-existing contractual
relationship that addresses location privacy.
3.2. Geopriv Entities and Functions
The entities of a geopriv application or transaction may be given
explicit roles:
3.2.1. Primary Geopriv Entities
Certain entities and roles are involved in most (and in some cases
all) geopriv transactions:
Target:
The entity whose location is desired by the Location Seeker.
In many cases the Target will be the human "user" of a Device
or an object such as a vehicle or shipping container to which
the Device is attached. In some instances the Target will be
the Device itself.
Device:
The technical device the location of which is tracked as a
proxy for the location of a Target. A Device might, for
example, be a cell phone, a Global Positioning Satellite (GPS)
receiver, a laptop equipped with a wireless access Device, or
a transmitter that emits a signal that can be tracked or
located. In some situations, such as when a Target manually
inputs location information (perhaps with a web browser), the
Target is effectively performing the function of a Device.
Rule Maker:
The individual or entity that has the authorization to set the
applicable privacy policies and rules. In many cases this
will be the owner of the Device, and in other cases this may
be the user who is in possession of the Device. For example,
parents may control what happens to the location information
derived from a child's cell phone. A company, in contrast, may
own and provide a cell phone to an employee but permit the
employee to set the privacy rules.
Cuellar, Morris, Mulligan 7
Geopriv Requirements Dec 2002
Location Seeker (LSeek):
An individual or entity who seeks to receive location data
about a Target.
A Location Seeker may act in one or more of the following more
specialized roles: as the Location Sighter, a Location Server, or as
an Ultimate Location Recipient:
Location Sighter (LoSi), or Location Data-Source
The original source of the sighting of a Target in a given
transaction.
Location Server (LServ), or Intermediate Location Recipient:
A Device or entity that provides access to Location
Information (possibly after processing or altering it) in
accordance with the privacy policies of the Rule Maker. Some
location tracking scenarios may involve a Target, Device, or
Device user performing the function of a Location Server.
Ultimate Location Recipient (ULR):
An individual or entity who receives location data about a
Target and does not transmit the location information or
information based on the Target's location (such as driving
directions to or from the Target) to any party OTHER than the
Target or the Rule Maker.
3.2.2. Secondary Geopriv Entities
Certain entities and functions are present or involved in only a
subset of geopriv transactions:
Data Transporter:
An entity or network that receives and forwards data without
processing or altering it. A Data Transporter could
theoretically be involved in almost any transmission between a
Device and a Location Server, a Location Server and a second
Location Server, or a Location Server and an Ultimate Location
Recipient. Some location tracking scenarios may not involve a
Data Transporter.
Initial Access Provider (IAP):
The entity that provides the initial network access or other
data communications services essential for the operation of
communications functions of the Device or computer equipment
in which the Device operates. Often, the IAP -- which will be
a wireless carrier, an Internet Service Provider, or an
internal corporate network -- will be identical to the LoSi.
In other cases the IAP has a "dumb" LoSi, one that transmits
geopriv data but does not implement or use any part of the
geopriv Location Object. Other cases may involve no IAP at
all or the IAP is only a Data Transporter.
Cuellar, Morris, Mulligan 8
Geopriv Requirements Dec 2002
3.2.3. Geopriv Data Storage Functions
Within the geopriv framework, certain data may be stored in various
functional entities:
Rule (or Policy) Storage
A storage used to store privacy-protecting policies, and
perhaps identifiers, credentials or keys. A Private Rule
Storage could be operated by a Device, a Location Server, or a
third party service provider.
How policies are authenticated and otherwise protected is outside of
the scope of this document, but see the remarks in Section 6
(Privacy Considerations).
Location Storage:
A Device or entity that stores raw or processed Location
Information for any period of time longer than the duration
necessary to complete an immediate transaction regarding the
LI.
The existence and data storage practices of Location Storage is
crucial to privacy considerations, because this may influence what
Location Information could eventually be revealed (through later
distribution, technical breach, or legal processes).
3.3. Privacy Policies and Rules
Privacy Policies are rules that regulate an entity's activities with
respect to location and other information, including, but not
limited to, the collection, use, disclosure, and retention of
location information. Such rules are generally based on fair
information practices, as detailed in (for example) the OECD
Guidelines on the Protection of Privacy and Transporter Flows of
Personal Data [OECD].
Privacy Policy or Privacy Rule:
A rule or set of rules that regulate an entity's activities
with respect to location information, including the
collection, use, disclosure, and retention of location
information. In particular, the policy describes how location
information may be used by an entity and which transformed
location information may be released to which entities under
which conditions. Policies must be obeyed; they are not
advisory.
A full set of Privacy Rules will likely include both rules that have
only one possible technical meaning, and rules that will be affected
by a locality's prevailing laws and customs. For example, a
distribution rule of the form "my location can only be disclosed to
the owner of such credentials and in such accuracy" has clear-cut
implications for the protocol that uses the LO. But other rules,
Cuellar, Morris, Mulligan 9
Geopriv Requirements Dec 2002
like retention or usage policies, may have unclear technical
consequences for the protocol or for the involved entities. For
example, the precise scope of a retention rule stating "you may not
store my location for more than 2 days" may in part turn on local
laws or customs.
3.4. Identifiers, Authentication and Authorization
Anonymity is the property of being not identifiable (within a set of
subjects). Anonymity serves as the base case for privacy: without
the ability to remain anonymous, individuals cannot control their
own privacy. Unlinkability ensures that a user may make multiple
uses of resources or services without others being able to link
these uses together. Unlinkability requires that entities are
unable to determine whether the same user caused certain specific
operations in the system. [ISO99] A pseudonym is simply a bit
string which is unique as ID and is suitable to be used for end-
point authentication.
Unlinked Pseudonym:
A pseudonym where the linking between the pseudonym and its
holder is, at least initially, not known to anybody with the
possible exception of the holder himself or a trusted server
of the user. See [Pfi01] (there the term is called Initially
Unlinked Pseudonym)
The word authentication is used in different meanings. Some require
that authentication associates an entity with a more or less well-
known identity. This basically means that if A authenticates
another entity B as being "id-B", then the label "id-B" is a well-
known, or at least a linkable identity of the entity. In this case,
the label "id-B" is called a publicly known identifier, and the
authentication is "explicit":
Explicit Authentication:
The act of verifying a claimed identity as the sole originator
of a message (message authentication) or as the end-point of a
channel (entity authentication). Moreover, this identity is
easily linked back to the real identity of the entity in
question, for instance being a pre-existing static label from
a predefined name space (telephone number, name, etc.).
Authorization
The act of determining if a particular right, such as access
to some resource, can be granted to the presenter of a
particular credential.
Depending on the type of credential, authorization may imply
Explicit Authentication or not.
Cuellar, Morris, Mulligan 10
Geopriv Requirements Dec 2002
4. Scenarios and Explanatory Discussion
4.1. Scenarios of Data Flow
In this subsection we introduce short scenarios to illustrate how
these terms and attributes describe location information
transactions.
SCENARIO 1: GPS Device with Internal Computing Power: Closed System
In this example, the Target wishes to know his/her location using
Global Positioning System (GPS) and the Device is capable of
independently processing the raw data to determine its location.
The location is derived as follows: the Device receives
transmissions from the GPS satellites, internally computes and
displays location. This is a closed system. For the purpose of this
and subsequent examples, it is assumed that the GPS satellite
broadcasts some signal, and has no information about the identity or
whereabouts of Devices using the signal.
GPS Satellite
|
|
|
|
V GPS Device
--------------------------------------------------
/ \
| Data ----- Location ----- Location |
| Transporter Server Storage |
\ | /
-------------------------------------------|------
|
------------|------
/ V \
/ Target Location \
| Seeker |
| |
\ Rule Maker /
\ /
-------------------
In this scenario the GPS Device is both the IAP and the LoSi. The
interaction occurs in a Trusted environment because it occurs in the
Rule Maker$(Bs (BDevice.
SCENARIO 2: Cell Phone Roaming
In this example, a cell phone is used outside its home service area
(roaming). Also, the cell phone service provider (cell phone Corp 2)
Cuellar, Morris, Mulligan 11
Geopriv Requirements Dec 2002
outsourced the accounting of cell phone usage. The cell phone is not
GPS-enabled. Location is derived by the cell phone network in which
the Target and Device are roaming. When the Target wishes to use
the cell phone, cell phone Corp 1 (IAP) provides the roaming service
for the Target, which sends the raw data about usage (e.g., duration
of call, location roaming network, etc.) to cell phone Corp 2, the
home service provider. Cell phone Corp 2 submits the raw data to
the accounting company, which processes the raw data for the
accounting statements. Finally, the raw data is sent to a data
warehouse where the raw data is stored in a Location Server (e.g.,
computer server).
Cell Phone Corp 1 Cell Phone Corp 2
----------------- -----------------
Sighting / \ Sighting / \
Device ----- | Data Transporter | --------- | Data Transporter |
Target \ / \ /
----------------- / -----------------
/ |
/ sighting|
/ |
----------- |
/ V
------------ / ----------
/ \ / / \
/ Location \ / | Location |
| Storage | Location Info | Storage |
| |<----------------- | |
| Location | | Location |
| Seeker | | Seeker |
\ / \ /
------------- ----------
Here cell phone corp 1 is the IAP and the LoSi. Cell phone corp 1
could be Non-trusted (the Rule Maker does not have a contract
protecting location information with corp 1 and there is no
contractual relationship with privacy provisions between corp 1 and
corp 2) or Trusted (contract with privacy protections between cell
phone corp 2 and corp 1). Cell phone corp 2 is Trusted.
SCENARIO 3: Mobile Communities and Location-Based Services
The figure below shows a common scenario, where a user wants to find
his friends or colleagues or wants to share his position with them
or with a Location-Based Service Provider. Some of the messages use
a Location Object to carry for instance: identities or pseudonyms,
credentials and proof-of-possession of them, Policies and Location
Data Information, including Data Types and Accuracy. They are shown
in the figure by normal arrows ("--->"). Other messages do not use
Cuellar, Morris, Mulligan 12
Geopriv Requirements Dec 2002
the Location Object and are outside of the scope of the geopriv WG,
but should be mentioned for understandability. They are shown in
the figure as starred arrows ("***>").
+---------+ +------------+
| Location| | Public |
| Data |<** | Policy |
| Source | * | Repository |
| + IAP | * +------------+
+---------+\ * * *
^ \ *5 3a* *
* \ * * *
* \ ** *
* \ * * *3a
5a * \* * *
* * \ * *
* * \ * *
* * \6 * *
+----------+ * \ * V
| Target | * \->+-----------+
| +----------+ 3 | Location |
+-| Rule |--------------------->| Server + |
| Maker | | Private |
+----------+<********************>| Repository|
^ 1 +-----------+
| ^ |
| 4| |7
| | V
| +----------+
| | Ultimate |
+---------------------------->| Location |
2 | Recipient|
+----------+
Figure 1: The Entities and Data Flows
1: Registration:
The Rule Maker registers himself and the Target with the
Location Server. This registration process is outside of the
scope of our discussion, but probably the Rule Maker has to
prove that he indeed is the owner of the privacy rights of the
Target (the Target is usually a Device owned by the Rule
Maker). The Rule Maker and the Location Server agree, as part
of the Registration Process, which keys or credentials and
proof-of-possession of the corresponding secrets they will use
to authenticate each other, and in particular, to authenticate
or sign the policies, or how they will agree on them or renew
those keys or credentials.
Cuellar, Morris, Mulligan 13
Geopriv Requirements Dec 2002
2: End-to-End Negotiation:
The Rule Maker and the Location Seeker exchange information
about the service (if any) and negotiate it. They also
negotiate the pseudonyms that they will use later on and the
credentials or keys that the Ultimate Location Recipient will
use to prove his authorization to the Location Server. This
End-to-End Negotiation may contain several messages and may
use or not the Location Object.
3: Policy Transfer:
The Rule Maker sends a Policy to the Location Server. This
Policy may be a field in a Location Object or not.
3a:Signed Policy:
As an alternative to the Policy Transfer, the Rule Maker may
write a policy and place it in the Open Repository. The
entities access the repository to read the signed policies.
4: Location Information Request:
The Location Seeker requests location information for a
Target. In this request, the Location Seeker may select which
location information data type it prefers. One way of
requesting Location Information MAY be sending a partially
filled Location Object, including only the identities of the
Target and Location Recipient and the desired Data Type and
accuracy, and providing proof of possession of the required
credentials. But whether the using protocol understands this
partially filled object as a request, this MAY depend on the
using protocol or on the context. The Location Seeker could
also specify the need for periodic location information
updates, but this is probably out of the scope of geopriv.
5: Locate:
When a Location Server receives an Location Information
Request for a Target for which has no current location
information, the server may send ask the Location Sighter to
locate the Target.
6: Location Information:
The Location Sighter sends the "full" location information to
the Location Server. This Location Information may be
embedded in a Location Object or not.
7: Filtered Location Information:
Then the Location Server sends the location information to the
Location Recipient. The information may be filtered in the
sense that in general a less precise or a computed version of
the information is being delivered.
5. Requirements
Cuellar, Morris, Mulligan 14
Geopriv Requirements Dec 2002
5.1. Location Object
Req. 1. (Location Object generalities)
1.1) Geopriv MUST define one Location Object (LO) -- both in
syntax and semantics -- that must be supported by all geopriv
entities.
1.2) Some fields of the Location Object MAY be optional. This
means that an instance of a Location Object MAY contain the
fields or not.
1.3) Some fields of the Location Object MAY be defined as
"extensions". This means that the syntax or semantics of these
fields is not fully defined in the basic Location Object
definition, but their use may be private to one or more using
protocols.
1.4) The Location Object MUST be extensible, allowing the
definition of new attributes or fields.
1.5) The object MUST be suitable for requesting and receiving a
location.
1.6) The object MUST permit (but not require) the policy to be
enforced by a third party.
1.7) The object MUST be usable in a variety of protocols, such as
HTTP and SIP, as well as local APIs.
1.8) The object MUST be usable in a secure manner even by
applications on constrained devices.
Req. 2. (Location Object fields) The Location Object definition
MUST support the following Fields (but not all LOs must use all
fields)
2.1) Target Identifier
2.2) Location Recipient Identity
This identity may be a multicast or group identity, used to
include the Location Object in multicast-based using protocols.
2.3) Location Recipient Credential
2.4) Location Recipient Proof-of-Possession of the Credential
2.5) Location Field.
Cuellar, Morris, Mulligan 15
Geopriv Requirements Dec 2002
Each Location Field may contain one or more Location
Representations, which can be also in different formats.
2.6) Location Data Type
When transmitting the Location Object, the sender and the
receiver must agree on the data type of the location information.
The using protocol may specify that the data type information is
part of the Location Object or that sender and receiver have
agreed on it before the actual data transfer.
2.7) Motion and direction vectors
2.8) Timing information:
(a) When was the LI accurate? (sighting time)
(b) Until when considered current? TTL (Time-to-live) (This is
different than a privacy rule setting a limit on data retention)
2.9) Policy Field: this field MAY be a referral to an applicable
policy (for instance, an URI to a full policy), or it MAY contain
a Limited Policy (see Req. 9), or both.
2.10) Security-headers and -trailers (for instance encryption
information, hashes, or signatures) (see Req. 13).
2.11) Version number
Req. 3. (Location Data Types)
3.1) The Location Object MUST define at least one Location Data
Type to be supported by all geopriv receivers (entities that
receive LOs).
3.2) The Location Object SHOULD define two Location Data Types:
one for latitude / longitude / altitude coordinates and one for
civil locations (City, Street, Number) supported by all geopriv
receivers (entities that receive LOs).
3.3) The latitude / longitude / altitude Data Type SHOULD also
support a delta format in addition to an absolute one, used for
the purpose of reducing the size of the packages or the security
and confidentiality needs.
3.4) The Location Object definition SHOULD agree on further
Location Data Types supported by some geopriv entities and
defined by other organizations.
5.2. The Using Protocol
Req. 4. The using protocol has to obey the privacy and security
instructions coded in the Location Object and in the
Cuellar, Morris, Mulligan 16
Geopriv Requirements Dec 2002
corresponding Policy Rules regarding the transmission and storage
of the LO.
Req. 5. The using protocol will typically facilitate that the keys
associated with the credentials are transported to the respective
parties, that is, key agreement is responsibility of the using
protocol.
Req. 6. (Single Message Transfer) In particular for tracking of
small target devices, the design should allow a single
message/packet transmission of location as a complete
transaction.
Other requirements on the using protocol are out of the scope of
this document. See also Section 9 (Protocol and LO Issues for later
Consideration)
5.3. Policy based Location Data Transfer
Req. 7. (LServ Policies) The decision of a Location Server to
provide a Location Seeker access to Location Information MUST be
based on Rule Maker-defined Privacy Policies.
It is outside of our scope how Privacy Policies are managed, how a
Location Server has access to the Privacy Policies, and if he is or
not aware of the full set of rules desired by the Rule-Maker. Note
that it might be that some rules contain private information not
intended for untrusted parties.
Req. 8. (LoSi Policies) Even if a Location Sighter is unaware of
and lacks access to the full Privacy Policies defined by the Rule
Maker, the Location Sighter MUST transmit Location Information in
compliance with instructions set by the Rule Maker. Such
compliance MAY be accomplished by the Location Sighter
transmitting LI only to a URI designated by the Rule Maker.
Req. 9. (ULR Policies) An Ultimate Location Recipient does not need
to be aware of the full policies defined by the Rule Maker
(because an ULR SHOULD NOT retransmit Location Information), and
thus an ULR SHOULD receive only the subset of Privacy Policies
necessary for the ULR to handle the LI in compliance with the
full Privacy Policies (such as, for example, an instruction on
the time period for which then LI can be retained).
Req. 10. (Full Policy language) Geopriv MAY specify a policy
language capable of expressing a wide range of privacy rules
concerning location information. This policy language MAY be an
existing one, an adaptation of an existing one or a new policy
language, and it SHOULD be as simple as possible.
Req. 11. (Limited Policy language) Geopriv MUST specify a limited
policy language capable of expressing a limited set of privacy
Cuellar, Morris, Mulligan 17
Geopriv Requirements Dec 2002
rules concerning location information. This policy language MAY
be an existing one, an adaptation of an existing one or a new
policy language. The Location Object MUST include sufficient
fields and data to express the limited set of privacy rules.
5.4. Location Object Privacy and Security
5.5. Identity Protection
Req. 12. (Identity Protection) The Location Object MUST support use
of Unlinked Pseudonyms in the corresponding identification fields
of Rule Maker, Target, Device, and Location Recipient. Since
Unlinked Pseudonyms are simply bit strings that are not linked
initially to a well-known identity, this requirement boils down
to saying that the name space for Identifiers used in the LO has
to be large enough to contain many unused strings.
5.6. Authentication Requirements
Req. 13. (Credential Requirements) The using protocol and the
Location Object SHOULD allow the use of different credentials
types, including privacy-enhancing credentials (like for instance
the ones described in [Bra00] or [Cha85]).
5.7. Actions to be secured
Req. 14. (Security Features) The Location Object MUST support
fields suitable for protecting the Object to provide the
following security features:
14.1) Mutual end-point authentication: the using protocol is
able to authenticate both parties in a Location Object
transmission,
14.2) Data object integrity: the LO is secured from
modification by unauthorized entities during transmission and
during storage,
14.3) Data object confidentiality: the LO is secured from
eavesdropping (unauthorized reading) during transmission and
during storage, and
14.4) Replay protection: an old LO may not be replayed by an
adversary or by the same entity that used the LO itself (except
perhaps during a small window of time that is configurable or
accepted by the Rule Maker).
Req. 15. (Minimal Crypto)
15.1) Geopriv MUST specify a minimum mandatory to implement
Location Object security including mandatory to implement crypto
Cuellar, Morris, Mulligan 18
Geopriv Requirements Dec 2002
algorithms, for digital signature algorithms and encryption
algorithms.
15.2) It MAY also define further mandatory to implement
Location Object security mechanisms for message authentication
codes (MACs) or other purposes.
15.3) The protocol SHOULD allow a bypass if authentication
fails in an emergency call.
The issue addressed in the last point is that an emergency call in
some very unfavorable situations my not be completed if the minimal
authentication fails. This is probably not what the user would like
to see. The user may prefer an unauthenticated call to an
unauthenticated emergency server than no call completion at all,
even at the risk that he is talking to an attacker or that his
information is not secured.
5.8. Non-Requirements
Non-Req. 1. (Bridging to non-IP networks) The geopriv specification
SHOULD NOT specify the bridging to non-IP networks (PSTN, etc).
6. Security Considerations
The purpose of the geopriv Location Object and the requirements on
the using protocol are to allow a policy-controlled disclosure of
location information for location services.
6.1. Traffic Analysis
The information carried within the Location Object is secured in a
way compliant with the privacy and security policies of the Rule
Maker, but other information, carried in other objects or headers
are in general not secured in the same way. This means that geopriv
does not as a general matter secure the Target against general
traffic analysis attacks or other forms of privacy violations.
6.2. Securing the Privacy Policies
The Privacy Policies of the Rule Maker regarding the location of the
Target may be accessible to a Location Server in a Private Storage
or in a Public Repository, or they may be carried by the Location
Object, or they may be presented by the Location Seeker as
capabilities or tokens. Each of this types of policy has to be
secured it$(Bs (Bown particular way.
The rules in a Private Storage are typically authenticated using a
MAC (Message Authentication Code) or a signature, depending on the
type of keys used. The rules in a Public Repository (one that in
Cuellar, Morris, Mulligan 19
Geopriv Requirements Dec 2002
principle may be accessed directly by several entities, for instance
several Location Servers) are typically digitally signed. A Policy
Field in a LO is secured as part of the LO itself. A Geopriv Token
(a token or ticket issued by the Rule Maker to a Location Seeker,
expressing the explicit consent of the Rule Maker to access his
location information) is authenticated or signed.
6.3. Emergency Case
One way of implementing the authentication bypass for emergency
calls, mentioned in Req 14.3) is to let the user have the choice of
writing a policy that says:
- "If the emergency server does not authenticate itself,
nevertheless send the location", or
- "If the emergency server does not authenticate itself, let the
call fail".
In the case where the authentication of the emergency call fails
because the user may not authenticate itself, the question arises:
whose policy to use? It is reasonable to use a default one: this
location information can only be sent to an emergency center.
Another situation, which should be studied in more detail is: what
to do if not only the user fails to authenticate itself, but also
the emergency center is not authenticable? It is reasonable to send
the Location Information anyway, but are there in this case any
security threats that must be considered?
6.4. Identities and Anonymity
The use of Unlinked Pseudonyms is necessary to obtain anonymity.
The purpose of the use of Unlinked Pseudonyms is the following: the
using protocol should be able to hide the real identity of the Rule
Maker, the Target, and the Device, the and to Location Servers or
Location Recipients. Also, the using protocol SHOULD be able to
hide the real identity of the Location Recipient to the Location
Server.
In this last case, the Target is not concerned about the Server
identifying him and knowing his location, but identifying his
business partners, and therefore his habits, etc. Reasons for
hiding the real identities of the Location Recipients include (a)
that this knowledge may be used to infer the identity of the Target,
(b) that knowledge of the identity of the Location Recipient may
embarrass the Target or breach confidential information, and (c)
that the dossier telling who has obtained a Target's location
information over a long period of time can give information on
habits, movements, etc. Even if the location service providers
agree to respect the privacy of the user, are compelled by laws or
regulations to protect the privacy of the user, and misbehavior or
Cuellar, Morris, Mulligan 20
Geopriv Requirements Dec 2002
negligence of the Location Server can be ruled out, there is still
risk that personal data may become available to unauthorized persons
through attacks from outsiders, unauthorized access from insiders,
technical or human errors, or legal processes.
In some occasions a Location Server has to know who is supplying
policies for a particular Target, but in other situations it could
be enough to know that the supplier of the policies is authorized to
do so. Those considerations are outside of our scope.
6.5. Unintended Target
An Unintended Target is a person or object tracked by proximity to
the Target. This special case most frequently occurs if the Target
is not a person. For example, the Target may be a rental car
equipped with a GPS Device, used to track car inventory. The rental
company may not care about the driver's location, but the driver's
privacy is implicitly affected.
Geopriv may or may not protect or affect the privacy of Unintended
Targets, but the impact on Unintended Targets should be
acknowledged.
7. Acknowledgements
We wish to thank the members of the IETF geopriv WG for their
comments and suggestions. Aaron Burstein, Mehmet Ersue, Allison
Mankin, Randall Gellens, Jon Peterson, and the participants of the
geopriv meetings in San Diego and Yokohama provided detailed
comments or text.
8. References
[Bra00] Stefan A.: Rethinking Public Key Infrastructures and Digital
Certificates : Building in Privacy, MIT Press; ISBN:
0262024918; 1st edition, August, 2000
[Cha85] Chaum, David: Security without Identification, Card
Computers to make Big Brother Obsolete. Original Verion
appeared in: Communications of the ACM, vol. 28 no. 10,
October 1985 pp. 1030-1044. Revised version available at
http://www.chaum.com/articles/
[ISO99] ISO99: ISO IS 15408, 1999, http://www.commoncriteria.org/.
[OECD] OECD Guidelines on the Protection of Privacy and Transborder
Flows of Personal Data, http://www.oecd.org.
[Pfi01] Pfitzmann, Andreas; Köhntopp, Marit: Anonymity,
Unobservability, and Pseudonymity - A Proposal for
Terminology; in: H Federrath (Ed.): Designing Privacy
Cuellar, Morris, Mulligan 21
Geopriv Requirements Dec 2002
Enhancing Technologies; Proc. Workshop on Design Issues in
Anonymity and Unobservability; LNCS 2009; 2001; 1-9. Newer
versions available at http://www.koehntopp.de/marit/pub/anon
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
9. Protocol and LO Issues for later Consideration
It seems important to mention some issues on the Location Object or
on the protocol, which have emerged during the discussion of earlier
versions of this document.
9.1. Multiple Locations in one LO
The possibility of inclusion of multiple locations is discussed in
another draft, draft-morris-geopriv-location-object-issues-00.txt.
An instance of a Location Object could contain zero, one, or several
Location Fields, perhaps in different formats. Several Location
Fields would be used to report the same sighting in different
formats, or multiple sightings at different times, or multiple
sensor locations for the same device, or other purposes.
9.2. Translation Fields
It is possible to include fields to indicate that one of the
locations is a translation of another. If this is done, it is also
possible to have a field to identify the translator, as identity and
method.
9.3. Specifying Desired Accuracy in a Request
If the LO is used to request location information (leaving some
fields empty), it is not clear how to specify the requested
accuracy. Are the data types "country/state/city" and
"country/state" different data types or the same data type with
different "accuracy" or "granularity"?
9.4. Truth Flag
Geopriv should not provide an attribute in object saying "I'm not
telling you the whole truth."
9.5. Timing Information Format
The format of timing information is out of the scope of this
document.
9.6. The Name Space of Identifiers
Cuellar, Morris, Mulligan 22
Geopriv Requirements Dec 2002
Who defines the Identities: may the using protocol define the
Identifiers or must the using protocol use and authenticate
Pseudonyms proposed by the policies, chosen independently of the
using protocol? Of course, if the using protocol has an appropriate
namespace, containing many unused names that may be used as
pseudonyms and may be replaced by new ones regularly, then the
Location Object may be able to use the name space. For this purpose,
the user would probably have to write his policies using this name
space. Note that it is necessary to change the used pseudonyms
regularly, because identifying the user behind an unlinked pseudonym
can be very simple.
There are several advantages of letting the using protocol to define
the name space:
o the embedded authentication would be easier, as the using protocol
has often already the credentials for the authentication identity
in place and the "embedded" authentication would be independent on
the form of Identifiers,
o the size of the names would be fixed.
On the other hand, the benefits of the policy choosing the
identifiers are:
o the user has a control of his anonymity, and
o the interworking of multiple systems with Location object across
protocol boundaries is facilitated.
10. Author's Addresses
Jorge R Cuellar
Siemens AG
Corporate Technology
CT IC 3
81730 Munich Email: Jorge.Cuellar@mchp.siemens.de
Germany
John B. Morris, Jr.
Director, Internet Standards, Technology & Policy Project
Center for Democracy and Technology
1634 I Street NW, Suite 1100
Washington, DC 20006 Email: jmorris@cdt.org
USA http://www.cdt.org
Deirdre K. Mulligan
Samuelson Law, Technology and Public Policy Clinic
Boalt Hall School of Law
University of California
Berkeley, CA 94720-7 Email: dmulligan@law.berkeley.edu
11. Full Copyright Statement
Copyright (C) The Internet Society (date). All Rights Reserved.
Cuellar, Morris, Mulligan 23
Geopriv Requirements Dec 2002
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Cuellar, Morris, Mulligan 24
Received on Fri Dec 27 13:19:46 2002
This archive was generated by hypermail 2.1.8 : Thu Jan 22 2004 - 12:32:23 EST