draft-ietf-geopriv-reqs-01.txt   draft-ietf-geopriv-reqs-02.txt 
Internet Draft J. Cuellar Internet Draft J. Cuellar
Document: draft-ietf-geopriv-reqs-01.txt Siemens AG Document: draft-ietf-geopriv-reqs-02.txt Siemens AG
John B. Morris, Jr. John B. Morris, Jr.
Center for Democracy and Technology Center for Democracy and Technology
D. Mulligan D. Mulligan
Samuelson Law, Technology, and Public Policy Clinic Samuelson Law, Technology, and Public Policy Clinic
Expires in six months November 2002 Expires in six months Jan 2003
Geopriv requirements Geopriv requirements
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at line 50 skipping to change at line 50
Location-based services, navigation applications, emergency Location-based services, navigation applications, emergency
services, management of equipment in the field, and other location- services, management of equipment in the field, and other location-
dependent services need geographic location information about a dependent services need geographic location information about a
Target (such as a user, resource or other entity). There is a need Target (such as a user, resource or other entity). There is a need
to securely gather and transfer location information for location to securely gather and transfer location information for location
services, while at the same time protecting the privacy of the services, while at the same time protecting the privacy of the
individuals involved. individuals involved.
Cuellar, Morris, Mulligan 1 Cuellar, Morris, Mulligan 1
Geopriv Requirements Nov 2002 Geopriv Requirements Jan 2003
This document focuses on the authorization, integrity and privacy This document focuses on the authorization, integrity and privacy
requirements for such location-dependent services. Specifically, it requirements for such location-dependent services. Specifically, it
describes the requirements for the geopriv Location Object (used to describes the requirements for the geopriv Location Object (used to
securely transfer location data and other privacy-enabling securely transfer location data and other privacy-enabling
information) and for the protocols that use this Location Object. information) and for the protocols that use this Location Object.
Table of Contents Table of Contents
1. Overview........................................................3 1. Overview........................................................3
skipping to change at line 79 skipping to change at line 79
3.2.1. Primary Geopriv Entities..............................7 3.2.1. Primary Geopriv Entities..............................7
3.2.2. Secondary Geopriv Entities............................8 3.2.2. Secondary Geopriv Entities............................8
3.2.3. Geopriv Data Storage Functions........................9 3.2.3. Geopriv Data Storage Functions........................9
3.3. Privacy Policies and Rules.................................9 3.3. Privacy Policies and Rules.................................9
3.4. Identifiers, Authentication and Authorization.............10 3.4. Identifiers, Authentication and Authorization.............10
4. Scenarios and Explanatory Discussion...........................11 4. Scenarios and Explanatory Discussion...........................11
4.1. Scenarios of Data Flow....................................11 4.1. Scenarios of Data Flow....................................11
5. Requirements...................................................14 5. Requirements...................................................14
5.1. Location Object...........................................15 5.1. Location Object...........................................15
5.2. The Using Protocol........................................16 5.2. The Using Protocol........................................16
5.3. Policy based Location Data transfer.......................17 5.3. Policy based Location Data Transfer.......................17
5.4. Location Object Privacy and Security......................17 5.4. Location Object Privacy and Security......................18
5.5. Identity Protection.......................................18 5.5. Identity Protection.......................................18
5.6. Authentication Requirements...............................18 5.6. Authentication Requirements...............................18
5.7. Actions to be secured.....................................18 5.7. Actions to be secured.....................................18
5.8. Non-Requirements..........................................19 5.8. Non-Requirements..........................................19
6. Security Considerations........................................19 6. Security Considerations........................................19
6.1. Traffic Analysis..........................................19 6.1. Traffic Analysis..........................................19
6.2. Securing the Privacy Policies.............................19 6.2. Securing the Privacy Policies.............................19
6.3. Emergency Case............................................20 6.3. Emergency Case............................................20
6.4. Identities and Anonymity..................................20 6.4. Identities and Anonymity..................................20
6.5. Unintended Target.........................................21 6.5. Unintended Target.........................................21
7. Acknowledgements...............................................21 7. Acknowledgements...............................................21
8. References.....................................................21 8. References.....................................................21
9. Protocol and LO Issues for later Consideration.................22 9. Protocol and LO Issues for later Consideration.................22
9.1. Single Message Transfer...................................22 9.1. Multiple Locations in one LO..............................22
9.2. Multiple Locations in one LO..............................22 9.2. Translation Fields........................................22
9.3. Translation Fields........................................22 9.3. Specifying Desired Accuracy in a Request..................22
9.4. Specifying Desired Accuracy in a Request..................22 9.4. Truth Flag................................................22
Cuellar, Morris, Mulligan 2 Cuellar, Morris, Mulligan 2
Geopriv Requirements Nov 2002 Geopriv Requirements Jan 2003
9.5. Truth Flag................................................22 9.5. Timing Information Format.................................22
9.6. Timing Information Format.................................22 9.6. The Name Space of Identifiers.............................22
9.7. The Name Space of Identifiers.............................22
10. Author's Addresses............................................23 10. Author's Addresses............................................23
11. Full Copyright Statement......................................23 11. Full Copyright Statement......................................23
1. Overview 1. Overview
Location-based services (applications that require geographic Location-based services (applications that require geographic
location information as input) are becoming increasingly common. location information as input) are becoming increasingly common.
The collection and transfer of location information about a The collection and transfer of location information about a
particular Device and/or Target can have important privacy particular Device and/or Target can have important privacy
implications. A key goal of the protocols described in this implications. A key goal of the protocols described in this
skipping to change at line 146 skipping to change at line 145
2) A critical role is played by user-controlled policies, which 2) A critical role is played by user-controlled policies, which
describe the restrictions imposed or permissions given by the describe the restrictions imposed or permissions given by the
"user" (or, as defined below, the "Rule Maker"). The policies "user" (or, as defined below, the "Rule Maker"). The policies
specify the necessary conditions that allow a Location Server to specify the necessary conditions that allow a Location Server to
forward Location Information to a Location Recipient, and the forward Location Information to a Location Recipient, and the
conditions under which and purposes for which the Location conditions under which and purposes for which the Location
Information can be used. Information can be used.
3) The Location Object should be able to carry a limited but core 3) The Location Object should be able to carry a limited but core
set of privacy policies. This core set is defined below and set of privacy policies. The exact form or expressiveness of
discussed more extensively in a separate document. Beyond the policies in the core set or in the full set is not further
core set of privacy policies, the user or Rule Maker should be discussed in this paper, but is discussed more extensively in a
able to define a more robust and complex set of policies. The separate document.
exact form or expressiveness of policies beyond the core set is
not further discussed in this paper.
Cuellar, Morris, Mulligan 3
Geopriv Requirements Nov 2002
4) Whenever appropriate, the location information should not be 4) Whenever appropriate, the location information should not be
linked to the real identity of the user or a static identifier 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 easily linked back to the real identity of the user (e.g., the
phone number). Rather, the user should be able to specify which phone number). Rather, the user should be able to specify which
Cuellar, Morris, Mulligan 3
Geopriv Requirements Jan 2003
local identifier, unlinked pseudonym, or private identifier is to local identifier, unlinked pseudonym, or private identifier is to
be bound to the location information. be bound to the location information.
5) The user may want to hide the real identities of himself and his 5) The user may want to hide the real identities of himself and his
partners not only to eavesdroppers but also to other entities partners not only to eavesdroppers but also to other entities
participating in the protocol. participating in the protocol.
Although complete anonymity may not be appropriate for some Although complete anonymity may not be appropriate for some
applications because of legal constraints or because some location applications because of legal constraints or because some location
services may in fact need explicit identifications, in most cases services may in fact need explicit identifications, in most cases
skipping to change at line 208 skipping to change at line 206
3.1. Foundational Definitions 3.1. Foundational Definitions
3.1.1. Location Information (LI) and Sighting 3.1.1. Location Information (LI) and Sighting
The focus of the geopriv working group is on information about a The focus of the geopriv working group is on information about a
Target's location that is NOT based on generally or publicly Target's location that is NOT based on generally or publicly
available sources, but instead on private information provided or available sources, but instead on private information provided or
created by a Target, a Target's Device, or a Target's network or created by a Target, a Target's Device, or a Target's network or
service provider: service provider:
Cuellar, Morris, Mulligan 4
Geopriv Requirements Nov 2002
Location Information (LI): Location Information (LI):
A relatively specific way of describing where a Device is A relatively specific way of describing where a Device is
located and that is (a) derived or computed from information located and that is (a) derived or computed from information
generally not available to the general public (such as generally not available to the general public (such as
Cuellar, Morris, Mulligan 4
Geopriv Requirements Jan 2003
information mainly available to a network or service information mainly available to a network or service
provider), (b) determined by a Device that may be not provider), (b) determined by a Device that may be not
generally publicly addressable or accessible, or (c) input or generally publicly addressable or accessible, or (c) input or
otherwise provided by a Target. otherwise provided by a Target.
As examples, LI could include (a) information calculated by As examples, LI could include (a) information calculated by
triangulating on a wireless signal with respect to cell phone triangulating on a wireless signal with respect to cell phone
towers, (b) longitude and latitude information determined by a towers, (b) longitude and latitude information determined by a
Device with GPS (global positioning satellite) capabilities, or (c) Device with GPS (global positioning satellite) capabilities, or (c)
information manually entered into a cell phone or laptop by a Target information manually entered into a cell phone or laptop by a Target
skipping to change at line 264 skipping to change at line 263
(Identifier, Location) (Identifier, Location)
where Identifier is the identifier assigned to a Target being where Identifier is the identifier assigned to a Target being
sighted, and Location is the current position of that 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 sighted. Not all entities may have access to exactly the same piece
of sighting information. A sighting may be transformed to a new of sighting information. A sighting may be transformed to a new
sighting pair: sighting pair:
(Identifier-1, Location-1) (Identifier-1, Location-1)
Cuellar, Morris, Mulligan 5
Geopriv Requirements Nov 2002
before it is provided by a Location Sighter or Location Server to before it is provided by a Location Sighter or Location Server to
another Location Recipient (for instance, another Location Server). another Location Recipient (for instance, another Location Server).
Cuellar, Morris, Mulligan 5
Geopriv Requirements Jan 2003
In this case, Identifier-1 may be Pseudonym, and Location-1 may have In this case, Identifier-1 may be Pseudonym, and Location-1 may have
less accuracy or granularity than the original value. less accuracy or granularity than the original value.
3.1.2. The Location Object 3.1.2. The Location Object
A main goal of the geopriv working group is to define a Location A main goal of the geopriv working group is to define a Location
Object (LO), to be used to convey both Location Information and Object (LO), to be used to convey both Location Information and
basic privacy-protecting instructions: basic privacy-protecting instructions:
Location Object (LO): This data contains the Location Information Location Object (LO): This data contains the Location Information
skipping to change at line 319 skipping to change at line 319
The security mechanisms of the Location Object itself are to be The security mechanisms of the Location Object itself are to be
preferred. preferred.
3.1.4. Trusted vs. Non-trusted Data Flows 3.1.4. Trusted vs. Non-trusted Data Flows
Location information can be used in very different environments. In Location information can be used in very different environments. In
some cases the participants will have longstanding relationships, some cases the participants will have longstanding relationships,
while in others participants may have discrete interactions with no while in others participants may have discrete interactions with no
prior contractual or other contact. prior contractual or other contact.
Cuellar, Morris, Mulligan 6
Geopriv Requirements Nov 2002
The different relationships raise different concerns for the The different relationships raise different concerns for the
implementation of privacy rules, including the need to communicate implementation of privacy rules, including the need to communicate
Cuellar, Morris, Mulligan 6
Geopriv Requirements Jan 2003
privacy policies. A public Rule Repository, for example, may be privacy policies. A public Rule Repository, for example, may be
unnecessary in a trusted environment where more efficient methods of unnecessary in a trusted environment where more efficient methods of
addressing privacy issues exist. The following terms distinguish addressing privacy issues exist. The following terms distinguish
between the two basic types of data flows: between the two basic types of data flows:
Trusted Data Flow: Trusted Data Flow:
A data flow that is governed by a pre-existing contractual A data flow that is governed by a pre-existing contractual
relationship that addresses location privacy. relationship that addresses location privacy.
Non-trusted Data Flow: Non-trusted Data Flow:
skipping to change at line 375 skipping to change at line 376
The individual or entity that has the authorization to set the The individual or entity that has the authorization to set the
applicable privacy policies and rules. In many cases this applicable privacy policies and rules. In many cases this
will be the owner of the Device, and in other cases this may 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, be the user who is in possession of the Device. For example,
parents may control what happens to the location information parents may control what happens to the location information
derived from a child's cell phone. A company, in contrast, may derived from a child's cell phone. A company, in contrast, may
own and provide a cell phone to an employee but permit the own and provide a cell phone to an employee but permit the
employee to set the privacy rules. employee to set the privacy rules.
Cuellar, Morris, Mulligan 7 Cuellar, Morris, Mulligan 7
Geopriv Requirements Nov 2002 Geopriv Requirements Jan 2003
Location Seeker (LSeek): Location Seeker (LSeek):
An individual or entity who seeks to receive location data An individual or entity who seeks to receive location data
about a Target. about a Target.
A Location Seeker may act in one or more of the following more A Location Seeker may act in one or more of the following more
specialized roles: as the Location Sighter, a Location Server, or as specialized roles: as the Location Sighter, a Location Server, or as
an Ultimate Location Recipient: an Ultimate Location Recipient:
Location Sighter (LoSi), or Location Data-Source Location Sighter (LoSi), or Location Data-Source
skipping to change at line 430 skipping to change at line 431
communications functions of the Device or computer equipment communications functions of the Device or computer equipment
in which the Device operates. Often, the IAP -- which will be in which the Device operates. Often, the IAP -- which will be
a wireless carrier, an Internet Service Provider, or an a wireless carrier, an Internet Service Provider, or an
internal corporate network -- will be identical to the LoSi. internal corporate network -- will be identical to the LoSi.
In other cases the IAP has a "dumb" LoSi, one that transmits 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 data but does not implement or use any part of the
geopriv Location Object. Other cases may involve no IAP at geopriv Location Object. Other cases may involve no IAP at
all or the IAP is only a Data Transporter. all or the IAP is only a Data Transporter.
Cuellar, Morris, Mulligan 8 Cuellar, Morris, Mulligan 8
Geopriv Requirements Nov 2002 Geopriv Requirements Jan 2003
3.2.3. Geopriv Data Storage Functions 3.2.3. Geopriv Data Storage Functions
Within the geopriv framework, certain data may be stored in various Within the geopriv framework, certain data may be stored in various
functional entities: functional entities:
Rule (or Policy) Storage Rule (or Policy) Storage
A storage used to store privacy-protecting policies, and A storage used to store privacy-protecting policies, and
perhaps identifiers, credentials or keys. A Private Rule perhaps identifiers, credentials or keys. A Private Rule
Storage could be operated by a Device, a Location Server, or a Storage could be operated by a Device, a Location Server, or a
skipping to change at line 483 skipping to change at line 484
information may be used by an entity and which transformed information may be used by an entity and which transformed
location information may be released to which entities under location information may be released to which entities under
which conditions. Policies must be obeyed; they are not which conditions. Policies must be obeyed; they are not
advisory. advisory.
A full set of Privacy Rules will likely include both rules that have A full set of Privacy Rules will likely include both rules that have
only one possible technical meaning, and rules that will be affected only one possible technical meaning, and rules that will be affected
by a locality's prevailing laws and customs. For example, a by a locality's prevailing laws and customs. For example, a
distribution rule of the form "my location can only be disclosed to distribution rule of the form "my location can only be disclosed to
the owner of such credentials and in such accuracy" has clear-cut 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 Cuellar, Morris, Mulligan 9
Geopriv Requirements Nov 2002 Geopriv Requirements Jan 2003
implications for the protocol that uses the LO. But other rules,
like retention or usage policies, may have unclear technical like retention or usage policies, may have unclear technical
consequences for the protocol or for the involved entities. For consequences for the protocol or for the involved entities. For
example, the precise scope of a retention rule stating "you may not 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 store my location for more than 2 days" may in part turn on local
laws or customs. laws or customs.
3.4. Identifiers, Authentication and Authorization 3.4. Identifiers, Authentication and Authorization
Anonymity is the property of being not identifiable (within a set of Anonymity is the property of being not identifiable (within a set of
subjects). Anonymity serves as the base case for privacy: without subjects). Anonymity serves as the base case for privacy: without
skipping to change at line 539 skipping to change at line 540
Authorization Authorization
The act of determining if a particular right, such as access The act of determining if a particular right, such as access
to some resource, can be granted to the presenter of a to some resource, can be granted to the presenter of a
particular credential. particular credential.
Depending on the type of credential, authorization may imply Depending on the type of credential, authorization may imply
Explicit Authentication or not. Explicit Authentication or not.
Cuellar, Morris, Mulligan 10 Cuellar, Morris, Mulligan 10
Geopriv Requirements Nov 2002 Geopriv Requirements Jan 2003
4. Scenarios and Explanatory Discussion 4. Scenarios and Explanatory Discussion
4.1. Scenarios of Data Flow 4.1. Scenarios of Data Flow
In this subsection we introduce short scenarios to illustrate how In this subsection we introduce short scenarios to illustrate how
these terms and attributes describe location information these terms and attributes describe location information
transactions. transactions.
SCENARIO 1: GPS Device with Internal Computing Power: Closed System SCENARIO 1: GPS Device with Internal Computing Power: Closed System
skipping to change at line 593 skipping to change at line 594
In this scenario the GPS Device is both the IAP and the LoSi. The 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 interaction occurs in a Trusted environment because it occurs in the
Rule MakerĘs Device. Rule MakerĘs Device.
SCENARIO 2: Cell Phone Roaming SCENARIO 2: Cell Phone Roaming
In this example, a cell phone is used outside its home service area In this example, a cell phone is used outside its home service area
(roaming). Also, the cell phone service provider (cell phone Corp 2) (roaming). Also, the cell phone service provider (cell phone Corp 2)
Cuellar, Morris, Mulligan 11 Cuellar, Morris, Mulligan 11
Geopriv Requirements Nov 2002 Geopriv Requirements Jan 2003
outsourced the accounting of cell phone usage. The cell phone is not outsourced the accounting of cell phone usage. The cell phone is not
GPS-enabled. Location is derived by the cell phone network in which 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 Target and Device are roaming. When the Target wishes to use
the cell phone, cell phone Corp 1 (IAP) provides the roaming service 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 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 of call, location ” roaming network, etc.) to cell phone Corp 2, the
home service provider. Cell phone Corp 2 submits the raw data to home service provider. Cell phone Corp 2 submits the raw data to
the accounting company, which processes the raw data for the the accounting company, which processes the raw data for the
accounting statements. Finally, the raw data is sent to a data accounting statements. Finally, the raw data is sent to a data
skipping to change at line 646 skipping to change at line 647
The figure below shows a common scenario, where a user wants to find 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 his friends or colleagues or wants to share his position with them
or with a Location-Based Service Provider. Some of the messages use or with a Location-Based Service Provider. Some of the messages use
a Location Object to carry for instance: identities or pseudonyms, a Location Object to carry for instance: identities or pseudonyms,
credentials and proof-of-possession of them, Policies and Location credentials and proof-of-possession of them, Policies and Location
Data Information, including Data Types and Accuracy. They are shown Data Information, including Data Types and Accuracy. They are shown
in the figure by normal arrows ("--->"). Other messages do not use in the figure by normal arrows ("--->"). Other messages do not use
Cuellar, Morris, Mulligan 12 Cuellar, Morris, Mulligan 12
Geopriv Requirements Nov 2002 Geopriv Requirements Jan 2003
the Location Object and are outside of the scope of the geopriv WG, the Location Object and are outside of the scope of the geopriv WG,
but should be mentioned for understandability. They are shown in but should be mentioned for understandability. They are shown in
the figure as starred arrows ("***>"). the figure as starred arrows ("***>").
+---------+ +------------+ +---------+ +------------+
| Location| | Public | | Location| | Public |
| Data |<** | Policy | | Data |<** | Policy |
| Source | * | Repository | | Source | * | Repository |
| + IAP | * +------------+ | + IAP | * +------------+
skipping to change at line 698 skipping to change at line 699
prove that he indeed is the owner of the privacy rights of the prove that he indeed is the owner of the privacy rights of the
Target (the Target is usually a Device owned by the Rule Target (the Target is usually a Device owned by the Rule
Maker). The Rule Maker and the Location Server agree, as part Maker). The Rule Maker and the Location Server agree, as part
of the Registration Process, which keys or credentials and of the Registration Process, which keys or credentials and
proof-of-possession of the corresponding secrets they will use proof-of-possession of the corresponding secrets they will use
to authenticate each other, and in particular, to authenticate to authenticate each other, and in particular, to authenticate
or sign the policies, or how they will agree on them or renew or sign the policies, or how they will agree on them or renew
those keys or credentials. those keys or credentials.
Cuellar, Morris, Mulligan 13 Cuellar, Morris, Mulligan 13
Geopriv Requirements Nov 2002 Geopriv Requirements Jan 2003
2: End-to-End Negotiation: 2: End-to-End Negotiation:
The Rule Maker and the Location Seeker exchange information The Rule Maker and the Location Seeker exchange information
about the service (if any) and negotiate it. They also about the service (if any) and negotiate it. They also
negotiate the pseudonyms that they will use later on and the negotiate the pseudonyms that they will use later on and the
credentials or keys that the Ultimate Location Recipient will credentials or keys that the Ultimate Location Recipient will
use to prove his authorization to the Location Server. This use to prove his authorization to the Location Server. This
End-to-End Negotiation may contain several messages and may End-to-End Negotiation may contain several messages and may
use or not the Location Object. use or not the Location Object.
skipping to change at line 752 skipping to change at line 753
7: Filtered Location Information: 7: Filtered Location Information:
Then the Location Server sends the location information to the Then the Location Server sends the location information to the
Location Recipient. The information may be filtered in the Location Recipient. The information may be filtered in the
sense that in general a less precise or a computed version of sense that in general a less precise or a computed version of
the information is being delivered. the information is being delivered.
5. Requirements 5. Requirements
Cuellar, Morris, Mulligan 14 Cuellar, Morris, Mulligan 14
Geopriv Requirements Nov 2002 Geopriv Requirements Jan 2003
5.1. Location Object 5.1. Location Object
Req. 1. (Location Object generalities) Req. 1. (Location Object generalities)
1.1) Geopriv MUST define one Location Object (LO) -- both in 1.1) Geopriv MUST define one Location Object (LO) -- both in
syntax and semantics -- that must be supported by all geopriv syntax and semantics -- that must be supported by all geopriv
entities. entities.
1.2) Some fields of the Location Object MAY be optional. This 1.2) Some fields of the Location Object MAY be optional. This
skipping to change at line 787 skipping to change at line 788
1.6) The object MUST permit (but not require) the policy to be 1.6) The object MUST permit (but not require) the policy to be
enforced by a third party. enforced by a third party.
1.7) The object MUST be usable in a variety of protocols, such as 1.7) The object MUST be usable in a variety of protocols, such as
HTTP and SIP, as well as local APIs. HTTP and SIP, as well as local APIs.
1.8) The object MUST be usable in a secure manner even by 1.8) The object MUST be usable in a secure manner even by
applications on constrained devices. applications on constrained devices.
Req. 2. (Location Object fields) The Location Object MUST support Req. 2. (Location Object fields) The Location Object definition
the following (eventually optional) Fields MUST support the following Fields (but not all LOs must use all
fields)
2.1) Target Identifier. 2.1) Target Identifier
2.2) Location Recipient Identity 2.2) Location Recipient Identity
This identity may be a multicast or group identity, used to This identity may be a multicast or group identity, used to
include the Location Object in multicast-based using protocols. include the Location Object in multicast-based using protocols.
2.3) Location Recipient Credential 2.3) Location Recipient Credential
2.4) Location Recipient Proof-of-Possession of the Credential 2.4) Location Recipient Proof-of-Possession of the Credential
2.5) Location Field. 2.5) Location Field.
Cuellar, Morris, Mulligan 15
Geopriv Requirements Jan 2003
Each Location Field may contain one or more Location Each Location Field may contain one or more Location
Representations, which can be also in different formats. Representations, which can be also in different formats.
Cuellar, Morris, Mulligan 15
Geopriv Requirements Nov 2002
2.6) Location Data Type 2.6) Location Data Type
When transmitting the Location Object, the sender and the When transmitting the Location Object, the sender and the
receiver must agree on the data type of the location information. receiver must agree on the data type of the location information.
The using protocol may specify that the data type information is The using protocol may specify that the data type information is
part of the Location Object or that sender and receiver have part of the Location Object or that sender and receiver have
agreed on it before the actual data transfer. agreed on it before the actual data transfer.
2.7) Motion and direction vectors 2.7) Motion and direction vectors
2.8) Timing information: 2.8) Timing information:
(a) When was the LI accurate? (sighting time) (a) When was the LI accurate? (sighting time)
(b) Until when considered current? TTL (Time-to-live) (This is (b) Until when considered current? TTL (Time-to-live) (This is
different than a privacy rule setting a limit on data retention) different than a privacy rule setting a limit on data retention)
2.9) Policy Field: this field MAY be a referral to an applicable 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 policy (for instance, an URI to a full policy), or it MAY contain
a Limited Policy (see Req. 9). a Limited Policy (see Req. 9), or both.
2.10) Security-headers and -trailers (for instance encryption 2.10) Security-headers and -trailers (for instance encryption
information, hashes, or signatures) (see Req. 13). information, hashes, or signatures) (see Req. 13).
2.11) Version number 2.11) Version number
Req. 3. (Location Data Types) Req. 3. (Location Data Types)
3.1) The Location Object MUST define at least one Location Data 3.1) The Location Object MUST define at least one Location Data
Type to be supported by all geopriv receivers (entities that Type to be supported by all geopriv receivers (entities that
skipping to change at line 857 skipping to change at line 859
and confidentiality needs. and confidentiality needs.
3.4) The Location Object definition SHOULD agree on further 3.4) The Location Object definition SHOULD agree on further
Location Data Types supported by some geopriv entities and Location Data Types supported by some geopriv entities and
defined by other organizations. defined by other organizations.
5.2. The Using Protocol 5.2. The Using Protocol
Req. 4. The using protocol has to obey the privacy and security Req. 4. The using protocol has to obey the privacy and security
instructions coded in the Location Object and in the instructions coded in the Location Object and in the
corresponding Policy Rules regarding the transmission and storage
of the LO.
Cuellar, Morris, Mulligan 16 Cuellar, Morris, Mulligan 16
Geopriv Requirements Nov 2002 Geopriv Requirements Jan 2003
corresponding Policy Rules regarding the transmission and storage
of the LO.
Req. 5. The using protocol will typically facilitate that the keys Req. 5. The using protocol will typically facilitate that the keys
associated with the credentials are transported to the respective associated with the credentials are transported to the respective
parties, that is, key agreement is responsibility of the using parties, that is, key agreement is responsibility of the using
protocol. 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 Other requirements on the using protocol are out of the scope of
this document. See also Section 9 (Protocol and LO Issues for later this document. See also Section 9 (Protocol and LO Issues for later
Consideration) Consideration)
5.3. Policy based Location Data Transfer 5.3. Policy based Location Data Transfer
Req. 6. (LServ Policies) The decision of a Location Server to Req. 7. (LServ Policies) The decision of a Location Server to
provide a Location Seeker access to Location Information MUST be provide a Location Seeker access to Location Information MUST be
based on Rule Maker-defined Privacy Policies. based on Rule Maker-defined Privacy Policies.
It is outside of our scope how Privacy Policies are managed, how a 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 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 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 that it might be that some rules contain private information not
intended for untrusted parties. intended for untrusted parties.
Req. 7. (LoSi Policies) Even if a Location Sighter is unaware of Req. 8. (LoSi Policies) Even if a Location Sighter is unaware of
and lacks access to the full Privacy Policies defined by the Rule and lacks access to the full Privacy Policies defined by the Rule
Maker, the Location Sighter MUST transmit Location Information in Maker, the Location Sighter MUST transmit Location Information in
compliance with instructions set by the Rule Maker. Such compliance with instructions set by the Rule Maker. Such
compliance MAY be accomplished by the Location Sighter compliance MAY be accomplished by the Location Sighter
transmitting LI only to a URI designated by the Rule Maker. transmitting LI only to a URI designated by the Rule Maker.
Req. 8. (ULR Policies) An Ultimate Location Recipient does not need Req. 9. (ULR Policies) An Ultimate Location Recipient does not need
to be aware of the full policies defined by the Rule Maker to be aware of the full policies defined by the Rule Maker
(because an ULR SHOULD NOT retransmit Location Information), and (because an ULR SHOULD NOT retransmit Location Information), and
thus an ULR SHOULD receive only the subset of Privacy Policies thus an ULR SHOULD receive only the subset of Privacy Policies
necessary for the ULR to handle the LI in compliance with the necessary for the ULR to handle the LI in compliance with the
full Privacy Policies (such as, for example, an instruction on full Privacy Policies (such as, for example, an instruction on
the time period for which then LI can be retained). the time period for which then LI can be retained).
Req. 9. (Full Policy language) Geopriv MAY specify a policy Req. 10. (Full Policy language) Geopriv MAY specify a policy
language capable of expressing a wide range of privacy rules language capable of expressing a wide range of privacy rules
concerning location information. This policy language MAY be an concerning location information. This policy language MAY be an
existing one, an adaptation of an existing one or a new policy existing one, an adaptation of an existing one or a new policy
language, and it SHOULD be as simple as possible. language, and it SHOULD be as simple as possible.
Req. 10. (Limited Policy language) Geopriv MUST specify a limited Req. 11. (Limited Policy language) Geopriv MUST specify a limited
policy language capable of expressing a limited set of privacy policy language capable of expressing a limited set of privacy
Cuellar, Morris, Mulligan 17
Geopriv Requirements Jan 2003
rules concerning location information. This policy language MAY rules concerning location information. This policy language MAY
be an existing one, an adaptation of an existing one or a new be an existing one, an adaptation of an existing one or a new
policy language. The Location Object MUST include sufficient policy language. The Location Object MUST include sufficient
fields and data to express the limited set of privacy rules. fields and data to express the limited set of privacy rules.
5.4. Location Object Privacy and Security 5.4. Location Object Privacy and Security
Cuellar, Morris, Mulligan 17
Geopriv Requirements Nov 2002
5.5. Identity Protection 5.5. Identity Protection
Req. 11. (Identity Protection) The Location Object MUST support use Req. 12. (Identity Protection) The Location Object MUST support use
of Unlinked Pseudonyms in the corresponding identification fields of Unlinked Pseudonyms in the corresponding identification fields
of Rule Maker, Target, Device, and Location Recipient. Since of Rule Maker, Target, Device, and Location Recipient. Since
Unlinked Pseudonyms are simply bit strings that are not linked Unlinked Pseudonyms are simply bit strings that are not linked
initially to a well-known identity, this requirement boils down initially to a well-known identity, this requirement boils down
to saying that the name space for Identifiers used in the LO has to saying that the name space for Identifiers used in the LO has
to be large enough to contain many unused strings. to be large enough to contain many unused strings.
5.6. Authentication Requirements 5.6. Authentication Requirements
Req. 12. (Credential Requirements) The using protocol and the Req. 13. (Credential Requirements) The using protocol and the
Location Object SHOULD allow the use of different credentials Location Object SHOULD allow the use of different credentials
types, including privacy-enhancing credentials (like for instance types, including privacy-enhancing credentials (like for instance
the ones described in [Bra00] or [Cha85]). the ones described in [Bra00] or [Cha85]).
5.7. Actions to be secured 5.7. Actions to be secured
Req. 13. (Security Features) The Location Object MUST support Req. 14. (Security Features) The Location Object MUST support
fields suitable for protecting the Object to provide the fields suitable for protecting the Object to provide the
following security features: following security features:
13.1) Mutual end-point authentication: the using protocol is 14.1) Mutual end-point authentication: the using protocol is
able to authenticate both parties in a Location Object able to authenticate both parties in a Location Object
transmission, transmission,
13.2) Data object integrity: the LO is secured from 14.2) Data object integrity: the LO is secured from
modification by unauthorized entities during transmission and modification by unauthorized entities during transmission and
during storage, during storage,
13.3) Data object confidentiality: the LO is secured from 14.3) Data object confidentiality: the LO is secured from
eavesdropping (unauthorized reading) during transmission and eavesdropping (unauthorized reading) during transmission and
during storage, and during storage, and
13.4) Replay protection: an old LO may not be replayed by an 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 adversary or by the same entity that used the LO itself (except
perhaps during a small window of time that is configurable or perhaps during a small window of time that is configurable or
accepted by the Rule Maker). accepted by the Rule Maker).
Req. 14. (Minimal Crypto) Req. 15. (Minimal Crypto)
14.1) Geopriv MUST specify a minimum mandatory to implement 15.1) Geopriv MUST specify a minimum mandatory to implement
Location Object security including mandatory to implement crypto Location Object security including mandatory to implement crypto
Cuellar, Morris, Mulligan 18
Geopriv Requirements Jan 2003
algorithms, for digital signature algorithms and encryption algorithms, for digital signature algorithms and encryption
algorithms. algorithms.
14.2) It MAY also define further mandatory to implement 15.2) It MAY also define further mandatory to implement
Location Object security mechanisms for message authentication Location Object security mechanisms for message authentication
codes (MACs) or other purposes. codes (MACs) or other purposes.
Cuellar, Morris, Mulligan 18 15.3) The protocol SHOULD allow a bypass if authentication
Geopriv Requirements Nov 2002
14.3) The protocol SHOULD allow a bypass if authentication
fails in an emergency call. fails in an emergency call.
The issue addressed in the last point is that an emergency call in The issue addressed in the last point is that an emergency call in
some very unfavorable situations my not be completed if the minimal some very unfavorable situations my not be completed if the minimal
authentication fails. This is probably not what the user would like authentication fails. This is probably not what the user would like
to see. The user may prefer an unauthenticated call to an to see. The user may prefer an unauthenticated call to an
unauthenticated emergency server than no call completion at all, unauthenticated emergency server than no call completion at all,
even at the risk that he is talking to an attacker or that his even at the risk that he is talking to an attacker or that his
information is not secured. information is not secured.
skipping to change at line 1014 skipping to change at line 1024
The Privacy Policies of the Rule Maker regarding the location of the The Privacy Policies of the Rule Maker regarding the location of the
Target may be accessible to a Location Server in a Private Storage 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 or in a Public Repository, or they may be carried by the Location
Object, or they may be presented by the Location Seeker as Object, or they may be presented by the Location Seeker as
capabilities or tokens. Each of this types of policy has to be capabilities or tokens. Each of this types of policy has to be
secured itĘs own particular way. secured itĘs own particular way.
The rules in a Private Storage are typically authenticated using a The rules in a Private Storage are typically authenticated using a
MAC (Message Authentication Code) or a signature, depending on the MAC (Message Authentication Code) or a signature, depending on the
type of keys used. The rules in a Public Repository (one that in type of keys used. The rules in a Public Repository (one that in
Cuellar, Morris, Mulligan 19
Geopriv Requirements Jan 2003
principle may be accessed directly by several entities, for instance principle may be accessed directly by several entities, for instance
several Location Servers) are typically digitally signed. A Policy several Location Servers) are typically digitally signed. A Policy
Field in a LO is secured as part of the LO itself. A Geopriv Token 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, (a token or ticket issued by the Rule Maker to a Location Seeker,
expressing the explicit consent of the Rule Maker to access his expressing the explicit consent of the Rule Maker to access his
location information) is authenticated or signed. location information) is authenticated or signed.
Cuellar, Morris, Mulligan 19
Geopriv Requirements Nov 2002
6.3. Emergency Case 6.3. Emergency Case
One way of implementing the authentication bypass for emergency One way of implementing the authentication bypass for emergency
calls, mentioned in Req 14.3) is to let the user have the choice of calls, mentioned in Req 14.3) is to let the user have the choice of
writing a policy that says: writing a policy that says:
- "If the emergency server does not authenticate itself, - "If the emergency server does not authenticate itself,
nevertheless send the location", or nevertheless send the location", or
- "If the emergency server does not authenticate itself, let the - "If the emergency server does not authenticate itself, let the
call fail". call fail".
skipping to change at line 1068 skipping to change at line 1079
business partners, and therefore his habits, etc. Reasons for business partners, and therefore his habits, etc. Reasons for
hiding the real identities of the Location Recipients include (a) hiding the real identities of the Location Recipients include (a)
that this knowledge may be used to infer the identity of the Target, that this knowledge may be used to infer the identity of the Target,
(b) that knowledge of the identity of the Location Recipient may (b) that knowledge of the identity of the Location Recipient may
embarrass the Target or breach confidential information, and (c) embarrass the Target or breach confidential information, and (c)
that the dossier telling who has obtained a Target's location that the dossier telling who has obtained a Target's location
information over a long period of time can give information on information over a long period of time can give information on
habits, movements, etc. Even if the location service providers habits, movements, etc. Even if the location service providers
agree to respect the privacy of the user, are compelled by laws or agree to respect the privacy of the user, are compelled by laws or
regulations to protect the privacy of the user, and misbehavior or regulations to protect the privacy of the user, and misbehavior or
Cuellar, Morris, Mulligan 20
Geopriv Requirements Jan 2003
negligence of the Location Server can be ruled out, there is still negligence of the Location Server can be ruled out, there is still
risk that personal data may become available to unauthorized persons risk that personal data may become available to unauthorized persons
through attacks from outsiders, unauthorized access from insiders, through attacks from outsiders, unauthorized access from insiders,
technical or human errors, or legal processes. technical or human errors, or legal processes.
In some occasions a Location Server has to know who is supplying In some occasions a Location Server has to know who is supplying
policies for a particular Target, but in other situations it could policies for a particular Target, but in other situations it could
Cuellar, Morris, Mulligan 20
Geopriv Requirements Nov 2002
be enough to know that the supplier of the policies is authorized to be enough to know that the supplier of the policies is authorized to
do so. Those considerations are outside of our scope. do so. Those considerations are outside of our scope.
6.5. Unintended Target 6.5. Unintended Target
An Unintended Target is a person or object tracked by proximity to An Unintended Target is a person or object tracked by proximity to
the Target. This special case most frequently occurs if the Target the Target. This special case most frequently occurs if the Target
is not a person. For example, the Target may be a rental car 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 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 company may not care about the driver's location, but the driver's
skipping to change at line 1123 skipping to change at line 1134
http://www.chaum.com/articles/ http://www.chaum.com/articles/
[ISO99] ISO99: ISO IS 15408, 1999, http://www.commoncriteria.org/. [ISO99] ISO99: ISO IS 15408, 1999, http://www.commoncriteria.org/.
[OECD] OECD Guidelines on the Protection of Privacy and Transborder [OECD] OECD Guidelines on the Protection of Privacy and Transborder
Flows of Personal Data, http://www.oecd.org. Flows of Personal Data, http://www.oecd.org.
[Pfi01] Pfitzmann, Andreas; K÷hntopp, Marit: Anonymity, [Pfi01] Pfitzmann, Andreas; K÷hntopp, Marit: Anonymity,
Unobservability, and Pseudonymity - A Proposal for Unobservability, and Pseudonymity - A Proposal for
Terminology; in: H Federrath (Ed.): Designing Privacy Terminology; in: H Federrath (Ed.): Designing Privacy
Cuellar, Morris, Mulligan 21
Geopriv Requirements Jan 2003
Enhancing Technologies; Proc. Workshop on Design Issues in Enhancing Technologies; Proc. Workshop on Design Issues in
Anonymity and Unobservability; LNCS 2009; 2001; 1-9. Newer Anonymity and Unobservability; LNCS 2009; 2001; 1-9. Newer
versions available at http://www.koehntopp.de/marit/pub/anon versions available at http://www.koehntopp.de/marit/pub/anon
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
Cuellar, Morris, Mulligan 21
Geopriv Requirements Nov 2002
9. Protocol and LO Issues for later Consideration 9. Protocol and LO Issues for later Consideration
It seems important to mention some issues on the Location Object or It seems important to mention some issues on the Location Object or
on the protocol, which have emerged during the discussion of earlier on the protocol, which have emerged during the discussion of earlier
versions of this document. versions of this document.
9.1. Single Message Transfer 9.1. Multiple Locations in one LO
For several purposes, and in particular for the tracking of small
target devices, the design should not preclude a single
message/packet transmission of location as a complete transaction.
9.2. Multiple Locations in one LO
The possibility of inclusion of multiple locations is discussed in The possibility of inclusion of multiple locations is discussed in
another draft, draft-morris-geopriv-location-object-issues-00.txt. another draft, draft-morris-geopriv-location-object-issues-00.txt.
An instance of a Location Object could contain zero, one, or several An instance of a Location Object could contain zero, one, or several
Location Fields, perhaps in different formats. Several Location Location Fields, perhaps in different formats. Several Location
Fields would be used to report the same sighting in different Fields would be used to report the same sighting in different
formats, or multiple sightings at different times, or multiple formats, or multiple sightings at different times, or multiple
sensor locations for the same device, or other purposes. sensor locations for the same device, or other purposes.
9.3. Translation Fields 9.2. Translation Fields
It is possible to include fields to indicate that one of the 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 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 possible to have a field to identify the translator, as identity and
method. method.
9.4. Specifying Desired Accuracy in a Request 9.3. Specifying Desired Accuracy in a Request
If the LO is used to request location information (leaving some If the LO is used to request location information (leaving some
fields empty), it is not clear how to specify the requested fields empty), it is not clear how to specify the requested
accuracy. Are the data types "country/state/city" and accuracy. Are the data types "country/state/city" and
"country/state" different data types or the same data type with "country/state" different data types or the same data type with
different "accuracy" or "granularity"? different "accuracy" or "granularity"?
9.5. Truth Flag 9.4. Truth Flag
Geopriv should not provide an attribute in object saying "I'm not Geopriv should not provide an attribute in object saying "I'm not
telling you the whole truth." telling you the whole truth."
9.6. Timing Information Format 9.5. Timing Information Format
The format of timing information is out of the scope of this The format of timing information is out of the scope of this
document. document.
9.7. The Name Space of Identifiers 9.6. The Name Space of Identifiers
Cuellar, Morris, Mulligan 22 Cuellar, Morris, Mulligan 22
Geopriv Requirements Nov 2002 Geopriv Requirements Jan 2003
Who defines the Identities: may the using protocol define the Who defines the Identities: may the using protocol define the
Identifiers or must the using protocol use and authenticate Identifiers or must the using protocol use and authenticate
Pseudonyms proposed by the policies, chosen independently of the Pseudonyms proposed by the policies, chosen independently of the
using protocol? Of course, if the using protocol has an appropriate using protocol? Of course, if the using protocol has an appropriate
namespace, containing many unused names that may be used as namespace, containing many unused names that may be used as
pseudonyms and may be replaced by new ones regularly, then the pseudonyms and may be replaced by new ones regularly, then the
Location Object may be able to use the name space. For this purpose, 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 the user would probably have to write his policies using this name
space. Note that it is necessary to change the used pseudonyms space. Note that it is necessary to change the used pseudonyms
skipping to change at line 1239 skipping to change at line 1245
Samuelson Law, Technology and Public Policy Clinic Samuelson Law, Technology and Public Policy Clinic
Boalt Hall School of Law Boalt Hall School of Law
University of California University of California
Berkeley, CA 94720-7 Email: dmulligan@law.berkeley.edu Berkeley, CA 94720-7 Email: dmulligan@law.berkeley.edu
11. Full Copyright Statement 11. Full Copyright Statement
Copyright (C) The Internet Society (date). All Rights Reserved. Copyright (C) The Internet Society (date). All Rights Reserved.
Cuellar, Morris, Mulligan 23 Cuellar, Morris, Mulligan 23
Geopriv Requirements Nov 2002 Geopriv Requirements Jan 2003
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/