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