summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7378.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7378.txt')
-rw-r--r--doc/rfc/rfc7378.txt1739
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]
+