Subject: [Ecrit] New draft on Secure Location Objects

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 03 Nov 2006 18:41:58 -0500

The issue of the security of location information in the GEOPRIV 
architecture has gotten a lot of discussion, so we wanted to examine 
some ways that security features might be embedded in location objects.

The internet-drafts queue seems to be saturated, so please find 
draft-barnes-geopriv-secure-location-object-00.txt attached.

Cheers,
--Richard

Network Working Group                                          R. Barnes
Internet-Draft                                               M. Lepinski
Intended status: Informational                                  R. Watro
Expires: April 27, 2007                                 BBN Technologies
                                                        October 24, 2006

                        Secure Location Objects
             draft-barnes-geopriv-secure-location-object-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 April 27, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   Protection of location information is an essential requirement of the
   GEOPRIV architecture.  Since using protocols cannot be relied upon to
   provide adequate protections to the location objects they carry, the
   location objects themselves must be secured.  This document examines
   several candidates for a Secure Location Object format in the context
   of GEOPRIV and ECRIT security requirements, including both locations
   by value and by reference.

Barnes, et al.           Expires April 27, 2007                 [Page 1]

Internet-Draft           Secure Location Objects            October 2006

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.  Security Threats . . . . . . . . . . . . . . . . . . . . . . .  3
     2.1.  Disclosure of Location Information . . . . . . . . . . . .  4
     2.2.  Use of Fake Location Information . . . . . . . . . . . . .  4
     2.3.  Denial of Location-based Services  . . . . . . . . . . . .  5
   3.  Design Considerations  . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Integration with LoST  . . . . . . . . . . . . . . . . . .  6
     3.2.  GEOPRIV Considerations . . . . . . . . . . . . . . . . . .  7
     3.3.  ECRIT Considerations . . . . . . . . . . . . . . . . . . .  7
     3.4.  Technical Considerations . . . . . . . . . . . . . . . . .  7
   4.  Candidate Secure Location Object Formats . . . . . . . . . . .  7
     4.1.  Location By Value  . . . . . . . . . . . . . . . . . . . .  8
       4.1.1.  Signed Location  . . . . . . . . . . . . . . . . . . .  8
       4.1.2.  Encrypted Location . . . . . . . . . . . . . . . . . .  9
     4.2.  Location By Reference  . . . . . . . . . . . . . . . . . . 11
     4.3.  Trust Models . . . . . . . . . . . . . . . . . . . . . . . 12
   5.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 13
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 14
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
   Intellectual Property and Copyright Statements . . . . . . . . . . 16

Barnes, et al.           Expires April 27, 2007                 [Page 2]

Internet-Draft           Secure Location Objects            October 2006

1.  Introduction

   The security of location objects as they are stored and transmitted
   over the Internet is an essential enabler of the GEOPRIV
   architecture.  Without the ability to guarantee the confidentiality
   of transmitted location information, an eavesdropper can circumvent
   GEOPRIV privacy rules; without authenticity and integrity, a third
   party can forge location information and degrade the reliability of
   the entire architecture.  Even though such security guarantees may at
   times need to be relaxed -- for instance, in an emergency calling --
   it is essential that the components of the GEOPRIV architecture make
   available a suite of security services.

   The fundamental unit of location information in the GEOPRIV
   architecture is the Location Object (LO): Location Objects are
   constructed by Location Generators; stored, transformed, and
   forwarded by Location Servers; and consumed by Location Recipients.
   In practice, these different entities are often under separate
   administrative domains, joined by various relationships and separated
   by diverse networks.  The sensitive location information contained in
   these LOs is thus stored and transmitted in a wide variety of
   circumstances, and faces the risk of unauthorized access at several
   points, even in the presence of privacy rules.

   While the GEOPRIV architecture does make certain requirements of
   "using protocols" -- protocols that read or modify LI -- it
   explicitly makes no specifications with regard to protocols used only
   for transport of LOs.  There are several transport mechanisms
   currently defined for conveying LOs from one point to another:
   Extensions have been defined for SIP, DHCP, and RADIUS, and others
   are being developed.  Of these, only SIP has any claim of secure
   transport, and even the mechanisms that SIP offers are either seldom
   implemented (S/MIME) or widely regarded as ineffective (SIPS).

   The security of LOs used in GEOPRIV thus cannot rely on the security
   of the underlying transport, but must instead by enforced by security
   features inherent in the location object itself.  We call location
   objects with such features Secure Location Objects, or SLOs.  Below,
   we summarize the threats to location information that have been
   identified by the ECRIT and GEOPRIV working groups to date, identify
   some additional design constraints that must be taken into account by
   an SLO design, and examine the feasibility of several possible SLO
   formats in light of these conditions.

