Internet Draft J. Cuellar Document: draft-cuellar-geopriv-reqs-02.txt Siemens AG John B. Morris, Jr. Center for Democracy and Technology D. Mulligan Samuelson Law, Technology, and Public Policy Clinic Expires: Nov. 2002 May 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 (user, resource or other entity). There is a need to securely gather and transfer location information for location services, protecting the privacy of the individuals involved. This document describes the requirements for the geopriv Location Object (used to transfer location data and perhaps some other Cuellar, Morris, Mulligan Expires Nov 2002 1 Geopriv Requirements May 2002 information) and for further IETF protocols that use this Location Object as an embedded protocol. We focus on authorization, integrity and privacy requirements. Table of Contents 1. Overview.......................................................2 2. Conventions used in this document..............................4 3. Usage Model....................................................4 3.1. Roles and attributes......................................4 3.2. Data......................................................7 3.3. Identification, Authentication, and Authorization.........8 3.4. Data Flows................................................9 3.4.1. Relationship framework..............................11 3.4.2. Scenarios of Data Flow..............................11 3.5. Further explanations.....................................13 3.5.1. Location Data Types.................................13 3.5.2. Public Global Identities............................14 3.5.3. Authorization without Explicit Authentication.......14 4. Requirements..................................................16 4.1. Protocols................................................16 4.2. Policy based Location Data transfer......................16 4.3. Location Object, Location Data...........................17 4.4. Policies.................................................17 4.5. Identity Protection......................................18 4.6. Authentication Requirements..............................18 4.7. Actions to be secured....................................19 5. Security Considerations.......................................19 6. References....................................................19 7. Author's Addresses............................................20 8. Full Copyright Statement......................................20 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 privacy implications. 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 target's (or better rule-maker's) policy. Cuellar, Morris, Mulligan Expires Nov 2002 2 Geopriv Requirements May 2002 In this paper we assume that "location information" is a relatively specific way of describing where a device is located and that the location information is either (a) derived or computed from information generally not available to the general public, or (b) determined by a device that is not generally publicly addressable or accessible. For example, location information could include information calculated by triangulating on a wireless signal with respect to cell phone towers, or longitude and latitude information determined by a device with GPS (global positioning satellite) capabilities. Excluded from the discussion below 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. It is important to note that information like IP address can enable someone to roughly or in some instances precisely estimate a location. Commercial services exist, for example, 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. This less accurate type of location computation still raises significant potential privacy and public policy concerns, but such scenarios are generally outside the scope of this document. For the purposes of this document, "policies" or "privacy rules" are rules that regulate an entity's activities with respect to location information, including, but not limited to, the collection, use, disclosure, and retention of location information. These rules must generally comply with fair information practices. For example, see the OECD (Organization for Economic Co-operation and Development) Guidelines on the Protection of Privacy and Transporter Flows of Personal Data at http://www1.oecd.org/dsti/sti/it/secur/prod/PRIVEN.HTM. The application of these rules is described briefly in the scenarios. However, they must be fully explored in a separate document prior to creating location privacy technologies. The main principles guiding the requirements exposed in this paper are: 1) Security of the protocol is of utmost importance to guarantee the correctness (integrity) and the confidentiality of the location information. This includes authenticating the main entities of the protocol and securing the exchanged messages. 2) A most important role is played by user-controlled policies, which describe the permissions (or consent) given by the user. The policies specify the necessary conditions that allow a Location Server to forward (transformed or filtered) location information to a Location Recipient and the conditions under which and purposes for which location information can be used. That is, using policies, the user is able to specify which Cuellar, Morris, Mulligan Expires Nov 2002 3 Geopriv Requirements May 2002 component or derived measure of the information is to be released to whom and in which granularity or accuracy. The exact form or expressiveness of policies is not further discussed in this paper. 3) Whenever possible, 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 (ie. phone number). Rather, the user is able to specify which local identifier, pseudonym, or private identifier is to be linked to the location information. 4) 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 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 [1]. Note that the requirements discussed here are requirements on privacy protocols for location services. Thus the requirements sometimes refer only to the capabilities of these protocols. For example, requiring that the protocol 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 is clearly not just a capability of the protocol. 3. Usage Model The following usage model will be discussed more extensively in another framework and scenarios document. We present here a summary of the terminology of the usage model for convenience. 3.1. Roles and attributes The entities of a geopriv application or scenario may be given explicit roles: Target: The entity whose location is desired by the Location Seeker. In many cases the Target will be the human "user" of a Device Cuellar, Morris, Mulligan Expires Nov 2002 4 Geopriv Requirements May 2002 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 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 there may be no Device, in the sense of this definition, but for instance a user is entering the location information manually. Rule-Maker: The individual or entity who has the authorization to set the applicable privacy rules, collectively known also as the policy. In some cases this is the user who is in possession of the Device, but is some cases it is not. For example, parents may control what happens to the location information derived from their children's cell phones. The Rule-Maker is often, but not always, the "owner" of the Device used to track location. For example, a company may own and provide a cell phone to an employee but permit him/her to set the privacy rules. Other proposed names are "Owner (of the privacy rights)" or "policy maker" Unintended Target: 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. Working group protocols may or may not protect or affect the privacy of Unintended Targets, but the impact on Unintended Targets should be acknowledged. Data Transporter (DT): An entity or networking 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 Processor, a Location Processor and a second Location Processor, or a Location Processor and a Location Seeker. Some location tracking scenarios may not involve a Data Transporter. Location Seeker (LS) An individual or entity who seeks to receive location data about a Target. Cuellar, Morris, Mulligan Expires Nov 2002 5 Geopriv Requirements May 2002 Computational Location Server (CLServ) A Device or entity that computes or processes raw data to compute or derive location data, or processes location data to transform or refine the data into new location data. <Why is this CLServ needed?> Location Storage (LStor) (. Location Server: Think of pure storage devices as disks. They matter for privacy purposes!) A Device or entity that stores raw or location data. Rule Repository (RR) A repository that contains private or public policies, identifiers, and perhaps also requests are stored. Attributes An entity that who seeks to access the location data is a Location Seeker and may act in one or more of the following roles: as the Location Sighter (Location Data Source), as 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 (LS), or Intermediate Location Recipient: A Device or entity that provides access to raw data or location data after processing or altering it or not. Some location tracking scenarios may not involve 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 another party distinct from the target or the Rule-Maker. A data transporter may be an Initial Access Provider (IAP): A data transporter 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. Most commonly, an IAP will be a wireless carrier, an Internet Service Provider, or an internal corporate network, used by the Target and the Target's Device and over which location services are provided or utilized. In many cases the IAP is the location sighter. In some instances the IAPs infrastructure may be owned and Cuellar, Morris, Mulligan Expires Nov 2002 6 Geopriv Requirements May 2002 controlled by another party who should be identified. Some location tracking scenarios may not involve any IAP. The rules of the Target may be accessible to a Location Server in the form of Private or Public Rules Repositories: Public Policy Repository: A repository where signed policies, identifiers, and perhaps also requests are stored. Private Policy Repository: A repository of authenticated policies, identifiers, and perhaps also requests are stored, for the private use of one Location Server. +------------------+-----+------+--------+---------+----------+ | | IAP | ULR | Public | Private | Location | | | | | RR | RR | Sighter | +------------------+-----+------+--------+---------+----------+ |Target | | | | | x | +------------------+-----+------+--------+---------+----------+ |Device | | | | | x | +------------------+-----+------+--------+---------+----------+ |Rule Maker | x | | | | x | +------------------+-----+------+--------+---------+----------+ |Unintended Target | | | | | | +------------------+-----+------+--------+---------+----------+ |Data Transporter | x | | | | x | +------------------+-----+------+--------+---------+----------+ |Location Seeker | x | x | | | | +------------------+-----+------+--------+---------+----------+ |Location Server | x | | | | x | +------------------+-----+------+--------+---------+----------+ |Rule Repository | | | x | x | | +------------------+-----+------+--------+---------+----------+ 3.2. Data The main data used by the protocol is the Location Object. It contains the "sighting" information (the pair identity and location) and some other information to be determined, e.g. time information, some types of policies, authenticators, etc. (If no time information is included, this implicitly means "at the current time" or "at a very recent time".) Sighting: the location information for a target. This is the main private data accessed by Location Servers and/or Ultimate Location Recipients. This sighting information is probably Cuellar, Morris, Mulligan Expires Nov 2002 7 Geopriv Requirements May 2002 included in the Location Object. Abstractly, it consists of two separate data fields: (Sighting-Identifier, Location) Sighting-Identifier is the identifier assigned to a device being sighted, and Location is the current position of a device being sighted. Not all entities have access to exactly the same piece of sighting information. The sighting may be transformed to a new sighting pair: (Sighting-Identifier-1, Location-1) before it is provided by the Location Data Source or the Location Server to another Location Recipient. Policy: A 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 contain "rules" or "assertions". Policies must be obeyed; they are not of advisory character. To make this more explicit, the term "rules" is also used instead of "policy". Data attributes: Filtered: Location information that has been computationally modified. 3.3. Identification, Authentication, and Authorization This subsection introduces some terms to be used later in the Requirements Section. Entity-Identifier: The names used by the entities of the protocol to identify, authenticate or authorize themselves to other entities. Policies also use entity-identifiers to express which Location Seekers may receive which transformed sighting information. The next type of identifier may not be used as an Entity-Identifier, since it can be shared by several, perhaps many, different entities: Role identifier ("administrator", "member-of-club-A", etc.) The meaning of the role may be context dependent. Cuellar, Morris, Mulligan Expires Nov 2002 8 Geopriv Requirements May 2002 People use the word authentication with different meanings. Some people insist that authentication associates an entity with a more or less well-known identity. This basically means that if A authenticates another entity as being "B", then the label "B" has also a meaning for many entities different from A. In this case, the label "B" is called a publicly known identifier, and the authentication is "explicit": Explicit Authentication The act of verifying a claimed static identity easily linked back to the real identity of the user, in the form of a pre- existing label from a predefined name space, as the sole originator of a message (message authentication) or as the end-point of a channel (entity authentication). 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. 3.4. Data Flows Figure 1 presents the entities of a "typical" protocol setting, using the Location Object and the data flows between those entities. Not all steps discussed here necessarily occur in every scenario. The data flows may be one-step message exchanges, or multi-step sub- protocols and the actual transport of the Location Object may be done via some other transport entities not included in the diagram. The data flows to be considered by the geopriv WG, in the sense that WG will assess their authentication, authorization and privacy requirements, are the following. They are shown in Figure 1 by normal arrows ("--->") LI (Location Information): the location data source sends the "full", raw location information to the location server. FLI (Filtered Location Information): The location server sends filtered location information to the Location Recipient. The information is filtered in the sense that in general not the original information is being delivered, but for instance a less precise version of the information. There is no technical reason for distinguishing Location Information from Filtered Location Information; it is just a way of insisting that the information sent by the location server is (or could be) different from the information he has received. Cuellar, Morris, Mulligan Expires Nov 2002 9 Geopriv Requirements May 2002 Pol (Policy): The Rule-Maker(or in particular, the target itself) sends a Policy to the location server. PolInfo (Policy Information): the server informs the Location Seeker which data type(s) of filtered location information are available to him for a given target. This mechanism must be able to be invoked by the Location Seeker before he sends an LRequest. LRequest (Location Information Request): the Location Seeker requests location information for a target, a given class of targets, or for targets with a particular set of attributes. In this request, the Location Seeker may select which location information data type it prefers. The Location Seeker can also specify the need for periodic location information updates. +---------+ Locate +-----------+ | Location|<************| Location | SPol +------------+ | Data | LI | Server + |<*************| Public | | Source |------------>| Private | * | Policy | | + IAP | | Repository|<---\ * | Repository | +---------+ +-----------+ | * +------------+ ^ | | | * ^ LRequest| |FLI |PolInfo | * * SPol | V V | * * +----------+ +-----------+ | * * | Target | | Location |<**+****/ +----------+ | or |<***********>| Server + | | | | |Rule-Maker| Service | Private | | <-----------|Rule-Maker| +----------+ | Repository|<--/ Pol | | ^ +-----------+ +----------+ * ^ | | * LRequest| |FLI |PolInfo * | V V * +----------+ * | Ultimate | ******************>| Location | Service | Recipient| +----------+ Figure 1: The Entities and Data Flows The following Data Flows MAY be outside of the scope of the geopriv WG, but should be mentioned for understandability. They are shown in Figure 1 as while starred arrows ("***>"). Cuellar, Morris, Mulligan Expires Nov 2002 10 Geopriv Requirements May 2002 Service: (Service Information, Negotiation and Delivery): The target (or the Rule-Maker) and the client exchange information about the service and negotiate it. The client provides service delivery to the target and accounting or billing date, as necessary. SPol (Signed Policy): As an alternative to Pol, the Rule-Maker may write a policy and place it in the Open Repository. The entities access the repository via SPol. Locate: Request to locate the target. When a Location Server receives an LRequest for a target for which has no current location information, the server may send this "Locate" request to the Location Data Source. 3.4.1. Relationship framework 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. The different relationships raise different concerns for the implementation of privacy rules, including the need to communicate privacy instructions. It is important that the Geopriv specification acknowledge the varied relationships between parties to location exchanges and set out a privacy framework suitable for each. A public rule repository for example seems to be superfluous in a trusted environment where more efficient methods of addressing privacy issues likely exist. We propose the following attributes as modifiers to a given data flow: Trusted: The data flow is governed by a contract that protects location privacy. Non-trusted: The data flow is not governed by a contract that protects location privacy. 3.4.2. Scenarios of Data Flow In this subsection we introduce two 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 Cuellar, Morris, Mulligan Expires Nov 2002 11 Geopriv Requirements May 2002 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 information, and has no capacity to record 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 rulemakers device. SCENARIO 2: Cell Phone Roaming: Cell Phone Company Outsourced Billing and IT In this example, a cell phone is used outside its home service area (roaming). Also, the cell phone service provider (cell phone Corp 2) outsourced the billing 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 billing company which processes the raw data for the billing 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). Cuellar, Morris, Mulligan Expires Nov 2002 12 Geopriv Requirements May 2002 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 rulemaker 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. 3.5. Further explanations <Note: This section is unnecessarily long! Most of text will be removed afterwards, but it may be useful in the discussions. The contents of this subsection may be out of the scope of the work of the working group. They are presented here to facilitate the understanding, present some possible examples, or suggest why some requirements are feasible.> 3.5.1. Location Data Types Two apparently different data types may contain the same information if it is possible to transform one data type into the other and vice- versa without information loss. One location data type DT1 may contain more location information than another DT2 in at least two different senses: - DT1 may have the same dimensions as DT2 has, plus some extra ones. (For instance, DT1 contains velocity, while DT2 does not). Cuellar, Morris, Mulligan Expires Nov 2002 13 Geopriv Requirements May 2002 - DT1 may be more accurate than DT2. In general, if DT1 has more information than DT2, then there is one a function that "translates correctly" from DT1 to DT2. There are other types of transformations that introduce errors (obfuscation: intentionally make the location values less accurate by adding randomness). During a transformation, information can be lost, but not gained. Of course, a transformation that merges information from several sources clearly increases the information of each one. Thus a transformation is a filtering of information. For instance there are transformation functions from both data types "(latitude, longitude, altitude)" and "(country, state, province, city)" to the data types "(country, state)" and "time zone", but not vice-versa. Notice that if the space regions determined by different location values of DT2 do not overlap, then there is at most one transformation from DT1 to DT2. If the space regions of DT2 overlap, then usually there is some choice, which can be given by a (pseudo-) random function. If DT1 does not have more information than DT2, then there is no function that "translates correctly" from DT1 to DT2. In other words: there are many functions that translate from DT1 to DT2, but all introduce some degree of error. We believe that this kind of functions should be avoided. 3.5.2. Public Global Identities If A has some information about a public global identifier "ID" and A discloses this information to B, then B may associate this information with the same entity as A did. In this way, B may accumulate information about the entity labeled by "ID". A public identity is a well-known label that identifies an entity for a (rather large) group of entities. A public identity may be the subscription identity at the home domain (if applicable), a well-known identity (name, address or Tel Number), etc. An entity may regard the disclosure of his public identity (in connection with some activity of him, his location or other attribute) as a violation of his privacy right. 3.5.3. Authorization without Explicit Authentication In order to remain anonymous, an entity may use private identifiers. Private identifiers convey less information than public identities, because they are meaningful to a smaller number of entities and in use for a shorter duration. Thus if A discloses a private identifier Cuellar, Morris, Mulligan Expires Nov 2002 14 Geopriv Requirements May 2002 to B, B is less likely to associate this information with a known individual or entity than if a public identifier was disclosed. Short-lived identifier an identifier that is used only for one or a limited number of "sessions". Short-lived identifiers may be used to anonymously authenticate entities in some settings. In many situations, including pre-paid services, token-based or role- based authorizations, unauthenticated key agreement, and purpose- based identifiers, there is no need for explicit authentication. Using weaker forms of authentication, the communication partner may still want to make sure that he is communicating to the same entity during the whole session, or that he is communicating with an authorized entity. Thus message authentication codes are used, based on "unauthenticated keys". Authorization credentials may be used in the same way as authentication credentials to secure a key agreement in the following sense: one party is assured that no other party aside from the owner of the authorization credentials (and possibly additional identified trusted parties) may gain access to the agreed secret key. The resulting keys are called authorized keys. Those keys may be used for message authentication, without implying an explicit authentication. In real life this corresponds for instance to the following situation: at a cloakroom a person deposits his coat and receives a credential that he may use later to obtain back the coat. One possible goal of the Rule-Maker is to hide the identity of the Location Recipient to the Location Server. Nevertheless, the Location Server has to be sure that the Rule-Maker has authorized the Recipient to access the location. This is a case of authorization without explicit authentication: the Location Server has to be sure that the Location Recipient is a particular (i.e., authorized) communication partner of the Rule-Maker. This may be done for instance as follows: consider a Location Seeker that obtains a set of "traveller's cheques" from the Rule-Maker. The cheques will be used to "buy" location information from a Location Service. Initially, the Location Seeker signs for a first time the cheques with any "signature" that he wants to use. The Rule-Maker, through his own signature, authorizes the signature of the Location Seeker. When presented to the Location Server, the cheques may be countersigned so that the server is sure that the signer is the same as the one who was authorized by the Rule-Maker. This countersignature does not only authenticate the Location Seeker to the verifier, but also indirectly to the Rule-Maker, when the cheque Cuellar, Morris, Mulligan Expires Nov 2002 15 Geopriv Requirements May 2002 is later presented to him. Incidentally, the Rule-Maker may achieve full information about who has accessed to his location information. To hide the real identity of the Rule-Maker to the Location Server, the following dual solution can be used. The Rule-Maker buys (say, using e-cash) a service from a Location Seeker (e.g. a navigation service). During this transaction, the Location Seeker and the Rule- Maker agree on one or several pseudonyms and a set of "traveller's cheques" that the target may use later to authenticate himself to the server and thus indirectly also to the Location Seeker. Since e-cash protocols may be also anonymous, this may be used to hide simultaneously, o the identity of the target from the Location Server, o the identity of the Location Seeker from the Location Server, o the identity of the target from the Location Seeker. But notice that the Location Data Source is in general not able to localize the target based on some short-lived identifier. In this scenario, the Location Data Source should be a Location Server, a different one from the one from whom the identity of the target is to be hidden. 4. Requirements 4.1. Protocols Req. 1. The geopriv protocol MUST be an embedded protocol: it defines a Location Object, together with the security mechanisms used to secure it. The security mechanisms are of two types: on one hand the Location Object as such is secured, using cryptographic checksums or encryption as part of the Location Object itself, and on the other hand security mechanisms may be provided by the embedding transport protocol that uses the Location Object. If possible, security mechanisms on the Location Object itself are to be preferred. We refer to the embedded protocol also as the geopriv protocol and to the combination of both the embedded protocol and the transport protocol as the combined protocol. 4.2. Policy based Location Data transfer Req. 2. The decision of a Location Server to provide a Location Seeker access to location information is based on user- defined privacy policies. Req. 3. The Location Data Source may be unaware of the full policies defined by the Rule-Maker, but in that case it Cuellar, Morris, Mulligan Expires Nov 2002 16 Geopriv Requirements May 2002 will have to obey another set of "generic" policies, consented to by the Rule-Maker, to transfer Location Data (raw or not) to another entity. Req. 4. An Ultimate Location Recipient does not need to be aware of the full policies defined by the Rule-Maker, but it will obey a set of policies regarding the use and retention of the location information. 4.3. Location Object, Location Data Req. 5. The embedded protocol MUST define one Location Object (both in syntax and semantics) that must be supported by all geopriv entities. Some fields of the Location Object MAY be opaque to the embedded protocol. Req. 6. The Location Object MAY define at least one Location Data Type (both syntax and semantics) that must be supported by all geopriv entities, or the Location Data field(s) of the Location Object MAY be opaque. The Location Object MAY define at least one Location Data Type When transmitting location information, (LI and FLI in Figure 1), the sender and the receiver must agree on the data type of the location information. The combined 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. Thus Req. 7. The Location Object MAY contain a field for the data type of the Location Data. This field MAY also be opaque. 4.4. Policies Req. 8. The Location Object MAY contain a field for policies that may be passed to the location server or may be stored in a public (open) repository. Req. 9. The Location Object MAY contain a field for identifiers that may be passed to the location server or may be stored in a public (open) repository. Req. 10. The Location Object MAY contain a field for requests from the clients. Req. 11. The combined protocol MAY specify a policy language. This policy language MAY be an existing one, an adaptation of an existing one or a new policy language. If specified, the policy language MUST be strong enough to express policies of the form: a group G of clients are allowed to know a certain transformation A of the location Cuellar, Morris, Mulligan Expires Nov 2002 17 Geopriv Requirements May 2002 L of a target together with a given identifier I of the target for a given purpose, for a given period of time. If specified, the policy language MUST be strong enough to express conditions on G and A as follows: G, the group of clients SHOULD be characterized by the possession of (identifiers, credentials) with a certain syntactic property. A, the transformation function MAY be specified by data type of the expected filtered location information. Within those constraints, the policy language SHOULD be as simple as possible, or it SHOULD be an existing policy language. 4.5. Identity Protection Req. 12. When a location server accepts a policy that uses a role identifier, the Rule-Maker MUST prove the ownership of the claimed role identifier. This is a property of the combined protocol. Req. 13. The combined protocol MUST be able to hide the real identity and static identifiers association with the real identity of the Rule-Maker, the target, and the device from the Ultimate Location Recipient. This may be easily done using short-lived or role identifiers. Req. 14. The combined protocol MUST be able to hide the real identity of the Location Recipient to the Location Server. <Give an example where hiding the identity of the Location Recipient is what should be required: The target is not concerned about the Server identifying him and knowing his location, but identifying his business partners, and therefore habits, etc.> Req. 15. The combined protocol MUST be able to hide the real identity of the Rule-Maker to a Location Seeker, including a Location Server. 4.6. Authentication Requirements Req. 16. The combined protocol MUST allow different authentication schemes. The combined protocol MUST guarantee that appropriate keys (shared or asymmetric) are generated and available to secure the Location Object within the embedded protocol. Req. 17. The combined protocol MUST allow authorization without explicit authentication. Cuellar, Morris, Mulligan Expires Nov 2002 18 Geopriv Requirements May 2002 4.7. Actions to be secured Req. 18. The embedded protocol MUST be able to secure the Location Object for the following message flows (mutual end-point authentication, data object integrity, data object confidentiality, replay protection, in the absence of a time parameter): LI, Pol, LIF, LRequest, and PolInfo. Req. 19. The embedded protocol MUST specify a minimum mandatory to implement Location Object security including mandatory to implement crypto transforms. Req. 20. The embedding protocol MAY provide extra security for these flows (hop-by-hop or end-to-end). In full details, these requirements have many consequences: the communicating parties MUST have security relationships between them, allowing them to construct secure channels between them. This may imply that some scenarios should not be permitted in general. The Rule-Maker MAY choose to use the security provided by the embedded or by the embedding protocol, or none. Req. 21. When a Location Server accepts a policy from the Rule- Maker, the target MUST prove to the combined protocol that he owns the claimed group or role identifier that should be passed to the Location Recipient. (For instance, if a Target wants the role identifier "medical doctor" to be passed to a Location Recipient, the Target must prove the claims to be a medical doctor.) Req. 22. The "generic" policies (as opposed to the policies created by the Rule-Maker) used by the Location Data Source, by the Ultimate Location Recipients and by the Location Server of some special scenarios to be discussed yet MUST be made explicit. 5. Security Considerations The purpose of the geopriv protocol is to allow a policy-controlled disclosure of location information for location services. Only the information carried within the Location Object is secured in a way compliant with the privacy and security policies of the target. This does not mean that geopriv secures the target against general traffic analysis attacks or other forms of privacy violations. The Location Server is assumed to be trustworthy. 6. References Cuellar, Morris, Mulligan Expires Nov 2002 19 Geopriv Requirements May 2002 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 7. 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 8. Full Copyright Statement Copyright (C) The Internet Society (date). All Rights Reserved. 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 Expires Nov 2002 20