Network Working Group R. Barnes Internet-Draft M. Lepinski Intended status: Standards Track BBN Technologies Expires: October 3, 2007 H. Tschofenig Nokia Siemens Networks H. Schulzrinne Columbia University April 2007 Threats to GEOPRIV Location Objects draft-barnes-geopriv-lo-sec-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on October 3, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract Presence-based location objects used by Internet protocols encode bindings of location information to identities of a presentity, with associated rules for the handling and usage of the location object. Parties that make use of location objects rely on the accuracy of Barnes, et al. Expires October 3, 2007 [Page 1] Internet-Draft LO Threats April 2007 these bindings to ensure their proper function, and the entities that they describe rely on the proper application of the included rules to ensure their privacy. This document describes the space of attacks against location objects. Requirements Language 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 [RFC2119]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Integrity and Authenticity Threats . . . . . . . . . . . . . . 5 2.1. Location and Time . . . . . . . . . . . . . . . . . . . . 5 2.2. Location and Identity . . . . . . . . . . . . . . . . . . 6 2.2.1. Spoofing . . . . . . . . . . . . . . . . . . . . . . . 6 2.2.2. Theft and Swapping . . . . . . . . . . . . . . . . . . 6 2.2.3. Levels of Identity . . . . . . . . . . . . . . . . . . 7 2.3. Tuples and Rules . . . . . . . . . . . . . . . . . . . . . 7 3. Confidentiality and Privacy Threats . . . . . . . . . . . . . 8 3.1. Eavesdropping . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Anonymity . . . . . . . . . . . . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Normative References . . . . . . . . . . . . . . . . . . . 9 6.2. Informative References . . . . . . . . . . . . . . . . . . 9 Appendix A. An Appendix . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Barnes, et al. Expires October 3, 2007 [Page 2] Internet-Draft LO Threats April 2007 1. Introduction RFC 4119 defines the PIDF-LO location object format, which extends the Presence Information Document Format [ref:RFC3863] to carry location information and rules regarding transmission and processing of that location information. A PIDF-LO document contains four essential types of information: Identifiers for the described presentity, location information, time-stamps, and rules. By grouping values of these various types together within an XML structure, a PIDF-LO document encodes a set of bindings among them. For instance, consider the following PIDF-LO document (copied from RFC 4119): 37:46:30N 122:25:10W no 2003-06-23T04:57:29Z sip:geotarget@example.com 2003-06-22T20:57:29Z Figure 1: A sample PIDF-LO Location Object This document asserts that the presentity identified as "sip:geotarget@example.com" was located at the point described in the element at the time indicated in the element; the content of this encoded statement is subject to the usage rules described in the element. For purposes of discussion, we will consider this as a pair of bindings: First, identity, location, and time are tied to each other (the "sighting binding"), and second, these are bound to a set of rules (the "rule Barnes, et al. Expires October 3, 2007 [Page 3] Internet-Draft LO Threats April 2007 binding"). Different entities require different assurances about these bindings. Location Recipients (LRs, as defined in [ref:RFC3693]) are primarily concerned with the integrity of the sighting binding (or a subset of it). In order to ensure that actions taken on the bases of the LO are correct, the LR must be assured that the information has not been altered in transit. On the other hand, the entity whose position is described in the LO (a Target per RFC 3693), may be more concerned that the usage rules cannot be removed or modified, so that he can rely on the fact that his privacy rules have been faithfully communicated. Different bindings are typically asserted by different entities as well. The entities best equipped to provide sighting bindings, for instance, will often be Location Servers within an access network, while the entity that will provide the rule binding (in RFC 3693, the Rule Maker) will most commonly be the target of the LO. These distinctions are important when one allows the possibility that bindings will be verifiably attested via digital signatures, possibly created with two different keys. In order to ensure that the LO provides the necessary assurances to relying parties (e.g., Targets and Location Recipients), one must consider the entire "life-cycle" of the LO as it is constructed, forwarded, and finally received. In general, this life-cycle consists of three high-level parts: The creation of sighting bindings, the binding of rules to the LO, and the conveyance of the LO from one party to another. As a particular LO is constructed, these steps may be interspersed and repeated; for example, the following could be the life-cycle of an LO: 1. (Sighting) A sighting function creates a sighting binding that ties a location to the target's MAC address 2. (Conveyance) The sighting function conveys the initial LO to the target 3. (Rule binding) The target adds a set of usage rules to the LO 4. (Conveyance) The target conveys the LO to a Location Server 5. (Sighting) The Location Server creates a second sighting binding, this time including a "sip:" URI to identify the Target 6. (Conveyance) The Location Server delivers the LO to a Location Recipient Barnes, et al. Expires October 3, 2007 [Page 4] Internet-Draft LO Threats April 2007 Security mechanisms can be added at any of these points. Bindings can be verifiably asserted via digital signatures. Conveyance protocols can provide confidentiality and integrity to LOs. An important point to keep in mind, however, is that relying on a mechanism that adds security at a given point on this chain implicitly assumes that everything before that point is trusted. For example, providing TLS on the final conveyance step only provides an overall guarantee of confidentiality if one assumes that all relays that the LO has traversed before the last one are trusted to have properly handled the LO. A note on trust: Security is fundamentally based on trust relationships. The goal of this document is to state requirements on mechanisms for USING trust relationships to give assurances about LOs. Nothing in this document requires a given trust model to be implemented; however, certain assurances have de facto trust requirements. For instance, if the user of a location object requires assurance that the location information provided has not been tampered with, then he must have a trust relationship with the entity that initially provided the location information, either directly or through an intermediary (such as a Certificate Authority in a PKI or simply another entity authorized to vouch for location). This document is presents an analysis of threats GEOPRIV Location Objects, much as RFC 3693 and RFC 3694 do. However, this document differs from prior documents in significant ways. This document presents a more thorough and detailed security analysis than RFC 3693; in particular, it specifies which attacks involve which data elements and bindings within an LO, so that security features provided to the LO can be matched against threats. The threat model we describe focuses on how location objects can be misused or corrupted across its entire life-cycle, a more general type of threat than is addressed in RFC 3694, which focuses on a single hop in a putative store-and-forward system. 2. Integrity and Authenticity Threats Parties that use location information need assurances that the bindings encoded in an LO are valid. In this section we discuss threats related to falsification of various bindings asserted by the LO and the potential impact of these threats. 2.1. Location and Time This threat, often referred to as time-shifting, occurs when the adversary pretends to currently be a location that she previously occupied. For example, Alice has possession of a valid location Barnes, et al. Expires October 3, 2007 [Page 5] Internet-Draft LO Threats April 2007 object asserting that she was in Chicago, IL on March 22, 2007, and she uses this to construct a valid location object asserting that Alice is in Chicago, IL on July 22, 2007, when in truth Trudy is in San Francisco, CA. Note that certain applications will not regard time-shifting as a threat, as old location is often good enough. However, an entity that receives a location object should be able to determine how old the object is, and make its own determination as to whether the information is fresh enough to be of use. 2.2. Location and Identity This threat has two parts: binding a different location to a valid identity, often referred to as location spoofing, and binding a different identity to a valid location, often referred to as location theft or location swapping (depending on whether the owner of the original identity participates in the attack). Additionally, some applications have multiple layers of identifiers, which need to be bound together in order to ensure the overall validity of the LO. In such cases, falsifying the binding between lower-layer and higher- layer identities introduces another variation of the location swapping threat. 2.2.1. Spoofing This threat occurs when the adversary pretends to be in an arbitrary location of her choosing. For example, Alice has possession of a valid location object asserting that she is currently in San Francisco, CA, and she uses this to construct a valid location object asserting that Alice is in Miami, FL. 2.2.2. Theft and Swapping This threat has two parts. In location theft, the adversary observes a location object for an honest user, and replays that location as her own. For example, Alice operates a SIP proxy in Chicago, IL and eavesdrops on a SIP message which contains a location object asserting that Bob is in Miami, FL. Alice then uses this to construct a valid location object asserting that she is in Miami, FL. In location swapping, a pair of adversaries conspire and each pretend to be at the other's location. For example, Alice is in Chicago, IL and receives a message from Trudy, her co-conspirator, which (among other things) includes a location object asserting that Trudy is in Miami, FL. Alice then uses this information from Trudy to construct a valid location object asserting that she is in Miami, FL. Barnes, et al. Expires October 3, 2007 [Page 6] Internet-Draft LO Threats April 2007 Note that no protocol can prevent location swapping. Since all identifiers and credentials are digital, if a pair of adversaries are willing to share everything (even secret passwords and keys), then Alice can always masquerade as Trudy and vice versa. The best one can hope for is to maximize the difficultly of location swapping and require that the adversaries must exchange secrets to execute a location-swapping attack. 2.2.3. Levels of Identity In an application where entities have multiple layers of identifiers, this threat presents an additional variation on location swapping. Two adversaries obtain location objects that bind locations to their low-layer identifiers, and then bind these lower-layer identifiers to the other's higher-layer identifier. For example, Trudy obtains a location object that binds her location to her physical-layer MAC address. She then sends this object (perhaps along with some additional information) to Alice. Alice then uses this information to construct a valid location object that binds her SIP AOR to Trudy's location and MAC address. As with location swapping, this attack cannot be prevented if Alice and Trudy are willing to exchange all of their secret information. However, when seeking to maximize the difficulty of location swapping, one must also consider this type of multi-layer swapping attack. Indeed, this threat is more likely to arise that other forms of location swapping, since it's rare that the same entity can authenticate both a low layer identifier (necessary for location determination) and a higher-layer identifier (e.g., one used for identification within the conveyance protocol). 2.3. Tuples and Rules This threat occurs, when the adversary obtains a location object with a certain set of privacy rules and produces a location object with the same identity and location, but with a different set of rules. For example, Alice receives Bob's location object which includes the rule that the location object cannot be retransmitted. Alice modifies the object to indicate that retransmission is allowed, and then transmits the modified object to Eve. Since Eve receives a valid location object that allows for retransmission, she may in turn send Bob's location to a variety of other parties. Thus far, the threats in this section have focused primarily on the capabilities of malicious location targets. However, in most systems, it is acceptable for the location target to modify the rules for her own location object. Therefore, in this threat we are primarily concerned with the ability of a third party adversary to Barnes, et al. Expires October 3, 2007 [Page 7] Internet-Draft LO Threats April 2007 modify the rules in an honest user's location object. 3. Confidentiality and Privacy Threats Locations and identifiers by themselves are not sensitive information, but a location object providing a binding between them is. The rule syntax defined in RFC 4119 and RFC 4745 can be used to specify the proper handling of such sensitive information. However, further mechanisms are necessary to make sure that such rules are followed, and to ensure the confidentiality of the location object as it is transmitted in accordance with such rules. 3.1. Eavesdropping Eavesdropping is the threat in which an adversary observes a location object that she is not authorized to view. There are two variations of this threat, the first is where the adversary is required the conveyance protocol to forward the location object, but is not authorized to learn the bindings in the object. For example, the adversary runs a SIP proxy (which does not perform location-based routing) eavesdrops on all location objects passing through the proxy. The second variation is where the adversary has no legitimate reason to handle the location object. For example, the adversary has a wireless receiver and eavesdrops on all location objects that are transmitted by a nearby wireless access point. Note that the latter threat is the easier one to mitigate. Indeed, store-and-forward conveyance protocols can employ hop-by-hop security mechanisms to prevent the second form of eavesdropping. However, preventing the first form of eavesdropping requires end-to-end security mechanism (and thus requires a trust relationship between the end-points). 3.2. Anonymity Note that in some settings confidentiality may only be required for certain bindings within the location object. For example, the rules associated with a location object might indicate that certain entities have the right to see the time and the location information, but not the identity of the location target. Alternatively, an entity might need to determine that two location objects both correspond to the same location target, and yet have no need to know the true identity of the target. In such examples, there is a threat that an adversary who has the right to see certain bindings of the location object could violate the anonymity of the target. Such a threat can be mitigated through Barnes, et al. Expires October 3, 2007 [Page 8] Internet-Draft LO Threats April 2007 the use of pseudonyms within the location object in place of the target's true identity. Such pseudonyms might be a truly random string, in the case where no one is authorized to learn the target's true identity, or an encrypted string, in the case where only holders of a particular cryptographic key are authorized to learn the target's true identity. 4. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 5. Security Considerations The focus of this document is the security of location objects. As such, security concerns are discussed throughout. 6. References 6.1. Normative References 6.2. Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3683] Rose, M., "A Practice for Revoking Posting Rights to IETF mailing lists", BCP 83, RFC 3683, February 2004. [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004. [RFC3694] Danley, M., Mulligan, D., Morris, J., and J. Peterson, "Threat Analysis of the Geopriv Protocol", RFC 3694, February 2004. [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005. [RFC4745] 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. Barnes, et al. Expires October 3, 2007 [Page 9] Internet-Draft LO Threats April 2007 Appendix A. An Appendix Authors' Addresses Richard Barnes BBN Technologies 9861 Broken Land Pkwy, Suite 400 Columbia, MD 21046 US Phone: +1 410 290 6169 Email: rbarnes@bbn.com URI: http://www.bbn.com/ Matt Lepinski BBN Technologies 10 Moulton St. Cambridge, MA 01238 US Phone: +1 617 873 5939 Email: mlepinski@bbn.com URI: http://www.bbn.com/ Hannes Tschofenig Nokia Siemens Networks Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany Email: Hannes.Tschofenig@nsn.com URI: http://www.tschofenig.com Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US Phone: +1 212 939 7004 Email: hgs@cs.columbia.edu URI: http://www.cs.columbia.edu Barnes, et al. Expires October 3, 2007 [Page 10] Internet-Draft LO Threats April 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Barnes, et al. Expires October 3, 2007 [Page 11]