2.  Security Threats

   Prior work by both the ECRIT and GEOPRIV working groups has

Barnes, et al.           Expires April 27, 2007                 [Page 3]

Internet-Draft           Secure Location Objects            October 2006

   identified a set of risks facing location information, which are
   summarized here as the risks of unauthorized disclosure, forgery, and
   denial of location-based services.  While these risks have special
   importance in the context of emergency calling, they apply broadly to
   the GEOPRIV architecture as a whole.

2.1.  Disclosure of Location Information

   The most immediate threat to location information is the disclosure
   of sensitive location information to unauthorized parties.  In
   particular, this allows an eavesdropper to circumvent any privacy
   rules that are supposed to govern the use of a LO.  Such disclosure
   could occur in either of the following ways:

   o  An attacker located on the path of communication to a legitimate
      location recipient may intercept a LO and extract sensitive
      location information.  For example, an attacker could be a
      compromised router on the public internet who scans incoming
      packets for insecure LOs.  Alternatively, such an attacker could
      be a compromised proxy server for some location-using protocol
      such as SIP

   o  An attacker may impersonate a legitimate location recipient in
      order to obtain a LO from location server.  For example, an
      attacker could attack the LoST service to cause legitimate users
      to send LOs to an attacker-controlled URI.  Alternatively, an
      attacker could supply forged credentials to a location server to
      request a LO stored on the server.

   This threat is discussed in [Geopriv-Threats], Section 4.1.1 as well
   as [Geopriv-L7], Section 10.2.  In the setting of emergency services,
   this threat is especially pertinent because the requester of
   emergency services is often in a vulnerable position and hence
   location information is particularly sensitive.  For example, a
   motorist injured in an accident on a deserted highway is an easy
   target for robbery.  The disclosure of location information in the
   event of an emergency is discussed in Security Threats and
   Requirements for Emergency Call Marking and Mapping [Ecrit-Threats]
   Section 5.2.3.

2.2.  Use of Fake Location Information

   A second threat to location information is the ability of an attacker
   to create LOs that contain false location information, i.e., a
   location that does not correspond to a target's true location.  There
   are several scenarios in which this might be accomplished:

Barnes, et al.           Expires April 27, 2007                 [Page 4]

