J. Cuellar Internet Draft M. Ersue Document: draft-cuellar-geopriv-reqs-01.txt Siemens AG Expires: 2002 Feb 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 such a geopriv protocol used to transfer location data, focusing on authorization, integrity and privacy. Cuellar, Ersue Expires September 2002 1 Geopriv Requirements March 2002 Table of Contents 1. Overview.......................................................2 2. Conventions used in this document..............................3 3. Usage Model....................................................3 3.1. Entities..................................................3 3.2. Data......................................................4 3.3. Identification, Authentication, and Authorization.........5 3.4. Data Flows................................................5 3.5. Further explanations......................................7 3.5.1. Location Data Types..................................8 3.5.2. Public Global Identities.............................8 3.5.3. Authorization without Explicit Authentication........9 4. Requirements..................................................10 4.1. Location information formats.............................10 4.2. Policies.................................................11 4.3. Identity Protection......................................11 4.4. Authentication Requirements..............................12 4.5. Actions to be secured....................................12 4.6. Transport Requirements...................................12 5. Security Considerations.......................................12 6. References....................................................13 7. Author's Addresses............................................13 8. Full Copyright Statement......................................13 1. Overview The main principles 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. That is, using policies, the user is able to specify which 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. 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. Cuellar, Ersue Expires September 2002 2 Geopriv Requirements March 2002 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 3.1. Entities The draft [2] introduces the following 5 functional elements (or "entities" of the protocol). Please refer to that draft for a discussion of the functionality of the entities and for a description of scenarios. Target: The entity whose location is desired by the Location Recipient. Owner of the privacy rights of the target, or, for abbreviation, the owner, or Rule maker, or policy maker: An entity that has the authorization to detemine and write the privacy policies that apply to the location information of the target. Other probably better names are "policy maker" or "rule maker" Location Server (or "Intermediate Location Receiver"): Entity offering Location Service capabilities based on user-defined privacy policies. Ultimate Location Recipient: A Location Recipient that is the ultimate recipient of the location information (he may not pass this information, or derived one, to others, except to the target or the owner). This entity does not need to be aware of the policies defined by the owner, but it will obey a set of "generic" policies. Location Data Source: The original source of the sighting. For technical reasons, mentioned in [2], the Location Data Source Cuellar, Ersue Expires September 2002 3 Geopriv Requirements March 2002 may be also unaware of the policies defined by the owner, but it will also then obey another set of "generic" policies. Further, we also consider here the following entities: 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. 3.2. Data The main data used by the protocol is the "sighting" (the pair identity and location) and the policies. Sighting: the private data accessed by the Location Data Source and Location Recipients. Abstractly, it is seen as a pair: (Sighting-Identifier, Location) expressing the assertion that the target identified by " Sighting-Identifier" is currently at position "Location". (In practice, this pair may include also a time component. For shortness, we assume no time information, implicitly meaning "at the current time" or "at a very recent time".) 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 being forwarded by the Location Data Source or by the Location Server to another Location Recipient. Sighting-Identifier: The first component of the sighting, used to identify the target. Location: The second component of the sighting, used to describe the current position of the target. Policy: An assertion that a certain transformed sighting information may be released to a certain entity (or group of entities) under a certain set of conditions. Policies are said to contain "rules" or "assertions". Policies in this sense (as in many other uses at the IETF) must be obeyed, they are not of advisory charachter. To make this more explicit, the term: "rule" has been also proposed to Cuellar, Ersue Expires September 2002 4 Geopriv Requirements March 2002 replace "policy", then being a "rule" composed of different "assertions". 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 Recipients may receive which transformed sighting information. The next type of identifier may not be used as an Entity-Identifier, since it shared by several, perhaps many, different entities: Role identifier ("administrator", "member-of-club-A", etc.) The meaning of the role may be context dependent. 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 identity, in the form of a pre- existing label from a publicly known 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 the protocol and the data flows between them. (The data flows MAY be one-step message exchanges, or multi-step sub-protocols). The data flows to be considered by the geopriv WG, in the sense that WG will assess their authentication, authorization and privacy requirements, are: LI (Location Information): the location data source sends the "full", raw location information to the location server. Cuellar, Ersue Expires September 2002 5 Geopriv Requirements March 2002 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 full information is being delivered, but only 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. Pol (Policy): An owner of the target (or in particular, the target itself) sends a Policy to the location server. PolInfo (Policy Information): the server informs the Location Recipient which data type(s) are available for filtered location information for a given target. This mechanism must be able to be invoked by the Location Recipient before he sends an LRequest. LRequest (Location Information Request): the Location Recipient 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 Recipient may select which location information data type it prefers. The Location Recipient can also specify the need for periodic location information updates. Cuellar, Ersue Expires September 2002 6 Geopriv Requirements March 2002 +---------+ Locate +-----------+ | Location|<************| Location | SPol +------------+ | Data | LI | Server + |<*************| Public | | Source |------------>| Private | * | Policy | +---------+ | Repository|<---\ * | Repository | +-----------+ | * +------------+ ^ | | | * ^ LRequest| |FLI |PolInfo | * *SPol | V V | * * +---------+ +-----------+ | * * | Target | | Location |<***+****/ +---------+ | or |<***********>| Server + | | | | | Owner | Service | Private | |<-----------| Owner | +---------+ | Repository|<---/ Pol | | ^ +-----------+ +---------+ * ^ | | * LRequest| |FLI |PolInfo * | V V * +----------+ * | Ultimate | ******************>| Location | Service | Recipient| +----------+ Figure 1: The Entities and Data Flows Normal arrows ("--->") are part of the scope of the geopriv WG, starred arrows ("***>") are probably not. The following Data Flows MAY be outside of the scope of the geopriv WG, but should be mentioned for understandability: Service: (Service Information, Negotiation and Delivery): The target (or the owner of the target) 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 owner of the target 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" command to the Location Data Source. 3.5. Further explanations Note: The contents of this subsection may be out of the scope of the work of the working group. They are presented here only to facilitate the understanding, present some possible examples, or suggest why some requirements are feasible. Cuellar, Ersue Expires September 2002 7 Geopriv Requirements March 2002 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). - 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. 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. Cuellar, Ersue Expires September 2002 8 Geopriv Requirements March 2002 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. The idea is that private identifiers convey less information than public identities, are meaningful to a smaller amount of entities, or are meaningful only for a quite short period of time. Thus if A has some information about a private identifier "ID" and A discloses this information to B, then it is quite probable that B may not associate this information with any identifier that he currently knows. 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 identify entities at least for a small period of time or by a small group of entities. 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 Owner is to hide the identity of the Location Recipient to the Location Server. Nevertheless, the Location Server has to be sure that the Owner 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 Owner. Cuellar, Ersue Expires September 2002 9 Geopriv Requirements March 2002 This may be done for instance as follows: consider a Location Recipient that obtains a set of "traveller's cheques" from an owner of the privacy rights of a target. The cheques will be used to "buy" location information from a Location Service. Initially, the Location Recipient signs for a first time the cheques with any "signature" that he wants to use. The owner, through his own signature, authorizes the signature of the Location Recipient. 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 owner. This countersignature does not only authenticate the Location Recipient to the verifier, but also indirectly to the owner, when the cheque is later presented to him. Incidentally, the owner may achieve full information about who has accessed to his location information. To hide the real identity of the owner to the Location Server, the following dual solution can be used. An owner buys (say, using e- cash) a service from a Location Recipient (e.g. a navigation service). During this transaction, the Location Recipient and the owner 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 Recipient. 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 Recipient from the Location Server, o the identity of the target from the Location Recipient. 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. Location information formats Req. 1. The protocol MAY define at least one location data type (both syntax and semantics) that must be supported by all geopriv entities. Req. 2. When transmitting location information, (LI and LIF in Figure 1), the sender and the receiver MUST agree on the data type of the location information. The protocol MAY specify that the data type information is part of the same message as the location information object or that sender Cuellar, Ersue Expires September 2002 10 Geopriv Requirements March 2002 and receiver have agreed on it before the actual data transfer. 4.2. Policies Req. 3. The protocol MAY specify the format of signed policies and identifiers that may be passed to the location server by other means besides the data flow Pol. For instance, such signed policies may be stored in a public (open) repository. This repository could also be used for location information requests from the clients. In that case, the protocol MAY specify the format of signed requests. The protocol MAY specify the data flow SPol, used to access the Public repository. In that case it MAY also specify the access control rules to the repository. Req. 4. The 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 L of a target together with a given identifier I of the target. 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.3. Identity Protection Req. 5. When a location server accepts a policy that uses a role identifier, the owner MUST prove the ownership of the claimed role identifier. Req. 6. The protocol MUST be able to hide the real identity of the owner or target to the Ultimate Location Recipient. This may be easily done using short-lived or role identifiers. Cuellar, Ersue Expires September 2002 11 Geopriv Requirements March 2002 Req. 7. The protocol MUST be able to hide the real identity of the Location Recipient to the Location Server. Req. 8. The protocol MUST be able to hide the real identity of the owner to a Location Recipient, including a Location Server. 4.4. Authentication Requirements Req. 9. The protocol MUST allow different authentication schemes Req. 10. The protocol MUST allow authorization without explicit authentication. 4.5. Actions to be secured Req. 11. The following message flows should be secured (mutual end-point authentication, data object integrity, data object confidentiality, replay protection): LI, Pol, LIF, LRequest, and PolInfo. In full details an with all its consequences, this requirement is not trivial to achieve: the communicating parties MUST have security relationships between them, allowing them to dynamically construct secure channels between them. This may imply that some scenarios should not be permitted in general. Req. 12. When a Location Server accepts a policy from an owner, the target MUST prove the ownership of the claimed group or role identifier that should be passed to the Location Recipient. Req. 13. The "generic" policies (as opposed to the policies created by the owner of the privacy) used by the Location Data Source, by the Ultimate Location Data Recipients and by the Location Server of Scenario 3 of [2] MUST be made explicit. 4.6. Transport Requirements There are many possible requirements that one could foresee. For instance, as in [3]: The protocol SHALL support UDP transport with retry timers for reliability. The protocol SHOULD support TCP as an optional transport and it MAY support RTP and/or SCTP as optional transports. Another possibility would be that: Req. 14. The protocol is transport "agnostic", that is, the protocol MUST allow use of different transports. 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 by this protocol is secured in a way compliant Cuellar, Ersue Expires September 2002 12 Geopriv Requirements March 2002 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 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Cuellar, Ersue, and Takahashi.: Geopriv Scenarios, draft- cuellar-geopriv-scenarios-00.txt, work in progress. [3] Rosen, et. al.: Geolocation/Privacy Object Requirements, draft- rosen-geopriv-requirements-00.txt, work in progress. 7. Author's Addresses Jorge R Cuellar Siemens AG Corporate Technology CT IC 3 81730 Munich Email: Jorge.Cuellar@mchp.siemens.de Germany Mehmet Ersue Siemens AG Information and Communication Mobile ICM N PG SP ST SA 1 81359 Munich Email: Mehmet.Ersue@icn.siemens.de Germany 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. Cuellar, Ersue Expires September 2002 13 Geopriv Requirements March 2002 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, Ersue Expires September 2002 14