From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7378.txt | 1739 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1739 insertions(+) create mode 100644 doc/rfc/rfc7378.txt (limited to 'doc/rfc/rfc7378.txt') 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 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 + is set to "no", as it is the passing to + third parties that 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, . + + [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, + . + + [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000, + . + + [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, . + + [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and + J. Polk, "Geopriv Requirements", RFC 3693, February 2004, + . + + + + +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, . + + [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. + Levkowetz, Ed., "Extensible Authentication Protocol + (EAP)", RFC 3748, June 2004, + . + + [RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, + W., and J. Peterson, "Presence Information Data Format + (PIDF)", RFC 3863, August 2004, + . + + [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object + Format", RFC 4119, December 2005, + . + + [RFC4474] Peterson, J. and C. Jennings, "Enhancements for + Authenticated Identity Management in the Session + Initiation Protocol (SIP)", RFC 4474, August 2006, + . + + [RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, + July 2006, . + + [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, . + + [RFC5012] Schulzrinne, H. and R. Marshall, Ed., "Requirements for + Emergency Context Resolution with Internet Technologies", + RFC 5012, January 2008, + . + + [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, . + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, August 2008, + . + + + + + + + +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, + . + + [RFC5606] Peterson, J., Hardie, T., and J. Morris, "Implications of + 'retransmission-allowed' for SIP Location Conveyance", + RFC 5606, August 2009, + . + + [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet + Mail Extensions (S/MIME) Version 3.2 Message + Specification", RFC 5751, January 2010, + . + + [RFC5808] Marshall, R., Ed., "Requirements for a Location-by- + Reference Mechanism", RFC 5808, May 2010, + . + + [RFC5985] Barnes, M., Ed., "HTTP-Enabled Location Delivery (HELD)", + RFC 5985, September 2010, + . + + [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, + . + + [RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance + for the Session Initiation Protocol", RFC 6442, + December 2011, . + + [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, + "Framework for Emergency Calling Using Internet + Multimedia", RFC 6443, December 2011, + . + + [RFC6444] Schulzrinne, H., Liess, L., Tschofenig, H., Stark, B., and + A. Kuett, "Location Hiding: Problem Statement and + Requirements", RFC 6444, January 2012, + . + + [RFC6753] Winterbottom, J., Tschofenig, H., Schulzrinne, H., and M. + Thomson, "A Location Dereference Protocol Using HTTP- + Enabled Location Delivery (HELD)", RFC 6753, October 2012, + . + + + +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, + . + + [RFC7090] Schulzrinne, H., Tschofenig, H., Holmberg, C., and M. + Patel, "Public Safety Answering Point (PSAP) Callback", + RFC 7090, April 2014, + . + + [RFC7199] Barnes, R., Thomson, M., Winterbottom, J., and H. + Tschofenig, "Location Configuration Extensions for Policy + Management", RFC 7199, April 2014, + . + + [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure + Telephone Identity Problem Statement and Requirements", + RFC 7340, September 2014, + . + + [RFC7375] Peterson, J., "Secure Telephone Identity Threat Model", + RFC 7375, October 2014, + . + + [SA] "Saudi Arabia - Illegal sale of SIMs blamed for surge in + hoax calls", Arab News, April 5, 2010, + . + + [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, + . + + [SWATing] "SWATing 911 Calls", Dispatch Magazine On-Line, + April 6, 2013, . + + [Swatting] "Don't Make the Call: The New Phenomenon of 'Swatting'", + Federal Bureau of Investigation, February 4, 2008, + . + + + + + +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, . + + [UK] "Rapper makes thousands of prank 999 emergency calls to UK + police", Digital Journal, June 24, 2010, + . + +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] + -- cgit v1.2.3