Internet-Draft           Secure Location Objects            October 2006

   o  An attacker could replay location information corresponding to the
      attacker's true location at an earlier point in time.  For
      example, an attacker who visits New York City in January could
      obtain a legitimate LO indicating his location in New York.  The
      attacker could then use this previously obtained LO to claim he is
      in New York the following summer.

   o  An attacker could replay location information corresponding to
      another target's location at an earlier point in time.  For
      example, an attacker who has never been to New York City may
      obtain a legitimate LO that indicates that Alice is in New York
      City.  The attacker could then later use this LO to claim that he
      is in New York.  Note that this attack may or not require the
      attacker to be able to extract information from the LO.

   o  An attacker could from scratch generate a forged LO corresponding
      to an arbitrary location.  For example, an attacker could forge a
      LO indicating that he is in New York City.  The attacker could
      then pass this LO off as legitimate and claim he is in New York
      even though he doesn't know of anyone who has been there.

   An extensive discussion of this threat appears in [Geopriv-L7],
   Section 8.  The threat is also discussed in also discussed in
   [Geopriv-Threats] Section 4.1.2.  In the setting of emergency
   services, this threat is especially pertinent because fake location
   information can be used to force scarce emergency-response resources
   to be improperly allocated.  For example, in the event of a disaster,
   when the demand for emergency services exceeds supply, an attacker
   using a fake location could cause an ambulance to be sent to a
   location where no one is present.  Even worse, an attacker could
   generate huge numbers of emergency phone calls from all over the
   world that all claim to be from a particular city.  Such an attack
   could easily overwhelm the public safety access point and deny
   emergency services to legitimate residents of the city.  The use of
   fake location information as it pertains to emergency services is
   discussed briefly in [Ecrit-Threats] Section 5.2.3.

2.3.  Denial of Location-based Services

   In a similar vein, an attacker could deny location-based services to
   an individual with legitimate need for these services.  In the
   current, unsecured architecture, this could occur in several ways:

   o  As discussed in Section 2.2, an attacker can deny access to
      location-based services by using forged location information to
      overwhelm location-based services for a particular location.

Barnes, et al.           Expires April 27, 2007                 [Page 5]

Internet-Draft           Secure Location Objects            October 2006

   o  An attacker could alter a location object to indicate an incorrect
      location of a target.  For example, when a legitimate user
      attempts to access a location-based service, an attacker on the
      path of communication may alter the location object to cause the
      request to be routed to the wrong service provider.

   o  An attacker could prevent a location recipient from obtaining a
      location information.  For example, an attacker might prevent a
      service provider from dereferencing a reference to a location
      object making it difficult for the user to receive location-
      appropriate services.

   This threat is discussed in the context of emergency services in
   [Ecrit-Threats] Section 5.2.2, but is equally applicable to other
   uses of the GEOPRIV architecture.

3.  Design Considerations

   In addition to the security objectives discussed in Section 2 above,
   there are several other constraints on the design of SLOs.  In
   general, use of SLOs must be compatible with other GEOPRIV and ECRIT
   protocols and architectures, with minimal modifications to either.
   One particular issue that is likely to arise is that in several
   possible SLO designs, the user (e.g., a UAC in the SIP model) may not
   have access to his own location (by value).

3.1.  Integration with LoST

   Currently, many of the proposed use cases for the Location-to-Service
   Translation Protocol (LoST [LoST]) assume that the UAC has access to
   its own location.  For instance:

   o  As currently defined, a LoST query includes the location of the
      target in GML.  In the case that the UAC is both the target of the
      query and the originator of the query, this means that the UAC
      must have access to its own location.

   o  LoST responses typically contain a service boundary so that a UAC
      can determine when it has left the region in which its current
      PSAP URI is valid, and thus must query the LoST server again.
      Such a boundary is useful only if the UAC is aware of its own
      location.

   A security architecture in which a UAC may not know its own location,
   may necessitate revisions to the way that LoST is used.  For
   instance, access networks or VoIP providers may need to provide LoST
   proxies that have access to location information.

Barnes, et al.           Expires April 27, 2007                 [Page 6]

Internet-Draft           Secure Location Objects            October 2006

3.2.  GEOPRIV Considerations

   It is as yet unclear which communications in the GEOPRIV architecture
   can or should make use of SLOs when exchanging location data.  The
   areas of application likely will be determined by the number of each
   GEOPRIV entity and the contractual, regulatory, or other trust
   relationships among them; these considerations also will affect the
   trust model underlying a SLO design.  In addition, the functions
   required of each entity in the GEOPRIV architecture will dictate
   certain levels of access, and SLOs must accommodate these
   requirements.  For instance, since the GEOPRIV architecture specifies
   that privacy rules are applied by a Location Server, use of SLOs must
   not preclude the Location Server from having sufficient knowledge of
   location information to apply these rules.

