idnits 2.17.1 draft-ietf-ecrit-trustworthy-location-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (2 June 2014) is 3614 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-stir-problem-statement' is defined on line 1021, but no explicit reference was found in the text == Unused Reference: 'I-D.jennings-stir-rfc4474bis' is defined on line 1031, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-ietf-stir-threats-02 -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5751 (Obsoleted by RFC 8551) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT Working Group H. Tschofenig 3 INTERNET-DRAFT ARM Ltd. 4 Category: Informational H. Schulzrinne 5 Expires: December 2, 2014 Columbia University 6 B. Aboba (ed.) 7 Microsoft Corporation 8 2 June 2014 10 Trustworthy Location 11 draft-ietf-ecrit-trustworthy-location-12.txt 13 Abstract 15 The trustworthiness of location information is critically important 16 for some location-based applications, such as emergency calling or 17 roadside assistance. 19 This document describes threats relating to conveyance of location in 20 an emergency call, and describes techniques that improve the 21 reliability and security of location information conveyed in a IP- 22 based emergency service call. It also provides guidelines for 23 assessing the trustworthiness of location information. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on December 2, 2014. 42 Copyright Notice 44 Copyright (c) 2014 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.2 Literature review . . . . . . . . . . . . . . . . . . . . 5 62 2. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 8 63 2.1. Location Spoofing . . . . . . . . . . . . . . . . . . . . 9 64 2.2. Identity Spoofing . . . . . . . . . . . . . . . . . . . . 9 65 3. Mitigation Techniques . . . . . . . . . . . . . . . . . . . . 10 66 3.1. Signed Location by Value . . . . . . . . . . . . . . . . . 10 67 3.2. Location by Reference . . . . . . . . . . . . . . . . . . 14 68 3.3. Proxy Adding Location . . . . . . . . . . . . . . . . . . 17 69 4. Location Trust Assessment . . . . . . . . . . . . . . . . . . 18 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 73 7.1. Informative references . . . . . . . . . . . . . . . . . . 22 74 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 25 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 77 1. Introduction 79 Several public and commercial services depend upon location 80 information in their operations. This includes emergency services 81 (such as fire, ambulance and police) as well as commercial services 82 such as food delivery and roadside assistance. 84 For circuit-switched calls from landlines, as well as for Voice over 85 IP (VoIP) services only supporting emergency service calls from 86 stationary devices, location provided to the Public Safety Answering 87 Point (PSAP) is determined from a lookup using the calling telephone 88 number. As a result, for landlines or stationary VoIP, spoofing of 89 caller identification can result in the PSAP incorrectly determining 90 the caller's location. Problems relating to calling party number and 91 Caller ID assurance have been analyzed by the "Secure Telephone 92 Identity Revisited" [STIR] Working Group as described in "Secure 93 Telephone Identity Problem Statement and Requirements" [I-D.ietf- 94 stir-problem-statement]. In addition to the work underway in STIR, 95 other mechanisms exist for validating caller identification. For 96 example, as noted in [EENA], one mechanism for validating caller 97 identification information (as well as the existence of an emergency) 98 is for the PSAP to call the user back, as described in [RFC7090]. 100 Given the existing work on caller identification, this document 101 focuses on the additional threats that are introduced by the support 102 of IP-based emergency services in nomadic and mobile devices, in 103 which location may be conveyed to the PSAP within the emergency call. 104 Ideally, a call taker at a PSAP should be able to assess, in real- 105 time, the level of trust that can be placed on the information 106 provided within a call. This includes automated location conveyed 107 along with the call and location information communicated by the 108 caller, as well as identity information relating to the caller or the 109 device initiating the call. Where real-time assessment is not 110 possible, it is important to be able to determine the source of the 111 call in a post-incident investigation, so as to be able to enforce 112 accountability. 114 This document defines terminology (including the meaning of 115 "trustworthy location") in Section 1.1, reviews existing work in 116 Section 1.2, describes the threat model in Section 2, outlines 117 potential mitigation techniques in Section 3, covers trust assessment 118 in Section 4 and discusses security considerations in Section 5. 120 1.1. Terminology 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in [RFC2119]. 126 The definitions of "Internet Access Provider (IAP)", "Internet 127 Service Provider (ISP)" and "Voice Service Provider (VSP)" are taken 128 from "Requirements for Emergency Context Resolution with Internet 129 Technologies" [RFC5012]. 131 The definition of a "hoax call" is taken from "False Emergency Calls" 132 [EENA]. 134 The definition of "Device", "Target" and "Location Information 135 Server" (LIS) is taken from "An Architecture for Location and 136 Location Privacy in Internet Applications" [RFC6280], Section 7. 138 The term "Device" denotes the physical device, such as a mobile 139 phone, PC, or embedded micro-controller, whose location is tracked as 140 a proxy for the location of a Target. 142 The term "Target" denotes an individual or other entity whose 143 location is sought in the Geopriv architecture. In many cases, the 144 Target will be the human user of a Device, or it may be an object 145 such as a vehicle or shipping container to which a Device is 146 attached. In some instances, the Target will be the Device itself. 147 The Target is the entity whose privacy Geopriv seeks to protect. 149 The term "Location Information Server" denotes an entity responsible 150 for providing devices within an access network with information about 151 their own locations. A Location Information Server uses knowledge of 152 the access network and its physical topology to generate and 153 distribute location information to devices. 155 The term "location determination method" refers to the mechanism used 156 to determine the location of a Target. This may be something 157 employed by a location information server (LIS), or by the Target 158 itself. It specifically does not refer to the location configuration 159 protocol (LCP) used to deliver location information either to the 160 Target or the Recipient. This term is re-used from "GEOPRIV PIDF-LO 161 Usage Clarification, Considerations, and Recommendations" [RFC5491]. 163 The term "source" is used to refer to the LIS, node, or device from 164 which a Recipient (Target or Third-Party) obtains location 165 information. 167 Additionally, the terms Location-by-Value (LbyV), Location-by- 168 Reference (LbyR), Location Configuration Protocol, Location 169 Dereference Protocol, and Location Uniform Resource Identifier (URI) 170 are re-used from "Requirements for a Location-by-Reference Mechanism" 171 [RFC5808]. 173 "Trustworthy Location" is defined as location information that can be 174 attributed to a trusted source, has been protected against 175 modification in transmit, and has been assessed as trustworthy. 177 "Location Trust Assessment" refers to the process by which the 178 reliability of location information can be assessed. This topic is 179 discussed in Section 4. 181 "Identity Spoofing" is where the attacker forges or obscures their 182 identity so as to prevent themselves from being identified as the 183 source of the attack. One class of identity spoofing attack involves 184 the forging of call origin identification. 186 The following additional terms apply to location spoofing: 188 "Place Shifting" is where the attacker constructs a Presence 189 Information Data Format Location Object (PIDF-LO) for a location 190 other than where they are currently located. In some cases, place 191 shifting can be limited in range (e.g., within the coverage area of a 192 particular cell tower). 194 "Time Shifting" is where the attacker uses or re-uses location 195 information that was valid in the past, but is no longer valid 196 because the attacker has moved. 198 "Location Theft" is where the attacker captures a Target's location 199 information (possibly including a signature) and presents it as their 200 own. Location theft can occur in a single instance, or may be 201 continuous (e.g., where the attacker has gained control over the 202 victim's device). Location theft may also be combined with time 203 shifting to present someone else's location information after the 204 original Target has moved. 206 1.2. Literature Review 208 There is existing work on the problem of hoax calls, as well as 209 analyses of aspects of the security of emergency services, threats to 210 geographic location privacy, threats relating to spoofing of caller 211 identification and modification of location information in transit. 212 This section reviews the literature. 214 1.2.1. Hoax Calls 216 Hoax calls have been a problem for emergency services dating back to 217 the time of street corner call boxes. As the European Emergency 218 Number Association (EENA) has noted [EENA]: "False emergency calls 219 divert emergency services away from people who may be in life- 220 threatening situations and who need urgent help. This can mean the 221 difference between life and death for someone in trouble." 222 EENA [EENA] has attempted to define terminology and describe best 223 current practices for dealing with false emergency calls. Reducing 224 the number of hoax calls represents a challenge, since emergency 225 services authorities in most countries are required to answer every 226 call (whenever possible). Where the caller cannot be identified, the 227 ability to prosecute is limited. 229 A particularly dangerous form of hoax call is "swatting" - a hoax 230 emergency call that draws a response from law enforcement prepared 231 for a violent confrontation (e.g. a fake hostage situation that 232 results in dispatching of a "Special Weapons And Tactics" (SWAT) 233 team). In 2008 the Federal Bureau of Investigation (FBI) issued a 234 warning [Swatting] about an increase in the frequency and 235 sophistication of these attacks. 237 As noted in [EENA], many documented cases of "swatting" involve not 238 only the faking of an emergency, but also falsification or 239 obfuscation of identity. There are a number of techniques by which 240 hoax callers attempt to avoid identification, and in general, the 241 ability to identify the caller appears to influence the incidence of 242 hoax calls. 244 Where a Voice Service Provider enables setting of the outbound caller 245 identification without checking it against the authenticated 246 identity, forging caller identification is trivial. Similarly where 247 an attacker can gain entry to a Private Branch Exchange (PBX), they 248 can then subsequently use that access to launch a denial of service 249 attack against the PSAP, or to make fraudulent emergency calls. 250 Where emergency calls have been allowed from handsets lacking a SIM 251 card, or where ownership of the SIM card cannot be determined, the 252 frequency of hoax calls has often been unacceptably high 253 [TASMANIA][UK][SA]. 255 However, there are few documented cases of hoax calls that have 256 arisen from conveyance of untrustworthy location information within 257 an emergency call, which is the focus of this document. 259 1.2.2. Existing IETF Work 261 The Internet architecture for emergency calling is described in 262 "Framework for Emergency Calling Using Internet Multimedia" [RFC6443] 263 and "Best Current Practice for Communications Services in Support of 264 Emergency Calling" [RFC6881]. The conveyance of location information 265 within the Session Initiation Protocol (SIP) is described in 266 "Location Conveyance for the Session Initiation Protocol" [RFC6442], 267 which in the Security Considerations (Section 7) includes discussion 268 of privacy, authentication and integrity concerns relating to 269 conveyed location. Note that while [RFC6442] does not prohibit the 270 conveyance of location within non-emergency calls, in practice, 271 location conveyance requires additional infrastructure as described 272 in [RFC6443]. As a result, privacy issues inherent in conveyance of 273 location within non-emergency calls are not considered within 274 [RFC6442]. 276 "Secure Telephone Identity Threat Model" [I-D.ietf-stir-threats] 277 analyzes threats relating to impersonation and obscuring of calling 278 party numbers, reviewing the capabilities available to attackers, and 279 the scenarios in which attacks are launched. 281 "An Architecture for Location and Location Privacy in Internet 282 Applications" [RFC6280] describes an architecture for privacy- 283 preserving location-based services in the Internet, focusing on 284 authorization, security and privacy requirements for the data formats 285 and protocols used by these services. Within the Security 286 Considerations (Section 5), mechanisms for ensuring the security of 287 the location distribution chain are discussed; these include 288 mechanisms for hop-by-hop confidentiality and integrity protection as 289 well as end-to-end assurance. As noted in Section 6.3: 291 "there are three critical steps in the placement of an emergency 292 call, each involving location information: 294 1. Determine the location of the caller. 296 2. Determine the proper Public Safety Answering Point (PSAP) for 297 the caller's location. 299 3. Send a SIP INVITE message, including the caller's location, to 300 the PSAP." 302 "Geopriv Requirements" [RFC3693] focuses on the authorization, 303 security and privacy requirements of location-dependent services, 304 including emergency services. Within the Security Considerations 305 (Section 8), this includes discussion of emergency services 306 authentication (Section 8.3), and issues relating to identity and 307 anonymity (Section 8.4). 309 "Threat Analysis of the Geopriv Protocol" [RFC3694] describes threats 310 against geographic location privacy, including protocol threats, 311 threats resulting from the storage of geographic location data, and 312 threats posed by the abuse of information. 314 "Security Threats and Requirements for Emergency Call Marking and 315 Mapping" [RFC5069] reviews security threats associated with the 316 marking of signalling messages and the process of mapping locations 317 to Universal Resource Identifiers (URIs) that point to PSAPs. RFC 318 5069 describes attacks on the emergency services system, such as 319 attempting to deny system services to all users in a given area, to 320 gain fraudulent use of services and to divert emergency calls to non- 321 emergency sites. In addition, it describes attacks against 322 individuals, including attempts to prevent an individual from 323 receiving aid, or to gain information about an emergency, as well as 324 attacks on emergency services infrastructure elements, such as 325 mapping discovery and mapping servers. 327 2. Threat Model 329 To provide a structured analysis we distinguish between three 330 adversary models: 332 External adversary model: The end host, e.g., an emergency caller 333 whose location is going to be communicated, is honest and the 334 adversary may be located between the end host and the location 335 server or between the end host and the PSAP. None of the 336 emergency service infrastructure elements act maliciously. 338 Malicious infrastructure adversary model: The emergency call routing 339 elements, such as the Location Information Server (LIS), the 340 Location-to-Service Translation (LoST) infrastructure, used for 341 mapping locations to PSAP address, or call routing elements, may 342 act maliciously. 344 Malicious end host adversary model: The end host itself acts 345 maliciously, whether the owner is aware of this or whether it is 346 acting under the control of a third party. 348 Since previous work describes attacks against infrastructure elements 349 (e.g. location servers, call route servers, mapping servers) or the 350 emergency services IP network, as well as threats from attackers 351 attempting to snoop location in transit, this document focuses on the 352 threats arising from end hosts providing false location information 353 within emergency calls (the malicious end host adversary model). 355 Since the focus is on malicious hosts, we do not cover threats that 356 may arise from attacks on infrastructure that hosts depend on to 357 obtain location. For example, end hosts may obtain location from 358 civilian GPS, which is vulnerable to spoofing [GPSCounter] or from 359 third party Location Service Providers (LSPs) which may be vulnerable 360 to attack or may not provide location accuracy suitable for emergency 361 purposes. 363 Also, we do not cover threats arising from inadequate location 364 infrastructure. For example, a stale wiremap or an inaccurate access 365 point location database could be utilized by the Location Information 366 Server (LIS) or the end host in its location determination, thereby 367 leading to an inaccurate determination of location. Similarly, a 368 Voice Service Provider (VSP) (and indirectly a LIS) could utilize the 369 wrong identity (such as an IP address) for location lookup, thereby 370 providing the end host with misleading location information. 372 2.1. Location Spoofing 374 Where location is attached to the emergency call by an end host, the 375 end host can fabricate a PIDF-LO and convey it within an emergency 376 call. The following represent examples of location spoofing: 378 Place shifting: Trudy, the adversary, pretends to be at an 379 arbitrary location. 381 Time shifting: Trudy pretends to be at a location she was a 382 while ago. 384 Location theft: Trudy observes or obtains Alice's location and 385 replays it as her own. 387 2.2. Identity Spoofing 389 While this document does not focus on the problems created by 390 determination of location based on spoofed caller identification, the 391 ability to ascertain identity is important, since the threat of 392 punishment reduces hoax calls. As an example, calls from pay phones 393 are subject to greater scrutiny by the call taker. 395 With calls originating on an IP network, at least two forms of 396 identity are relevant, with the distinction created by the split 397 between the IAP and the VSP: 399 (a) network access identity such as might be determined via 400 authentication (e.g., using the Extensible Authentication Protocol 401 (EAP) [RFC3748]); 403 (b) caller identity, such as might be determined from authentication 404 of the emergency caller at the VoIP application layer. 406 If the adversary did not authenticate itself to the VSP, then 407 accountability may depend on verification of the network access 408 identity. However, this also may not have been authenticated, such 409 as in the case where an open IEEE 802.11 Access Point is used to 410 initiate a hoax emergency call. Although endpoint information such 411 as the IP or MAC address may have been logged, tying this back to the 412 device owner may be challenging. 414 Unlike the existing telephone system, VoIP emergency calls can 415 provide an identity that need not necessarily be coupled to a 416 business relationship with the IAP, ISP or VSP. However, due to the 417 time-critical nature of emergency calls, multi-layer authentication 418 is undesirable, so that in most cases, only the device placing the 419 call will be able to be identified. Furthermore, deploying 420 additional credentials for emergency service purposes (such as 421 certificates) increases costs, introduces a significant 422 administrative overhead and is only useful if widely deployed. 424 3. Mitigation Techniques 426 The sections that follow present three mechanisms for mitigating the 427 threats presented in Section 2: 429 1. Signed location by value (Section 3.1), which provides for 430 authentication and integrity protection of the PIDF-LO. At the 431 time of this writing, there is only an expired straw-man proposal 432 for this mechanism [I-D.thomson-geopriv-location-dependability], 433 so that it is not suitable for deployment. 435 2. Location-by-reference (Section 3.2), which enables location to 436 be obtained by the PSAP directly from the location server, over a 437 confidential and integrity-protected channel, avoiding 438 modification by the end-host or an intermediary. This mechanism 439 is specified in [RFC6753]. 441 3. Proxy added location (Section 3.3), which protects against 442 location forgery by the end host. This mechanism is specified in 443 [RFC6442]. 445 3.1. Signed Location by Value 447 With location signing, a location server signs the location 448 information before it is sent to the Target. The signed location 449 information is then sent to the location recipient, who verifies it. 451 Figure 1 shows the communication model with the target requesting 452 signed location in step (a), the location server returns it in step 453 (b) and it is then conveyed to the location recipient in step (c) who 454 verifies it. For SIP, the procedures described in "Location 455 Conveyance for the Session Initiation Protocol" [RFC6442] are 456 applicable for location conveyance. 458 +-----------+ +-----------+ 459 | | | Location | 460 | LIS | | Recipient | 461 | | | | 462 +-+-------+-+ +----+------+ 463 ^ | --^ 464 | | -- 465 Geopriv |Req. | -- 466 Location |Signed |Signed -- Protocol Conveying 467 Configuration |Loc. |Loc. -- Location (e.g. SIP) 468 Protocol |(a) |(b) -- (c) 469 | v -- 470 +-+-------+-+ -- 471 | Target / | -- 472 | End Host + 473 | | 474 +-----------+ 476 Figure 1: Location Signing 478 A straw-man proposal for location signing is provided in "Digital 479 Signature Methods for Location Dependability" [I-D.thomson-geopriv- 480 location-dependability]. Note that since this document is no longer 481 under development, location signing cannot be considered deployable 482 at the time of this writing. 484 In order to limit replay attacks, this document proposes the addition 485 of a "validity" element to the PIDF-LO, including a "from" sub- 486 element containing the time that location information was validated 487 by the signer, as well as an "until" sub-element containing the last 488 time that the signature can be considered valid. 490 One of the consequences of including an "until" element is that even 491 a stationary target would need to periodically obtain a fresh PIDF- 492 LO, or incur the additional delay of querying during an emergency 493 call. 495 Although privacy-preserving procedures may be disabled for emergency 496 calls, by design, PIDF-LO objects limit the information available for 497 real-time attribution. As noted in [RFC5985] Section 6.6: 499 The LIS MUST NOT include any means of identifying the Device in 500 the PIDF-LO unless it is able to verify that the identifier is 501 correct and inclusion of identity is expressly permitted by a Rule 502 Maker. Therefore, PIDF parameters that contain identity are 503 either omitted or contain unlinked pseudonyms [RFC3693]. A 504 unique, unlinked presentity URI SHOULD be generated by the LIS for 505 the mandatory presence "entity" attribute of the PIDF document. 507 Optional parameters such as the "contact" and "deviceID" elements 508 [RFC4479] are not used. 510 Also, the device referred to in the PIDF-LO may not necessarily be 511 the same entity conveying the PIDF-LO to the PSAP. As noted in 512 [RFC6442] Section 1: 514 In no way does this document assume that the SIP user agent client 515 that sends a request containing a location object is necessarily 516 the Target. The location of a Target conveyed within SIP 517 typically corresponds to that of a device controlled by the 518 Target, for example, a mobile phone, but such devices can be 519 separated from their owners, and moreover, in some cases, the user 520 agent may not know its own location. 522 Without the ability to tie the target identity to the identity 523 asserted in the SIP message, it is possible for an attacker to cut 524 and paste a PIDF-LO obtained by a different device or user into a SIP 525 INVITE and send this to the PSAP. This cut and paste attack could 526 succeed even when a PIDF-LO is signed, or [RFC4474] is implemented. 528 To address location-spoofing attacks, [I-D.thomson-geopriv-location- 529 dependability] proposes addition of an "identity" element which could 530 include a SIP URI (enabling comparison against the identity asserted 531 in the SIP headers) or an X.509v3 certificate. If the target was 532 authenticated by the LIS, an "authenticated" attribute is added. 533 However, inclusion of an "identity" attribute could enable location 534 tracking, so that a "hash" element is also proposed which could 535 contain a hash of the content of the "identity" element instead. In 536 practice, such a hash would not be much better for real-time 537 validation than a pseudonym. 539 Location signing cannot deter attacks in which valid location 540 information is provided. For example, an attacker in control of 541 compromised hosts could launch a denial-of-service attack on the PSAP 542 by initiating a large number of emergency calls, each containing 543 valid signed location information. Since the work required to verify 544 the location signature is considerable, this could overwhelm the PSAP 545 infrastructure. 547 However, while DDOS attacks are unlikely to be deterred by location 548 signing, accurate location information would limit the subset of 549 compromised hosts that could be used for an attack, as only hosts 550 within the PSAP serving area would be useful in placing emergency 551 calls. 553 Location signing is also difficult when the host obtains location via 554 mechanisms such as GPS, unless trusted computing approaches, with 555 tamper-proof GPS modules, can be applied. Otherwise, an end host can 556 pretend to have a GPS device, and the recipient will need to rely on 557 its ability to assess the level of trust that should be placed in the 558 end host location claim. 560 Even though location signing mechanisms have not been standardized, 561 [NENA-i2] Section 3.7 includes operational recommendations relating 562 to location signing: 564 Location determination is out of scope for NENA, but we can offer 565 guidance on what should be considered when designing mechanisms to 566 report location: 568 1. The location object should be digitally signed. 570 2. The certificate for the signer (LIS operator) should be 571 rooted in VESA. For this purpose, VPC and ERDB operators 572 should issue certs to LIS operators. 574 3. The signature should include a timestamp. 576 4. Where possible, the Location Object should be refreshed 577 periodically, with the signature (and thus the timestamp) 578 being refreshed as a consequence. 580 5. Anti-spoofing mechanisms should be applied to the Location 581 Reporting method. 583 [Note: The term Valid Emergency Services Authority (VESA) refers 584 to the root certificate authority. VPC stands for VoIP 585 Positioning Center and ERDB stands for the Emergency Service Zone 586 Routing Database.] 588 As noted above, signing of location objects implies the development 589 of a trust hierarchy that would enable a certificate chain provided 590 by the LIS operator to be verified by the PSAP. Rooting the trust 591 hierarchy in VESA can be accomplished either by having the VESA 592 directly sign the LIS certificates, or by the creation of 593 intermediate Certificate Authorities (CAs) certified by the VESA, 594 which will then issue certificates to the LIS. In terms of the 595 workload imposed on the VESA, the latter approach is highly 596 preferable. However, this raises the question of who would operate 597 the intermediate CAs and what the expectations would be. 599 In particular, the question arises as to the requirements for LIS 600 certificate issuance, and how they would compare to requirements for 601 issuance of other certificates such as an SSL/TLS web certificate. 603 3.2. Location by Reference 605 Location-by-reference was developed so that end hosts can avoid 606 having to periodically query the location server for up-to-date 607 location information in a mobile environment. Additionally, if 608 operators do not want to disclose location information to the end 609 host without charging them, location-by-reference provides a 610 reasonable alternative. Also, since location-by-reference enables 611 the PSAP to directly contact the location server, it avoids potential 612 attacks by intermediaries. As noted in "A Location Dereference 613 Protocol Using HTTP-Enabled Location Delivery (HELD)" [RFC6753], a 614 location reference can be obtained via HTTP-Enabled Location Delivery 615 (HELD) [RFC5985]. 617 Figure 2 shows the communication model with the target requesting a 618 location reference in step (a), the location server returns the 619 reference in step (b), and it is then conveyed to the location 620 recipient in step (c). The location recipient needs to resolve the 621 reference with a request in step (d). Finally, location information 622 is returned to the Location Recipient afterwards. For location 623 conveyance in SIP, the procedures described in [RFC6442] are 624 applicable. 626 +-----------+ Geopriv +-----------+ 627 | | Location | Location | 628 | LIS +<------------->+ Recipient | 629 | | Dereferencing | | 630 +-+-------+-+ Protocol (d) +----+------+ 631 ^ | --^ 632 | | -- 633 Geopriv |Req. | -- 634 Location |LbyR |LbyR -- Protocol Conveying 635 Configuration |(a) |(b) -- Location (e.g. SIP) 636 Protocol | | -- (c) 637 | V -- 638 +-+-------+-+ -- 639 | Target / | -- 640 | End Host + 641 | | 642 +-----------+ 644 Figure 2: Location by Reference 646 Where location by reference is provided, the recipient needs to 647 deference the LbyR in order to obtain location. The details for the 648 dereferencing operations vary with the type of reference, such as a 649 HTTP, HTTPS, SIP, SIPS URI or a SIP presence URI. 651 For location-by-reference, the location server needs to maintain one 652 or several URIs for each target, timing out these URIs after a 653 certain amount of time. References need to expire to prevent the 654 recipient of such a Uniform Resource Locator (URL) from being able to 655 permanently track a host and to offer garbage collection 656 functionality for the location server. 658 Off-path adversaries must be prevented from obtaining the target's 659 location. The reference contains a randomized component that 660 prevents third parties from guessing it. When the location recipient 661 fetches up-to-date location information from the location server, it 662 can also be assured that the location information is fresh and not 663 replayed. However, this does not address location theft. 665 With respect to the security of the de-reference operation, [RFC6753] 666 Section 6 states: 668 TLS MUST be used for dereferencing location URIs unless 669 confidentiality and integrity are provided by some other 670 mechanism, as discussed in Section 3. Location Recipients MUST 671 authenticate the host identity using the domain name included in 672 the location URI, using the procedure described in Section 3.1 of 673 [RFC2818]. Local policy determines what a Location Recipient does 674 if authentication fails or cannot be attempted. 676 The authorization by possession model (Section 4.1) further relies 677 on TLS when transmitting the location URI to protect the secrecy 678 of the URI. Possession of such a URI implies the same privacy 679 considerations as possession of the PIDF-LO document that the URI 680 references. 682 Location URIs MUST only be disclosed to authorized Location 683 Recipients. The GEOPRIV architecture [RFC6280] designates the 684 Rule Maker to authorize disclosure of the URI. 686 Protection of the location URI is necessary, since the policy 687 attached to such a location URI permits anyone who has the URI to 688 view the associated location information. This aspect of security 689 is covered in more detail in the specification of location 690 conveyance protocols, such as [RFC6442]. 692 For authorizing access to location-by-reference, two authorization 693 models were developed: "Authorization by Possession" and 694 "Authorization via Access Control Lists". With respect to 695 "Authorization by Possession" [RFC6753] Section 4.1 notes: 697 In this model, possession -- or knowledge -- of the location URI 698 is used to control access to location information. A location URI 699 might be constructed such that it is hard to guess (see C8 of 700 [RFC5808]), and the set of entities that it is disclosed to can be 701 limited. The only authentication this would require by the LS is 702 evidence of possession of the URI. The LS could immediately 703 authorize any request that indicates this URI. 705 Authorization by possession does not require direct interaction 706 with Rule Maker; it is assumed that the Rule Maker is able to 707 exert control over the distribution of the location URI. 708 Therefore, the LIS can operate with limited policy input from a 709 Rule Maker. 711 Limited disclosure is an important aspect of this authorization 712 model. The location URI is a secret; therefore, ensuring that 713 adversaries are not able to acquire this information is paramount. 714 Encryption, such as might be offered by TLS [RFC5246] or S/MIME 715 [RFC5751], protects the information from eavesdroppers. 717 Using possession as a basis for authorization means that, once 718 granted, authorization cannot be easily revoked. Cancellation of 719 a location URI ensures that legitimate users are also affected; 720 application of additional policy is theoretically possible but 721 could be technically infeasible. Expiration of location URIs 722 limits the usable time for a location URI, requiring that an 723 attacker continue to learn new location URIs to retain access to 724 current location information. 726 In situations where "Authorization by Possession" is not suitable 727 (such as where location hiding [RFC6444] is required), the 728 "Authorization via Access Control Lists" model may be preferred. 730 Without the introduction of hierarchy, it would be necessary for the 731 PSAP to obtain client certificates or Digest credentials for all the 732 LISes in its coverage area, to enable it to successfully dereference 733 LbyRs. In situations with more than a few LISes per PSAP, this would 734 present operational challenges. 736 A certificate hierarchy providing PSAPs with client certificates 737 chaining to the VESA could be used to enable the LIS to authenticate 738 and authorize PSAPs for dereferencing. Note that unlike PIDF-LO 739 signing (which mitigates against modification of PIDF-LOs), this 740 merely provides the PSAP with access to a (potentially unsigned) 741 PIDF-LO, albeit over a protected TLS channel. 743 Another approach would be for the local LIS to upload location 744 information to a location aggregation point who would in turn manage 745 the relationships with the PSAP. This would shift the management 746 burden from the PSAPs to the location aggregation points. 748 3.3. Proxy Adding Location 750 Instead of relying upon the end host to provide location, is possible 751 for a proxy that has the ability to determine the location of the end 752 point (e.g., based on the end host IP or MAC address) to retrieve and 753 add or override location information. 755 The use of proxy-added location is primarily applicable in scenarios 756 where the end host does not provide location. As noted in [RFC6442] 757 Section 4.1: 759 A SIP intermediary SHOULD NOT add location to a SIP request that 760 already contains location. This will quite often lead to 761 confusion within LRs. However, if a SIP intermediary adds 762 location, even if location was not previously present in a SIP 763 request, that SIP intermediary is fully responsible for addressing 764 the concerns of any 424 (Bad Location Information) SIP response it 765 receives about this location addition and MUST NOT pass on 766 (upstream) the 424 response. A SIP intermediary that adds a 767 locationValue MUST position the new locationValue as the last 768 locationValue within the Geolocation header field of the SIP 769 request. 771 A SIP intermediary MAY add a Geolocation header field if one is 772 not present -- for example, when a user agent does not support the 773 Geolocation mechanism but their outbound proxy does and knows the 774 Target's location, or any of a number of other use cases (see 775 Section 3). 777 As noted in [RFC6442] Section 3.3: 779 This document takes a "you break it, you bought it" approach to 780 dealing with second locations placed into a SIP request by an 781 intermediary entity. That entity becomes completely responsible 782 for all location within that SIP request (more on this in Section 783 4). 785 While it is possible for the proxy to override location included by 786 the end host, [RFC6442] Section 3.4 notes the operational 787 limitations: 789 Overriding location information provided by the user requires a 790 deployment where an intermediary necessarily knows better than an 791 end user -- after all, it could be that Alice has an on-board GPS, 792 and the SIP intermediary only knows her nearest cell tower. Which 793 is more accurate location information? Currently, there is no way 794 to tell which entity is more accurate or which is wrong, for that 795 matter. This document will not specify how to indicate which 796 location is more accurate than another. 798 The disadvantage of this approach is the need to deploy application 799 layer entities, such as SIP proxies, at IAPs or associated with IAPs. 800 This requires a standardized VoIP profile to be deployed at every end 801 device and at every IAP. This might impose interoperability 802 challenges. 804 Additionally, the IAP needs to take responsibility for emergency 805 calls, even for customers they have no direct or indirect 806 relationship with. To provide identity information about the 807 emergency caller from the VSP it would be necessary to let the IAP 808 and the VSP to interact for authentication (see, for example, 809 "Diameter Session Initiation Protocol (SIP) Application" [RFC4740]). 810 This interaction along the Authentication, Authorization and 811 Accounting infrastructure is often based on business relationships 812 between the involved entities. An arbitrary IAP and VSP are unlikely 813 to have a business relationship. In case the interaction between the 814 IAP and the VSP fails due to the lack of a business relationship then 815 typically a fall-back would be provided where no emergency caller 816 identity information is made available to the PSAP and the emergency 817 call still has to be completed. 819 4. Location Trust Assessment 821 The ability to assess the level of trustworthiness of conveyed 822 location information is important, since this makes it possible to 823 understand how much value should be placed on location information, 824 as part of the decision making process. As an example, if automated 825 location information is understood to be highly suspect or is absent, 826 a call taker can put more effort into verifying the authenticity of 827 the call and to obtaining location information from the caller. 829 Location trust assessment has value regardless of whether the 830 location itself is authenticated (e.g. signed location) or is 831 obtained directly from the location server (e.g. location-by- 832 reference) over security transport, since these mechanisms do not 833 provide assurance of the validity or provenance of location data. 835 To prevent location-theft attacks, the "entity" element of the PIDF- 836 LO is of limited value if an unlinked pseudonym is provided in this 837 field. However, if the LIS authenticates the target, then the 838 linkage between the pseudonym and the target identity can be 839 recovered in a post-incident investigation. 841 As noted in [I.D.thomson-geopriv-location-dependability], if the 842 location object was signed, the location recipient has additional 843 information on which to base their trust assessment, such as the 844 validity of the signature, the identity of the target, the identity 845 of the LIS, whether the LIS authenticated the target, and the 846 identifier included in the "entity" field. 848 Caller accountability is also an important aspect of trust 849 assessment. Can the individual purchasing the device or activating 850 service be identified or did the call originate from a non-service 851 initialized (NSI) device whose owner cannot be determined? Prior to 852 the call, was the caller authenticated at the network or application 853 layer? In the event of a hoax call, can audit logs be made available 854 to an investigator, or can information relating to the owner of an 855 unlinked pseudonym be provided, enabling investigators to unravel the 856 chain of events that lead to the attack? 858 In practice, the source of the location data is important for 859 location trust assessment. For example, location provided by a 860 Location Information Server (LIS) whose administrator has an 861 established history of meeting emergency location accuracy 862 requirements (e.g. Phase II) may be considered more reliable than 863 location information provided by a third party Location Service 864 Provider (LSP) that disclaims use of location information for 865 emergency purposes. 867 However, even where an LSP does not attempt to meet the accuracy 868 requirements for emergency location, it still may be able to provide 869 information useful in assessing about how reliable location 870 information is likely to be. For example, was location determined 871 based on the nearest cell tower or 802.11 Access Point (AP), or was a 872 triangulation method used? If based on cell tower or AP location 873 data, was the information obtained from an authoritative source (e.g. 874 the tower or AP owner) and when was the last time that the location 875 of the tower or access point was verified? 877 For real-time validation, information in the signaling and media 878 packets can be cross checked against location information. For 879 example, it may be possible to determine the city, state, country or 880 continent associated with the IP address included within SIP Via: or 881 Contact: headers, or the media source address, and compare this 882 against the location information reported by the caller or conveyed 883 in the PIDF-LO. However, in some situations only entities close to 884 the caller may be able to verify the correctness of location 885 information. 887 Real-time validation of the timestamp contained within PIDF-LO 888 objects (reflecting the time at which the location was determined) is 889 also challenging. To address time-shifting attacks, the "timestamp" 890 element of the PIDF-LO, defined in [RFC3863], can be examined and 891 compared against timestamps included within the enclosing SIP 892 message, to determine whether the location data is sufficiently 893 fresh. However, the timestamp only represents an assertion by the 894 LIS, which may or may not be trustworthy. For example, the recipient 895 of the signed PIDF-LO may not know whether the LIS supports time 896 synchronization, or whether it is possible to reset the LIS clock 897 manually without detection. Even if the timestamp was valid at the 898 time location was determined, a time period may elapse between when 899 the PIDF-LO was provided and when it is conveyed to the recipient. 900 Periodically refreshing location information to renew the timestamp 901 even though the location information itself is unchanged puts 902 additional load on LISes. As a result, recipients need to validate 903 the timestamp in order to determine whether it is credible. 905 While this document focuses on the discussion of real-time 906 determination of suspicious emergency calls, the use of audit logs 907 may help in enforcing accountability among emergency callers. For 908 example, in the event of a hoax call, information relating to the 909 owner of the unlinked pseudonym could be provided to investigators, 910 enabling them to unravel the chain of events that lead to the attack. 911 However, while auditability is an important deterrent, it is likely 912 to be of most benefit in situations where attacks on the emergency 913 services system are likely to be relatively infrequent, since the 914 resources required to pursue an investigation are likely to be 915 considerable. However, although real-time validation based on PIDF- 916 LO elements is challenging, where LIS audit logs are available (such 917 as where a law enforcement agency can present a subpoena), linking of 918 a pseudonym to the device obtaining location can be accomplished 919 during an investigation. 921 Where attacks are frequent and continuous, automated mechanisms are 922 required. For example, it might be valuable to develop mechanisms to 923 exchange audit trails information in a standardized format between 924 ISPs and PSAPs / VSPs and PSAPs or heuristics to distinguish 925 potentially fraudulent emergency calls from real emergencies. While 926 a Completely Automated Public Turing test to tell Computers and 927 Humans Apart (CAPTCHA) may be applied to suspicious calls to lower 928 the risk from bot-nets, this is quite controversial for emergency 929 services, due to the risk of delaying or rejecting valid calls. 931 5. Security Considerations 933 Although it is important to ensure that location information cannot 934 be faked, the mitigation techniques presented in this document are 935 not universally applicable. For example, there will be many GPS- 936 enabled devices that will find it difficult to utilize any of the 937 solutions described in Section 3. It is also unlikely that users 938 will be willing to upload their location information for 939 "verification" to a nearby location server located in the access 940 network. 942 This document focuses on threats that arise from conveyance of 943 misleading location information, rather than caller identification or 944 authentication and integrity protection of the messages in which 945 location is conveyed. Nevertheless, these aspects are important. In 946 some countries, regulators may not require the authenticated identity 947 of the emergency caller (e.g. emergency calls placed from PSTN pay 948 phones or SIM-less cell phones). Furthermore, if identities can 949 easily be crafted (as it is the case with many VoIP offerings today), 950 then the value of emergency caller authentication itself might be 951 limited. As a result, attackers can forge emergency call information 952 with a lower risk of being held accountable, which may encourage hoax 953 calls. 955 In order to provide authentication and integrity protection for the 956 Session Initiation Protocol (SIP) messages conveying location, 957 several security approaches are available. It is possible to ensure 958 that modification of the identity and location in transit can be 959 detected by the location recipient (e.g., the PSAP), using 960 cryptographic mechanisms, as described in "Enhancements for 961 Authenticated Identity Management in the Session Initiation Protocol" 962 [RFC4474]. However, compatibility with Session Border Controllers 963 (SBCs) that modify integrity-protected headers has proven to be an 964 issue in practice, and as a result, a revision is in progress 965 [I.D.jennings-stir-rfc4474bis]. In the absence of an end-to-end 966 solution, SIP over Transport Layer Security (TLS) can be used to 967 provide message authentication and integrity protection hop-by-hop. 969 PSAPs remain vulnerable to distributed denial of service attacks, 970 even where the mitigation techniques described in this document are 971 utilized. Placing a large number of emergency calls that appear to 972 come from different locations is an example of an attack that is 973 difficult to carry out within the legacy system, but is easier to 974 imagine within IP-based emergency services. Also, in the current 975 system, it would be very difficult for an attacker from country 'Foo' 976 to attack the emergency services infrastructure located in country 977 'Bar', but this attack is possible within IP-based emergency 978 services. 980 While manually mounting the attacks described in Section 2 is non- 981 trivial, the attacks described in this document can be automated. 982 While manually carrying out a location theft would require the 983 attacker to be in proximity to the location being spoofed, or to 984 collude with another end host, an attacker able to run code on an end 985 host can obtain its location, and cause an emergency call to be made. 986 While manually carrying out a time shifting attack would require that 987 the attacker visit the location and submit it before the location 988 information is considered stale, while travelling rapidly away from 989 that location to avoid apprehension, these limitations would not 990 apply to an attacker able to run code on the end host. While 991 obtaining a PIDF-LO from a spoofed IP address requires that the 992 attacker be on the path between the HELD requester and the LIS, if 993 the attacker is able to run code requesting the PIDF-LO, retrieve it 994 from the LIS, and then make an emergency call using it, this attack 995 becomes much easier. To mitigate the risk of automated attacks, 996 service providers can limit the ability of untrusted code (such as 997 WebRTC applications written in Javascript) to make emergency calls. 999 Emergency services have three finite resources subject to denial of 1000 service attacks: the network and server infrastructure, call takers 1001 and dispatchers, and the first responders, such as fire fighters and 1002 police officers. Protecting the network infrastructure is similar to 1003 protecting other high-value service providers, except that location 1004 information may be used to filter call setup requests, to weed out 1005 requests that are out of area. Even for large cities PSAPs may only 1006 have a handful of call takers on duty. So even if automated 1007 techniques are utilized to evaluate the trustworthiness of conveyed 1008 location and call takers can, by questioning the caller, eliminate 1009 many hoax calls, PSAPs can be overwhelmed even by a small-scale 1010 attack. Finally, first responder resources are scarce, particularly 1011 during mass-casualty events. 1013 6. IANA Considerations 1015 This document does not require actions by IANA. 1017 7. References 1019 7.1. Informative References 1021 [I-D.ietf-stir-problem-statement] 1022 Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 1023 Telephone Identity Problem Statement", Internet draft (work in 1024 progress), draft-ietf-stir-problem-statement-05.txt, May 2014. 1026 [I-D.ietf-stir-threats] 1027 Peterson, J., "Secure Telephone Identity Threat Model", 1028 Internet draft (work in progress), draft-ietf-stir- 1029 threats-02.txt, February 2014. 1031 [I-D.jennings-stir-rfc4474bis] 1032 Peterson, J., Jennings, C. and E. Rescorla, "Authenticated 1033 Identity Management in the Session Initiation Protocol (SIP)", 1034 Internet draft (work in progress), draft-jennings-stir- 1035 rfc4474bis-01.txt, February 2014. 1037 [I-D.thomson-geopriv-location-dependability] 1038 Thomson, M. and J. Winterbottom, "Digital Signature Methods 1039 for Location Dependability", Internet draft (work in 1040 progress), draft-thomson-geopriv-location- 1041 dependability-07.txt, March 2011. 1043 [EENA] EENA, "False Emergency Calls", EENA Operations Document, 1044 Version 1.1, May 2011, http://www.eena.org/ressource/static/ 1045 files/2012_05_04-3.1.2.fc_v1.1.pdf 1047 [GPSCounter] 1048 Warner, J. S. and R. G. Johnston, "GPS Spoofing 1049 Countermeasures", Los Alamos research paper LAUR-03-6163, 1050 December 2003. 1052 [NENA-i2] "08-001 NENA Interim VoIP Architecture for Enhanced 9-1-1 1053 Services (i2)", December 2005. 1055 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1056 Requirement Levels", BCP 14, RFC 2119, March 1997. 1058 [RFC2818] Rescorla, E., "HTTP over TLS", RFC 2818, May 2000. 1060 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. 1061 Polk, "Geopriv Requirements", RFC 3693, February 2004. 1063 [RFC3694] Danley, M., Mulligan, D., Morris, J. and J. Peterson, "Threat 1064 Analysis of the Geopriv Protocol", RFC 3694, February 2004. 1066 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1067 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 1068 3748, June 2004. 1070 [RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W. and 1071 J. Peterson, "Presence Information Data Format (PIDF)", RFC 1072 3863, August 2004. 1074 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated 1075 Identity Management in the Session Initiation Protocol (SIP)", 1076 RFC 4474, August 2006. 1078 [RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, July 1079 2006. 1081 [RFC4740] Garcia-Martin, M., Belinchon, M., Pallares-Lopez, M., Canales- 1082 Valenzuela, C., and K. Tammi, "Diameter Session Initiation 1083 Protocol (SIP) Application", RFC 4740, November 2006. 1085 [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for Emergency 1086 Context Resolution with Internet Technologies", RFC 5012, 1087 January 2008. 1089 [RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H. and M. Shanmugam, 1090 "Security Threats and Requirements for Emergency Call Marking 1091 and Mapping", RFC 5069, January 2008. 1093 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Level Security 1094 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1096 [RFC5491] Winterbottom, J., Thomson, M. and H. Tschofenig, "GEOPRIV 1097 Presence Information Data Format Location Object (PIDF-LO) 1098 Usage Clarification, Considerations, and Recommendations", RFC 1099 5491, March 2009. 1101 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail 1102 Extensions (S/MIME) Version 3.2 Message Specification", RFC 1103 5751, January 2010. 1105 [RFC5808] Marshall, R., "Requirements for a Location-by-Reference 1106 Mechanism", RFC 5808, May 2010. 1108 [RFC5985] Barnes, M., "HTTP Enabled Location Delivery (HELD)", RFC 5985, 1109 September 2010. 1111 [RFC6280] Barnes, R., et. al, "An Architecture for Location and Location 1112 Privacy in Internet Applications", RFC 6280, July 2011. 1114 [RFC6442] Polk, J., Rosen, B. and J. Peterson, "Location Conveyance for 1115 the Session Initiation Protocol", RFC 6442, December 2011. 1117 [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 1118 "Framework for Emergency Calling Using Internet Multimedia", 1119 RFC 6443, December 2011. 1121 [RFC6444] Schulzrinne, H., Liess, L., Tschofenig, H., Stark, B., and A. 1122 Kuett, "Location Hiding: Problem Statement and Requirements", 1123 RFC 6444, January 2012. 1125 [RFC6753] Winterbottom, J., Tschofenig. H., Schulzrinne, H. and M. 1126 Thomson, "A Location Dereference Protocol Using HTTP-Enabled 1127 Location Delivery (HELD)", RFC 6753, October 2012. 1129 [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for 1130 Communications Services in Support of Emergency Calling", BCP 1131 181, RFC 6881, March 2013. 1133 [RFC7090] Schulzrinne, H., Tschofenig, H., Holmberg, C. and M. Patel, 1134 "Public Safety Answering Point (PSAP) Callback", RFC 7090, 1135 April 2014. 1137 [SA] "Saudi Arabia - Illegal sale of SIMs blamed for surge in hoax 1138 calls", Arab News, May 4, 2010, 1139 http://www.menafn.com/qn_news_story_s.asp?StoryId=1093319384 1141 [STIR] IETF, "Secure Telephone Identity Revisited (stir) Working 1142 Group", http://datatracker.ietf.org/wg/stir/charter/, October 1143 2013. 1145 [Swatting] 1146 "Don't Make the Call: The New Phenomenon of 'Swatting', 1147 Federal Bureau of Investigation, February 4, 2008, 1148 http://www.fbi.gov/news/stories/2008/february/swatting020408 1150 [TASMANIA] 1151 "Emergency services seek SIM-less calls block", ABC News 1152 Online, August 18, 2006, 1153 http://www.abc.net.au/elections/tas/2006/news/stories/ 1154 1717956.htm?elections/tas/2006/ 1156 [UK] "Rapper makes thousands of prank 999 emergency calls to UK 1157 police", Digital Journal, June 24, 2010, 1158 http://www.digitaljournal.com/article/293796?tp=1 1160 Acknowledgments 1162 We would like to thank the members of the IETF ECRIT working group, 1163 including Marc Linsner and Brian Rosen, for their input at IETF 85 1164 that helped get this documented pointed in the right direction. We 1165 would also like to thank members of the IETF GEOPRIV WG, including 1166 Andrew Newton, Murugaraj Shanmugam, Martin Thomson, Richard Barnes 1167 and Matt Lepinski for their feedback to previous versions of this 1168 document. Thanks also to Pete Resnick, Adrian Farrel, Alissa Cooper, 1169 Bert Wijnen and Meral Shirazipour who provided review comments in 1170 IETF last call. 1172 Authors' Addresses 1174 Hannes Tschofenig 1175 ARM Ltd. 1176 110 Fulbourn Rd 1177 Cambridge CB1 9NJ 1178 Great Britain 1180 Email: Hannes.tschofenig@gmx.net 1181 URI: http://www.tschofenig.priv.at 1183 Henning Schulzrinne 1184 Columbia University 1185 Department of Computer Science 1186 450 Computer Science Building, New York, NY 10027 1187 US 1189 Phone: +1 212 939 7004 1190 Email: hgs@cs.columbia.edu 1191 URI: http://www.cs.columbia.edu 1193 Bernard Aboba 1194 Microsoft Corporation 1195 One Microsoft Way 1196 Redmond, WA 98052 1197 US 1199 Email: bernard_aboba@hotmail.com