J. Cuellar Internet Draft M. Ersue Document: draft-cuellar-geopriv-reqs-00.txt Siemens AG Expires: 2002 November 2001 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). A protocol will be designed to securely transfer the location information to a location server and to authorize the location server to release securely the information to a client. This document describes the requirements for such a geopriv protocol, focusing on authorization, integrity and privacy. The main principle is that the owner of the target may specify which location information may be released to whom under which further conditions. Cuellar, Ersue Expires May 2002 1 Geopriv Requirements November 2001 Table of Contents 1. Overview.......................................................2 2. Conventions used in this document..............................3 3. Requirements...................................................3 3.1. Entities and Data Flows...................................3 3.2. Location..................................................6 3.2.1. Location information formats.........................8 3.3. Identity of Users, Clients................................8 3.3.1. Public Identities....................................8 3.3.2. Private Identifiers..................................8 3.3.3. Credentials for Authentication and Authorization.....9 3.4. Policies.................................................11 3.5. Actions to be secured....................................11 3.5.1. Authentication Requirements.........................11 3.6. Transport Requirements...................................11 4. Security Considerations.......................................12 5. References....................................................12 6. Author's Addresses............................................12 7. Full Copyright Statement......................................12 1. Overview Some applications (called in the sequel "location service clients", or simply "clients") need geographic location information about an entity (user, mobile node, resource, etc. in the sequel called "target"). Location information may be regarded, independently of any concrete syntax, as a tuple of information: (latitude, longitude, altitude [, current time, velocity, next position, next time, ...]) where optional parameters (perhaps user-defined) are included in square brackets. Location information is first sent from the target to the location server. Then the location server filters the information and sends filtered location information to the clients, in agreement with the explicit consent of the target. The main principle behind the protocol to be defined is that the "owner" of the target information specifies which location information may be released to whom under which conditions. Such an assertion is called a "location information policy" or simply a "policy". For instance a target may give location information to the location server as a triplet (latitude, longitude, altitude) and present an identifier of the target (a NAI, an IP-Address, a pseudonym, etc., with proper credentials) together with a policy, which describes Cuellar, Ersue Expires May 2002 2 Geopriv Requirements November 2001 which abstraction of the location information may be given to which clients under which conditions. In our example, the user of the mobile node may declare that the members of a certain group may know on which time zone he currently is. 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 [RFC-2119]. Note that the requirements specified in this document are to be used to discuss possible geopriv protocols. As such, the requirements language frequently refers to 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. 3. Requirements 3.1. Entities and Data Flows There are apparently two ways to securely transfer the location information from a target to a client. One is using a "location server" as an intermediate node, and the other is a direct transfer between target and client. We will argue that the second case is a special case of the first one. A "location server" receives location information from a target and policies from the owner of the target. On the other hand, the location server receives client requests for specific targets or for classes of targets. The location server implements security and policy enforcing functionality. He uses a private repository to securely store this information (location information, policies, requests). The "direct" solution may be seen as a special case of the "location server solution" when the location server (or agent) is located in the same equipment as the target. In that case, the target equipment (target plus location server) itself is sending the location information directly to the client. For this particular case, the interface between target and service location server MAY be a private interface and MAY comply with the geopriv protocol or not. Further, a public (open) repository may be used for signed policies, identifiers, and perhaps also requests. Target: The entity whose location is desired by the client. Initially, the location is known by the target itself or by an owner of the target. The protocol does not specify how the target or the owner learns the location information. On the other hand, the protocol specifies how the location information is sent from Cuellar, Ersue Expires May 2002 3 Geopriv Requirements November 2001 the target or owner to the client, via an intermediate trusted node, the server. Location Server: software and/or hardware entity offering Location Service capabilities. On one side, the Location Server receives and processes Location Information, policies, and identifiers from targets. On the other side, it accepts services requests from clients, and responds sending back Filtered Location Information of the targets. The Location Service server may consist of one or more Location Service components, and may be distributed. Client: software and/or hardware entity that interacts with a Location Server for the purpose of obtaining location information for one or more Mobile Nodes. One client may be distributed. Owner of the target: An entity that has the authorization to decide the policies that apply to the location information of the target (for instance, equipment in the field). Most frequently, the owner of the target is the target itself. One target may have several owners and one owner may have several targets. The owner is in possession of credentials showing that he is owner of the identifier of the target. Open repository: A repository where signed policies, identifiers, and perhaps also requests are stored. Several policy servers may use the same repository or the repository may be distributed or replicated. 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 specified by the protocol are: LI (Location Information): The target (or an owner of the target) sends location information to the location server. Also some network entity, properly authenticated and authorized by the network, may send the Location Information to the Location Server. This could be some location detection function in the access network. The authentication /authorization requirements for this case are for further discussion. This case is different from the owner of the target, since there is no close relationship between this network entity and this particular target. FLI (Filtered Location Information): The location server sends filtered location information to the client. Cuellar, Ersue Expires May 2002 4 Geopriv Requirements November 2001 Pol (Policy): An owner of the target (or in particular, the target itself) sends a Policy to the location server PolI (Policy Information): the server informs the client which data type(s) are available for filtered location information for a given target. This mechanism MUST be able to be invoked by the client before he sends a LRequest. LRequest (Location Information Request): the client requests location information from a given set of targets. In this request the client MUST be able to select which location information data type it prefers. The client MUST also be able to specify the need for periodic position updates. +---------+ SPol +-----------+ LD | Target |***********>| Open | ******>| | | Policy | | Owner |----+ | Repository| +---------+ | +-----------+ ^ | | * LD * LI| | * SPol * | | V +---------+ | | Pol +---------+-----------+ LD | | | +------>| Location| Private | ******>| Target | V | Server | | | |-------------->| (Agent) | Repository| +---------+ LI +---------+-----------+ ^ ^ | | * LRequest| |FLI |PolI * | V V * +---------+ * | | ********************>| Client | Service | | +---------+ Figure 1: The Entities and Data Flows Normal arrows ("--->") MUST be part of the protocol, starred arrows ("***>") are probably out of scope of the protocol, as described in the text. The following data flow could be specified by the protocol: 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. The following data flows are part of the general context, but probably will be left out of scope of the geopriv protocol: Cuellar, Ersue Expires May 2002 5 Geopriv Requirements November 2001 LD (Location Data): the target or/and the owner of the target obtain the location data for the target. 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. Req. 1. The protocol MUST support the model of Figure 1. In particular, the protocol MUST specify the following data flows: LI, FLI, Pol, LRequest, and PolI. Req. 2. The protocol MAY specify the data flow SPol. Req. 3. The protocol SHOULD NOT specify the data flow LD, Service. Req. 4. The protocol MAY specify the data flow used for Server Discovery Req. 5. 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 open repository. In that case if SHOULD also specify the access control to the repository, in order to avoid denial of service attacks by erasing information of the repository. 3.2. Location Location has usually two or three space coordinates -- say, (latitude, longitude, altitude) or just (latitude, longitude). The units to measure location may be fixed-point arithmetic, or discrete (street address or time zone). It may be only 1-dimensional (distance to a fixed reference point, time zone) or it may contain besides the space coordinate(s) other different kinds of information, including for instance time information or velocity. Thus location information determines a point or a set of points in an n-dimensional space, n = 1, 2, 3 or more. Location Information has a limited range of values for the same reason it has limited precision -- because digital systems represent numbers with a finite number of bits. But also the customer policies may insist that the location information is presented to the client Cuellar, Ersue Expires May 2002 6 Geopriv Requirements November 2001 with a low accuracy. In general, a location value is not interpreted as a single point in space (not even as the best approximation in a discrete grid of points) but as a region in space. The space regions determined by different location values may overlap. Notice that accuracy is not a component of the location. (In particular, notice that accuracy alone gives no information at all where or how an object is). Accuracy is not a location information, but rather a modifier of location information (telling that a point representation should be interpreted as a region in space). Location may be represented in many different ways, that is, using different "location data types". The definition of a location data type includes both syntax (format) and semantics (intended meaning), but we will leave any syntactic details to the protocol document. Basic types of location data types are: geodesic datum (i.e. WGS84 in a concrete representation) latitude, longitude, altitude country, state, province, city, street, street number, building, floor, room time zone Abstracting away from the concrete syntax, the information itself will be called "location information". 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 time information, 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. This type of conversion will be called an "abstraction". During an abstraction, information can be lost, but not gained. Thus an abstraction is a filtering of information. For instance there are abstraction 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 abstraction 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 Cuellar, Ersue Expires May 2002 7 Geopriv Requirements November 2001 function. Obfuscation (intentionally make the location values less accurate by adding randomness) together with lower accuracy, is exactly an example of this. 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. (For further discussion). 3.2.1. Location information formats Req. 6. The protocol MUST define at least one location data type (both syntax and semantics) that MUST be supported by all geopriv entities. Req. 7. At least one data type MUST use WGS84 geodetic datum as reference system. Req. 8. 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 and receiver have agreed on it before the actual data transfer. 3.3. Identity of Users, Clients 3.3.1. Public Identities If A has some information about a public 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.3.2. Private Identifiers 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 Cuellar, Ersue Expires May 2002 8 Geopriv Requirements November 2001 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. One-time identifier an identifier that is used only for a "session". Two occurrences of the same one-time-identifier on different sessions may not correspond to the same user, and may not imply a relation between the two occurrences) Pseudonym an identifier chosen by an entity with the intention of using it on several sessions. If the identity and the corresponding credentials are well chosen, two occurrences of the same pseudonym correspond to the same user, or, if not, imply a relation between the two users. The two preceding identifiers may be used as identities, at least for a small period of time or by a small group of entities. The next type of identifier may not be used as an identity, since it applies to many different entities: Role identifier ("administrator", "member_of_club_A", etc.) The meaning of the role may be context dependent. Depending on its privacy policy, an entity may still regard the disclosure of one of his private identifiers (in connection with some activity of him, his location or other attribute) to be a violation of his privacy right. 3.3.3. Credentials for Authentication and Authorization 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 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 as in the following definition: Explicit Authentication The act of verifying a claimed identity, in the form of a pre- existing label from a mutually known name space, as the sole originator of a message (message authentication) or as the end- point of a channel (entity authentication). Nevertheless, the communication partner wants to make sure that he is communicating to the same entity during the whole session. Thus Cuellar, Ersue Expires May 2002 9 Geopriv Requirements November 2001 message authentication codes are used, based on "unauthenticated keys". To avoid confusion let us introduce the following definition: Purpose-built Authentication The act of verifying that a communication partner, as sole originator of a message or as the end-point of a channel, is the same as a previous communication partner (of the same or different entity). This is usually implemented in the following way: the claimer or the verifier creates an ephemeral label, a "purpose-built identity" that will be used to correlate the different appearances of the claimer. The point is that this purpose- built identity contains no information for anyone besides the involved parties. 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. 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. 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. In a more complex example, an unauthenticated client hands in a certain amount of money in a bank and obtains in return a set of travelers cheques, that he should sign immediately with any "signature" that he wants to use. When presenting the cheques to obtain a service, the cheques may be countersigned in such a way that the receiver of the cheque is sure that the signer is the same as the one who bought the cheques. This countersignature does not only authenticate the user to the receiver, but also indirectly to the bank, when the cheque is later presented to it. Two cheques with corresponding signatures identify the signing customers as the same. For our purposes the following very similar scenario can be considered: an unauthenticated target buys (say, using e-money) a navigation service from a client. During this transaction, the client and the target agree on one or several pseudonyms and a set of credentials that the target may use later to authenticate himself to the server and thus indirectly also to the client. Cuellar, Ersue Expires May 2002 10 Geopriv Requirements November 2001 3.4. Policies A location privacy policy is an assertion that a certain amount of information (identity or identifier plus location) may be released to a certain entity (or group of entities) under a certain set of conditions. Req. 9. The protocol MUST specify a policy language. This policy language MAY be an existing one, an adaptation of an existing one or a new policy language. Req. 10. The policy language MUST be strong enough to express policies of the form: a group G of clients are allowed to know a certain abstraction A of the location L of a target together with a given identifier I of the target. Req. 11. 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 abstraction function MAY be specified by data type of the expected filtered location information. Req. 12. Within the constraints of the last two requirements, the policy language SHOULD be as simple as possible, or it SHOULD be an existing policy language. Req. 13. When a location server accepts a policy from a target or target owner, the target (or owner) MUST prove the ownership of I, the claimed identifier. 3.5. Actions to be secured Req. 14. The protocol MUST allow that following message flows be secured (unilateral or mutual end-point authentication, data object integrity, data object confidentiality, replay protection): LI, Pol, LIF, LRequest, and PolI. This SHOULD be achieved with IPSec but it MAY be achieved with methods defined by the protocol itself. 3.5.1. Authentication Requirements Req. 15. The protocol MUST allow different authentication schemes Req. 16. The protocol MUST allow authorization without explicit authentication. 3.6. Transport Requirements There are many possible requirements that one could foresee. For instance, as in [Rosen]: The protocol SHALL support UDP transport Cuellar, Ersue Expires May 2002 11 Geopriv Requirements November 2001 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 the protocol is transport "agnostic", that is, the protocol MUST allow use of different transports. tbd 4. 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 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. 5. References [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [Rosen] Rosen, et. al.: Geolocation/Privacy Object Requirements, draft-rosen-geopriv-requirements-00.txt, work in progress 6. Author's Addresses Jorge R Cuellar Siemens AG Otto-Hahn Ring 6 81730 Munich Germany Email: jorge.cuellar@mchp.siemens.de Mehmet Ersue Siemens AG Hofmannstr. 51 81359 Munich Germany Email: Mehmet.Ersue@icn.siemens.de 7. 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 Cuellar, Ersue Expires May 2002 12 Geopriv Requirements November 2001 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, Ersue Expires May 2002 13