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