J. Cuellar Internet Draft M. Ersue Document: draft-cuellar-geopriv-scenarios-00.txt Siemens AG Expires: 2002 Kenji Takahashi NTT Feb 2002 Geopriv Scenarios 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 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 some scenarios for such a protocol, as a basis to discuss and analyze the security (authentication, authorization, integrity and confidentiality) and privacy issues and requirements associated with the services. Cuellar, Ersue, Takahashi Expires Aug 2002 1 Geopriv Scenarios Feb 2002 Table of Contents 1. Overview.......................................................2 2. Conventions used in this document..............................3 3. Entities and Data Flows........................................3 3.1. Entities...............................................3 3.2. Data Flows.............................................5 3.3. Further explanations...................................6 4. Services.......................................................8 4.1. "Here I am!" Services..................................8 4.2. "Where am I?" Services.................................8 4.3. "Where is he?" Services................................9 5. Scenarios......................................................9 5.1. Scenario 1: The handset-based solution.................9 5.2. Scenario 2: A Network-Based Location Data Source......10 5.3. Scenario 3: External Location Server..................11 5.4. Scenario 4: External Location Server and Recipients...12 5.5. Scenario 5: External Location Data Source and Server..12 6. Security Considerations.......................................14 7. References....................................................14 8. Author's Addresses............................................14 9. Full Copyright Statement......................................14 1. Overview This draft introduces scenarios between the following 5 functional elements (or "entiites" of the protocol): Target: The entity whose location is desired by the Location Recipient. Owner of the privacy rights of the target, or, for abbreviation, the owner: 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. Location Data Source: The original source of the sighting. Those entities and the data flows between them are introduced in Section 3. Section 4 presents well-known commercial services. In Japan, all major mobile carriers provide the following types of services: Cuellar, Ersue, Takahashi Expires Aug 2002 2 Geopriv Scenarios Feb 2002 1. "Where am I?" service (Carriers tell subscribers where they are located on a map.) 2. "Here I am!" (Subscribers may send their location information to other subscribers or to Internet users via e-mail or other means.) 3. "Where is he/she?" (Carriers tell users where someone is located.) Section 5 discusses some possible scenarios. 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]. 3. Entities and Data Flows In this section we first explain the functional entities that participate in a location service system and present the basic communication between them. Note that there is no widely accepted terminology and hence some of the terms are perhaps still quite ad- hoc. The authors acknowledge the terminology discussions in the geopriv mailing list. 3.1. Entities Target: The entity whose location is desired by the Location Recipient. The target may be a device (say, a cellular phone), a person (say, the subscriber of the cellular phone), an animal, a ship or truck, equipment in the field, etc. Owner of the privacy rights of the target, or, for abbreviation, the owner: An entity that has the authorization to decide the policies that apply to the location information of the target. When the target is a natural person, the owner of the target is often the target itself. After the initial registration of a target with the system, the owner is in possession of credentials showing that he is authorized to make the policies for the target. How this happens (that the owner proves that he owns the privacy rights and how he obtains the credentials) is outside of the scope of this discussion. We simply assume that the owner knows the correct secrets needed to authenticate the policies of the targets. The exact nature of the secrets and the mechanics of the authentication is perhaps also outside the scope of the WG. Other proposed names are "policy maker" and "rule maker" Cuellar, Ersue, Takahashi Expires Aug 2002 3 Geopriv Scenarios Feb 2002 Location Recipient: Entity that obtains the location of targets. To obtain location information for one or more targets, it interacts with a Location Server or with the Location Data Source. Depending on whether he forwards the information further or not, we distinguish two types of Location Recipients: Location Servers and Ultimate Location Recipients. Location Server: Software and/or hardware entity offering Location Service capabilities based on user-defined privacy policies. Another proposed name is "Intermediate Location Receiver". 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). Other proposed names for the Ultimate Location Recipient are: Location Requestor, Ultimate Location Requestor, Location Seeker, or Location Service Client. The name client is unfortunate, since the Ultimate Location Recipient may be a location-aware value- added service provider (to the owner or the target). Location Data Source: The original source of the sighting, that is, the matching of an identifier for the target, a position, and a time. In some scenarios, o the target itself is the location data source (or better, they are co-located). o In some situations the "owner" (see below) may be the original data source, for instance simply because he knows where his equipment is. o It is also possible that the Location Data Source is fully aware of the owner's policies. In this case the owner is able to authorize the Location Data Source to provide the position to a recipient. Then, the recipient can easily link the origin of the location data and the origin of the policies, thus convincing himself of the authenticity of the location data. In those cases we will say that the Location Data Source is a Location Server. (But there are other types of Location Servers.) In general, the Location Data Source is some network entity, properly authenticated and authorized by the network, but perhaps totally unknown to the target and in particular unaware of the full details of the policies of the owner, or not fully trusted by him. Cuellar, Ersue, Takahashi Expires Aug 2002 4 Geopriv Scenarios Feb 2002 The location data source, or the person who legally owns it, may have the "copyrights" of the sighting, but in general not the ownership of the privacy rights of the target. The user (that is, the owner) should have full control on his policies used by Location Servers. To quote the International Working Group on Data Protection in Telecommunications [EU-IWGDP]: "The user must be able to access, correct and delete his or her preference data also in cases where the preferences of the user are not stored on the mobile device, but within the network." Location Recipients may submit location requests asking for the location of a particular target, for the members of a group, or for targets with given attributes. 3.2. Data Flows The so called "pull-model" is as follows: the Location Server 1. receives Location Information from the Location Data Source or from other Location Servers, 2. receives, directly or through a repository or a trusted third party, the policies associated with the targets, 3. accepts services requests from Location Recipients (including other location servers), 4. matches the location request to the policies for the target and processes the Location Information accordingly, and 5. returns Filtered Location Information of the target. Of course, other models are possible, but in principle, they contain the same information flows between the entities. The single data flows are: LI (Location Information), FLI (Filtered Location Information), Pol (Policy), PolInfo (Policy Information) and LRequest (Location Information Request). They will now be discussed: 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 full information is being delivered, but only a less precise version of the information. Cuellar, Ersue, Takahashi Expires Aug 2002 5 Geopriv Scenarios Feb 2002 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. 3.3. Further explanations (Note: Parts of the contents of this subsection may be out of the scope of the work of the working group. But it is necessary to introduce some notation and concepts to later say: "*Precisely that* is outside of our scope".) The term "device" denotes the piece of physical electronic equipment (if any) that is presumed to be carried by or affixed to the target. There may be a few times we want to differentiate the target from the device. At this point of the discussion in the geopriv WG it is unclear to which extent the contents of the data flows LI, FLI, Pol, PolInfo, and LRequest will be in the scope of the WG, but at least a naive conceptual explanation of what could be meant is helpful for the understanding. Location Services deal with at least these two types of information: identities (for authentication, authorization, and, for the purposes of privacy, anonymity) and location (not any type of private information, like private medical information). Disregarding completely the formats or data types that are or will be used, the private data sent in LI may be seen as a pair: (user identifier, location information) (For shortness and simplicity, we assume no time-stamp as a third coordinate in this sighting, implicitly meaning "at the current time" Cuellar, Ersue, Takahashi Expires Aug 2002 6 Geopriv Scenarios Feb 2002 or "at a very recent time". Notice that this is in many cases enough, since anyway time-stamps are not exact and clocks are not usually synchronized. The question, where the target was during the last couple of hours is generally not addressed by location services.) But, instead of providing the full information ("user ABC is at coordinates xyz"), the location server matches the request of the Location Recipient and the policies for the target and changes perhaps both, the identifier and the location information. He just says: "a customer of yours is at the entrance of the Palace Hotel" to a taxi, or "Gottfried Frege is AtHome" to a friend of Gottfried, "pseudonym2947a is at 25 Main Street" to a nearby restaurant, or "truck27 is at HangarB371" to a manager in an airport. The location server has to know which Location Recipients have permission to access the Location Information, in which accuracy, etc. In other words, what the location server will forward to the Location Recipient is a new version of the pair: (user identifier-1, information-content-1) where information-content-1 is the "translation" of the location information to the proper format and accuracy, and user identifier-1 is another identifier of the target. How exactly policies are written or what is their expressive power, is left out of the scope of this discussion. But for better understanding of what could be intended, an example of a policy is adequate: o "My family is allowed to know my street address; o within 8am-5pm during working days my boss is allowed to know the city and . if I am inside a campus of my corporation, then also the campus, building, and room number; o any member of my corporation is allowed to know the time zone I am." This policy contains 4 permission rules. There is another interface or set of interfaces between Location Recipient, target (or owner), and location service that is outside of the scope of this paper (and probably of the WG) but for better understanding needs to be considered in our picture. This set of interfaces will be denoted collectively by "Service": Service: A set of interfaces and data flows used to set-up and provide value-added location-aware services, where Cuellar, Ersue, Takahashi Expires Aug 2002 7 Geopriv Scenarios Feb 2002 o the Location Recipient subscribes himself to the services of the Location Server. o the Location Recipient and the owner agree on identities (say relation-pseudonyms, purpose-built-identities, local names, or real identities) to be used later as well as on credentials or cryptographic material to prove the ownership of the negotiated identities. This will be discussed later. o The value-added service may be provided by sending an encrypted e-mail or other type of e-message to the target or owner, or the owner one activates a web page of the Ultimate Location Recipient using TLS. Knowing now the location of the target, the web-server provides a location-based information service. 4. Services A more systematic treatment of scenarios will be given in forthcoming versions of this draft. 4.1. "Here I am!" Services After locating himself, the target (=owner) may send his location to the Ultimate Location Recipient. In this service, the target (=owner) may take the initiative to send the location, rather than responding to requests. This corresponsd basically to scenarios 1 and 2. 4.2. "Where am I?" Services Those are services where the Location Recipient wants to know where he is, but he does not have any Location Data resources needed with her. In one particular case, the Location Recipient does know the location (say, using a GPS chip), but not in the form that he needs it (say, as a street address). In this case, the owner asks an external Location Server to translate the information to a street address or position on a map. The Location Server obtains the location from the Location Data Source, which is the target itself converts the location information to the requested form and sends it back to the owner. This corresponds to Scenario 3 In a second particular case, the Location Recipient does not know the location at all. The owner (e.g. cellular service subscriber) asks an external Location Server for the location of the target (e.g. the cellular phone he is carrying). The Location Server obtains the location from the Location Data Source, (e.g. cellular carrier) over IP or other network. This corresponds to the particular case of Scenario 5, in which the Ultimate Location Recipient is also the Cuellar, Ersue, Takahashi Expires Aug 2002 8 Geopriv Scenarios Feb 2002 owner. Alternatively, the Location Server may internally obtain the location (in this case, the Location Server and Location Data Source are treated as the same entity). 4.3. "Where is he?" Services Location Recipient wants to know where a given target is. This corresponds to Scenarios 4 and 5. 5. Scenarios In the scenarios we only consider location recipients that require an explicit authorization from the owner to obtain the location information. This authorization is given in the form of user-defined policies. Other Location Recipients, for instance, the ones defined by regulatory requirements, (including the receivers of emergency calls, emergency alert, lawful interception) will probably have a different authorization status than the recipients considered in the following scenarios. We consider now the following 5 scenarios: 1 2 3 4 5 +----------+----------+----------+----------+----------+ | Loc | Loc | Loc | Loc | Loc | | Server | Server | Server | Server | Server | | = | = +----------+----------+----------+ | Owner | Owner | Owner | Owner | Owner | | = | = | = | = | = | | Target | Target | Target | Target | Target | | = + ---------+ = | = +----------+ | Loc | Loc | Loc | Loc | Loc | | Data | Data | Data | Data | Data | | Source | Source | Source | Source | Source | +----------+----------+ = +----------+----------+ | Ultimate | Ultimate | Ultimate | Ultimate | Ultimate | | Loc | Loc | Loc | Loc | Loc | | Recipient| Recipient| Recipient| Recipient| Recipient| +----------+----------+----------+----------+----------+ In this table, each column corresponds to one scenario. Two Functional Elements are in the same box if they are equal (or in the same physical entity). For instance in Scenario 1 there are 2 physical entities, (the Ultimate Location Recipient is one; all other functional entities collapse to another) and in Scenario 5 there are 4 different physical entities, (only the owner and the target are the same). A more systematic treatment of scenarios will be given in forthcoming versions of this draft. 5.1. Scenario 1: The handset-based solution Cuellar, Ersue, Takahashi Expires Aug 2002 9 Geopriv Scenarios Feb 2002 The first case we want to consider is a mobile node (laptop or handheld) that at the same time is the target, owner, Location Server, and Location Data Source. The mobile node discovers its own position using a GPS mechanism, a manual input from the user or a co- located sensor that recognizes the relative position of some active badges or other reference points. An application running in the mobile node delivers its location to some Ultimate Location Recipients. An Ultimate Location Recipient that wants to know the position of the mobile node sends a Location Requests to the application running on the mobile node. After authenticating the Location Recipient, the application checks which policy rule matches, translates the location information to the appropriate form and sends back this Filtered Location Information to the Ultimate Location Recipient. Notice that in this case the policies are only for internal use of the mobile node and as such do not have to be standardized. Only the interface to the Ultimate Location Recipients has to be standardized. The Location Recipient himself has to obey some perhaps implicit policies, to be discussed in the requirements draft. 5.2. Scenario 2: A Network-Based Location Data Source This scenario is very similar to the first one, but instead of the mobile node discovering his position by himself, it uses an underlying location system based on a co-located active badge, a Layer 2 interface, a service provided by his access network or a similar infrastructure. +----------+ | Location | | Data | | Source | +----------+ | | LI V +----------+ | Location | | Server | LReq +-----------+ | = |<-----------------| Ultimate | | Target | | Location | | = |----------------->| Recipient | | Owner | FLI +-----------+ +----------+ Figure 1. Scenario 2 Cuellar, Ersue, Takahashi Expires Aug 2002 10 Geopriv Scenarios Feb 2002 Notice that in this scenario no Location Recipient exists, besides the owner and the Ultimate Location Recipients served by the owner. Thus, the user (owner) is in full control of its private information. But it may be unclear how the user makes sure that the Location Data Source does not provide location information to other location recipients. Either the Location Data Source is aware of the full policies of the owner, (that is it is a Location Server), or of the mobile node subscription profile (or something of that sort). A precise requirement should be formulated to guarantee this privacy protection. Nevertheless, there is already some concern about the location information leaking to entities not authorized. To quote the International Working Group on Data Protection in Telecommunications [EU-IWGDP]: "The user must remain in full control on whether precise location information is generated in the network. In this respect, handset- based solutions where the creation of precise location information is initiated by the mobile device seem to offer a better degree of privacy than network-based solutions where location information is generated as a standard feature and choice of the user over this information is limited to the question whether it will be communicated to third parties." Another concern is that, depending on the sensing infrastructure and its trusts relationships to the user, authenticating the supplied location information is difficult for the following reasons: o some sensor systems only detect active badges that can be removed from the mobile object they represent. o sensor systems are not equipped with proper keys or key distribution software. 5.3. Scenario 3: External Location Server Another variant is when the target does not have enough resources to compute the translation of the location information to the data type that he requires. For instance, the target knows his exact coordinates and wants to retrieve the street address. To do this, the target sends first his (raw) location information to a location service that will perform the translation and than asks for the location information in the required format. Thus here the target is the client of the location service, that is, he is the Location Recipient. Let us further assume that o there are no other Location Recipients to the location service besides the target, and Cuellar, Ersue, Takahashi Expires Aug 2002 11 Geopriv Scenarios Feb 2002 o the target is also the owner of the privacy rights. In this case, no explicit policies are needed for the location service, but he has to obey some standard user-independent policies (to be discussed in the requirements draft). 5.4. Scenario 4: External Location Server and Recipients +----------+ | Location | | Data | LI +-----------+ | Source |-------------->| | | = | Pol | Location | | Target |-------------->| Server | | = | +-----------+ | Owner | ^ | +----------+ Req | | FLI ^ | V \ +-----------+ \ | Ultimate | --------------->| Location | Service | Recipient | +-----------+ Figure 2. Scenario 4 The next scenario we consider introduces policies to the external location server. This corresponds to scenario 3 when there are other Location Recipients besides the target or owner. Examples for this and the next scenarios are given by Location-Based Information services that allow subscribers to access filtered and tailored information based on the location of the requesting user. Those services include navigation, city sightseeing, location dependent content broadcast, and mobile yellow pages. There is a special case of Scenario 4 that could be considered separately: this is when the Location Recipient is also the owner. This situation is found in particular in some tracking services that include Fleet and Asset Management Services allowing the tracking of location and status of vehicles (cars, trucks, etc.), animal, assets, or people, for example when supervisor of a delivery service who needs to know the location and status of employees, parents who need to know where their children are. There are some examples of tracing services that do not fall in the special case, for instance stolen vehicle location. 5.5. Scenario 5: External Location Data Source and Server Cuellar, Ersue, Takahashi Expires Aug 2002 12 Geopriv Scenarios Feb 2002 +----------+ | Location | | Data | | Source | +----------+ | LI V +----------+ +-----------+ | Target | Pol | | | = |------------->| Location | | Owner | | Server | +----------+ +-----------+ ^ ^ | \ Req | | FLI \ | V \ +-----------+ \ | Ultimate | --------------->| Location | Service | Recipient | +-----------+ Figure 3. Scenario 5 This scenario is a simple combination of previous ones, but it brings some new complications. The target itself is not able to calculate its position and requires an external location data source. But this location data source passes the information to an external location server, instead of the target itself. Even if the target was able to perform the necessary translations, this scenario will be common to support the operation of the access network: for instance Location Based Charging, which allows a subscriber to be charged different rates depending on the subscriber's location, or monitoring of QoS parameters correlated to location for monitoring of Service Level Agreements (SLAs) and for quality assurance, utilization review, credentialing, and other activities that are part of ensuring appropriate treatment and payment. In general, there are some issues with this scenario. The user may be roaming outside of his home network, and the location server in the visited network may be untrusted, or the regulations in the given country are not so stringent as in his. Or perhaps the visited domain does not support the privacy-protecting protocol he needs. That is, perhaps there is no location server or the location server of the visited domain is perhaps not able even to parse the policies of the user correctly. Another reason may be that the owner does not want to download his policy files at this location because they already contain some private information about the partners that he communicates with, to which groups he belongs to, or the location server may observe the IP addresses of the Location Recipients that ask for my location information and deduce from that sensitive information. The user wants to stipulate very simple instructions for Cuellar, Ersue, Takahashi Expires Aug 2002 13 Geopriv Scenarios Feb 2002 the location data source of the visited domain, namely "send the location information to my trusted or my home location server!" 6. 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. 7. References [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [EU-IWGDP] International Working Group on Data Protection in Telecommunications: Common Position on Privacy and location information in mobile communications services. Adopted at the 29th meeting of the Working Group on 15/16 Februar 2001 in Bangalore. http://www.datenschutz-berlin.de/doc/int/iwgdpt/locat_en.htm 8. Author's Addresses Jorge R Cuellar Siemens AG Otto-Hahn Ring 6 81730 Munich Email: jorge.cuellar@mchp.siemens.de Germany Mehmet Ersue Siemens AG Hofmannstr. 51 81359 Munich Email: Mehmet.Ersue@icn.siemens.de Germany Kenji Takahashi Information Sharing Platform Laboratories NTT 3-9-11 Midoricho Musashino, Tokyo 180-8585 E-mail: takahashi.kenji@lab.ntt.co.jp Japan 9. 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 Cuellar, Ersue, Takahashi Expires Aug 2002 14 Geopriv Scenarios Feb 2002 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, Ersue, Takahashi Expires Aug 2002 15