MAY depend on the using protocol or on the context. The
Location Recipient could also specify the need for periodic
location information updates, but this is probably out of the
scope of Geopriv.
3: Locate:
When a Location Server receives a Location Information Request
for a Target which has no current location information, the
server may ask the Location Generator to locate the Target.
4: Location Information:
The Location Generator sends the "full" location information to
the Location Server. This Location Information may or may not
be embedded in a Location Object.
5: Filtered Location Information:
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.
7. Requirements
7.1. Location Object
Remember that this document is primarily specifying requirements on
the definition of the LO. Some Requirements read like this: "The LO
definition MUST contain Field ’A’ as an optional field." This
requirement states that
o the document that defines the LO MUST define the LO field ’A’,
o the field ’A’ MUST be defined as optional to use (an instance of a
LO MAY or may not contain the field ’A’).
Some Requirements read like this: "The LO definition MUST contain
Field ’A’, which MAY be an optional field." This requirement states
that
o the document that defines the LO MUST define the LO field ’A’,
o the field ’A’ MAY be defined as optional or not to use. If it is
defined as optional to use, any instance of an LO MAY or may not
contain the field ’A’; if it is not optional, all instances of LOs
MUST contain the field ’A’.
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 or may not contain
the fields.
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 of the
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 Privacy Rules 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
contain the following Fields, which MAY be optional to use:
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
2.5.1) Motion and direction vectors. This field MUST be optional.
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 the sender and receiver have agreed
on it before the actual data transfer.
2.7) Timing information:
(a) When was the Location Information 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.8) Rule Field: this field MAY be a referral to an applicable
Rule (for instance, a URI to a full Rule), or it MAY contain a
Limited Rule (see Req. 11), or both.
2.9) Security-headers and -trailers (for instance encryption
information, hashes, or signatures) (see Req. 14 and 15).
2.10) 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.
7.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 corresponding
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 establishment is the 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, but might be the subject of future efforts from this
working group. See also Section 9 (Protocol and LO Issues for later
Consideration).
7.3. Rule based Location Data Transfer
Req. 7. (LS Rules) The decision of a Location Server to provide a
Location Recipient access to Location Information MUST be based on
Rule Maker-defined Privacy Rules.
It is outside of our scope how Privacy Rules are managed and how a
Location Server has access to the Privacy Rules. Note that it might
be that some rules contain private information not intended for
untrusted parties.
Req. 8. (LG Rules) Even if a Location Generator is unaware of and
lacks access to the full Privacy Rules defined by the Rule Maker,
the Location Generator MUST transmit Location Information in
compliance with instructions set by the Rule Maker. Such
compliance MAY be accomplished by the Location Generator
transmitting the LO only to a URI designated by the Rule Maker.
Req. 9. (Viewer Rules) A Viewer does not need to be aware of the
full Rules defined by the Rule Maker (because a Viewer SHOULD NOT
retransmit Location Information), and thus a Viewer SHOULD receive
only the subset of Privacy Rules necessary for the Viewer to
handle the LO in compliance with the full Privacy Rules (such as,
instruction on the time period for which the LO can be retained).
Req. 10. (Full Rule language) Geopriv MAY specify a Rule language
capable of expressing a wide range of privacy rules concerning
location information. This Rule language MAY be an existing one,
an adaptation of an existing one or a new Rule language, and it
SHOULD be as simple as possible.
Req. 11. (Limited Rule language) Geopriv MUST specify a limited Rule
language capable of expressing a limited set of privacy rules
concerning location information. This Rule language MAY be an
existing one, an adaptation of an existing one or a new Rule
language. The Location Object MUST include sufficient fields and
data to express the limited set of privacy rules.
7.4. Location Object Privacy and Security
7.4.1. 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.
7.4.2. Authentication Requirements
Req. 13. (Credential Requirements) The using protocol and the
Location Object SHOULD allow the use of different credential
types, including privacy-enhancing credentials (for instance those
described in [Bra00] or [Cha85]).
7.4.3. 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
storage,
14.3) Data object confidentiality: the LO is secured from
eavesdropping (unauthorized reading) during transmission and
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
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 unfavorable situations may not be completed if the minimal
authentication fails. This is probably not what the user would like
to happen. The user may prefer an unauthenticated call to an
unauthenticated emergency server over no call completion at all, even
at the risk that he is talking to an attacker or that his information
is not secured.
7.5. Non-Requirements
Non-Req. 1. (Bridging to non-IP networks) The Geopriv specification
SHOULD NOT specify the bridging to non-IP networks (PSTN, etc).
8. Security Considerations
The purpose of the Geopriv Location Object and the requirements on
the using protocol are to allow a Privacy Rule-controlled disclosure
of location information for location services.
8.1. Traffic Analysis
The information carried within the Location Object is secured in a
way compliant with the privacy and security Rules 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 may not
as a general matter, secure the Target against general traffic
analysis attacks or other forms of privacy violations.
8.2. Securing the Privacy Rules
The Privacy Rules of the Rule Maker regarding the location of the
Target may be accessible to a Location Server in a public or non-
public Rule Holder, or they may be carried by the Location Object, or
they may be presented by the Location Recipient as capabilities or
tokens. Each type of Rule has to be secured its own particular way.
The rules in a non-public Rule Holder are typically authenticated
using a MAC (Message Authentication Code) or a signature, depending
on the type of keys used. The rules in a public Rule Holder (one
that in principle may be accessed directly by several entities, for
instance several Location Servers) are typically digitally signed.
Rule Fields in an LO are secured as part of the LO itself. A Geopriv
Token (a token or ticket issued by the Rule Maker to a Location
Recipient, expressing the explicit consent of the Rule Maker to
access his location information) is authenticated or signed.
8.3. Emergency Case
Let us consider the situation where the authentication fails in an
emergency call because the authentication center fails to
authenticate itself. In this case, one way of implementing the
authentication bypass for emergency calls (mentioned in Req 15.3) is
to let the user have the choice of writing a Rule that says:
- "If the emergency server does not authenticate itself, send the
location information anyway", or
- "If the emergency server does not authenticate itself, let the
call fail".
Second, in the case where the authentication of the emergency call
fails because the user may not authenticate itself, the question
arises: whose Rule to use? It is reasonable to use a default one:
this location information can only be sent to an emergency center.
The third 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 any security
threats that must be considered?
8.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, from Location Servers or Location
Recipients, if required by the RM. Also, the using protocol SHOULD
be able to hide the real identity of the Location Recipient from 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 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.
On some occasions, a Location Server has to know who is supplying the
Privacy Rules for a particular Target, while in other situations it
could be enough to know that the supplier of the Rules is authorized
to do so.
8.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.
9. Protocol and LO Issues for later Consideration
This section briefly discusses issues relating to the Location Object
or the protocol that have emerged during the discussion of earlier
versions of this document.
9.1. Multiple Locations in one LO
A location Field is intended to represent one point or one region in
space (either 1, 2, or 3 dimensionally). The possibility of
inclusion of multiple locations is discussed in another document.
The current rough consensus is the following: the LO definition MAY
allow the Location Field to be optional, to appear exactly one time
or to occur several times. Each Location Field may contain one or
more "Location Representations", each of which is intended to
represent a different measurement or a different formatting of the
same position. But there are other possibilities for using multiple
Location Fields and multiple representations: maybe 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, which could also
depend on the using protocol. This is all for further discussion.
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. Truth Flag
Geopriv MUST be silent on the truth or lack-of-truth of the location
information contained in the LO. Thus, the LO MUST NOT provide an
attribute in object saying "I am (or am not) telling you the whole
truth."
9.4. Timing Information Format
The format of timing information is out of the scope of this
document.
9.5. The Name Space of Identifiers
Who defines the Identities: can the using protocol define the
Identifiers or must the using protocol use and authenticate
Pseudonyms proposed by the Rules, 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 Rules 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 in letting the using protocol define the
name space:
o the embedded authentication would be easier, as the using protocol
often already has 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 Rule 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. 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, and the participants of the Geopriv meetings
in San Diego and Yokohama provided detailed comments or text.
11. References
11.1. Normative Reference
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
11.2. Informative 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 Version
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; Koehntopp, Marit: Anonymity,
Unobservability, and Pseudonymity - A Proposal for
Terminology; in: H Federrath (Ed.): Designing Privacy
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
12. Authors’ Addresses
Jorge R Cuellar
Siemens AG
Corporate Technology
CT IC 3
81730 Munich, Germany
EMail: Jorge.Cuellar@siemens.com
John B. Morris, Jr.
Director, Internet Standards, Technology & Privacy Project
Center for Democracy & Technology
1634 I Street NW, Suite 1100
Washington, D.C. 20006 USA
EMail: jmorris@cdt.org
URI: http://www.cdt.org
Deirdre K. Mulligan
Samuelson Law, Technology & Public Policy Clinic
Boalt Hall School of Law
University of California
Berkeley, CA 94720 USA
EMail: dmulligan@law.berkeley.edu
URI: http://www.law.berkeley.edu/cenpro/samuelson/
Jon Peterson
NeuStar, Inc.
1800 Sutter St
Suite 5707
Concord, CA 94520 USA
EMail: jon.peterson@neustar.biz
URI: http://www.neustar.biz/
James M. Polk
Cisco Systems
2200 East President George Bush Turnpike
Richardson, Texas 75082 USA
EMail: jmpolk@cisco.com
13. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78 and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to
rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other