[Docs] [txt|pdf] [Tracker] [Email] [Nits] [IPR]

Versions: 00 01 02 03 04 05 draft-ietf-geopriv-arch

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):

 <?xml version="1.0" encoding="UTF-8"?>
  <presence xmlns="urn:ietf:params:xml:ns:pidf"
     xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
     xmlns:gml="urn:opengis:specification:gml:schema-xsd:feature:v3.0"
     entity="pres:meaningless-F32AC8D@example.com">
   <tuple id="sg89ae">
    <status>
     <gp:geopriv>
       <gp:location-info>
         <gml:location>
           <gml:Point gml:id="point1" srsName="epsg:4326">
             <gml:coordinates>37:46:30N 122:25:10W</gml:coordinates>
           </gml:Point>
          </gml:location>
       </gp:location-info>
       <gp:usage-rules>
         <gp:retransmission-allowed>no</gp:retransmission-allowed>
         <gp:retention-expiry>2003-06-23T04:57:29Z</gp:retention-expiry>
       </gp:usage-rules>
     </gp:geopriv>
    </status>
    <contact>sip:geotarget@example.com</contact>
    <timestamp>2003-06-22T20:57:29Z</timestamp>
   </tuple>
  </presence>
   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
   <gp:location-info> element at the time indicated in the <timestamp>
   element; the content of this encoded statement is subject to the
   usage rules described in the <gp:usage-rules> 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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/