3.3.  ECRIT Considerations

   A critical usage of GEOPRIV location objects is in emergency
   services, both for routing emergency calls to the correct PSAP and
   for directing emergency services to the location of the emergency.
   In such situations, it is essential that all relevant location
   information be available to all emergency responders that require it.
   When adding confidentiality features to a location object, therefore,
   appropriate failover mechanisms must be available.

3.4.  Technical Considerations

   User devices that are expected to handle location objects are
   becoming increasingly mobile.  In the context of SIP, this will be
   especially true as SIP is applied within cellular wireless networks.
   In order to facilitate the use of SLOs by these devices, an SLO
   design should be adaptable for use in an environment where there are
   constraints on both the processing power and bandwidth available to
   user devices.  SLOs are generally amenable to such environments,
   since they require no cryptographic operations to be performed in
   order to store or transmit them securely, and, at least when
   expressed as locations by reference, can consume very little
   bandwidth and storage space.

4.  Candidate Secure Location Object Formats

   Following the convention of SIP Location Conveyance [SIPLocation], we
   broadly divide the category of SLOs (objects that can be transmitted
   while still maintaining certain security properties) into those based
   on location by value and those based on location by reference.  We
   then discuss candidate SLOs in both categories and discuss the
   properties of a trust model relied upon by any SLO.  Note, however,

Barnes, et al.           Expires April 27, 2007                 [Page 7]

Internet-Draft           Secure Location Objects            October 2006

   that in spite of this division, these two types of SLO can be
   naturally combined, for instance multi-layer access control could be
   achieved by using a secured location reference to refer to a secured
   location value.

4.1.  Location By Value

   Conveyance of location by value is the act of transmitting an entire
   LO, rather than a reference to it.  Security properties can be added
   to such a location object by either signing the location object,
   encrypting it, or both, using a technology such as S/MIME or XMLDsig.
   Each type of object -- signed, encrypted, or both -- has a different
   set of security properties, discussed below.

   Although we separately discuss the signing and encrypting of LOs, it
   is natural to consider combining the two approaches.  This raises the
   question of whether a LO should be first signed and then encrypted,
   or vice-versa.  We therefore briefly discuss the advantages of both
   approaches.

   o  In settings where denial of service attacks are likely, signing an
      already encrypted LO is advantageous because a recipient of such
      LOs can quickly discard LOs with invalid signatures without
      needing to spend resources decrypting the object.  Additionally,
      in settings where some fields of the LO should be encrypted and
      other fields should be left unencrypted, it is advantageous to
      sign the entire LO after the private fields have been encrypted.

   o  The use of objects that are first signed and then encrypted
      requires less work on the part of the location producer.  Indeed,
      a location producer may produce a single signed object which can
      then be encrypted, by a separate party, for delivery to multiple
      recipients.  Similarly, the recipient of such an LO can re-encrypt
      the signed object for delivery to a new recipient without the
      involvement of the location producer.  Additionally, in settings
      where different portions of an LO should be signed by different
      entities, it is advantageous to first sign and then encrypt the
      LO.

4.1.1.  Signed Location

   A "signed location" SLO consists of a LO together with a signature of
   some or all of the LO by a recognized authority, likely a Location
   Server or Location Generator.  Use of a signed location SLO has the
   following security implications:

   o  Perhaps most importantly, use of a signed location SLO mitigates
      all of the threats in Section 2.2 arising from the use of forged

Barnes, et al.           Expires April 27, 2007                 [Page 8]

