doc: Add RFC documents

1 files changed, 1739 insertions, 0 deletions

diff --git a/doc/rfc/rfc7378.txt b/doc/rfc/rfc7378.txt
new file mode 100644
index 0000000..a903c5e
--- /dev/null
+++ b/doc/rfc/rfc7378.txt
@@ -0,0 +1,1739 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                     H. Tschofenig
+Request for Comments: 7378                                   Independent
+Category: Informational                                   H. Schulzrinne
+ISSN: 2070-1721                                      Columbia University
+                                                           B. Aboba, Ed.
+                                                   Microsoft Corporation
+                                                           December 2014
+
+
+                          Trustworthy Location
+
+Abstract
+
+   The trustworthiness of location information is critically important
+   for some location-based applications, such as emergency calling or
+   roadside assistance.
+
+   This document describes threats to conveying location, particularly
+   for emergency calls, and describes techniques that improve the
+   reliability and security of location information.  It also provides
+   guidelines for assessing the trustworthiness of location information.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   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).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see 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/rfc7378.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tschofenig, et al.            Informational                     [Page 1]
+
+RFC 7378                  Trustworthy Location             December 2014
+
+
+Copyright Notice
+
+   Copyright (c) 2014 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.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Terminology ................................................3
+      1.2. Emergency Services Architecture ............................5
+   2. Threat Models ...................................................8
+      2.1. Existing Work ..............................................8
+      2.2. Adversary Model ............................................9
+      2.3. Location Spoofing .........................................10
+      2.4. Identity Spoofing .........................................11
+   3. Mitigation Techniques ..........................................11
+      3.1. Signed Location-by-Value ..................................12
+      3.2. Location-by-Reference .....................................15
+      3.3. Proxy-Added Location ......................................18
+   4. Location Trust Assessment ......................................20
+   5. Security Considerations ........................................23
+   6. Privacy Considerations .........................................24
+   7. Informative References .........................................26
+   Acknowledgments ...................................................30
+   Authors' Addresses ................................................30
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tschofenig, et al.            Informational                     [Page 2]
+
+RFC 7378                  Trustworthy Location             December 2014
+
+
+1.  Introduction
+
+   Several public and commercial services need location information to
+   operate.  This includes emergency services (such as fire, ambulance,
+   and police) as well as commercial services such as food delivery and
+   roadside assistance.
+
+   For circuit-switched calls from landlines, as well as for Voice over
+   IP (VoIP) services that only support emergency service calls from
+   stationary Devices, location provided to the Public Safety Answering
+   Point (PSAP) is determined from a lookup using the calling telephone
+   number.  As a result, for landlines or stationary VoIP, spoofing of
+   caller identification can result in the PSAP incorrectly determining
+   the caller's location.  Problems relating to calling party number and
+   Caller ID assurance have been analyzed by the Secure Telephone
+   Identity Revisited [STIR] working group as described in "Secure
+   Telephone Identity Problem Statement and Requirements" [RFC7340].  In
+   addition to the work underway in STIR, other mechanisms exist for
+   validating caller identification.  For example, as noted in [EENA],
+   one mechanism for validating caller identification information (as
+   well as the existence of an emergency) is for the PSAP to call the
+   user back, as described in [RFC7090].
+
+   Given the existing work on caller identification, this document
+   focuses on the additional threats that are introduced by the support
+   of IP-based emergency services in nomadic and mobile Devices, in
+   which location may be conveyed to the PSAP within the emergency call.
+   Ideally, a call taker at a PSAP should be able to assess, in real
+   time, the level of trust that can be placed on the information
+   provided within a call.  This includes automated location conveyed
+   along with the call and location information communicated by the
+   caller, as well as identity information relating to the caller or the
+   Device initiating the call.  Where real-time assessment is not
+   possible, it is important to be able to determine the source of the
+   call in a post-incident investigation, so as to be able to enforce
+   accountability.
+
+   This document defines terminology (including the meaning of
+   "trustworthy location") in Section 1.1, reviews existing work in
+   Section 1.2, describes threat models in Section 2, outlines potential
+   mitigation techniques in Section 3, covers trust assessment in
+   Section 4, and discusses security considerations in Section 5.
+
+1.1.  Terminology
+
+   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 [RFC2119].
+
+
+
+Tschofenig, et al.            Informational                     [Page 3]
+
+RFC 7378                  Trustworthy Location             December 2014
+
+
+   We use the definitions of "Internet Access Provider (IAP)", "Internet
+   Service Provider (ISP)", and "Voice Service Provider (VSP)" found in
+   "Requirements for Emergency Context Resolution with Internet
+   Technologies" [RFC5012].
+
+   [EENA] defines a "hoax call" as follows: "A false or malicious call
+   is when a person deliberately telephones the emergency services and
+   tells them there is an emergency when there is not."
+
+   The definitions of "Device", "Target", and "Location Information
+   Server" (LIS) are taken from "An Architecture for Location and
+   Location Privacy in Internet Applications" [RFC6280], Section 7.
+
+   The term "Device" denotes the physical device, such as a mobile
+   phone, PC, or embedded microcontroller, whose location is tracked as
+   a proxy for the location of a Target.
+
+   The term "Target" denotes an individual or other entity whose
+   location is sought in the Geopriv architecture [RFC6280].  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 the architecture described in
+   [RFC6280] seeks to protect.
+
+   The term "Location Information Server" denotes 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.
+
+   The term "location determination method" refers to the mechanism used
+   to determine the location of a Target.  This may be something
+   employed by a LIS or by the Target itself.  It specifically does not
+   refer to the location configuration protocol (LCP) used to deliver
+   location information to either the Target or the Recipient.  This
+   term is reused from "GEOPRIV Presence Information Data Format
+   Location Object (PIDF-LO) Usage Clarification, Considerations, and
+   Recommendations" [RFC5491].
+
+   The term "source" is used to refer to the LIS, node, or Device from
+   which a Recipient (Target or third party) obtains location
+   information.
+
+
+
+
+
+
+
+
+Tschofenig, et al.            Informational                     [Page 4]
+
+RFC 7378                  Trustworthy Location             December 2014
+
+
+   Additionally, the terms "location-by-value" (LbyV), "location-by-
+   reference" (LbyR), "Location Configuration Protocol", "Location
+   Dereference Protocol", and "Location Uniform Resource Identifier"
+   (URI) are reused from "Requirements for a Location-by-Reference
+   Mechanism" [RFC5808].
+
+   "Trustworthy Location" is defined as location information that can be
+   attributed to a trusted source, has been protected against
+   modification in transmit, and has been assessed as trustworthy.
+
+   "Location Trust Assessment" refers to the process by which the
+   reliability of location information can be assessed.  This topic is
+   discussed in Section 4.
+
+   "Identity Spoofing" occurs when the attacker forges or obscures their
+   identity so as to prevent themselves from being identified as the
+   source of the attack.  One class of identity spoofing attack involves
+   the forging of call origin identification.
+
+   The following additional terms apply to location spoofing
+   (Section 2.3):
+
+   With "Place Shifting", attackers construct a Presence Information
+   Data Format Location Object (PIDF-LO) for a location other than where
+   they are currently located.  In some cases, place shifting can be
+   limited in range (e.g., within the coverage area of a particular cell
+   tower).
+
+   "Time Shifting" occurs when the attacker uses or reuses location
+   information that was valid in the past but is no longer valid because
+   the attacker has moved.
+
+   "Location Theft" occurs when the attacker captures a Target's
+   location information (possibly including a signature) and presents it
+   as their own.  Location theft can occur in a single instance or may
+   be continuous (e.g., where the attacker has gained control over the
+   victim's Device).  Location theft may also be combined with time
+   shifting to present someone else's location information after the
+   original Target has moved.
+
+1.2.  Emergency Services Architecture
+
+   This section describes how location is utilized in the Internet
+   Emergency Services Architecture, as well as the existing work on the
+   problem of hoax calls.
+
+
+
+
+
+
+Tschofenig, et al.            Informational                     [Page 5]
+
+RFC 7378                  Trustworthy Location             December 2014
+
+
+1.2.1.  Location
+
+   The Internet architecture for emergency calling is described in
+   "Framework for Emergency Calling Using Internet Multimedia"
+   [RFC6443].  Best practices for utilizing the architecture to make
+   emergency calls are described in "Best Current Practice for
+   Communications Services in Support of Emergency Calling" [RFC6881].
+
+   As noted in "An Architecture for Location and Location Privacy in
+   Internet Applications" [RFC6280], Section 6.3:
+
+      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 conveyance of location information within the Session Initiation
+   Protocol (SIP) is described in "Location Conveyance for the Session
+   Initiation Protocol" [RFC6442].  Conveyance of location-by-value
+   (LbyV) as well as conveyance of location-by-reference (LbyR) are
+   supported.  Section 7 of [RFC6442] ("Security Considerations")
+   discusses privacy, authentication, and integrity concerns relating to
+   conveyed location.  This includes discussion of transmission-layer
+   security for confidentiality and integrity protection of SIP, as well
+   as (undeployed) end-to-end security mechanisms for protection of
+   location information (e.g., S/MIME).  Regardless of whether
+   transmission-layer security is utilized, location information may be
+   available for inspection by an intermediary that -- if it decides
+   that the location value is unacceptable or insufficiently accurate --
+   may send an error indication or replace the location, as described in
+   [RFC6442], Section 3.4.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tschofenig, et al.            Informational                     [Page 6]
+
+RFC 7378                  Trustworthy Location             December 2014
+
+
+   Although the infrastructure for location-based routing described in
+   [RFC6443] was developed for use in emergency services, [RFC6442]
+   supports conveyance of location within non-emergency calls as well as
+   emergency calls.  Section 1 of "Implications of 'retransmission-
+   allowed' for SIP Location Conveyance" [RFC5606] describes the overall
+   architecture, as well as non-emergency usage scenarios (note: the
+   [LOC-CONVEY] citation in the quote below refers to the document later
+   published as [RFC6442]):
+
+      The Presence Information Data Format for Location Objects (PIDF-LO
+      [RFC4119]) carries both location information (LI) and policy
+      information set by the Rule Maker, as is stipulated in [RFC3693].
+      The policy carried along with LI allows the Rule Maker to
+      restrict, among other things, the duration for which LI will be
+      retained by recipients and the redistribution of LI by recipients.
+
+      The Session Initiation Protocol [RFC3261] is one proposed Using
+      Protocol for PIDF-LO.  The conveyance of PIDF-LO within SIP is
+      specified in [LOC-CONVEY].  The common motivation for providing LI
+      in SIP is to allow location to be considered in routing the SIP
+      message.  One example use case would be emergency services, in
+      which the location will be used by dispatchers to direct the
+      response.  Another use case might be providing location to be used
+      by services associated with the SIP session; a location associated
+      with a call to a taxi service, for example, might be used to route
+      to a local franchisee of a national service and also to route the
+      taxi to pick up the caller.
+
+1.2.2.  Hoax Calls
+
+   Hoax calls have been a problem for emergency services dating back to
+   the time of street corner call boxes.  As the European Emergency
+   Number Association (EENA) has noted [EENA]:
+
+      False emergency calls divert emergency services away from people
+      who may be in life-threatening situations and who need urgent
+      help.  This can mean the difference between life and death for
+      someone in trouble.
+
+   EENA [EENA] has attempted to define terminology and describe best
+   current practices for dealing with false emergency calls.  Reducing
+   the number of hoax calls represents a challenge, since emergency
+   services authorities in most countries are required to answer every
+   call (whenever possible).  Where the caller cannot be identified, the
+   ability to prosecute is limited.
+
+
+
+
+
+
+Tschofenig, et al.            Informational                     [Page 7]
+
+RFC 7378                  Trustworthy Location             December 2014
+
+
+   A particularly dangerous form of hoax call is "swatting" -- a hoax
+   emergency call that draws a response from law enforcement prepared
+   for a violent confrontation (e.g., a fake hostage situation that
+   results in the dispatching of a "Special Weapons And Tactics" (SWAT)
+   team).  In 2008, the Federal Bureau of Investigation (FBI) issued a
+   warning [Swatting] about an increase in the frequency and
+   sophistication of these attacks.
+
+   Many documented cases of "swatting" (also sometimes referred to as
+   "SWATing") involve not only the faking of an emergency but also
+   falsification or obfuscation of identity [Swatting] [SWATing].  There
+   are a number of techniques by which hoax callers attempt to avoid
+   identification, and in general, the ability to identify the caller
+   appears to influence the incidence of hoax calls.
+
+   Where a Voice Service Provider allows the caller to configure its
+   outbound caller identification without checking it against the
+   authenticated identity, forging caller identification is trivial.
+   Similarly, where an attacker can gain entry to a Private Branch
+   Exchange (PBX), they can then subsequently use that access to launch
+   a denial-of-service attack against the PSAP or make fraudulent
+   emergency calls.  Where emergency calls have been allowed from
+   handsets lacking a subscriber identification module (SIM) card,
+   so-called non-service initialized (NSI) handsets, or where ownership
+   of the SIM card cannot be determined, the frequency of hoax calls has
+   often been unacceptably high [TASMANIA] [UK] [SA].
+
+   However, there are few documented cases of hoax calls that have
+   arisen from conveyance of untrustworthy location information within
+   an emergency call, which is the focus of this document.
+
+2.  Threat Models
+
+   This section reviews existing analyses of the security of emergency
+   services, threats to geographic location privacy, threats relating to
+   spoofing of caller identification, and threats related to
+   modification of location information in transit.  In addition, the
+   threat model applying to this work is described.
+
+2.1.  Existing Work
+
+   "An Architecture for Location and Location Privacy in Internet
+   Applications" [RFC6280] 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.
+
+
+
+
+
+Tschofenig, et al.            Informational                     [Page 8]
+
+RFC 7378                  Trustworthy Location             December 2014
+
+
+   In Section 5 of [RFC6280] ("An Architecture for Location and Location
+   Privacy in Internet Applications"), mechanisms for ensuring the
+   security of the location distribution chain are discussed; these
+   include mechanisms for hop-by-hop confidentiality and integrity
+   protection as well as end-to-end assurance.
+
+   "Geopriv Requirements" [RFC3693] focuses on the authorization,
+   security, and privacy requirements of location-dependent services,
+   including emergency services.  Section 8 of [RFC3693] includes
+   discussion of emergency services authentication (Section 8.3), and
+   issues relating to identity and anonymity (Section 8.4).
+
+   "Threat Analysis of the Geopriv Protocol" [RFC3694] describes threats
+   against geographic location privacy, including protocol threats,
+   threats resulting from the storage of geographic location data, and
+   threats posed by the abuse of information.
+
+   "Security Threats and Requirements for Emergency Call Marking and
+   Mapping" [RFC5069] reviews security threats associated with the
+   marking of signaling messages and the process of mapping locations to
+   Universal Resource Identifiers (URIs) that point to PSAPs.  RFC 5069
+   describes attacks on the emergency services system, such as
+   attempting to deny system services to all users in a given area, to
+   gain fraudulent use of services and to divert emergency calls to
+   non-emergency sites.  In addition, it describes attacks against
+   individuals, including attempts to prevent an individual from
+   receiving aid, or to gain information about an emergency, as well as
+   attacks on emergency services infrastructure elements, such as
+   mapping discovery and mapping servers.
+
+   "Secure Telephone Identity Threat Model" [RFC7375] analyzes threats
+   relating to impersonation and obscuring of calling party numbers,
+   reviewing the capabilities available to attackers, and the scenarios
+   in which attacks are launched.
+
+2.2.  Adversary Model
+
+   To provide a structured analysis, we distinguish between three
+   adversary models:
+
+   External adversary model:  The end host, e.g., an emergency caller
+      whose location is going to be communicated, is honest, and the
+      adversary may be located between the end host and the location
+      server or between the end host and the PSAP.  None of the
+      emergency service infrastructure elements act maliciously.
+
+
+
+
+
+
+Tschofenig, et al.            Informational                     [Page 9]
+
+RFC 7378                  Trustworthy Location             December 2014
+
+
+   Malicious infrastructure adversary model:  The emergency call routing
+      elements, such as the Location Information Server (LIS), the
+      Location-to-Service Translation (LoST) infrastructure (which is
+      used for mapping locations to PSAP addresses), or call routing
+      elements, may act maliciously.
+
+   Malicious end host adversary model:  The end host itself acts
+      maliciously, whether the owner is aware of this or the end host is
+      acting under the control of a third party.
+
+   Since previous work describes attacks against infrastructure elements
+   (e.g., location servers, call route servers, mapping servers) or the
+   emergency services IP network, as well as threats from attackers
+   attempting to snoop location in transit, this document focuses on the
+   threats arising from end hosts providing false location information
+   within emergency calls (the malicious end host adversary model).
+
+   Since the focus is on malicious hosts, we do not cover threats that
+   may arise from attacks on infrastructure that hosts depend on to
+   obtain location.  For example, end hosts may obtain location from
+   civilian GPS, which is vulnerable to spoofing [GPSCounter], or from
+   third-party Location Service Providers (LSPs) that may be vulnerable
+   to attack or may not provide location accuracy suitable for emergency
+   purposes.
+
+   Also, we do not cover threats arising from inadequate location
+   infrastructure.  For example, the LIS or end host could base its
+   location determination on a stale wiremap or an inaccurate access
+   point location database, leading to an inaccurate location estimate.
+   Similarly, a Voice Service Provider (VSP) (and, indirectly, a LIS)
+   could utilize the wrong identity (such as an IP address) for location
+   lookup, thereby providing the end host with misleading location
+   information.
+
+2.3.  Location Spoofing
+
+   Where location is attached to the emergency call by an end host, the
+   end host can fabricate a PIDF-LO and convey it within an emergency
+   call.  The following represent examples of location spoofing:
+
+   Place shifting:  Mallory, the adversary, pretends to be at an
+                    arbitrary location.
+
+   Time shifting:   Mallory pretends to be at a location where she was
+                    a while ago.
+
+   Location theft:  Mallory observes or obtains Alice's location and
+                    replays it as her own.
+
+
+
+Tschofenig, et al.            Informational                    [Page 10]
+
+RFC 7378                  Trustworthy Location             December 2014
+
+
+2.4.  Identity Spoofing
+
+   While this document does not focus on the problems created by
+   determination of location based on spoofed caller identification, the
+   ability to ascertain identity is important, since the threat of
+   punishment reduces hoax calls.  As an example, calls from pay phones
+   are subject to greater scrutiny by the call taker.
+
+   With calls originating on an IP network, at least two forms of
+   identity are relevant, with the distinction created by the split
+   between the IAP and the VSP:
+
+   (a) network access identity such as might be determined via
+       authentication (e.g., using the Extensible Authentication
+       Protocol (EAP) [RFC3748]);
+
+   (b) caller identity, such as might be determined from authentication
+       of the emergency caller at the VoIP application layer.
+
+   If the adversary did not authenticate itself to the VSP, then
+   accountability may depend on verification of the network access
+   identity.  However, the network access identity may also not have
+   been authenticated, such as in the case where an open IEEE 802.11
+   Access Point is used to initiate a hoax emergency call.  Although
+   endpoint information such as the IP address or Media Access Control
+   (MAC) address may have been logged, tying this back to the Device
+   owner may be challenging.
+
+   Unlike the existing telephone system, VoIP emergency calls can
+   provide an identity that need not necessarily be coupled to a
+   business relationship with the IAP, ISP, or VSP.  However, due to the
+   time-critical nature of emergency calls, multi-layer authentication
+   is undesirable.  Thus, in most cases, only the Device placing the
+   call will be able to be identified.  Furthermore, deploying
+   additional credentials for emergency service purposes (such as
+   certificates) increases costs, introduces a significant
+   administrative overhead, and is only useful if widely deployed.
+
+3.  Mitigation Techniques
+
+   The sections that follow present three mechanisms for mitigating the
+   threats presented in Section 2:
+
+   1. Signed location-by-value (Section 3.1), which provides for
+      authentication and integrity protection of the PIDF-LO.  There is
+      only an expired straw-man proposal for this mechanism
+      [Loc-Dependability]; thus, as of the time of this writing this
+      mechanism is not suitable for deployment.
+
+
+
+Tschofenig, et al.            Informational                    [Page 11]
+
+RFC 7378                  Trustworthy Location             December 2014
+
+
+   2. Location-by-reference (Section 3.2), which enables location to be
+      obtained by the PSAP directly from the location server, over a
+      confidential and integrity-protected channel, avoiding
+      modification by the end host or an intermediary.  This mechanism
+      is specified in [RFC6753].
+
+   3. Proxy-added location (Section 3.3), which protects against
+      location forgery by the end host.  This mechanism is specified in
+      [RFC6442].
+
+3.1.  Signed Location-by-Value
+
+   With location signing, a location server signs the location
+   information before it is sent to the Target.  The signed location
+   information is then sent to the Location Recipient, who verifies it.
+
+   Figure 1 shows the communication model with the Target requesting
+   signed location in step (a); the location server returns it in
+   step (b), and it is then conveyed to the Location Recipient, who
+   verifies it (step (c)).  For SIP, the procedures described in
+   "Location Conveyance for the Session Initiation Protocol" [RFC6442]
+   are applicable for location conveyance.
+
+                   +-----------+               +-----------+
+                   |           |               | Location  |
+                   |    LIS    |               | Recipient |
+                   |           |               |           |
+                   +-+-------+-+               +----+------+
+                     ^       |                    --^
+                     |       |                  --
+       Geopriv       |Req.   |                --
+       Location      |Signed |Signed        -- Protocol Conveying
+       Configuration |Loc.   |Loc.        --   Location (e.g., SIP)
+       Protocol      |(a)    |(b)       --     (c)
+                     |       v        --
+                   +-+-------+-+    --
+                   | Target /  |  --
+                   | End Host  +
+                   |           |
+                   +-----------+
+
+                        Figure 1: Location Signing
+
+   A straw-man proposal for location signing is provided in "Digital
+   Signature Methods for Location Dependability" [Loc-Dependability].
+   Note that since [Loc-Dependability] is no longer under development,
+   location signing cannot be considered deployable at the time of this
+   writing.
+
+
+
+Tschofenig, et al.            Informational                    [Page 12]
+
+RFC 7378                  Trustworthy Location             December 2014
+
+
+   In order to limit replay attacks, that proposal calls for the
+   addition of a "validity" element to the PIDF-LO, including a "from"
+   sub-element containing the time that location information was
+   validated by the signer, as well as an "until" sub-element containing
+   the last time that the signature can be considered valid.
+
+   One of the consequences of including an "until" element is that even
+   a stationary Target would need to periodically obtain a fresh
+   PIDF-LO, or incur the additional delay of querying during an
+   emergency call.
+
+   Although privacy-preserving procedures may be disabled for emergency
+   calls, by design, PIDF-LO objects limit the information available for
+   real-time attribution.  As noted in [RFC5985], Section 6.6:
+
+      The LIS MUST NOT include any means of identifying the Device in
+      the PIDF-LO unless it is able to verify that the identifier is
+      correct and inclusion of identity is expressly permitted by a Rule
+      Maker.  Therefore, PIDF parameters that contain identity are
+      either omitted or contain unlinked pseudonyms [RFC3693].  A
+      unique, unlinked presentity URI SHOULD be generated by the LIS for
+      the mandatory presence "entity" attribute of the PIDF document.
+
+      Optional parameters such as the "contact" and "deviceID" elements
+      [RFC4479] are not used.
+
+   Also, the Device referred to in the PIDF-LO may not necessarily be
+   the same entity conveying the PIDF-LO to the PSAP.  As noted in
+   [RFC6442], Section 1:
+
+      In no way does this document assume that the SIP user agent client
+      that sends a request containing a location object is necessarily
+      the Target.  The location of a Target conveyed within SIP
+      typically corresponds to that of a Device controlled by the
+      Target, for example, a mobile phone, but such Devices can be
+      separated from their owners, and moreover, in some cases, the user
+      agent may not know its own location.
+
+   Without the ability to tie the Target identity to the identity
+   asserted in the SIP message, it is possible for an attacker to cut
+   and paste a PIDF-LO obtained by a different Device or user into a SIP
+   INVITE and send this to the PSAP.  This cut-and-paste attack could
+   succeed even when a PIDF-LO is signed or when [RFC4474] is
+   implemented.
+
+
+
+
+
+
+
+Tschofenig, et al.            Informational                    [Page 13]
+
+RFC 7378                  Trustworthy Location             December 2014
+
+
+   To address location-spoofing attacks, [Loc-Dependability] proposes
+   the addition of an "identity" element that could include a SIP URI
+   (enabling comparison against the identity asserted in the SIP
+   headers) or an X.509v3 certificate.  If the Target was authenticated
+   by the LIS, an "authenticated" attribute is added.  However, because
+   the inclusion of an "identity" element could enable location
+   tracking, a "hash" element is also proposed that could instead
+   contain a hash of the content of the "identity" element.  In
+   practice, such a hash would not be much better for real-time
+   validation than a pseudonym.
+
+   Location signing cannot deter attacks in which valid location
+   information is provided.  For example, an attacker in control of
+   compromised hosts could launch a denial-of-service attack on the PSAP
+   by initiating a large number of emergency calls, each containing
+   valid signed location information.  Since the work required to verify
+   the location signature is considerable, this could overwhelm the PSAP
+   infrastructure.
+
+   However, while DDoS attacks are unlikely to be deterred by location
+   signing, accurate location information would limit the subset of
+   compromised hosts that could be used for an attack, as only hosts
+   within the PSAP serving area would be useful in placing emergency
+   calls.
+
+   Location signing is also difficult when the host obtains location via
+   mechanisms such as GPS, unless trusted computing approaches, with
+   tamper-proof GPS modules, can be applied.  Otherwise, an end host can
+   pretend to have GPS, and the Recipient will need to rely on its
+   ability to assess the level of trust that should be placed in the end
+   host location claim.
+
+   Even though location-signing mechanisms have not been standardized,
+   [NENA-i2], Section 4.7 includes operational recommendations relating
+   to location signing:
+
+      Location configuration and conveyance requirements are described
+      in NENA 08-752[27], but guidance is offered here on what should be
+      considered when designing mechanisms to report location:
+
+      1. The location object should be digitally signed.
+
+      2. The certificate for the signer (LIS operator) should be rooted
+         in VESA.  For this purpose, VPC and ERDB operators should issue
+         certificates to LIS operators.
+
+      3. The signature should include a timestamp.
+
+
+
+
+Tschofenig, et al.            Informational                    [Page 14]
+
+RFC 7378                  Trustworthy Location             December 2014
+
+
+      4. Where possible, the Location Object should be refreshed
+         periodically, with the signature (and thus the timestamp) being
+         refreshed as a consequence.
+
+      5. Antispoofing mechanisms should be applied to the Location
+         Reporting method.
+
+   (Note: The term "Valid Emergency Services Authority" (VESA) refers to
+   the root certificate authority.  "VPC" stands for VoIP Positioning
+   Center, and "ERDB" stands for the Emergency Service Zone Routing
+   Database.)
+
+   As noted above, signing of location objects implies the development
+   of a trust hierarchy that would enable a certificate chain provided
+   by the LIS operator to be verified by the PSAP.  Rooting the trust
+   hierarchy in the VESA can be accomplished either by having the VESA
+   directly sign the LIS certificates or by the creation of intermediate
+   Certificate Authorities (CAs) certified by the VESA, which will then
+   issue certificates to the LIS.  In terms of the workload imposed on
+   the VESA, the latter approach is highly preferable.  However, this
+   raises the question of who would operate the intermediate CAs and
+   what the expectations would be.
+
+   In particular, the question arises as to the requirements for LIS
+   certificate issuance, and how they would compare to requirements for
+   issuance of other certificates such as a Secure Socket
+   Layer/Transport Layer Security (SSL/TLS) web certificate.
+
+3.2.  Location-by-Reference
+
+   Location-by-reference was developed so that end hosts can avoid
+   having to periodically query the location server for up-to-date
+   location information in a mobile environment.  Additionally, if
+   operators do not want to disclose location information to the end
+   host without charging them, location-by-reference provides a
+   reasonable alternative.  Also, since location-by-reference enables
+   the PSAP to directly contact the location server, it avoids potential
+   attacks by intermediaries.
+
+   As noted in "A Location Dereference Protocol Using HTTP-Enabled
+   Location Delivery (HELD)" [RFC6753], a location reference can be
+   obtained via HELD [RFC5985].  In addition, "Location Configuration
+   Extensions for Policy Management" [RFC7199] extends location
+   configuration protocols such as HELD to provide hosts with a
+   reference to the rules that apply to a location-by-reference so that
+   the host can view or set these rules.
+
+
+
+
+
+Tschofenig, et al.            Informational                    [Page 15]
+
+RFC 7378                  Trustworthy Location             December 2014
+
+
+   Figure 2 shows the communication model with the Target requesting a
+   location reference in step (a); the location server returns the
+   reference and, potentially, the policy in step (b), and it is then
+   conveyed to the Location Recipient in step (c).  The Location
+   Recipient needs to resolve the reference with a request in step (d).
+   Finally, location information is returned to the Location Recipient
+   afterwards.  For location conveyance in SIP, the procedures described
+   in [RFC6442] are applicable.
+
+                   +-----------+  Geopriv      +-----------+
+                   |           |  Location     | Location  |
+                   |    LIS    +<------------->+ Recipient |
+                   |           | Dereferencing |           |
+                   +-+-------+-+ Protocol (d)  +----+------+
+                     ^       |                    --^
+                     |       |                  --
+       Geopriv       |Req.   |LbyR +          --
+       Location      |LbyR   |Policy        -- Protocol Conveying
+       Configuration |(a)    |(b)         --   Location (e.g., SIP)
+       Protocol      |       |          --     (c)
+                     |       V        --
+                   +-+-------+-+    --
+                   | Target /  |  --
+                   | End Host  +
+                   |           |
+                   +-----------+
+
+                      Figure 2: Location-by-Reference
+
+   Where location-by-reference is provided, the Recipient needs to
+   dereference the LbyR in order to obtain location.  The details for
+   the dereferencing operations vary with the type of reference, such as
+   an HTTP, HTTPS, SIP, secure SIP (SIPS), or SIP Presence URI.
+
+   For location-by-reference, the location server needs to maintain one
+   or several URIs for each Target, timing out these URIs after a
+   certain amount of time.  References need to expire to prevent the
+   Recipient of such a Uniform Resource Locator (URL) from being able to
+   permanently track a host and to offer garbage collection
+   functionality for the location server.
+
+   Off-path adversaries must be prevented from obtaining the Target's
+   location.  The reference contains a randomized component that
+   prevents third parties from guessing it.  When the Location Recipient
+   fetches up-to-date location information from the location server, it
+   can also be assured that the location information is fresh and not
+   replayed.  However, this does not address location theft.
+
+
+
+
+Tschofenig, et al.            Informational                    [Page 16]
+
+RFC 7378                  Trustworthy Location             December 2014
+
+
+   With respect to the security of the dereference operation, [RFC6753],
+   Section 6 states:
+
+      TLS MUST be used for dereferencing location URIs unless
+      confidentiality and integrity are provided by some other
+      mechanism, as discussed in Section 3.  Location Recipients MUST
+      authenticate the host identity using the domain name included in
+      the location URI, using the procedure described in Section 3.1 of
+      [RFC2818].  Local policy determines what a Location Recipient does
+      if authentication fails or cannot be attempted.
+
+      The authorization by possession model (Section 4.1) further relies
+      on TLS when transmitting the location URI to protect the secrecy
+      of the URI.  Possession of such a URI implies the same privacy
+      considerations as possession of the PIDF-LO document that the URI
+      references.
+
+      Location URIs MUST only be disclosed to authorized Location
+      Recipients.  The GEOPRIV architecture [RFC6280] designates the
+      Rule Maker to authorize disclosure of the URI.
+
+      Protection of the location URI is necessary, since the policy
+      attached to such a location URI permits anyone who has the URI to
+      view the associated location information.  This aspect of security
+      is covered in more detail in the specification of location
+      conveyance protocols, such as [RFC6442].
+
+   For authorizing access to location-by-reference, two authorization
+   models were developed: "Authorization by Possession" and
+   "Authorization via Access Control Lists".  With respect to
+   "Authorization by Possession", [RFC6753], Section 4.1 notes:
+
+      In this model, possession -- or knowledge -- of the location URI
+      is used to control access to location information.  A location URI
+      might be constructed such that it is hard to guess (see C8 of
+      [RFC5808]), and the set of entities that it is disclosed to can be
+      limited.  The only authentication this would require by the LS is
+      evidence of possession of the URI.  The LS could immediately
+      authorize any request that indicates this URI.
+
+      Authorization by possession does not require direct interaction
+      with a Rule Maker; it is assumed that the Rule Maker is able to
+      exert control over the distribution of the location URI.
+      Therefore, the LIS can operate with limited policy input from a
+      Rule Maker.
+
+
+
+
+
+
+Tschofenig, et al.            Informational                    [Page 17]
+
+RFC 7378                  Trustworthy Location             December 2014
+
+
+      Limited disclosure is an important aspect of this authorization
+      model.  The location URI is a secret; therefore, ensuring that
+      adversaries are not able to acquire this information is paramount.
+      Encryption, such as might be offered by TLS [RFC5246] or S/MIME
+      [RFC5751], protects the information from eavesdroppers.
+
+      ...
+
+      Using possession as a basis for authorization means that, once
+      granted, authorization cannot be easily revoked.  Cancellation of
+      a location URI ensures that legitimate users are also affected;
+      application of additional policy is theoretically possible but
+      could be technically infeasible.  Expiration of location URIs
+      limits the usable time for a location URI, requiring that an
+      attacker continue to learn new location URIs to retain access to
+      current location information.
+
+   In situations where "Authorization by Possession" is not suitable
+   (such as where location hiding [RFC6444] is required), the
+   "Authorization via Access Control Lists" model may be preferred.
+
+   Without the introduction of a hierarchy, it would be necessary for
+   the PSAP to obtain credentials, such as certificates or shared
+   symmetric keys, for all the LISs in its coverage area, to enable it
+   to successfully dereference LbyRs.  In situations with more than a
+   few LISs per PSAP, this would present operational challenges.
+
+   A certificate hierarchy providing PSAPs with client certificates
+   chaining to the VESA could be used to enable the LIS to authenticate
+   and authorize PSAPs for dereferencing.  Note that unlike PIDF-LO
+   signing (which mitigates modification of PIDF-LOs), this merely
+   provides the PSAP with access to a (potentially unsigned) PIDF-LO,
+   albeit over a protected TLS channel.
+
+   Another approach would be for the local LIS to upload location
+   information to a location aggregation point who would in turn manage
+   the relationships with the PSAP.  This would shift the management
+   burden from the PSAPs to the location aggregation points.
+
+3.3.  Proxy-Added Location
+
+   Instead of relying upon the end host to provide location, is possible
+   for a proxy that has the ability to determine the location of the end
+   point (e.g., based on the end host IP or MAC address) to retrieve and
+   add or override location information.  This requires deployment of
+   application-layer entities by ISPs, unlike the two other techniques.
+   The proxies could be used for emergency or non-emergency
+   communications, or both.
+
+
+
+Tschofenig, et al.            Informational                    [Page 18]
+
+RFC 7378                  Trustworthy Location             December 2014
+
+
+   The use of proxy-added location is primarily applicable in scenarios
+   where the end host does not provide location.  As noted in [RFC6442],
+   Section 4.1:
+
+      A SIP intermediary SHOULD NOT add location to a SIP request that
+      already contains location.  This will quite often lead to
+      confusion within LRs.  However, if a SIP intermediary adds
+      location, even if location was not previously present in a SIP
+      request, that SIP intermediary is fully responsible for addressing
+      the concerns of any 424 (Bad Location Information) SIP response it
+      receives about this location addition and MUST NOT pass on
+      (upstream) the 424 response.  A SIP intermediary that adds a
+      locationValue MUST position the new locationValue as the last
+      locationValue within the Geolocation header field of the SIP
+      request.
+
+      ...
+
+      A SIP intermediary MAY add a Geolocation header field if one is
+      not present -- for example, when a user agent does not support the
+      Geolocation mechanism but their outbound proxy does and knows the
+      Target's location, or any of a number of other use cases (see
+      Section 3).
+
+   As noted in [RFC6442], Section 3.3:
+
+      This document takes a "you break it, you bought it" approach to
+      dealing with second locations placed into a SIP request by an
+      intermediary entity.  That entity becomes completely responsible
+      for all location within that SIP request (more on this in
+      Section 4).
+
+   While it is possible for the proxy to override location included by
+   the end host, [RFC6442], Section 3.4 notes the operational
+   limitations:
+
+      Overriding location information provided by the user requires a
+      deployment where an intermediary necessarily knows better than an
+      end user -- after all, it could be that Alice has an on-board GPS,
+      and the SIP intermediary only knows her nearest cell tower.  Which
+      is more accurate location information?  Currently, there is no way
+      to tell which entity is more accurate or which is wrong, for that
+      matter.  This document will not specify how to indicate which
+      location is more accurate than another.
+
+
+
+
+
+
+
+Tschofenig, et al.            Informational                    [Page 19]
+
+RFC 7378                  Trustworthy Location             December 2014
+
+
+   The disadvantage of this approach is the need to deploy application-
+   layer entities, such as SIP proxies, at IAPs or associated with IAPs.
+   This requires that a standardized VoIP profile be deployed at every
+   end Device and at every IAP.  This might impose interoperability
+   challenges.
+
+   Additionally, the IAP needs to take responsibility for emergency
+   calls, even for customers with whom they have no direct or indirect
+   relationship.  To provide identity information about the emergency
+   caller from the VSP, it would be necessary to let the IAP and the VSP
+   interact for authentication (see, for example, "Diameter Session
+   Initiation Protocol (SIP) Application" [RFC4740]).  This interaction
+   along the Authentication, Authorization, and Accounting
+   infrastructure is often based on business relationships between the
+   involved entities.  An arbitrary IAP and VSP are unlikely to have a
+   business relationship.  If the interaction between the IAP and the
+   VSP fails due to the lack of a business relationship, then typically
+   a fall-back would be provided where no emergency caller identity
+   information is made available to the PSAP and the emergency call
+   still has to be completed.
+
+4.  Location Trust Assessment
+
+   The ability to assess the level of trustworthiness of conveyed
+   location information is important, since this makes it possible to
+   understand how much value should be placed on location information as
+   part of the decision-making process.  As an example, if automated
+   location information is understood to be highly suspect or is absent,
+   a call taker can put more effort into verifying the authenticity of
+   the call and obtaining location information from the caller.
+
+   Location trust assessment has value, regardless of whether the
+   location itself is authenticated (e.g., signed location) or is
+   obtained directly from the location server (e.g., location-by-
+   reference) over security transport, since these mechanisms do not
+   provide assurance of the validity or provenance of location data.
+
+   To prevent location-theft attacks, the "entity" element of the
+   PIDF-LO is of limited value if an unlinked pseudonym is provided in
+   this field.  However, if the LIS authenticates the Target, then the
+   linkage between the pseudonym and the Target identity can be
+   recovered in a post-incident investigation.
+
+
+
+
+
+
+
+
+
+Tschofenig, et al.            Informational                    [Page 20]
+
+RFC 7378                  Trustworthy Location             December 2014
+
+
+   As noted in [Loc-Dependability], if the location object was signed,
+   the Location Recipient has additional information on which to base
+   their trust assessment, such as the validity of the signature, the
+   identity of the Target, the identity of the LIS, whether the LIS
+   authenticated the Target, and the identifier included in the "entity"
+   field.
+
+   Caller accountability is also an important aspect of trust
+   assessment.  Can the individual purchasing the Device or activating
+   service be identified, or did the call originate from a non-service
+   initialized (NSI) Device whose owner cannot be determined?  Prior to
+   the call, was the caller authenticated at the network or application
+   layer?  In the event of a hoax call, can audit logs be made available
+   to an investigator, or can information relating to the owner of an
+   unlinked pseudonym be provided, enabling investigators to unravel the
+   chain of events that led to the attack?
+
+   In practice, the source of the location data is important for
+   location trust assessment.  For example, location provided by a
+   Location Information Server (LIS) whose administrator has an
+   established history of meeting emergency location accuracy
+   requirements (e.g., United States Phase II E-911 location accuracy)
+   may be considered more reliable than location information provided by
+   a third-party Location Service Provider (LSP) that disclaims use of
+   location information for emergency purposes.
+
+   However, even where an LSP does not attempt to meet the accuracy
+   requirements for emergency location, it still may be able to provide
+   information useful in assessing how reliable location information is
+   likely to be.  For example, was location determined based on the
+   nearest cell tower or 802.11 Access Point (AP), or was a
+   triangulation method used?  If based on cell tower or AP location
+   data, was the information obtained from an authoritative source
+   (e.g., the tower or AP owner), and when was the last time that the
+   location of the tower or access point was verified?
+
+   For real-time validation, information in the signaling and media
+   packets can be cross-checked against location information.  For
+   example, it may be possible to determine the city, state, country, or
+   continent associated with the IP address included within SIP Via or
+   Contact header fields, or the media source address, and compare this
+   against the location information reported by the caller or conveyed
+   in the PIDF-LO.  However, in some situations, only entities close to
+   the caller may be able to verify the correctness of location
+   information.
+
+
+
+
+
+
+Tschofenig, et al.            Informational                    [Page 21]
+
+RFC 7378                  Trustworthy Location             December 2014
+
+
+   Real-time validation of the timestamp contained within PIDF-LO
+   objects (reflecting the time at which the location was determined) is
+   also challenging.  To address time-shifting attacks, the "timestamp"
+   element of the PIDF-LO, defined in [RFC3863], can be examined and
+   compared against timestamps included within the enclosing SIP
+   message, to determine whether the location data is sufficiently
+   fresh.  However, the timestamp only represents an assertion by the
+   LIS, which may or may not be trustworthy.  For example, the Recipient
+   of the signed PIDF-LO may not know whether the LIS supports time
+   synchronization, or whether it is possible to reset the LIS clock
+   manually without detection.  Even if the timestamp was valid at the
+   time location was determined, a time period may elapse between when
+   the PIDF-LO was provided and when it is conveyed to the Recipient.
+   Periodically refreshing location information to renew the timestamp
+   even though the location information itself is unchanged puts
+   additional load on LISs.  As a result, Recipients need to validate
+   the timestamp in order to determine whether it is credible.
+
+   While this document focuses on the discussion of real-time
+   determination of suspicious emergency calls, the use of audit logs
+   may help in enforcing accountability among emergency callers.  For
+   example, in the event of a hoax call, information relating to the
+   owner of the unlinked pseudonym could be provided to investigators,
+   enabling them to unravel the chain of events that led to the attack.
+   However, while auditability is an important deterrent, it is likely
+   to be of most benefit in situations where attacks on the emergency
+   services system are likely to be relatively infrequent, since the
+   resources required to pursue an investigation are likely to be
+   considerable.  However, although real-time validation based on
+   PIDF-LO elements is challenging, where LIS audit logs are available
+   (such as where a law enforcement agency can present a subpoena),
+   linking of a pseudonym to the Device obtaining location can be
+   accomplished during an investigation.
+
+   Where attacks are frequent and continuous, automated mechanisms are
+   required.  For example, it might be valuable to develop mechanisms to
+   exchange audit trail information in a standardized format between
+   ISPs and PSAPs / VSPs and PSAPs or heuristics to distinguish
+   potentially fraudulent emergency calls from real emergencies.  While
+   a Completely Automated Public Turing test to tell Computers and
+   Humans Apart (CAPTCHA) may be applied to suspicious calls to lower
+   the risk from bot-nets, this is quite controversial for emergency
+   services, due to the risk of delaying or rejecting valid calls.
+
+
+
+
+
+
+
+
+Tschofenig, et al.            Informational                    [Page 22]
+
+RFC 7378                  Trustworthy Location             December 2014
+
+
+5.  Security Considerations
+
+   Although it is important to ensure that location information cannot
+   be faked, the mitigation techniques presented in this document are
+   not universally applicable.  For example, there will be many GPS-
+   enabled Devices that will find it difficult to utilize any of the
+   solutions described in Section 3.  It is also unlikely that users
+   will be willing to upload their location information for
+   "verification" to a nearby location server located in the access
+   network.
+
+   This document focuses on threats that arise from conveyance of
+   misleading location information, rather than caller identification or
+   authentication and integrity protection of the messages in which
+   location is conveyed.  Nevertheless, these aspects are important.  In
+   some countries, regulators may not require the authenticated identity
+   of the emergency caller (e.g., emergency calls placed from Public
+   Switched Telephone Network (PSTN) pay phones or SIM-less cell
+   phones).  Furthermore, if identities can easily be crafted (as is the
+   case with many VoIP offerings today), then the value of emergency
+   caller authentication itself might be limited.  As a result,
+   attackers can forge emergency calls with a lower risk of being held
+   accountable, which may encourage hoax calls.
+
+   In order to provide authentication and integrity protection for the
+   Session Initiation Protocol (SIP) messages conveying location,
+   several security approaches are available.  It is possible to ensure
+   that modification of the identity and location in transit can be
+   detected by the Location Recipient (e.g., the PSAP), using
+   cryptographic mechanisms, as described in "Enhancements for
+   Authenticated Identity Management in the Session Initiation Protocol
+   (SIP)" [RFC4474].  However, compatibility with Session Border
+   Controllers (SBCs) that modify integrity-protected headers has proven
+   to be an issue in practice, and as a result, a revision of [RFC4474]
+   is in progress [SIP-Identity].  In the absence of an end-to-end
+   solution, SIP over Transport Layer Security (TLS) can be used to
+   provide message authentication and integrity protection hop by hop.
+
+   PSAPs remain vulnerable to distributed denial-of-service attacks,
+   even where the mitigation techniques described in this document are
+   utilized.  Placing a large number of emergency calls that appear to
+   come from different locations is an example of an attack that is
+   difficult to carry out within the legacy system but is easier to
+   imagine within IP-based emergency services.  Also, in the current
+   system, it would be very difficult for an attacker from one country
+   to attack the emergency services infrastructure located in another
+   country, but this attack is possible within IP-based emergency
+   services.
+
+
+
+Tschofenig, et al.            Informational                    [Page 23]
+
+RFC 7378                  Trustworthy Location             December 2014
+
+
+   While manually mounting the attacks described in Section 2 is
+   non-trivial, the attacks described in this document can be automated.
+   While manually carrying out a location theft would require that the
+   attacker be in proximity to the location being spoofed, or to collude
+   with another end host, an attacker able to run code on an end host
+   can obtain its location and cause an emergency call to be made.
+   While manually carrying out a time-shifting attack would require that
+   the attacker visit the location and submit it before the location
+   information is considered stale, while traveling rapidly away from
+   that location to avoid apprehension, these limitations would not
+   apply to an attacker able to run code on the end host.  While
+   obtaining a PIDF-LO from a spoofed IP address requires that the
+   attacker be on the path between the HELD requester and the LIS, if
+   the attacker is able to run code requesting the PIDF-LO, retrieve it
+   from the LIS, and then make an emergency call using it, this attack
+   becomes much easier.  To mitigate the risk of automated attacks,
+   service providers can limit the ability of untrusted code (such as
+   WebRTC applications written in JavaScript) to make emergency calls.
+
+   Emergency services have three finite resources subject to denial-of-
+   service attacks: the network and server infrastructure; call takers
+   and dispatchers; and the first responders, such as firefighters and
+   police officers.  Protecting the network infrastructure is similar to
+   protecting other high-value service providers, except that location
+   information may be used to filter call setup requests, to weed out
+   requests that are out of area.  Even for large cities, PSAPs may only
+   have a handful of call takers on duty.  So, even if automated
+   techniques are utilized to evaluate the trustworthiness of conveyed
+   location and call takers can, by questioning the caller, eliminate
+   many hoax calls, PSAPs can be overwhelmed even by a small-scale
+   attack.  Finally, first-responder resources are scarce, particularly
+   during mass-casualty events.
+
+6.  Privacy Considerations
+
+   The emergency calling architecture described in [RFC6443] utilizes
+   the PIDF-LO format defined in [RFC4119].  As described in the
+   location privacy architecture [RFC6280], privacy rules that may
+   include policy instructions are conveyed along with the location
+   object.
+
+
+
+
+
+
+
+
+
+
+
+Tschofenig, et al.            Informational                    [Page 24]
+
+RFC 7378                  Trustworthy Location             December 2014
+
+
+   The intent of the location privacy architecture was to provide strong
+   privacy protections, as noted in [RFC6280], Section 1.1:
+
+      A central feature of the Geopriv architecture is that location
+      information is always bound to privacy rules to ensure that
+      entities that receive location information are informed of how
+      they may use it.  These rules can convey simple directives ("do
+      not share my location with others"), or more robust preferences
+      ("allow my spouse to know my exact location all of the time, but
+      only allow my boss to know it during work hours")...  The binding
+      of privacy rules to location information can convey users' desire
+      for and expectations of privacy, which in turn helps to bolster
+      social and legal systems' protection of those expectations.
+
+   However, in practice this architecture has limitations that apply
+   within emergency and non-emergency situations.  As noted in
+   Section 1.2.2, concerns about hoax calls have led to restrictions on
+   anonymous emergency calls.  Caller identification (potentially
+   asserted in SIP via P-Asserted-Identity and SIP Identity) may be used
+   during emergency calls.  As a result, in many cases location
+   information transmitted within SIP messages can be linked to caller
+   identity.  For example, in the case of a signed LbyV, there are
+   privacy concerns arising from linking the location object to
+   identifiers to prevent replay attacks, as described in Section 3.1.
+
+   The ability to observe location information during emergency calls
+   may also represent a privacy risk.  As a result, [RFC6443] requires
+   transmission-layer security for SIP messages, as well as interactions
+   with the location server.  However, even where transmission-layer
+   security is used, privacy rules associated with location information
+   may not apply.
+
+   In many jurisdictions, an individual requesting emergency assistance
+   is assumed to be granting permission to the PSAP, call taker, and
+   first responders to obtain their location in order to accelerate
+   dispatch.  As a result, privacy policies associated with location are
+   implicitly waived when an emergency call is initiated.  In addition,
+   when location information is included within SIP messages in either
+   emergency or non-emergency uses, SIP entities receiving the SIP
+   message are implicitly assumed to be authorized Location Recipients,
+   as noted in [RFC5606], Section 3.2:
+
+      Consensus has emerged that any SIP entity that receives a SIP
+      message containing LI through the operation of SIP's normal
+      routing procedures or as a result of location-based routing should
+      be considered an authorized recipient of that LI.  Because of this
+      presumption, one SIP element may pass the LI to another even if
+      the LO it contains has <retransmission-allowed> set to "no"; this
+
+
+
+Tschofenig, et al.            Informational                    [Page 25]
+
+RFC 7378                  Trustworthy Location             December 2014
+
+
+      sees the passing of the SIP message as part of the delivery to
+      authorized recipients, rather than as retransmission.  SIP
+      entities are still enjoined from passing these messages
+      outside the normal routing to external entities if
+      <retransmission-allowed> is set to "no", as it is the passing to
+      third parties that <retransmission-allowed> is meant to control.
+
+   Where LbyR is utilized rather than LbyV, it is possible to apply more
+   restrictive authorization policies, limiting access to intermediaries
+   and snoopers.  However, this is not possible if the "authorization by
+   possession" model is used.
+
+7.  Informative References
+
+   [EENA]     EENA, "False Emergency Calls", EENA Operations Document,
+              Version 1.1, May 2011, <http://www.eena.org/ressource/
+              static/files/2012_05_04-3.1.2.fc_v1.1.pdf>.
+
+   [GPSCounter]
+              Warner, J. and R. Johnston, "GPS Spoofing
+              Countermeasures", Los Alamos research paper LAUR-03-6163,
+              December 2003.
+
+   [Loc-Dependability]
+              Thomson, M. and J. Winterbottom, "Digital Signature
+              Methods for Location Dependability", Work in Progress,
+              draft-thomson-geopriv-location-dependability-07,
+              March 2011.
+
+   [NENA-i2]  NENA 08-001, "NENA Interim VoIP Architecture for Enhanced
+              9-1-1 Services (i2)", Version 2, August 2010.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000,
+              <http://www.rfc-editor.org/info/rfc2818>.
+
+   [RFC3261]  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, <http://www.rfc-editor.org/info/rfc3261>.
+
+   [RFC3693]  Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
+              J. Polk, "Geopriv Requirements", RFC 3693, February 2004,
+              <http://www.rfc-editor.org/info/rfc3693>.
+
+
+
+
+Tschofenig, et al.            Informational                    [Page 26]
+
+RFC 7378                  Trustworthy Location             December 2014
+
+
+   [RFC3694]  Danley, M., Mulligan, D., Morris, J., and J. Peterson,
+              "Threat Analysis of the Geopriv Protocol", RFC 3694,
+              February 2004, <http://www.rfc-editor.org/info/rfc3694>.
+
+   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
+              Levkowetz, Ed., "Extensible Authentication Protocol
+              (EAP)", RFC 3748, June 2004,
+              <http://www.rfc-editor.org/info/rfc3748>.
+
+   [RFC3863]  Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr,
+              W., and J. Peterson, "Presence Information Data Format
+              (PIDF)", RFC 3863, August 2004,
+              <http://www.rfc-editor.org/info/rfc3863>.
+
+   [RFC4119]  Peterson, J., "A Presence-based GEOPRIV Location Object
+              Format", RFC 4119, December 2005,
+              <http://www.rfc-editor.org/info/rfc4119>.
+
+   [RFC4474]  Peterson, J. and C. Jennings, "Enhancements for
+              Authenticated Identity Management in the Session
+              Initiation Protocol (SIP)", RFC 4474, August 2006,
+              <http://www.rfc-editor.org/info/rfc4474>.
+
+   [RFC4479]  Rosenberg, J., "A Data Model for Presence", RFC 4479,
+              July 2006, <http://www.rfc-editor.org/info/rfc4479>.
+
+   [RFC4740]  Garcia-Martin, M., Ed., Belinchon, M., Pallares-Lopez, M.,
+              Canales-Valenzuela, C., and K. Tammi, "Diameter Session
+              Initiation Protocol (SIP) Application", RFC 4740,
+              November 2006, <http://www.rfc-editor.org/info/rfc4740>.
+
+   [RFC5012]  Schulzrinne, H. and R. Marshall, Ed., "Requirements for
+              Emergency Context Resolution with Internet Technologies",
+              RFC 5012, January 2008,
+              <http://www.rfc-editor.org/info/rfc5012>.
+
+   [RFC5069]  Taylor, T., Ed., Tschofenig, H., Schulzrinne, H., and M.
+              Shanmugam, "Security Threats and Requirements for
+              Emergency Call Marking and Mapping", RFC 5069,
+              January 2008, <http://www.rfc-editor.org/info/rfc5069>.
+
+   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.2", RFC 5246, August 2008,
+              <http://www.rfc-editor.org/info/rfc5246>.
+
+
+
+
+
+
+
+Tschofenig, et al.            Informational                    [Page 27]
+
+RFC 7378                  Trustworthy Location             December 2014
+
+
+   [RFC5491]  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,
+              <http://www.rfc-editor.org/info/rfc5491>.
+
+   [RFC5606]  Peterson, J., Hardie, T., and J. Morris, "Implications of
+              'retransmission-allowed' for SIP Location Conveyance",
+              RFC 5606, August 2009,
+              <http://www.rfc-editor.org/info/rfc5606>.
+
+   [RFC5751]  Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
+              Mail Extensions (S/MIME) Version 3.2 Message
+              Specification", RFC 5751, January 2010,
+              <http://www.rfc-editor.org/info/rfc5751>.
+
+   [RFC5808]  Marshall, R., Ed., "Requirements for a Location-by-
+              Reference Mechanism", RFC 5808, May 2010,
+              <http://www.rfc-editor.org/info/rfc5808>.
+
+   [RFC5985]  Barnes, M., Ed., "HTTP-Enabled Location Delivery (HELD)",
+              RFC 5985, September 2010,
+              <http://www.rfc-editor.org/info/rfc5985>.
+
+   [RFC6280]  Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
+              Tschofenig, H., and H. Schulzrinne, "An Architecture for
+              Location and Location Privacy in Internet Applications",
+              BCP 160, RFC 6280, July 2011,
+              <http://www.rfc-editor.org/info/rfc6280>.
+
+   [RFC6442]  Polk, J., Rosen, B., and J. Peterson, "Location Conveyance
+              for the Session Initiation Protocol", RFC 6442,
+              December 2011, <http://www.rfc-editor.org/info/rfc6442>.
+
+   [RFC6443]  Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
+              "Framework for Emergency Calling Using Internet
+              Multimedia", RFC 6443, December 2011,
+              <http://www.rfc-editor.org/info/rfc6443>.
+
+   [RFC6444]  Schulzrinne, H., Liess, L., Tschofenig, H., Stark, B., and
+              A.  Kuett, "Location Hiding: Problem Statement and
+              Requirements", RFC 6444, January 2012,
+              <http://www.rfc-editor.org/info/rfc6444>.
+
+   [RFC6753]  Winterbottom, J., Tschofenig, H., Schulzrinne, H., and M.
+              Thomson, "A Location Dereference Protocol Using HTTP-
+              Enabled Location Delivery (HELD)", RFC 6753, October 2012,
+              <http://www.rfc-editor.org/info/rfc6753>.
+
+
+
+Tschofenig, et al.            Informational                    [Page 28]
+
+RFC 7378                  Trustworthy Location             December 2014
+
+
+   [RFC6881]  Rosen, B. and J. Polk, "Best Current Practice for
+              Communications Services in Support of Emergency Calling",
+              BCP 181, RFC 6881, March 2013,
+              <http://www.rfc-editor.org/info/rfc6881>.
+
+   [RFC7090]  Schulzrinne, H., Tschofenig, H., Holmberg, C., and M.
+              Patel, "Public Safety Answering Point (PSAP) Callback",
+              RFC 7090, April 2014,
+              <http://www.rfc-editor.org/info/rfc7090>.
+
+   [RFC7199]  Barnes, R., Thomson, M., Winterbottom, J., and H.
+              Tschofenig, "Location Configuration Extensions for Policy
+              Management", RFC 7199, April 2014,
+              <http://www.rfc-editor.org/info/rfc7199>.
+
+   [RFC7340]  Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure
+              Telephone Identity Problem Statement and Requirements",
+              RFC 7340, September 2014,
+              <http://www.rfc-editor.org/info/rfc7340>.
+
+   [RFC7375]  Peterson, J., "Secure Telephone Identity Threat Model",
+              RFC 7375, October 2014,
+              <http://www.rfc-editor.org/info/rfc7375>.
+
+   [SA]       "Saudi Arabia - Illegal sale of SIMs blamed for surge in
+              hoax calls", Arab News, April 5, 2010,
+              <http://www.arabnews.com/node/341463>.
+
+   [SIP-Identity]
+              Peterson, J., Jennings, C. and E. Rescorla, "Authenticated
+              Identity Management in the Session Initiation Protocol
+              (SIP)", Work in Progress, draft-ietf-stir-rfc4474bis-02,
+              October 2014.
+
+   [STIR]     IETF, "Secure Telephone Identity Revisited (stir) Working
+              Group", October 2013,
+              <http://datatracker.ietf.org/wg/stir/charter/>.
+
+   [SWATing]  "SWATing 911 Calls", Dispatch Magazine On-Line,
+              April 6, 2013, <http://www.911dispatch.com/
+              swating-911-calls/>.
+
+   [Swatting] "Don't Make the Call: The New Phenomenon of 'Swatting'",
+              Federal Bureau of Investigation, February 4, 2008,
+              <http://www.fbi.gov/news/stories/2008/february/
+              swatting020408>.
+
+
+
+
+
+Tschofenig, et al.            Informational                    [Page 29]
+
+RFC 7378                  Trustworthy Location             December 2014
+
+
+   [TASMANIA] "Emergency services seek SIM-less calls block", ABC News
+              Online, August 18, 2006, <http://www.abc.net.au/elections/
+              tas/2006/news/stories/1717956.htm?elections/tas/2006/>.
+
+   [UK]       "Rapper makes thousands of prank 999 emergency calls to UK
+              police", Digital Journal, June 24, 2010,
+              <http://www.digitaljournal.com/article/293796?tp=1>.
+
+Acknowledgments
+
+   We would like to thank the members of the IETF ECRIT working group,
+   including Marc Linsner and Brian Rosen, for their input at IETF 85
+   that helped get this document pointed in the right direction.  We
+   would also like to thank members of the IETF GEOPRIV working group,
+   including Richard Barnes, Matt Lepinski, Andrew Newton, Murugaraj
+   Shanmugam, and Martin Thomson for their feedback on previous versions
+   of this document.  Alissa Cooper, Adrian Farrel, Pete Resnick, Meral
+   Shirazipour, and Bert Wijnen provided helpful review comments during
+   the IETF last call.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tschofenig, et al.            Informational                    [Page 30]
+
+RFC 7378                  Trustworthy Location             December 2014
+
+
+Authors' Addresses
+
+   Hannes Tschofenig
+   Austria
+
+   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
+   United States
+
+   Phone: +1 212 939 7004
+   EMail: hgs@cs.columbia.edu
+   URI:   http://www.cs.columbia.edu
+
+
+   Bernard Aboba (editor)
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   United States
+
+   EMail: bernard_aboba@hotmail.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tschofenig, et al.            Informational                    [Page 31]
+