draft-ietf-geopriv-reqs-03.txt   draft-ietf-geopriv-reqs-04.txt 
Internet Draft Jorge Cuellar Internet Draft Jorge Cuellar
Document: draft-ietf-geopriv-reqs-03.txt Siemens AG Document: draft-ietf-geopriv-reqs-04.txt Siemens AG
John B. Morris, Jr. John B. Morris, Jr.
Center for Democracy and Technology Center for Democracy and Technology
Deirdre Mulligan Deirdre Mulligan
Samuelson Law, Technology, and Public Privacy Clinic Samuelson Law, Technology, and Public Privacy Clinic
Jon Peterson Jon Peterson
NeuStar NeuStar
James Polk James Polk
Cisco Cisco
Expires in six months Mar 2003 Expires in six months Oct 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 52 skipping to change at line 52
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract Abstract
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
Cuellar, Morris, Mulligan, Peterson, Polk 1 Cuellar, Morris, Mulligan, Peterson, Polk 1
Geopriv Requirements Mar 2003 Geopriv Requirements Oct 2003
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.
This document focuses on the authorization, security and privacy This document focuses on the authorization, security 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 (LO) and describes the requirements for the Geopriv Location Object (LO) and
for the protocols that use this Location Object. This LO is for the protocols that use this Location Object. This LO is
skipping to change at line 103 skipping to change at line 103
8.3. Emergency Case...........................................23 8.3. Emergency Case...........................................23
8.4. Identities and Anonymity.................................23 8.4. Identities and Anonymity.................................23
8.5. Unintended Target........................................24 8.5. Unintended Target........................................24
9. Protocol and LO Issues for later Consideration................24 9. Protocol and LO Issues for later Consideration................24
9.1. Multiple Locations in one LO.............................24 9.1. Multiple Locations in one LO.............................24
9.2. Translation Fields.......................................24 9.2. Translation Fields.......................................24
9.3. Truth Flag...............................................25 9.3. Truth Flag...............................................25
9.4. Timing Information Format................................25 9.4. Timing Information Format................................25
Cuellar, Morris, Mulligan, Peterson, Polk 2 Cuellar, Morris, Mulligan, Peterson, Polk 2
Geopriv Requirements Mar 2003 Geopriv Requirements Oct 2003
9.5. The Name Space of Identifiers............................25 9.5. The Name Space of Identifiers............................25
10. Acknowledgements.............................................25 10. Acknowledgements.............................................25
11. References...................................................25 11. References...................................................25
12. Author's Addresses...........................................26 12. Author's Addresses...........................................26
13. Full Copyright Statement.....................................27 13. Full Copyright Statement.....................................27
1. Overview 1. Overview
Location-based services (applications that require geographic Location-based services (applications that require geographic
skipping to change at line 157 skipping to change at line 157
3) One type of Privacy Rules specify in particular how location 3) One type of Privacy Rules specify in particular how location
information should be filtered, depending on who the recipient information should be filtered, depending on who the recipient
is. Filtering is the process of reducing the precision or is. Filtering is the process of reducing the precision or
resolution of the data. A typical rule may be of the form: "my resolution of the data. A typical rule may be of the form: "my
location can only be disclosed to the owner of such credentials location can only be disclosed to the owner of such credentials
in such precision or resolution" (e.g., "my co-workers can be in such precision or resolution" (e.g., "my co-workers can be
told the city I am currently in"). told the city I am currently in").
Cuellar, Morris, Mulligan, Peterson, Polk 3 Cuellar, Morris, Mulligan, Peterson, Polk 3
Geopriv Requirements Mar 2003 Geopriv Requirements Oct 2003
4) The Location Object should be able to carry a limited but core 4) The Location Object should be able to carry a limited but core
set of Privacy Rules. The exact form or expressiveness of those set of Privacy Rules. The exact form or expressiveness of those
Rules in the core set or in the full set is not further discussed Rules in the core set or in the full set is not further discussed
in this document, but will be discussed more extensively in in this document, but will be discussed more extensively in
future documents produced by this working group. future documents produced by this working group.
5) Whenever appropriate, the location information should not be 5) 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 (i.e., easily linked back to the real identity of the user (i.e.,
skipping to change at line 213 skipping to change at line 213
3. Glossary 3. Glossary
For easy reference and readability, below are basic terms that will For easy reference and readability, below are basic terms that will
be defined more formally and fully later in this document. be defined more formally and fully later in this document.
Location Generator (LG): The entity that initially determines or Location Generator (LG): The entity that initially determines or
gathers the location of the Target and creates Location gathers the location of the Target and creates Location
Objects describing the location of the Target. Objects describing the location of the Target.
Cuellar, Morris, Mulligan, Peterson, Polk 4 Cuellar, Morris, Mulligan, Peterson, Polk 4
Geopriv Requirements Mar 2003 Geopriv Requirements Oct 2003
Location Object (LO): An object conveying location information Location Object (LO): An object conveying location information
(and possibly privacy rules) to which Geopriv security (and possibly privacy rules) to which Geopriv security
mechanisms and privacy rules are to be applied. mechanisms and privacy rules are to be applied.
Location Recipient (LR): The entity that receives location Location Recipient (LR): The entity that receives location
information. It may have asked for this location explicitly information. It may have asked for this location explicitly
(by sending a query to a location server), or it may receive (by sending a query to a location server), or it may receive
this location asynchronously. this location asynchronously.
skipping to change at line 241 skipping to change at line 241
Principal: The holder/subject of the credentials, e.g. a Principal: The holder/subject of the credentials, e.g. a
workstation user or a network server. workstation user or a network server.
Resolution: The fineness of detail that can be distinguished in Resolution: The fineness of detail that can be distinguished in
measured area. Applied to Geopriv this means the fineness of measured area. Applied to Geopriv this means the fineness of
area within provided, and closed, borders (ex. Latitude and area within provided, and closed, borders (ex. Latitude and
Longitude boundaries). Longitude boundaries).
Rule Holder: The entity that provides the rules associated with a Rule Holder: The entity that provides the rules associated with a
particular target for the distribution of location particular target for the distribution of location
information. It may either push rules to a location server, information. It may either push rules to a location server,
or a location server may pull rules from the Rule Holder. or a location server may pull rules from the Rule Holder.
Rule Maker: The authority that creates rules governing access to Rule Maker: The authority that creates rules governing access to
location information for a target (typically, this it the location information for a target (typically, this it the
target themselves). target themselves).
Rule, or Privacy Rule: A directive that regulates an entity's Rule, or Privacy Rule: A directive that regulates an entity's
activities with respect to location information, including the activities with respect to location information, including the
collection, use, disclosure, and retention of location collection, use, disclosure, and retention of location
information. information.
skipping to change at line 267 skipping to change at line 267
Viewer: A Principal that consumes location information that is Viewer: A Principal that consumes location information that is
communicated by a Geopriv Location Object, but does not pass communicated by a Geopriv Location Object, but does not pass
this information further. this information further.
Resolution and Precision are very close terms. Either quality can Resolution and Precision are very close terms. Either quality can
be 'reduced' to coarsen location information: 'resolution' by be 'reduced' to coarsen location information: 'resolution' by
defining a off-center perimeter around a user's location or defining a off-center perimeter around a user's location or
Cuellar, Morris, Mulligan, Peterson, Polk 5 Cuellar, Morris, Mulligan, Peterson, Polk 5
Geopriv Requirements Mar 2003 Geopriv Requirements Oct 2003
otherwise enlarging the area in consideration (from state to otherwise enlarging the area in consideration (from state to
country, say) and 'precision' by discarding significant digits of country, say) and 'precision' by discarding significant digits of
positioning information (rounding off longitude and latitude from positioning information (rounding off longitude and latitude from
seconds to minutes, say). Another WG document treats this topic in seconds to minutes, say). Another WG document treats this topic in
much more detail. much more detail.
4. Primary Geopriv Entities 4. Primary Geopriv Entities
The following picture shows the primary Geopriv entities in a simple The following picture shows the primary Geopriv entities in a simple
skipping to change at line 318 skipping to change at line 318
applies the rules (which it learns from the Rule Holder) to applies the rules (which it learns from the Rule Holder) to
LOs it receives from LGs, and then notifies LRs of resulting LOs it receives from LGs, and then notifies LRs of resulting
LOs as necessary. LOs as necessary.
Location Recipient (LR): The LR is an element that receives Location Recipient (LR): The LR is an element that receives
notifications of Location Objects from Location Servers. The notifications of Location Objects from Location Servers. The
LR may render these LOs to a user or automaton in some LR may render these LOs to a user or automaton in some
fashion. fashion.
Cuellar, Morris, Mulligan, Peterson, Polk 6 Cuellar, Morris, Mulligan, Peterson, Polk 6
Geopriv Requirements Mar 2003 Geopriv Requirements Oct 2003
Rule Holder (RH): The RH is an element that houses Privacy Rules Rule Holder (RH): The RH is an element that houses Privacy Rules
for receiving, filtering and distributing Location Objects for for receiving, filtering and distributing Location Objects for
specific Targets. A LS may query an RH for a set of rules, or specific Targets. A LS may query an RH for a set of rules, or
rules may be pushed from the RH to an LS. The rules in the rules may be pushed from the RH to an LS. The rules in the
Rule Holder are populated by the Rule Maker. Rule Holder are populated by the Rule Maker.
Thus Location Generation is the process of gathering Location Thus Location Generation is the process of gathering Location
Information, perhaps from multiple sources, at an IP-based Geopriv Information, perhaps from multiple sources, at an IP-based Geopriv
Entity, the LG, which communicates with other Geopriv Entities. Entity, the LG, which communicates with other Geopriv Entities.
skipping to change at line 373 skipping to change at line 373
This Location Information may have determined in many different This Location Information may have determined in many different
ways, including: ways, including:
(a) derived or computed from information generally not available to (a) derived or computed from information generally not available to
the general public (such as information mainly available to a the general public (such as information mainly available to a
network or service provider), (b) determined by a Device that may be network or service provider), (b) determined by a Device that may be
not generally publicly addressable or accessible, or (c) input or not generally publicly addressable or accessible, or (c) input or
otherwise provided by a Target. otherwise provided by a Target.
Cuellar, Morris, Mulligan, Peterson, Polk 7 Cuellar, Morris, Mulligan, Peterson, Polk 7
Geopriv Requirements Mar 2003 Geopriv Requirements Oct 2003
As examples, the Location Information could include (a) information As examples, the Location Information could include (a) information
calculated by triangulating on a wireless signal with respect to calculated by triangulating on a wireless signal with respect to
cell phone towers, (b) longitude and latitude information determined cell phone towers, (b) longitude and latitude information determined
by a Device with GPS (global positioning satellite) capabilities, by a Device with GPS (global positioning satellite) capabilities,
(c) information manually entered into a cell phone or laptop by a (c) information manually entered into a cell phone or laptop by a
Target in response to a query, or (d) automatically delivered by Target in response to a query, or (d) automatically delivered by
some other IP protocol, such as at device configuration via DHCP. some other IP protocol, such as at device configuration via DHCP.
Excluded from this definition is the determination of location Excluded from this definition is the determination of location
skipping to change at line 427 skipping to change at line 427
(Identifier-1, Location-1) (Identifier-1, Location-1)
before it is provided by a Location Generator or Location Server to before it is provided by a Location Generator or Location Server to
Location Recipient. In this case, Identifier-1 may be Pseudonym, Location Recipient. In this case, Identifier-1 may be Pseudonym,
and Location-1 may have less precision or resolution than the and Location-1 may have less precision or resolution than the
original value. original value.
5.2. The Location Object and Using Protocol 5.2. The Location Object and Using Protocol
Cuellar, Morris, Mulligan, Peterson, Polk 8 Cuellar, Morris, Mulligan, Peterson, Polk 8
Geopriv Requirements Mar 2003 Geopriv Requirements Oct 2003
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
of the Target, and other fields including an identity or of the Target, and other fields including an identity or
pseudonym of the Target, time information, core Privacy Rules, pseudonym of the Target, time information, core Privacy Rules,
authenticators, etc. Most of the fields are optional, authenticators, etc. Most of the fields are optional,
including the Location Information itself. including the Location Information itself.
skipping to change at line 482 skipping to change at line 482
some cases the participants will have longstanding relationships, some cases the participants will have longstanding relationships,
while in others the participants may have discrete interactions with while in others the participants may have discrete interactions with
no prior contractual or other contact. no prior contractual or other contact.
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
Privacy Rules. A public Rule Holder, for example, may be Privacy Rules. A public Rule Holder, for example, may be
unnecessary in a trusted environment where more efficient methods of unnecessary in a trusted environment where more efficient methods of
Cuellar, Morris, Mulligan, Peterson, Polk 9 Cuellar, Morris, Mulligan, Peterson, Polk 9
Geopriv Requirements Mar 2003 Geopriv Requirements Oct 2003
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:
The data flow is not governed by a pre-existing contractual The data flow is not governed by a pre-existing contractual
skipping to change at line 536 skipping to change at line 536
override might be placed on the Privacy Rules of the Rule override might be placed on the Privacy Rules of the Rule
Maker: Maker:
1. In the case of emergency services (such as E911 within the 1. In the case of emergency services (such as E911 within the
United States), local or national laws may require that United States), local or national laws may require that
accurate location information be transmitted in certain accurate location information be transmitted in certain
defined emergency call situations. The Geopriv Working Group defined emergency call situations. The Geopriv Working Group
MUST facilitate this situation. MUST facilitate this situation.
Cuellar, Morris, Mulligan, Peterson, Polk 10 Cuellar, Morris, Mulligan, Peterson, Polk 10
Geopriv Requirements Mar 2003 Geopriv Requirements Oct 2003
2. In the case of legal interception, the RM may not be aware 2. In the case of legal interception, the RM may not be aware
of an override directive imposed by a legal authority. It is of an override directive imposed by a legal authority. It is
not the expectation of the Working Group that particular not the expectation of the Working Group that particular
accommodation will be made to facilitate this situation. accommodation will be made to facilitate this situation.
3. In the context of an employment relationship or other 3. In the context of an employment relationship or other
contractual relationship, the owner of a particular location contractual relationship, the owner of a particular location
(such as a corporate campus) may impose constraints on the use (such as a corporate campus) may impose constraints on the use
of Privacy Rules by a Rule Maker. It is not the expectation of Privacy Rules by a Rule Maker. It is not the expectation
skipping to change at line 591 skipping to change at line 591
may not involve any AP, or the AP may only act as a Data may not involve any AP, or the AP may only act as a Data
Transporter. Transporter.
Location Storage: Location Storage:
A Device or entity that stores raw or processed Location A Device or entity that stores raw or processed Location
Information, such as a database, for any period of time longer Information, such as a database, for any period of time longer
than the duration necessary to complete an immediate than the duration necessary to complete an immediate
transaction regarding the Location Information. transaction regarding the Location Information.
Cuellar, Morris, Mulligan, Peterson, Polk 11 Cuellar, Morris, Mulligan, Peterson, Polk 11
Geopriv Requirements Mar 2003 Geopriv Requirements Oct 2003
The existence and data storage practices of Location Storage is The existence and data storage practices of Location Storage is
crucial to privacy considerations, because this may influence what crucial to privacy considerations, because this may influence what
Location Information could eventually be revealed (through later Location Information could eventually be revealed (through later
distribution, technical breach, or legal processes). distribution, technical breach, or legal processes).
5.5. Privacy Rules 5.5. Privacy Rules
Privacy Rules are rules that regulate an entity's activities with Privacy Rules are rules that regulate an entity's activities with
respect to location and other information, including, but not respect to location and other information, including, but not
skipping to change at line 644 skipping to change at line 644
the ability to remain anonymous, individuals may be unable to the ability to remain anonymous, individuals may be unable to
control their own privacy. Unlinkability ensures that a user may control their own privacy. Unlinkability ensures that a user may
make multiple uses of resources or services without others being make multiple uses of resources or services without others being
able to link these uses to each other. Unlinkability requires that able to link these uses to each other. Unlinkability requires that
entities are unable to determine whether the same user caused entities are unable to determine whether the same user caused
certain specific operations in the system. [ISO99] A pseudonym is 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 simply a bit string which is unique as ID and is suitable to be used
for end-point authentication. for end-point authentication.
Cuellar, Morris, Mulligan, Peterson, Polk 12 Cuellar, Morris, Mulligan, Peterson, Polk 12
Geopriv Requirements Mar 2003 Geopriv Requirements Oct 2003
Unlinked Pseudonym: Unlinked Pseudonym:
A pseudonym where the linking between the pseudonym and its A pseudonym where the linking between the pseudonym and its
holder is, at least initially, not known to anybody with the holder is, at least initially, not known to anybody with the
possible exception of the holder himself or a trusted server possible exception of the holder himself or a trusted server
of the user. See [Pfi01] (there the term is called Initially of the user. See [Pfi01] (there the term is called Initially
Unlinked Pseudonym) Unlinked Pseudonym)
The word authentication is used in different meanings. Some require The word authentication is used in different meanings. Some require
that authentication associates an entity with a more or less well- that authentication associates an entity with a more or less well-
skipping to change at line 697 skipping to change at line 697
Global Positioning System (GPS) and the Device is capable of Global Positioning System (GPS) and the Device is capable of
independently processing the raw data to determine its location. independently processing the raw data to determine its location.
The location is derived as follows: the Device receives The location is derived as follows: the Device receives
transmissions from the GPS satellites, internally computes and transmissions from the GPS satellites, internally computes and
displays location. This is a closed system. For the purpose of this displays location. This is a closed system. For the purpose of this
and subsequent examples, it is assumed that the GPS satellite and subsequent examples, it is assumed that the GPS satellite
broadcasts some signal, and has no information about the identity or broadcasts some signal, and has no information about the identity or
whereabouts of Devices using the signal. whereabouts of Devices using the signal.
Cuellar, Morris, Mulligan, Peterson, Polk 13 Cuellar, Morris, Mulligan, Peterson, Polk 13
Geopriv Requirements Mar 2003 Geopriv Requirements Oct 2003
GPS Satellite GPS Satellite
| |
| Sighting (not a Geopriv Interface) | Sighting (not a Geopriv Interface)
| |
| |
| |
V GPS Device V GPS Device
-------------------------------------------------- --------------------------------------------------
/ \ / \
skipping to change at line 727 skipping to change at line 727
/ V \ / V \
/ Target Location \ / Target Location \
| Recipient | | Recipient |
| | | |
\ Rule Maker / \ Rule Maker /
\ / \ /
------------------- -------------------
In this scenario the GPS Device is both the AP and the LG. The In this scenario the GPS Device is both the AP and the LG. The
interaction occurs in a Trusted environment because it occurs in the interaction occurs in a Trusted environment because it occurs in the
Rule Makers Device. Rule Makers 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)
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 (AP) provides the roaming service the cell phone, cell phone Corp 1 (AP) 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
warehouse where the raw data is stored in a Location Server (e.g., warehouse where the raw data is stored in a Location Server (e.g.,
computer server). computer server).
Cuellar, Morris, Mulligan, Peterson, Polk 14 Cuellar, Morris, Mulligan, Peterson, Polk 14
Geopriv Requirements Mar 2003 Geopriv Requirements Oct 2003
Cell Phone Corp 1 Cell Phone Corp 2 Cell Phone Corp 1 Cell Phone Corp 2
----------------- ----------------- ----------------- -----------------
Sighting / \ Publish / \ Sighting / \ Publish / \
Device ----- | Data Transporter | --------- | Data Transporter | Device ----- | Data Transporter | --------- | Data Transporter |
Target \ / Interface \ / Target \ / Interface \ /
----------------- / ----------------- ----------------- / -----------------
/ | / |
/ | Notification / | Notification
/ | Interface / | Interface
skipping to change at line 787 skipping to change at line 787
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, Rules and Location Data credentials and proof-of-possession of them, Rules and Location Data
Information, including Data Types and Precision or Resolution. Information, including Data Types and Precision or Resolution.
Messages that do not use the Location Object and are outside of the Messages that do not use the Location Object and are outside of the
scope of the Geopriv WG, but should be mentioned for scope of the Geopriv WG, but should be mentioned for
understandability, are shown in the figure as starred arrows understandability, are shown in the figure as starred arrows
("***>"). ("***>").
Cuellar, Morris, Mulligan, Peterson, Polk 15 Cuellar, Morris, Mulligan, Peterson, Polk 15
Geopriv Requirements Mar 2003 Geopriv Requirements Oct 2003
+---------+ +------------+ +---------+ +------------+
| | | | | | | |
| Location|<** | Public | | Location|<** | Public |
|Generator| * | Rule Holder| |Generator| * | Rule Holder|
| | * | | | | * | |
+---------+\ * +------------+ +---------+\ * +------------+
\ *3 1a* * \ *3 1a* *
\ * * * \ * * *
\ ** * \ ** *
skipping to change at line 840 skipping to change at line 840
1a:Signed Rule: 1a:Signed Rule:
As an alternative, the Rule Maker may write a Rule and place As an alternative, the Rule Maker may write a Rule and place
it in a Public Rule Holder. The entities access the it in a Public Rule Holder. The entities access the
repository to read the signed Rules. repository to read the signed Rules.
2: Location Information Request: 2: Location Information Request:
The Location Recipient requests location information for a The Location Recipient requests location information for a
Cuellar, Morris, Mulligan, Peterson, Polk 16 Cuellar, Morris, Mulligan, Peterson, Polk 16
Geopriv Requirements Mar 2003 Geopriv Requirements Oct 2003
Target. In this request, the Location Recipient may select Target. In this request, the Location Recipient may select
which location information data type it prefers. One way of which location information data type it prefers. One way of
requesting Location Information MAY be sending a partially requesting Location Information MAY be sending a partially
filled Location Object, including only the identities of the filled Location Object, including only the identities of the
Target and Location Recipient and the desired Data Type and Target and Location Recipient and the desired Data Type and
precision or resolution, and providing proof of possession of precision or resolution, and providing proof of possession of
the required credentials. But whether the using protocol the required credentials. But whether the using protocol
understands this partially filled object as a request, this understands this partially filled object as a request, this
MAY depend on the using protocol or on the context. The MAY depend on the using protocol or on the context. The
skipping to change at line 896 skipping to change at line 896
Field 'A', which MAY be an optional field." This requirement states Field 'A', which MAY be an optional field." This requirement states
that that
o the document that defines the LO MUST define the LO field 'A', 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 o the field 'A' MAY be defined as optional or not to use. If it is
defined as optional to use, any instance of a LO MAY contain the defined as optional to use, any instance of a LO MAY contain the
field 'A' or not; if it is not optional, all instances of LOs MUST field 'A' or not; if it is not optional, all instances of LOs MUST
contain the field 'A'. contain the field 'A'.
Cuellar, Morris, Mulligan, Peterson, Polk 17 Cuellar, Morris, Mulligan, Peterson, Polk 17
Geopriv Requirements Mar 2003 Geopriv Requirements Oct 2003
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
means that an instance of a Location Object MAY contain the means that an instance of a Location Object MAY contain the
fields or not. fields or not.
skipping to change at line 949 skipping to change at line 949
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.
2.5.1) Motion and direction vectors. This field MUST be 2.5.1) Motion and direction vectors. This field MUST be
optional. optional.
Cuellar, Morris, Mulligan, Peterson, Polk 18 Cuellar, Morris, Mulligan, Peterson, Polk 18
Geopriv Requirements Mar 2003 Geopriv Requirements Oct 2003
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) Timing information: 2.7) Timing information:
skipping to change at line 1004 skipping to change at line 1004
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 Rules regarding the transmission and storage of the corresponding Rules regarding the transmission and storage of the
LO. 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
Cuellar, Morris, Mulligan, Peterson, Polk 19 Cuellar, Morris, Mulligan, Peterson, Polk 19
Geopriv Requirements Mar 2003 Geopriv Requirements Oct 2003
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 Req. 6. (Single Message Transfer) In particular for tracking of
small target devices, the design should allow a single small target devices, the design should allow a single
message/packet transmission of location as a complete message/packet transmission of location as a complete
transaction. 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
skipping to change at line 1059 skipping to change at line 1059
SHOULD be as simple as possible. SHOULD be as simple as possible.
Req. 11. (Limited Rule language) Geopriv MUST specify a limited Req. 11. (Limited Rule language) Geopriv MUST specify a limited
Rule language capable of expressing a limited set of privacy Rule language capable of expressing a limited set of privacy
rules concerning location information. This Rule language MAY be rules concerning location information. This Rule language MAY be
an existing one, an adaptation of an existing one or a new Rule an existing one, an adaptation of an existing one or a new Rule
language. The Location Object MUST include sufficient fields and language. The Location Object MUST include sufficient fields and
data to express the limited set of privacy rules. data to express the limited set of privacy rules.
Cuellar, Morris, Mulligan, Peterson, Polk 20 Cuellar, Morris, Mulligan, Peterson, Polk 20
Geopriv Requirements Mar 2003 Geopriv Requirements Oct 2003
7.4. Location Object Privacy and Security 7.4. Location Object Privacy and Security
7.4.1. Identity Protection 7.4.1. Identity Protection
Req. 12. (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
skipping to change at line 1115 skipping to change at line 1115
15.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
algorithms, for digital signature algorithms and encryption algorithms, for digital signature algorithms and encryption
algorithms. algorithms.
15.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, Peterson, Polk 21 Cuellar, Morris, Mulligan, Peterson, Polk 21
Geopriv Requirements Mar 2003 Geopriv Requirements Oct 2003
15.3) The protocol SHOULD allow a bypass if authentication 15.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 unfavorable situations may not be completed if the minimal some unfavorable situations may 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 happen. The user may prefer an unauthenticated call to an to happen. The user may prefer an unauthenticated call to an
unauthenticated emergency server over no call completion at all, unauthenticated emergency server over 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
skipping to change at line 1168 skipping to change at line 1168
using a MAC (Message Authentication Code) or a signature, depending using a MAC (Message Authentication Code) or a signature, depending
on the type of keys used. The rules in a public Rule Holder (one 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 that in principle may be accessed directly by several entities, for
instance several Location Servers) are typically digitally signed. instance several Location Servers) are typically digitally signed.
Rule Fields in a LO are secured as part of the LO itself. A Geopriv Rule Fields in a LO are secured as part of the LO itself. A Geopriv
Token (a token or ticket issued by the Rule Maker to a Location Token (a token or ticket issued by the Rule Maker to a Location
Recipient, expressing the explicit consent of the Rule Maker to Recipient, expressing the explicit consent of the Rule Maker to
access his location information) is authenticated or signed. access his location information) is authenticated or signed.
Cuellar, Morris, Mulligan, Peterson, Polk 22 Cuellar, Morris, Mulligan, Peterson, Polk 22
Geopriv Requirements Mar 2003 Geopriv Requirements Oct 2003
8.3. Emergency Case 8.3. Emergency Case
Let us consider the situation where the authentication fails in an Let us consider the situation where the authentication fails in an
emergency call because the authentication center fails to emergency call because the authentication center fails to
authenticate itself. In this case, one way of implementing the authenticate itself. In this case, one way of implementing the
authentication bypass for emergency calls, mentioned in Req 15.3) is authentication bypass for emergency calls, mentioned in Req 15.3) is
to let the user have the choice of writing a Rule that says: to let the user have the choice of writing a Rule that says:
- "If the emergency server does not authenticate itself, send the - "If the emergency server does not authenticate itself, send the
location information anyway", or location information anyway", or
skipping to change at line 1222 skipping to change at line 1222
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
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.
Cuellar, Morris, Mulligan, Peterson, Polk 23 Cuellar, Morris, Mulligan, Peterson, Polk 23
Geopriv Requirements Mar 2003 Geopriv Requirements Oct 2003
In some occasions a Location Server has to know who is supplying the In some occasions a Location Server has to know who is supplying the
Privacy Rules for a particular Target, but in other situations it Privacy Rules for a particular Target, but in other situations it
could be enough to know that the supplier of the Rules is authorized could be enough to know that the supplier of the Rules is authorized
to do so. to do so.
8.5. Unintended Target 8.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
skipping to change at line 1274 skipping to change at line 1274
discussion. discussion.
9.2. 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.
Cuellar, Morris, Mulligan, Peterson, Polk 24 Cuellar, Morris, Mulligan, Peterson, Polk 24
Geopriv Requirements Mar 2003 Geopriv Requirements Oct 2003
9.3. Truth Flag 9.3. Truth Flag
Geopriv MUST be silent on the truth or lack-of-truth of the location 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 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 attribute in object saying "I am (or am not) telling you the whole
truth." truth."
9.4. Timing Information Format 9.4. 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.5. The Name Space of Identifiers 9.5. The Name Space of Identifiers
skipping to change at line 1327 skipping to change at line 1327
We wish to thank the members of the IETF Geopriv WG for their We wish to thank the members of the IETF Geopriv WG for their
comments and suggestions. Aaron Burstein, Mehmet Ersue, Allison comments and suggestions. Aaron Burstein, Mehmet Ersue, Allison
Mankin, Randall Gellens, and the participants of the Geopriv Mankin, Randall Gellens, and the participants of the Geopriv
meetings in San Diego and Yokohama provided detailed comments or meetings in San Diego and Yokohama provided detailed comments or
text. text.
11. References 11. References
Cuellar, Morris, Mulligan, Peterson, Polk 25 Cuellar, Morris, Mulligan, Peterson, Polk 25
Geopriv Requirements Mar 2003 Geopriv Requirements Oct 2003
[Bra00] Stefan A.: Rethinking Public Key Infrastructures and Digital [Bra00] Stefan A.: Rethinking Public Key Infrastructures and Digital
Certificates : Building in Privacy, MIT Press; ISBN: Certificates : Building in Privacy, MIT Press; ISBN:
0262024918; 1st edition, August, 2000 0262024918; 1st edition, August, 2000
[Cha85] Chaum, David: Security without Identification, Card [Cha85] Chaum, David: Security without Identification, Card
Computers to make Big Brother Obsolete. Original Version Computers to make Big Brother Obsolete. Original Version
appeared in: Communications of the ACM, vol. 28 no. 10, appeared in: Communications of the ACM, vol. 28 no. 10,
October 1985 pp. 1030-1044. Revised version available at October 1985 pp. 1030-1044. Revised version available at
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; Khntopp, Marit: Anonymity, [Pfi01] Pfitzmann, Andreas; Khntopp, 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
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.
12. Author's Addresses 12. Author's Addresses
skipping to change at line 1383 skipping to change at line 1383
University of California University of California
Berkeley, CA 94720-7 Email: dmulligan@law.berkeley.edu Berkeley, CA 94720-7 Email: dmulligan@law.berkeley.edu
USA USA
Jon Peterson Jon Peterson
NeuStar, Inc. NeuStar, Inc.
1800 Sutter St 1800 Sutter St
Suite 5707 Email: jon.peterson@neustar.biz Suite 5707 Email: jon.peterson@neustar.biz
Cuellar, Morris, Mulligan, Peterson, Polk 26 Cuellar, Morris, Mulligan, Peterson, Polk 26
Geopriv Requirements Mar 2003 Geopriv Requirements Oct 2003
Concord, CA 94520 http://www.neustar.biz/ Concord, CA 94520 http://www.neustar.biz/
USA USA
James M. Polk James M. Polk
Cisco Systems Cisco Systems
2200 East President George Bush Turnpike 2200 East President George Bush Turnpike
Richardson, Texas 75082 USA7 Email: jmpolk@cisco.com Richardson, Texas 75082 USA7 Email: jmpolk@cisco.com
13. Full Copyright Statement 13. Full Copyright Statement
 End of changes. 

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