Internet-Draft           Secure Location Objects            October 2006

      location information.  An attacker who is not an authorized signer
      in the underlying trust model is unable to create fake location
      objects.  In particular, this prevents an attacker from claiming
      he is at a distant location.  Additionally, if a timestamp is
      included in the signed object, an attacker cannot replay a
      previously obtained location object (either his own or someone
      else's).

   o  Use of a signed location SLO partially mitigates the threats in
      Section 2.3 regarding denial of service.  An attacker on the
      communication path between a user and a location-based service
      provider cannot alter the location object in transit to make it
      appear that the user is at a distant location.  Obviously, certain
      attackers on the communication path can always deny service to an
      individual by dropping the individual's request.  However, an
      attack that drops the entire request is simpler to detect and
      respond to an attack that alters the location, since when a
      request is dropped the user finds out immediately (as soon as the
      time-out fails) but if a location is altered it is unclear how
      long it will take to determine that a problem has occurred.

   Naturally, the security properties granted by use of signed location
   SLOs fundamentally rely on a suitable trust model; as discussed in
   section 4.3, development of this trust model is a nontrivial but
   tractable problem.  In order for signed location to be useful, it
   must be difficult for an attacker to compromise an authorized signer
   of location information.  When signed location SLOs are used, it is
   the responsibility of the using protocol to take appropriate action
   when the signature fails to verify.  For example, in most cases, a
   signed SLO with an invalid signature might be discarded altogether,
   but in the special case of emergency services, a call with a location
   signature that fails to verify might be answered but given lower
   priority than calls with valid SLOs.

4.1.2.  Encrypted Location

   An "encrypted location" SLO is a LO encrypted in such a way that it
   is readable only by its intended recipient(s).  Use of an encrypted
   location SLO has the following security implications:

   o  Use of an encrypted location SLO mitigates all of the threats in
      Section 2.1 arising from improper disclosure of location
      information.  Unless the attacker is able to compromise the secret
      decryption key of the intended location recipient, it is
      infeasible for him to extract information from any encrypted
      location SLO he might obtain.  Therefore, even if the attacker is
      able, for example, to compromise a proxy on the communication path
      to a location recipient the sensitive location information

Barnes, et al.           Expires April 27, 2007                 [Page 9]

Internet-Draft           Secure Location Objects            October 2006

      contained in the SLO remains private.

   o  Use of an encrypted location SLO only partially mitigates the
      threats in Section 2.2 regarding forgery of location information.
      Depending on the key distribution architecture, it may be possible
      for an attacker to obtain the encryption key of a legitimate
      location recipient and forge an encrypted location SLO.  Of
      course, these threats can be mitigated (as described in Section
      4.1.1) by combining signing and encrypting of location objects.
      On the other hand, because an eavesdropper does not have access to
      the information contained in an encrypted location SLO, it is very
      difficult for him to modify the location in transit.

   o  Use of an encrypted location SLO can pose additional risks
      regarding the denial of service threats discussed in Section 2.3.
      In particular, use of an encrypted location SLO introduces the
      possibility that a user is denied a service because the service
      provider cannot decrypt the SLO to extract LI.  This could occur
      because of a key-management error, or because of an attack on the
      mechanism used to distribute public keys.

   The use of encrypted location SLOs relies fundamentally on a reliable
   mechanism to distribute the keys belonging to legitimate service
   providers; the difficulty of this task will derive from the
   underlying trust model.  In the context of emergency services, for
   example, one might use the LoST protocol to return a certificate for
   a PSAP in addition to the PSAP's URI.  This reduces the incremental
   risk of using encryption, since an attacker who is able to use LoST
   to distribute incorrect public keys can surely disrupt emergency
   services in other ways.

   One often-mentioned advantage of location-by-reference is that the
   required dereference operation creates an opportunity for location
   providers to enforce a scheme in which the party dereferencing the
   URL pays the provider for the location.  A secondary advantage of
   encrypted location SLOs is that they can be used to extend this model
   to location by value: The encrypted location object can be
   transmitted to the location recipient, but encrypted in such a way
   that the SLO cannot be used by the recipient until he performs a
   second decryption or key exchange transaction with the location
   provider.  However, just as the by-reference payment scheme is viable
   only if a user cannot dereference a URL to obtain his own location,
   this model forces a transaction only if a user cannot decrypt an
   encrypted location SLO containing his location.  While this may force
   some adaptation of existing protocols (as discussed in Section 3), it
   seems that use of encrypted location SLOs for this purpose is still
   consistent with broader usage.  For example, LoST servers could be
   operated by entities that maintain business relationships with

Barnes, et al.           Expires April 27, 2007                [Page 10]

Internet-Draft           Secure Location Objects            October 2006

   location providers, so that encrypted location SLOs included in LoST
   queries could be decrypted.

4.2.  Location By Reference

   Conveyance of location by reference is the act of transmitting not an
   object containing LI, but rather a URL (or other pointer) that can be
   dereferenced to obtain a LO.  Location URLs have several important
   security implications:

   o  Perhaps most importantly, use of location by reference forces a
      location recipient to conduct a separate transaction in order to
      obtain the desired LI, which has the effect of allowing any
      security decisions to be delayed until the time when a location
      URL is dereferenced.  This property allows much more complicated
      security and privacy policies to be enforced at the location
      server (such as rules about location expiration and
      retransmission), rather than delegating trust to using protocols.
      At the same time, however, it also lends itself very naturally to
      failover, since the location server can make a decision to grant
      access to parties that can demonstrate a need and authority for
      access, such as emergency service providers.

   o  Because a location URL references a resource held by a third party
      (commonly, a location server), not by the location target or
      location recipient, location references cannot be constructed by a
      user, but rather must be obtained from an location server.  This
      yields very powerful anti-forgery (hence anti-spam) properties,
      since a user cannot forge a location URL that references LI
      indicating that he is elsewhere than he is, and likewise, a third
      party (e.g., a man in the middle) cannot modify a URL to deny
      location-based services.

   We call a location reference that employs one or more security
   protocols in its dereference a secured location reference.  Any
   security protocols used in conjunction with location references will
   be reliant on a suitable trust model; as discussed in section 4.3,
   development of this trust model seems to be a nontrivial, but
   tractable problem.  In order for secured location references to be
   suitable for use in emergency services, the dereferencing protocol
   and any security protocols employed between the recipient and the
   location server must be made sufficiently reliable for use in an
   emergency.  As is the case with normal, unsecured location
   references, the most significant risk is introduced by the
   dereferencing protocol, since the location server is capable of
   granting access to LI independent of security policies and protocols.

Barnes, et al.           Expires April 27, 2007                [Page 11]

Internet-Draft           Secure Location Objects            October 2006

4.3.  Trust Models

   Any SLO system will be based on an underlying trust model.  The
   structure of this model deeply influences the nature of the security
   guarantees that the SLO system can provide.  Such guarantees include:

   o  Authentication of location recipients: Use of SLOs offers another
      mechanism for authenticating identities referenced by privacy
      rules.  Using secure location by value, objects can be encrypted
      for a specific recipient, and using secure location by reference,
      a location server can interpret a cryptographic credential to
      grant or deny access to specific recipients.  In particular,
      emergency service providers could be unambiguously identified by
      their credentials to be assured access to the LI they require.

   o  Authentication and integrity of location information: In the PSTN,
      location information is provided by wireline or wireless
      operators, and thus assumed by all using parties to be reliable.
      Use of location signing in secure location objects provides a
      mechanism to translate these assurances to IP-based telephony and
      other location-based Internet services.

   o  Non-repudiation of location information: By the same token as
      above, the current PSTN architecture allows failures of the
      location architecture to be clearly attributed to the provider of
      faulty LI, for purposes of determining regulatory or civil
      liability.  For location-based services over IP, particularly
      emergency services, this is an important function that can be
      enabled by secure location objects.

   These features require the identification and issuance of credentials
   for two classes of entities: Location producers and location
   consumers.  The case of location consumers seems to be the simpler,
   if we envision two major use cases, (1) emergency services calling,
   and (2) client-server style location-based services.  In the former
   case, the set of PSAPs and emergency service providers is small and
   stable enough to be manageable.  In some cases, even further
   simplification will be possible: In the NENA i3 architecture, for
   example, one might need to manage credentials only for gateways
   between emergency services networks and the Internet.  For other
   client-server location-based services, there are several current
   trust models that could be adapted, such as the broad, flat PKI model
   used by HTTPS or the more flexible model used in DNSSEC.

   Constructing a system for authenticating location producers is more
   difficult.  For example, an organization that administers a corporate
   network of SIP-based desk phones might provision these phones with
   fine-grained location information, such as their floor and room

Barnes, et al.           Expires April 27, 2007                [Page 12]

Internet-Draft           Secure Location Objects            October 2006

   number.  By some calculations [ref:Henning], in New York City alone
   there are thousands of organizations that might be expected to do
   become location producers in this way, several of which appear and
   disappear each day.  On the other hand, such location producers need
   only be included in a trust model if the goal of this trust model is
   to provide guarantees stronger than are offered by the PSTN.  An
   initial capability to provide PSTN-equivalent security would require
   only the inclusion of telecommunications and internet service
   providers; construction of a PKI on the scale of the former is
   already being under taken by the SIDR working group and the Regional
   Internet Registries.  In addition, many VoIP providers currently
   outsource location determination functions to other entities, which
   further consolidates the set of location producers.  Note also that
   although we have treated here the specific example of location for
   VoIP, the same access networks that provide location for these
   services will be used to access other location-based services, so a
   trust model for location producers in a VoIP setting would be
   extensible to a model for more general location-based services.

5.  Conclusions

   The purpose of this document is to start a discussion about the
   requirements of GEOPRIV and ECRIT for security in location objects.
   Clearly, it is tempting to push responsibility for security onto the
   protocols that carry LOs and the using protocols that process them.
   Currently, however, these protocols are unable to provide the end-to-
   end security guarantees necessary to mitigate threats to the privacy
   of location information and the integrity of location-based services.
   Without securing the location object itself, entities that generate
   LOs have no assurances that the LOs will not be misused, and critical
   applications such as emergency services have no assurances that the
   LOs they receive have not been forged or otherwise tampered with.

   In this document, we considered three approaches to securing LOs.
   Signing a location object can prevent forgery and mitigate resulting
   denial of service attacks.  Encrypting location objects can prevent
   the improper disclosure of location information, but encryption
   results in an opaque location object that may require adaptation of
   using protocols.  Using location by reference in conjunction with a
   secure dereferencing transaction can prevent both forgery and
   improper disclosure of location information.  However, obtaining
   location information from a location-by-reference object requires an
   additional transaction that could introduce additional risk in time-
   critical applications such as emergency services.  Naturally, these
   techniques for securing location objects can be combined to obtain
   stronger security guarantees or increased robustness.  For example, a
   location reference could be appended to a signed and encrypted

Barnes, et al.           Expires April 27, 2007                [Page 13]

Internet-Draft           Secure Location Objects            October 2006

   location object to obtain the security guarantees of location-by-
   reference and yet require a separate de-referencing transaction only
   in the event that decryption fails.  Achieving security through any
   of these mechanisms will require an appropriate trust model.

6.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.

7.  Security Considerations

   The focus of this document is security; hence security considerations
   permeate this specification.

8.  Acknowledgements

9.  References

9.1.  Normative References

   [RFC2119]  "", 2005.

9.2.  Informative References

   [Ecrit-Threats]
              Nortel, Siemens, Columbia University, and Siemens,
              "Security Threats and Requirements for Emergency Call
              Marking and Mapping", July 2006.

   [Geopriv-L7]
              Siemens Networks and Columbia University, "Geopriv Layer 7
              Location Configuration Protocol; Problem Statement and
              Requirements", October 2006.

   [Geopriv-Threats]
              Technology and Public Policy Clinic, Technology and Public
              Policy Clinic, Center for Democracy and Technology, and
              NeuStar, "Threat Analysis of the Geopriv Protocol",
              February 2004.

   [LoST]     Qualcomm, Inc., SunRocket, Columbia University, and

Barnes, et al.           Expires April 27, 2007                [Page 14]

Internet-Draft           Secure Location Objects            October 2006

              Siemens, "LoST: A Location-to-Service Translation
              Protocol", September 2006.

   [RFC3693]  Siemens AG, Center for Democracy and Technology,
              Technology and Public Policy Clinic, NeuStar, and Cisco,
              "Geopriv Requirements", February 2004.

   [SIPLocation]
              Qualcomm, Inc. and SunRocket, "Session Initiation Protocol
              Location Conveyance", October 2006.

Authors' Addresses

   Richard Barnes
   BBN Technologies
   9861 Broken Land Pkwy
   Columbia, Maryland  21046
   USA

   Phone: +1-410-290-6169
   Email: [email-masked]

   Matt Lepinski
   BBN Technologies
   10 Moulton St.
   Cambridge, Massachusetts  02138
   USA

   Phone: +1-617-873-5939
   Email: [email-masked]

   Ron Watro
   BBN Technologies
   10 Moulton St.
   Cambridge, Massachusetts  02138
   USA

   Phone: +1-617-873-2551
   Email: [email-masked]

Barnes, et al.           Expires April 27, 2007                [Page 15]

Internet-Draft           Secure Location Objects            October 2006

Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   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 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
   [email-masked].

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Barnes, et al.           Expires April 27, 2007                [Page 16]

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 4 Nov 2006 16:09:19 -0500

Richard,

your author group may benefit from perusing the ECRIT and GEOPRIV  
mailing list archives, as they discuss many of these issues in depth.  
Unfortunately, issues such as what it means to sign a location (how  
can the receiver tell who can legitimately sign for an unknown user's  
location?) do not seem to be reflected in your draft. Given the long  
and contentious debates on these topics, it would seem helpful to  
avoid having them again, so I think you could do the working groups a  
favor by reflecting those discussions in your draft. If you're able  
to summarize and reflect on those issues, your draft could be  
potentially useful to move the discussion forward, rather than just  
having the same discussion again.

Many of these items are already discussed in the L7 and conveyance  
document, so it might be useful to reduce the overlap.

Henning

On Nov 3, 2006, at 6:41 PM, Richard L. Barnes wrote:

> architecture has gotten a lot of discussion, so we wanted to  
> examine some ways that security features might be embedded in  
> location objects.
>
>                                                         October 24,  
> 2006

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 06 Nov 2006 09:52:45 -0800

Henning,

You're certainly right that we don't need to revisit the arguments that 
have gone on about location signing (and other security issues).  In 
this draft, I think we were hoping to sidestep some of that by treating 
mechanisms for security separately from the underlying trust models.  
That is, this draft is trying to examine the tradeoffs of various 
security mechanisms, and their performance against security threats in 
current GEOPRIV and ECRIT documents -- independent of the trust model 
and associated semantics.

I agree that the trust model that supports GEOPRIV security is a 
complicated and difficult question, and one we should elaborate on more 
in our next draft.   We will try to incorporate the prior ECRIT and 
GEOPRIV discussions, in addition to the current documents.  However, we 
should bear in mind that the selection of a trust model is a separate 
and independent problem from defining formats and mechanisms that might 
rely on such a trust model.

Thanks,
--Richard

Henning Schulzrinne wrote:
> favor by reflecting those discussions in your draft. If you're able to 
> summarize and reflect on those issues, your draft could be potentially 
> useful to move the discussion forward, rather than just having the 
> same discussion again.
>