Internet Engineering Task Force (IETF) R. Barnes Request for Comments: 6280 M. Lepinski BCP: 160 BBN Technologies Updates: 3693, 3694 A. Cooper Category: Best Current Practice J. Morris ISSN: 2070-1721 Center for Democracy & Technology H. Tschofenig Nokia Siemens Networks H. Schulzrinne Columbia University July 2011 An Architecture for Location and Location Privacy in Internet Applications
AbstractLocation-based services (such as navigation applications, emergency services, and management of equipment in the field) need geographic location information about Internet hosts, their users, and other related entities. These applications need to securely gather and transfer location information for location services, and at the same time protect the privacy of the individuals involved. This document describes an architecture for privacy-preserving location-based services in the Internet, focusing on authorization, security, and privacy requirements for the data formats and protocols used by these services. Status of This Memo This memo documents an Internet Best Current Practice. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6280.
Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
1. Introduction ....................................................3 1.1. Binding Rules to Data ......................................4 1.2. Location-Specific Privacy Risks ............................5 1.3. Privacy Paradigms ..........................................6 2. Terminology Conventions .........................................7 3. Overview of the Architecture ....................................7 3.1. Basic Geopriv Scenario .....................................8 3.2. Roles and Data Formats ....................................10 4. The Location Life Cycle ........................................12 4.1. Positioning ...............................................13 4.1.1. Determination Mechanisms and Protocols .............14 4.1.2. Privacy Considerations for Positioning .............16 4.1.3. Security Considerations for Positioning ............16 4.2. Location Distribution .....................................17 4.2.1. Privacy Rules ......................................17 4.2.2. Location Configuration .............................19 4.2.3. Location References ................................20 4.2.4. Privacy Considerations for Distribution ............21 4.2.5. Security Considerations for Distribution ...........23 4.3. Location Use ..............................................24 4.3.1. Privacy Considerations for Use .....................25 4.3.2. Security Considerations for Use ....................25 5. Security Considerations ........................................25 6. Example Scenarios ..............................................28 6.1. Minimal Scenario ..........................................28 6.2. Location-Based Web Services ...............................29 6.3. Emergency Calling .........................................31 6.4. Combination of Services ...................................32 7. Glossary .......................................................35 8. Acknowledgements ...............................................38 9. References .....................................................38 9.1. Normative References ......................................38 9.2. Informative References ....................................38
information is transmitted and accessed in a secure and privacy- protective way is essential to the future success of these services, as well as the minimization of the privacy harms that could flow from their wide deployment and use. Standards for communicating location information over the Internet have an important role to play in providing a technical basis for privacy and security protection. This document describes a standardized privacy- and security-focused architecture for location- based services in the Internet: the Geopriv architecture. The central component of the Geopriv architecture is the location object, which is used to convey both location information about an individual or device and user-specified privacy rules governing that location information. As location information moves through its life cycle -- positioning, distribution, and use by its ultimate recipient(s) -- Geopriv provides mechanisms to secure the integrity and confidentiality of location objects and to ensure that location information is only transmitted in compliance with the user's privacy rules. The goals of this document are two-fold: First, the architecture described revises and expands on the basic Geopriv Requirements  , in order to clarify how these privacy concerns and the Geopriv architecture apply to use cases that have arisen since the publication of those documents. Second, this document provides a general introduction to Geopriv and Internet location-based services, and is useful as a good first document for readers new to Geopriv.
Binding of usage rules to sensitive information is a common way of protecting information. Several emerging schemes for expressing copyright information provide for rules to be transmitted together with copyrighted works. The Creative Commons  model is the most prominent example, allowing an owner of a work to set four types of rules ("Attribution", "Noncommercial", "No Derivative Works", and "ShareAlike") governing the subsequent use of the work. After the author sets these rules, the rules are conveyed together with the work itself, so that every recipient is aware of the copyright terms. Classification systems for controlling sensitive documents within an organization are another example. In these systems, when a document is created, it is marked with a classification such as "SECRET" or "PROPRIETARY". Each recipient of the document knows from this marking that the document should only be shared with other people who are authorized to access documents with that marking. Classification markings can also convey other sorts of rules, such as a specification for how long the marking is valid (a declassification date). The United States Department of Defense guidelines for classification  provide one example.
Section 5 describes how some security mechanisms can address this to a limited extent.
By binding privacy rules to location information, however, Geopriv provides valuable information about users' privacy preferences, so that non-technical forces such as legal contracts, governmental consumer protection authorities, and marketplace feedback can better enforce those privacy preferences. If a commercial recipient of location information, for example, violates the location rules bound to the information, the recipient can in a growing number of countries be charged with violating consumer or data protection laws. In the absence of a binding of rules with location information, consumer protection authorities would be less able to protect individuals whose location information has been abused. RFC 2119 . Throughout the remainder of this document, capitalized terms defined in Section 7 refer to Geopriv-specific roles and formats; the same terms used in all lowercase refer generically to those terms.
Privacy rules and their distribution are thus the central technical components of the privacy system, since they inform location recipients about how they are authorized to use that information. The two goals in the preceding paragraph are enabled by two classes of rules: 1. Access control rules: Rules that describe which entities may receive location information and in what form 2. Usage rules: Rules that describe what uses of location information are authorized Within this framework for privacy, security mechanisms provide support for the application of privacy rules. For example, authentication mechanisms validate the identities of entities requesting a location (so that authorization and access-control policies can be applied), and confidentiality mechanisms protect location information en route between privacy-preserving entities. Security mechanisms can also provide assurances that are outside the purview of privacy by, for example, assuring location recipients that location information has been faithfully transmitted to them by its creator.
Some of Alice's friends will be interested in using Alice's location only for their own purposes, for example, to meet up with her or plot her location over time. The usage rules that they receive direct them as to what they can or cannot do (for example, Alice might not want them keeping her location for more than, say, two weeks). Consider one friend, Bob, who wants to send Alice's location to some of his friends. To operate in a privacy-protective way, Bob needs not only usage rules for himself, but also access control rules that describe who he can send information to and rules to give to the recipients. If the rules he received from the presence server authorize him to give Alice's location to others, he may do so; otherwise, he will require additional rules from Alice before he is authorized to distribute her location. If recipients who receive Alice's location from Bob want to distribute the location information further, they must go through the same process as Bob. The whole example is illustrated in the following figure: +----------+ | Wireless | | Location | | Service | Retrieve +----------+ Access Control Rules | +--------------------------------+ | | +--------------------------+ | Location | | Access | | | | | Control Rules v | | | | +-----+ | | | | Bob | | | | |+---+|--> ... | | | +----->||PC || ........... v | | ++---++ | +------+| +----------+ | | |Mobile|+--Location->| Presence |--Location-->| +----------+ | |Phone || | Server | |---->| Friend-1 | | +------++---Rules--->| |---Rules---->| +----------+ | Alice | +----------+ | | O | | | /|\ | | +----------+ | / \ | +---->| Friend-2 | `---------' +----------+ Figure 1: Basic Geopriv Scenario
Figure 1. Device: The physical device, such as a mobile phone, PC, or embedded micro-controller, whose location is tracked as a proxy for the location of a Target. Alice's mobile phone is the Device in Figure 1. Rule Maker (RM): Performs the role of creating rules governing access to location information for a Target. In some cases, the Target performs the Rule Maker role (as is the case with Alice), and in other cases they are separate. For example, a parent may serve as the Rule Maker when the Target is his child, or a corporate security officer may serve as the Rule Maker for devices owned by the corporation but used by employees. The Rule Maker is also not necessarily the owner of the Device. For example, a corporation may provide a Device to an employee but permit the employee to serve as the Rule Maker and set her own privacy rules. Location Generator (LG): Performs the roles of initially determining or gathering the location of the Device and providing it to Location Servers. Location Generators may be any sort of software or hardware used to obtain the Device's location. Examples include Global Positioning System (GPS) chips and cellular networks. A Device may even perform the Location Generator role for itself; Devices capable of unassisted satellite-based positioning and Devices that accept manually entered location information are two examples. The wireless location service plays the Location Generator role in Figure 1. Location Server (LS): Performs the roles of receiving location information and rules, applying the rules to the location information to determine what other entities, if any, can receive location information, and providing the location to Location Recipients. Location Servers receive location information from Location Generators and rules from Rule Makers, and then apply the rules to the location information. Location Servers may not necessarily be "servers" in the colloquial sense of hosts in
remote data centers servicing requests. Rather, a Location Server can be any software or hardware component that distributes location information. Examples include a server in an access network, a presence server, or a Web browser or other software running on a Device. The above example includes three Location Servers: Alice's mobile phone, the presence service, and Bob's PC. Location Recipient (LR): Performs the role of receiving location information. A Location Recipient may ask for a location explicitly (by sending a query to a Location Server), or it may receive a location asynchronously. The presence service, Bob, Friend-1, and Friend-2 are Location Recipients in Figure 1. In general, these roles may or may not be performed by physically separate entities, as demonstrated by the entities in Figure 1, many of which perform multiple roles. It is not uncommon for the same entity to perform both the Location Generator and Location Server roles, or both the Location Recipient and Location Server roles. A single entity may take on multiple roles simply by virtue of its own capabilities and the permissions provided to it. Although in the above example there is only a single Location Generator and a single Rule Maker, in some cases a Location Server may receive Location Objects from multiple Location Generators or Rules from multiple Rule Makers. Likewise, a single Location Generator may publish location information to multiple Location Servers, and a single Location Recipient may receive Location Objects from multiple Location Servers. There is a close relationship between a Target and its Device. The term "Device" is used when discussing protocol interactions, whereas the term "Target" is used when discussing generically the person or object being located and its privacy. While in the example above there is a one-to-one relationship between the Target and the Device, Geopriv can also be used to convey location information about a device that is not directly linked to a single individual or object, such as a Device shared by multiple individuals. Two data formats are necessary within this architecture: Location Object (LO): An object used to convey location information together with Privacy Rules. Geopriv supports both geodetic location data (latitude, longitude, altitude, etc.) and civic location data (street, city, state, etc.). Either or both types of location information may be present in a single LO (see the considerations in  for LOs containing multiple locations). Location Objects typically include some sort of identifier of the Target.
Privacy Rule: A directive that regulates an entity's activities with respect to location information, including the collection, use, disclosure, and retention of the location information. Privacy Rules describe which entities may obtain location information in what form (access control rules) and how location information may be used by an entity (usage rules). The whole example, using Geopriv roles and formats, is illustrated in the following figure: +----+ | LG | +----+ ^ | Positioning Data | | +------------Privacy Rules------------------>+----+ | | +---->| LR |--> ... | | | | LS | v | | +----+ +-------+ | |Target | +----+ | +----+ |Device |--------------->| LR |---------------+---->| LR | | RM | LO | LS | LO | +----+ | LS | +----+ | +-------+ | | +----+ +---->| LR | +----+ Figure 2: Basic Geopriv Scenario
3. Use: A Location Recipient receives the location and uses it. Each of these phases involves a different set of Geopriv roles, and each has a different set of privacy and security implications. The Geopriv roles are mapped onto the location life cycle in the figure below. +----------+ | Rule |+ | Maker(s)|| Positioning | || Data +----------+| | +----------+ | | Rules | | | | V V +----------+ +----------+ +----------+ |Location | Location | Location |+ LO |Location | |Generator |--------------->| Server(s)||-------------->|Recipient | | | | || | | +----------+ +----------+| +----------+ +----------+ <-------------------------><---------------------------><-----------> Positioning Distribution Use Figure 3: Location Life Cycle
positioning often provides location information to protocols by which the network informs a Device of its own location. These are known as Location Configuration Protocols; see Section 4.2.2 for further discussion. Network-assisted systems account for the greatest number and diversity of positioning schemes. In these systems, the work of positioning is divided between the Device and an external LG via some communication (possibly over the Internet), typically in one of two ways: o The Device provides measurements to the LG, or o The LG provides assistance data to the Device. "Measurements" are understood to be observations about the Device's environment, ranging from wireless signal strengths to the Media Access Control (MAC) address of a first-hop router. "Assistance" is the complement to measurement, namely the positioning information that enables the computation of location based on measurements. A set of wireless base station locations (or wireless calibration information) would be an assistance datum, as would be a table that maps routers to buildings in a corporate campus. For example, wireless and wired networks can serve as the basis for network-assisted positioning. In several current 802.11 positioning systems, the Device sends measurements (e.g., MAC addresses and signal strengths) to an LG, and the LG returns a location to the client. In wired networks, the Device can send its MAC address to the LG, which can query the MAC-layer infrastructure to determine the switch and port to which that MAC address is connected, then query a wire map to determine the location at which the wire connected to that port terminates. As an aside, the common phrase "assisted GPS" ("assisted GNSS" more broadly) actually encompasses techniques that transmit both measurements and assistance data. Systems in which the Device provides the LG with GNSS measurements are measurement-based, while those in which the assistance server provides ephemeris or almanac data are assistance-based in the above terminology. (Those familiar with GNSS positioning will note that there are of course cases in which both of these interactions occur within a single location determination protocol, so the categories are not mutually exclusive.) Naturally, the exchange of measurement or positioning data between the Device and the LG requires a protocol over which the information is carried. The structure of this protocol will depend on which of
the two patterns a network-assisted scheme follows. Conversely, the structure of the protocol will determine which of the two parties (the Device, the LG, or both) is aware of the Device's location at the end of the protocol interaction. Section 4.2.4 apply. In some deployment scenarios, positioning functions and distribution functions may need to be provided by separate entities, in which case the LG and LS roles will not be performed by the same entity. In this situation, the LG acts as a "dumb", non-privacy-aware positioning resource, and the LS provides the privacy logic necessary to support distribution (possibly with multiple LSes using the same LG). In order to allow the privacy-unaware LG to distribute location information to these LSes while maintaining privacy, the relationship between the LG and its set of LSes MUST be tightly constrained (effectively "hard-wired"). That is, the LG MUST only provide location information to a small fixed set of LSes, and each of these LSes MUST comply with the requirements of Section 4.2.4.
2) By eavesdropping, a third party may be able to obtain measurements sent by the Device itself that indicate the rough position of the Device. To mitigate this risk, protocols used for positioning MUST provide confidentiality and integrity protections in order to prevent observation and modification of transmitted positioning data while en route between the Target and the LG. If an LG or a Target chooses to act as an LS, it inherits the security requirements for an LS, described in Section 4.2.5. 6] to provide a framework for broad-based rule specifications. Geopriv Policy  defines a language for creating location-specific rules. The XML Configuration Access Protocol (XCAP)  can be used as a protocol to install rules in both of these formats.
Privacy Rules follow a default-deny pattern: an empty set of Rules implies that all requests for location information should be denied, except requests made by the Target itself. Each Rule adds to the set, granting a specific permission. Adding a Rule can only augment privacy protections because all Rules are positive grants of permission. The following are examples of Privacy Rules governing location distribution: o Retransmit location information when requested from example.com. o Retransmit only city and country. o Retransmit location information with no less than a 100-meter radius of uncertainty. o Retransmit location information only for the next two weeks. LSes enforce Privacy Rules in two ways: by denying requests for location information, or by transforming the location information before retransmitting it. LSes may also receive Rules governing location retention, such as "Retain location only for 48 hours". Such Rules are simply directives about how long the Target's location information can be retained. Privacy Rules can govern the behavior of both LSes and LRs. Rules that direct LSes about how to treat a Target's location information are known as Local Rules. Local Rules are used internally by the LS to handle requests from LRs. They are not distributed to LRs. Forwarded Rules, on the other hand, travel inside LOs and direct LSes and LRs about how to handle the location information they receive. Because the Rules themselves may reveal potentially sensitive information about the Target, only the minimal subset of Forwarded Rules necessary to handle the LO is distributed.
An example can illustrate the interaction between Local Rules and Forwarded Rules. Suppose Alice provides the following Local Rules to an LS: o The LS may retransmit Alice's precise location to Bob, who in turn is permitted to retain the location information for one month. o The LS may retransmit Alice's city, state, and country to Steve, who in turn is permitted to retain the location information for one hour. o The LS may retransmit Alice's country to a photo-sharing Web site, which in turn is permitted to retain the location information for one year and retransmit it to any requesters. When Steve asks for Alice's location, the LS can transmit to Steve the limited location information (city, state, and country) along with Forwarded Rules instructing Steve to (a) not further retransmit Alice's location information, and (b) only retain the location information for one hour. By only sending these specifically applicable Forwarded Rules to Steve (as opposed to the full set of Local Rules), the LS is protecting Alice's privacy by not disclosing to Steve that (for example) Alice allows Bob to obtain more precise location information than Alice allows Steve to receive. Geopriv is designed to be usable even by devices with constrained processing capabilities. To ensure that Forwarded Rules can be processed on constrained devices, LOs are required to carry only a limited set of Forwarded Rules, with an option to reference a more robust set of external Rules. The limited Rule set covers two privacy aspects: how long the Target's location may be retained ("Retention"), and whether or not the Target's location may be retransmitted ("Retransmission"). An LO may contain a pointer to more robust Rules, such as those shown in the set of four Rules at the beginning of this section.
A Location Configuration Protocol (LCP)  is one mechanism that can be used by a Device to discover its own location from a LIS. LCPs provide functions in the way they obtain, transport, and deliver location requests and responses between a LIS and a Device such that the LIS can trust that the location requests and responses handled via the LCP are in fact from/to the Target. Several LCPs have been developed within Geopriv    . A LIS whose sole purpose is to perform Location Configuration need only follow a simple privacy-preserving policy: transmit a Target's location only to the Target itself. This is known as the "LCP policy". Importantly, if an LS is also serving in the role of LG and it has not been provisioned with Privacy Rules for a particular Target, it MUST follow the LCP policy, whether it is a LIS or not. In the positioning phase, an entity serving the roles of both LG and LS that has not received Privacy Rules must follow this policy. The same is true for any LS in the distribution phase. 14]. Distribution of location-by-reference (distribution of location URIs) offers several benefits. Location URIs are a more compact way of transmitting location information, since URIs are usually smaller than LOs. A recipient of location information can make multiple requests to a URI over time to receive updated location information if the URI is configured to provide a fresh location rather than a single "snapshot". From a positioning perspective, location-by-reference can offer the additional benefit of "just in time" positioning. If a location is distributed by reference, an entity acting as a combined LG/LS only needs to perform positioning operations when a recipient dereferences a previously distributed URI.
From a privacy perspective, distributing a location as a URI instead of as an LO can help protect privacy by forcing each recipient of the location to request location information from the referenced LS, which can then apply access controls individually to each recipient. But the benefit provided here is contingent on the LS applying access controls. If the LS does not apply an access control policy to requests for a location URI (in other words, if it enforces the "possession model" defined in ), then transmitting a location URI presents the same privacy risks as transmitting the LO itself. Moreover, the use of location URIs without access controls can introduce additional privacy risks: If URIs are predictable, an attacker to whom the URI has not been sent may be able to guess the URI and use it to obtain the referenced LO. To mitigate this, location URIs without access controls need to be constructed so that they contain a random component with sufficient entropy to make guessing infeasible.
if it is in a format with no Rules syntax -- then the LS MUST delete it. Emergency services provide an exception in that Rules can be implicit; see ). If the LO included Rules by reference, but these Rules were not obtained for any reason, the LS MUST NOT transmit the LO and MUST adhere to the provided value in the retention-expires field. An LS that receives Rules both directly from one or more Rule Makers and through LOs MUST combine the Rules in a given LO with Rules it has received from the RMs. The strategy the LS uses to combine these sets of Rules is a matter for local policy, depending on the relative priority that the LS grants to each source of Rules. Some example policies are: Union: A transmission of location information is authorized if it is authorized by either a rule in the LO or an RM-provided rule. Intersection: A transmission of location information is authorized if it is authorized by both a rule in the LO and an RM-provided rule. RM Override: A transmission of location information is authorized if it is authorized by an RM-provided rule, regardless of the LO Rules. LO Override: A transmission of location information is authorized if it is authorized by an LO-provided rule, regardless of the RM Rules. The default combination policy for an LS that receives multiple rule sets is to combine them according to procedures in Section 10 of RFC 4745 . Privacy rules always grant access; i.e., the default is to deny access, and rules specify conditions under which access is allowed. Thus, when an LS is provided more than one policy document that applies to a given LO, it has been instructed to provide access when any of the rules apply. That is, the "Union" policy is the default policy for an LS with multiple sources of policy. An LS MAY choose to apply a more restrictive policy by ignoring some of the grants of permission in the privacy rules provided. The "Intersection" policy and both "Override" policies listed above are of this latter character. Protocols that are used for managing rules should allow an RM to retrieve from the LS the set of rules that will ultimately be applied. For example, in the basic HTTP-based protocol defined in , an RM can use a GET request to retrieve the policy being applied by the LS and a PUT request to specify new rules.
Different policies may be applicable in different scenarios. In cases where an external RM is more trusted than the source of the LO, the "RM Override" policy may be suitable (for example, if the external RM is the Target and the LO is provided by a third party). Conversely, the "LO Override" policy is better suited to cases where the LO provider is more trusted than the RM, for example, if the RM is the user of a mobile device LS and the LO contains Rules from the RM's parents or corporate security office. The "Intersection" policy takes the strictest view of the permission grants, giving equal weight to all RMs (including the LO creator). Each of these policies will also have different privacy consequences. Following the "Intersection" policy ensures that the most privacy- protective subset of all RMs' rules will be followed. The "Union" policy and both "Override" policies may defy the expectations of any RM (including, potentially, the Target) whose policy is not followed. For example, if a Target acting as an RM sets Rules and those Rules are overridden by the application of a more permissive LO Override policy that has been set by the Target's parent or employer acting as an RM, the retransmission or retention of the Target's data may come as a surprise to the Target. For this reason, it is RECOMMENDED that LSes provide a way for RMs to be able to find out which policy will be applied to the distribution of a given LO.
As they travel through the Internet, LOs necessarily pass through a sequence of intermediaries, ranging from layer-2 switches to IP routers to application-layer proxies and gateways. The ability of an LS to protect privacy by making access control decisions is reduced if these intermediaries have access to an LO as it travels between privacy-preserving entities. Ideally, LOs SHOULD be transmitted with confidentiality protection end-to-end between an LS that transmits location information and the LR that receives it. In some cases, the protocol conveying an LO provides confidentiality protection as a built-in security solution for its signaling (and potentially its data traffic). In this case, carrying an unprotected LO within such an encrypted channel is sufficient. Many protocols, however, are offering communication modes where messages are either unprotected or protected on a hop-by- hop basis (for example, between intermediaries in a store-and-forward protocol). In such a case, it is RECOMMENDED that the protocol allow for the use of encrypted LOs, or for the transmission of a reference to a location in place of an LO .
17] or Transport Layer Security (TLS) . Additionally, if (1) the protocol provides mutual authentication for every segment, and (2) every entity in the location distribution chain exchanges information only with entities with whom it has a trust relationship, entities can transitively obtain assurances regarding the origin and ultimate destination of the LO. Of course, direct assurances are always preferred over assurances requiring transitive trust, since they require fewer assumptions. Using protocol mechanisms alone, the entities can receive assurances only about a single hop in the distribution chain. For example, suppose that an LR receives location information from an LS over an integrity- and confidentiality-protected channel. The LR knows that
Location Server: The Location Server is responsible for enforcing the Target's Privacy Rules. The first assurance required by the LS is that the binding between the Target's Privacy Rules and the Target's identity is authentic. Authenticating and authorizing the Rule Maker who creates, updates, and deletes the Privacy Rules prevents rule-tampering attacks. The LS has to ensure that the authorization policies are not exposed to third parties, if so desired by the Rule Maker and when the rules themselves are privacy-sensitive. Location Recipient: The Location Recipient is the consumer of the LO. The LR thus requires assurances about the authenticity of the bindings between the Target's location, the Target's identity, and the time. Ensuring the authenticity of these bindings helps to prevent various attacks, such as falsifying the location, modifying the timestamp, faking the identity, and replaying LOs. Location Generator: The primary assurance required by the Location Generator is that the LS to which the LO is initially published is one that is trusted to enforce the Target's Privacy Rules. Authenticating the trusted LS mitigates the risk of server impersonation attacks. Additionally, the LG is responsible for the location determination process, which is also sensible from a security perspective because wrong input provided by external entities can lead to undesirable disclosure or access to location information. Assurances as to the integrity and confidentiality of a Location Object can be provided directly through the LO format. RFC 4119  provides a description for the usage of Secure/Multipurpose Internet Mail Extensions (S/MIME) to integrity and confidentiality protection. Although such direct, end-to-end assurances are desirable, and these mechanisms should be used whenever possible, there are many deployment scenarios where directly securing an LO is impractical. For example, in some deployment scenarios a direct trust relationship may not exist between the creator of the Location Object and the recipient. Additionally, in a scenario where many recipients are authorized to receive a given LO, the creator of the LO cannot guarantee end-to-end confidentiality without knowing precisely which recipient will receive the LO. Many of these cases can, however, be addressed by the usage of a location-by-reference mechanism, possibly combined with an LO.
19] -- namely, that the principal Rules that can be set are limits on the retransmission and retention of the LO. While these two Rules are the most well-known and important examples, the specific types of Rules an LS or LR must consider will in general depend on the types of LOs it processes. 20] or SIP INVITE message ), and the server delivers that service immediately (e.g., in a 200 OK response in HTTP or SIP), without retaining or retransmitting the Device's location. The Device acts as an LG by using a Device-based positioning algorithm (e.g., manual entry) and as an LS by interpreting the rule and transmitting the LO. The Target acts as a Rule Maker by specifying that the location should be sent to the server. The server acts as an LR by receiving and using the LO. In this case, the privacy of location information is maintained in two steps: The first step is that the location is only transmitted as directed by the single Rule Maker, namely the Target. The second step is simply the fact that the server, as LR, does not do anything that creates a privacy risk -- it does not retain or retransmit the location. Because the server limits its behavior in this way, it does not need to read the Rules in the LO, even though they were provided -- no Rule would prevent it from using the location in this safe manner. The following outline summarizes this scenario: o Positioning: Device-based, Device=LG o Distribution hop 1: HTTP User Agent (UA) --> Ephemeral Web service, privacy via user indication
o Use: Ephemeral Web service delivers response without retaining or retransmitting location o Key point: * LRs that do not behave in ways that risk privacy are Geopriv- compliant by default. No further action is necessary. 22] to a server in the same domain as the page and renders this information to the user. At first blush, this scenario seems much more complicated than the minimal scenario above. However, most of the privacy considerations are actually the same. The positioning phase in this scenario begins when the browser extension contacts the positioning server. The positioning server acts as an LG. The distribution phase actually occurs entirely within the Target host. This phase begins when the positioning server, now acting as an LS, follows the LCP policy by providing the location only to the Target. The next hop in distribution occurs when the browser extension (an entity under the control of the Target) passes an LO to the Web page (an entity under the control of its author). In this phase, the browser extension acts as an LS, with the Target as the sole Rule Maker; the user interface for rule-making is effectively a
protocol for conveying Rules, and the extension's API effectively defines a way to communicate LOs and an LO format. The Web site acts as an LR when the Web page accepts the LO. The use phase encompasses the Web site's use of the LO. In this context, the phrase "Web site" encompasses not only the Web page, but also the dedicated supporting logic behind it. Considering the entire Web site as a recipient, rather than a single page, it becomes clear that sending the LO in an XMLHttpRequest to a back-end server is like passing it to a separate component of the LR, as opposed to retransmitting it to another entity. Thus, even in this case, where location-relevant information is obtained from a back-end server, the LR does not retain or retransmit the location, so its behavior is "privacy-safe" -- it doesn't need to interpret the Rules in the LO. However, consider a variation on this scenario where the Web page requests additional information (a map, for instance) from a third- party site. In this case, since location information is being transmitted to a third party, the Web site (either in the Web page or in a back-end server) would need to verify that this transmission is allowed by the LO's Privacy Rules. Similarly, if the site wanted to log the user's location information, then it would need to examine the LO to determine how long this information can be retained. In such a case, if the LR needs to do something that is not allowed by the Rules, it may have to deny service to the user, while hopefully providing a message with the reason. Nonetheless, if the Rules permit retention or retransmission, even if this retransmission is limited by access control rules, then the LR may do so to the extent the Rules allow. The following outline summarizes this scenario: o Positioning: Network-assisted, positioning server=LG o Rule installation: RM (=Target) gives permission to sites and sets LO Rules o Distribution hop 1: positioning server=LS --> Target, privacy via LCP policy o Distribution hop 2: Browser=LS --> Web site=LR, privacy via user confirmation o Use: Back-end server delivers location-relevant information without further retransmission, then deletes location; privacy via safe behavior
o Key points: * Privacy in this scenario is provided by a combination of explicit user direction and Rules in an LO. * Distribution can occur within a host, between components that do not trust each other. * Some transmissions of the location are actually internal to an LR. * LRs that do things that might be constrained by Rules need to verify that these actions are allowed for a particular LO. 23] . In this architecture, there are three critical steps in the placement of an emergency call, each involving location information: 1. Determine the location of the caller. 2. Determine the proper Public Safety Answering Point (PSAP) for the caller's location. 3. Send a SIP INVITE message, including the caller's location, to the PSAP. The first step in an emergency call is to determine the location of the caller. This step is the positioning phase of the location life cycle. The location is determined by whatever means are available to the caller's device, or to the network, if this step is being done by a proxy. The entity doing the positioning, whether the caller or a proxy, acts as an LS, preserving the privacy of location information by only including it in emergency calls. The second step in an emergency call encompasses location distribution and use. The entity that is routing the emergency call sends location information through the Location-to-Service Translation (LoST) Protocol  to a mapping server. In this role, the routing entity acts as an LS and the LoST server acts as an LR. The LO format within LoST does not allow Rules to be sent along with the location, but because LoST is an application-specific protocol, the sending of the location within a LoST message authorizes the LoST server to use the location to complete the protocol, namely to route
the message as necessary through the LoST mapping architecture . That is, the LoST server is authorized to complete the LoST protocol, but to do nothing else. The third step in an emergency call is again a combination of distribution and use. The caller, or another entity that inserts the caller's location, acts as an LS, and the PSAP acts as an LR. In this specific example, the caller's location is transmitted either as a PIDF-LO or as a reference that returns a PIDF-LO, or both; in the latter case, the reference should be appropriately protected so that only the PSAP has access. In any case, the receipt of an LO implies that the PSAP should obey the Rules in those LOs in order to preserve privacy. Depending on the regulatory environment, the PSAP may have the option to ignore those constraints in order to respond to an emergency, or it may be bound to respect these Rules in spite of the emergency situation. The following outline summarizes this scenario: o Positioning: Any o Distribution/use hop 1: Target=LS --> LoST infrastructure (no Rules), privacy via authorization implicit in protocol o Distribution/use hop 2: Target=LS --> PSAP, privacy via Rules in LO o Use: PSAP uses location to deliver emergency services o Key points: * Privacy in this scenario is provided by a combination of explicit user direction, implicit authorization particular to a protocol, and Rules in an LO. * LRs may be constrained to respect or ignore Privacy Rules by local regulation.
Suppose Alice as the Target subscribes to a wireless ISP that determines her location using a network-based positioning technique, e.g., via the location of the base station serving the Target, and provides that information directly to a location-enhanced presence provider. This presence provider might use SIP, the Extensible Messaging and Presence Protocol (XMPP) , or another protocol). The location-enhanced presence provider allows Alice to specify Rules for how this location is distributed: which friends should receive Alice's location and what Rules they should get with it. Alice uses a few other location-enhanced services as well, so she sends Rules that allow her location to be shared with those services, and that allow those services to retain and retransmit her location. Bob is one of Alice's friends, and he receives her location via this location-enhanced presence service. Noting that she's at their favorite coffee shop, Bob wants to upload a photo of the two of them at the coffee shop to a photo-sharing site, along with an LO that marks the location. Bob checks the Rules in Alice's LO and verifies that the photo-sharing site is one of the services that Alice authorized. Seeing that Alice has authorized him to give the LO to the photo-sharing site, he attaches it to the photo and uploads it. Once the geo-tagged photo is uploaded, the photo-sharing site reads the Rules in the LO and verifies that the site is authorized to store the photo and to share it with others. Since Alice has allowed the site to retransmit and retain without any constraints, the site fulfills Bob's request to make the geo-tagged photo publicly accessible. Eve, another user of the photo-sharing site, downloads the photo of Alice and Bob at the coffee shop and receives Alice's LO along with it. Eve posts the photo and location to her public page on a social networking site without checking the Rules, even though the LO doesn't allow Eve to send the location anywhere else. The social networking site, however, observes that no retransmission or retention are allowed, both of which it needs for a public posting, and rejects the upload. In terms of the location life cycle, this scenario consists of a positioning step, followed by four distribution hops and use. Positioning is the simplest step: An LG in Alice's ISP monitors her location and transmits it to the presence service, maintaining privacy by only transmitting the location information to a single entity to which Alice has delegated privacy responsibilities.
The first distribution hop occurs when the presence server sends the location to Bob. In this transaction, the presence server acts as an LS, Alice acts as an RM, and Bob acts as an LR. The privacy of this transaction is assured by the fact that Alice has installed Rules on the presence server that dictate who it may allow to access her location. The second distribution hop is when Bob uploads the LO to the photo-sharing site. Here Bob acts as an LS, preserving the privacy of location information by verifying that the Rules in the LO allow him to upload it. The third distribution hop is when the photo-sharing site sends the LO to Eve, likewise following the Rules -- but a different set of Rules than for Bob, since an LO can specify different Rule sets for different LSes. Eve is the fourth LS in the chain, and fails to comply with Geopriv by not checking the Rules in the LO prior to uploading the LO to the social networking site. The site, however, is a responsible LR -- it checks the Rules in the LO, sees that they don't allow it to use the location as it needs to, and discards the LO. The following outline summarizes this scenario: o Positioning: Network-based, LG in network, privacy via exclusive relationship with presence service o Distribution/use hop 1: Presence server --> Bob, privacy via Alice's access control rules o Distribution/use hop 2: Bob --> photo-sharing site, privacy via Rules for Bob in LO o Distribution/use hop 3: Photo-sharing site --> Eve, privacy via Rules for site in LO o Distribution/use hop 4: Eve --> Social networking site, violates privacy by retransmitting o Use: Social networking site, privacy via checking Rules and discarding o Key points: * Privacy can be preserved through multiple hops. * An LO can specify different Rules for different entities. * An LS can still disobey the Rules, but even then, the architecture still works in some cases.
RFC 4949 . $ Access Control Rule A rule that describes which entities may receive location information and in what form. $ civic location The geographic position of an entity in terms of a postal address or civic landmark. Examples of such data are room number, street number, street name, city, postal code, county, state, and country. $ Device The physical device, such as a mobile phone, PC, or embedded micro-controller, whose location is tracked as a proxy for the location of a Target. $ geodetic location The geographic position of an entity in a particular coordinate system, for example, a latitude-longitude pair. $ Local Rule A Privacy Rule that directs a Location Server about how to treat a Target's location information. Local Rules are used internally by a Location Server to handle requests from Location Recipients. They are not distributed to Location Recipients. $ Location Generator (LG) Performs the role of initially determining or gathering the location of a Target. Location Generators may be any sort of software or hardware used to obtain a Target's location. Examples include GPS chips and cellular networks.
$ Location Information Server (LIS) An entity responsible for providing devices within an access network with information about their own locations. A Location Information Server uses knowledge of the access network and its physical topology to generate and distribute location information to devices. $ Location Object (LO) A data unit that conveys location information together with Privacy Rules within the Geopriv architecture. A Location Object may convey geodetic location data (latitude, longitude, altitude), civic location data (street, city, state, etc.), or both. $ Location Recipient (LR) An ultimate end-point entity to which a Location Object is distributed. Location Recipients request location information about a particular Target from a Location Server. If allowed by the appropriate Privacy Rules, a Location Recipient will receive Location Objects describing the Target's location from the Location Server. $ Location Server (LS) An entity that receives Location Objects from Location Generators, Privacy Rules from Rule Makers, and location requests from Location Recipients. A Location Server applies the appropriate Privacy Rules to a Location Object received from a Location Generator and may disclose the Location Object, in compliance with the Rules, to Location Recipients. Location Servers may not necessarily be "servers" in the colloquial sense of hosts in remote data centers servicing requests. Rather, a Location Server can be any software or hardware component that receives and distributes location information. Examples include a positioning server (with a location interface) in an access network, a presence server, or a Web browser or other software running on a Target's device.
$ Privacy Rule A directive that regulates an entity's activities with respect to a Target's location information, including the collection, use, disclosure, and retention of the location information. Privacy Rules describe how location information may be used by an entity, the level of detail with which location information may be described to an entity, and the conditions under which location information may be disclosed to an entity. Privacy Rules are communicated from Rule Makers to Location Servers and conveyed in Location Objects throughout the Geopriv architecture. $ Rule See Privacy Rule. $ Rule Maker (RM) An individual or entity that is authorized to set Privacy Rules for a Target. In some cases, a Rule Maker and a Target will be the same individual or entity, and in other cases they will be separate. For example, a parent may serve as the Rule Maker when the Target is his child. The Rule Maker is also not necessarily the owner of a Target device. For example, a corporation may own a device that it provides to an employee but permit the employee to serve as the Rule Maker and set her own Privacy Rules. Rule Makers provide the Privacy Rules associated with a Target to Location Servers. $ Forwarded Rule A Privacy Rule that travels inside a Location Object. Forwarded Rules direct Location Recipients about how to handle the location information they receive. Because the Forwarded Rules themselves may reveal potentially sensitive information about a Target, only the minimal subset of Forwarded Rules necessary for a Location Recipient to handle a Location Object is distributed to the Location Recipient. $ Target An individual or other entity whose location is sought in the Geopriv architecture. In many cases, the Target will be the human user of a Device, or it may be an object such as a vehicle or shipping container to which a Device is attached. In some instances, the Target will be the Device itself. The Target is the entity whose privacy Geopriv seeks to protect.
$ Usage Rule A rule that describes what uses of location information are authorized. Section 5 is largely based on the security investigations conducted as part of the Geopriv Layer-7 Location Configuration Protocol design team, which produced . We would like to thank all the members of the design team. We would also like to thank Marc Linsner and Martin Thomson for their contributions regarding terminology and LCPs.  Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.  Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004.  Danley, M., Mulligan, D., Morris, J., and J. Peterson, "Threat Analysis of the Geopriv Protocol", RFC 3694, February 2004.  U.S. Department of Defense, "National Industrial Security Program Operating Manual", DoD 5220-22M, January 1995.  Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations", RFC 5491, March 2009.  Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk, J., and J. Rosenberg, "Common Policy: A Document Format for Expressing Privacy Preferences", RFC 4745, February 2007.  Schulzrinne, H., Ed., Tschofenig, H., Ed., Morris, J., Cuellar, J., and J. Polk, "Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information", Work in Progress, March 2011.
 Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", RFC 4825, May 2007.  Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location Configuration Protocol: Problem Statement and Requirements", RFC 5687, March 2010.  Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information", RFC 3825, July 2004.  Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information", RFC 4776, November 2006.  Polk, J., "Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6 Option for a Location Uniform Resource Identifier (URI)", Work in Progress, February 2011.  Barnes, M., Ed., "HTTP-Enabled Location Delivery (HELD)", RFC 5985, September 2010.  Marshall, R., Ed., "Requirements for a Location-by-Reference Mechanism", RFC 5808, May 2010.  Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, "LoST: A Location-to-Service Translation Protocol", RFC 5222, August 2008.  Barnes, R., Thomson, M., Winterbottom, J., and H. Tschofenig, "Location Configuration Extensions for Policy Management", Work in Progress, June 2011.  Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.  Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.  Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.  Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
 Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.  World Wide Web Consortium, "The XMLHttpRequest Object", W3C document http://www.w3.org/TR/XMLHttpRequest/, August 2010.  Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, "Framework for Emergency Calling Using Internet Multimedia", Work in Progress, October 2010.  Rosen, B. and J. Polk, "Best Current Practice for Communications Services in support of Emergency Calling", Work in Progress, March 2011.  Schulzrinne, H., "Location-to-URL Mapping Architecture and Framework", RFC 5582, September 2009.  Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011.  Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, August 2007.  <http://creativecommons.org/>
Alissa Cooper Center for Democracy & Technology 1634 I Street NW, Suite 1100 Washington, DC USA EMail: firstname.lastname@example.org John Morris Center for Democracy & Technology 1634 I Street NW, Suite 1100 Washington, DC USA EMail: email@example.com Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland Phone: +358 (50) 4871445 EMail: Hannes.Tschofenig@gmx.net URI: http://www.tschofenig.priv.at Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US Phone: +1 212 939 7004 EMail: firstname.lastname@example.org URI: http://www.cs.columbia.edu