idnits 2.17.00 (12 Aug 2021) /tmp/idnits50911/draft-ietf-ecrit-trustworthy-location-10.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 (31 May 2014) is 2912 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 993, but no explicit reference was found in the text == Outdated reference: draft-ietf-stir-problem-statement has been published as RFC 7340 == Outdated reference: draft-ietf-stir-threats has been published as RFC 7375 -- 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 (==), 4 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 1, 2014 Columbia University 6 B. Aboba (ed.) 7 Microsoft Corporation 8 31 May 2014 10 Trustworthy Location 11 draft-ietf-ecrit-trustworthy-location-10.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 focuses on the security issues arising from conveyance 20 of location within an emergency call, and describes mechanisms 21 availble to convey location in a manner that is inherently secure and 22 reliable. It also provides guidelines for assessing the 23 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 1, 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 . . . . . . . . . . . . . . . . . . . . . . . . 7 63 2.1. Location Spoofing . . . . . . . . . . . . . . . . . . . . 8 64 2.2. Identity Spoofing . . . . . . . . . . . . . . . . . . . . 9 65 3. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . . . . . 25 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 after the fact, so as to be able to enforce accountability. 113 This document defines terminology (including the meaning of 114 "trustworthy location") in Section 1.1, reviews existing work in 115 Section 1.2, describes the threat model in Section 2, outlines 116 potential solutions in Section 3, covers trust assessment in Section 117 4 and discusses security considerations in Section 5. 119 1.1. Terminology 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in [RFC2119]. 125 The definitions of "Internet Access Provider (IAP)", "Internet 126 Service Provider (ISP)" and "Voice Service Provider (VSP)" are taken 127 from "Requirements for Emergency Context Resolution with Internet 128 Technologies" [RFC5012]. 130 The definition of a "hoax call" is taken from "False Emergency Calls" 131 [EENA]. 133 The definition of "Target" and "Device" is taken from "An 134 Architecture for Location and Location Privacy in Internet 135 Applications" [RFC6280]. 137 The term "location determination method" refers to the mechanism used 138 to determine the location of a Target. This may be something 139 employed by a location information server (LIS), or by the Target 140 itself. It specifically does not refer to the location configuration 141 protocol (LCP) used to deliver location information either to the 142 Target or the Recipient. This term is re-used from "GEOPRIV PIDF-LO 143 Usage Clarification, Considerations, and Recommendations" [RFC5491]. 145 The term "source" is used to refer to the LIS, node, or device from 146 which a Recipient (Target or Third-Party) obtains location 147 information. 149 Additionally, the terms Location-by-Value (LbyV), Location-by- 150 Reference (LbyR), Location Configuration Protocol, Location 151 Dereference Protocol, and Location Uniform Resource Identifier (URI) 152 are re-used from "Requirements for a Location-by-Reference Mechanism" 153 [RFC5808]. 155 "Trustworthy Location" is defined as location information that can be 156 attributed to a trusted source, has been protected against 157 modification in transmit, and has been assessed as trustworthy. 159 "Location Trust Assessment" refers to the process by which the 160 reliability of location information can be assessed. This topic is 161 discussed in Section 4. 163 The following additional terms apply to location spoofing: 165 "Place Shifting" is where the attacker constructs a Presence 166 Information Data Format Location Object (PIDF-LO) for a location 167 other than where they are currently located. In some cases, place 168 shifting can be limited in range (e.g., within the coverage area of a 169 particular cell tower). 171 "Time Shifting" is where the attacker uses or re-uses location 172 information that was valid in the past, but is no longer valid 173 because the attacker has moved. 175 "Location Theft" is where the attacker captures a Target's location 176 information and presents it as their own. Location theft can occur 177 in a single instance, or may be continuous (e.g., where the attacker 178 has gained control over the victim's device). Location theft may 179 also be combined with time shifting to present someone else's 180 location information after the original Target has moved. 182 "Identity Spoofing" is where the attacker forges or obscures their 183 identity so as to prevent themselves from being identified as the 184 source of the attack. One class of identity spoofing attack involves 185 the forging of call origin identification. 187 1.2. Literature Review 189 There is existing work on the problem of hoax calls, as well as 190 analyses of aspects of the security of emergency services, threats to 191 geographic location privacy, threats relating to spoofing of caller 192 identification and modification of location information in transit. 193 This section reviews the literature. 195 1.2.1. Hoax Calls 197 Hoax calls have been a problem for emergency services dating back to 198 the time of street corner call boxes. The European Emergency Number 199 Association (EENA) has noted [EENA]: "False emergency calls divert 200 emergency services away from people who may be in life-threatening 201 situations and who need urgent help. This can mean the difference 202 between life and death for someone in trouble." As a result, 203 considerable attention has been focused on the problem. 205 EENA [EENA] has attempted to define terminology and describe best 206 current practices for dealing with false emergency calls. Reducing 207 the number of hoax calls represents a challenge, since emergency 208 services authorities in most countries are required to answer every 209 call (whenever possible). Where the caller cannot be identified, the 210 ability to prosecute is limited. 212 A particularly dangerous form of hoax call is "swatting" - a hoax 213 emergency call that draws a response from law enforcement prepared 214 for a violent confrontation (e.g. a fake hostage situation that 215 results in dispatching of a "Special Weapons And Tactics" (SWAT) 216 team). In 2008 the Federal Bureau of Investigation (FBI) issued a 217 warning [Swatting] about an increase in the frequency and 218 sophistication of these attacks. 220 As noted in [EENA], many documented cases of "swatting" involve not 221 only the faking of an emergency, but also falsification or 222 obfuscation of identity. In general, the ability to identify the 223 caller also appears to influence the incidence of hoax calls. Where 224 a Voice Service Provider enables setting of the outbound caller 225 identification without checking it against the authenticated 226 identity, forging caller identification is trivial. Similarly where 227 an attacker can gain entry to a Private Branch Exchange (PBX), they 228 can then subsequently use that access to launch a denial of service 229 attack against the PSAP, or to make fraudulent emergency calls. 230 Where emergency calls have been allowed from handsets lacking a SIM 231 card, or where ownership of the SIM card cannot be determined, the 232 frequency of hoax calls has often been unacceptably high 233 [TASMANIA][UK][SA]. 235 However, to date there have been few documented cases of hoax calls 236 that have arisen from conveyance of untrustworthy location 237 information within an emergency call, which is the focus of this 238 document. 240 1.2.2. Existing IETF Work 242 The Internet architecture for emergency calling is described in 243 "Framework for Emergency Calling Using Internet Multimedia" [RFC6443] 244 and "Best Current Practice for Communications Services in Support of 245 Emergency Calling" [RFC6881]. The conveyance of location information 246 within the Session Initiation Protocol (SIP) is described in 247 "Location Conveyance for the Session Initiation Protocol" [RFC6442], 248 which in the Security Considerations (Section 7) includes discussion 249 of privacy, authentication and integrity concerns relating to 250 conveyed location. Note that while [RFC6442] does not prohibit the 251 conveyance of location within non-emergency calls, in practice, 252 location conveyance requires additional infrastructure as described 253 in [RFC6443]. As a result, privacy issues inherent in conveyance of 254 location within non-emergency calls are not considered within 255 [RFC6442]. 257 "Secure Telephone Identity Threat Model" [I-D.ietf-stir-threats] 258 analyzes threats relating to impersonation and obscuring of calling 259 party numbers, reviewing the capabilities available to attackers, and 260 the scenarios in which attacks are launched. 262 "An Architecture for Location and Location Privacy in Internet 263 Applications" [RFC6280] describes an architecture for privacy- 264 preserving location-based services in the Internet, focusing on 265 authorization, security and privacy requirements for the data formats 266 and protocols used by these services. Within the Security 267 Considerations (Section 5), mechanisms for ensuring the security of 268 the location distribution chain are discussed; these include 269 mechanisms for hop-by-hop confidentiality and integrity protection as 270 well as end-to-end assurance. As noted in Section 6.3: 272 "there are three critical steps in the placement of an emergency 273 call, each involving location information: 275 1. Determine the location of the caller. 277 2. Determine the proper Public Safety Answering Point (PSAP) for the 278 caller's location. 280 3. Send a SIP INVITE message, including the caller's location, to the 281 PSAP." 283 "Geopriv Requirements" [RFC3693] focuses on the authorization, 284 security and privacy requirements of location-dependent services, 285 including emergency services. Within the Security Considerations 286 (Section 8), this includes discussion of emergency services 287 authentication (Section 8.3), and issues relating to identity and 288 anonymity (Section 8.4). 290 "Threat Analysis of the Geopriv Protocol" [RFC3694] describes threats 291 against geographic location privacy, including protocol threats, 292 threats resulting from the storage of geographic location data, and 293 threats posed by the abuse of information. 295 "Security Threats and Requirements for Emergency Call Marking and 296 Mapping" [RFC5069] reviews security threats associated with the 297 marking of signalling messages and the process of mapping locations 298 to Universal Resource Identifiers (URIs) that point to PSAPs. RFC 299 5069 describes attacks on the emergency services system, such as 300 attempting to deny system services to all users in a given area, to 301 gain fraudulent use of services and to divert emergency calls to non- 302 emergency sites. In addition, it describes attacks against 303 individuals, including attempts to prevent an individual from 304 receiving aid, or to gain information about an emergency, as well as 305 attacks on emergency services infrastructure elements, such as 306 mapping discovery and mapping servers. 308 2. Threat Model 310 To provide a structured analysis we distinguish between three 311 adversary models: 313 External adversary model: The end host, e.g., an emergency caller 314 whose location is going to be communicated, is honest and the 315 adversary may be located between the end host and the location 316 server or between the end host and the PSAP. None of the 317 emergency service infrastructure elements act maliciously. 319 Malicious infrastructure adversary model: The emergency call routing 320 elements, such as the Location Information Server (LIS), the 321 Location-to-Service Translation (LoST) infrastructure, used for 322 mapping locations to PSAP address, or call routing elements, may 323 act maliciously. 325 Malicious end host adversary model: The end host itself acts 326 maliciously, whether the owner is aware of this or whether it is 327 acting under the control of a third party. 329 Since previous work describes attacks against infrastructure elements 330 (e.g. location servers, call route servers, mapping servers) or the 331 emergency services IP network, as well as threats from attackers 332 attempting to snoop location in transit, this document focuses on the 333 threats arising from end hosts providing false location information 334 within emergency calls (the malicious end host adversary model). 336 Since the focus is on malicious hosts, we do not cover threats that 337 may arise from attacks on infrastructure that hosts depend on to 338 obtain location. For example, end hosts may obtain location from 339 civilian GPS, which is vulnerable to spoofing [GPSCounter] or from 340 third party Location Service Providers (LSPs) which may be vulnerable 341 to attack or may not provide location accuracy suitable for emergency 342 purposes. 344 Also, we do not cover threats arising from inadequate location 345 infrastructure. For example, a stale wiremap or an inaccurate access 346 point location database could be utilized by the Location Information 347 Server (LIS) or the end host in its location determination, thereby 348 leading to an inaccurate determination of location. Similarly, a 349 Voice Service Provider (VSP) (and indirectly a LIS) could utilize the 350 wrong identity (such as an IP address) for location lookup, thereby 351 providing the end host with misleading location information. 353 2.1. Location Spoofing 355 Where location is attached to the emergency call by an end host, the 356 end host can fabricate a PIDF-LO and convey it within an emergency 357 call. The following represent examples of location spoofing: 359 Place shifting: Trudy, the adversary, pretends to be at an 360 arbitrary location. 362 Time shifting: Trudy pretends to be at a location she was a 363 while ago. 365 Location theft: Trudy observes or obtains Alice's location and 366 replays it as her own. 368 2.2. Identity Spoofing 370 While this document does not focus on the problems created by 371 determination of location based on spoofed caller identification, the 372 ability to ascertain identity is important, since the threat of 373 punishment reduces hoax calls. As an example, calls from pay phones 374 are subject to greater scrutiny by the call taker. 376 With calls originating on an IP network, at least two forms of 377 identity are relevant, with the distinction created by the split 378 between the IAP and the VSP: 380 (a) network access identity such as might be determined via 381 authentication (e.g., using the Extensible Authentication Protocol 382 (EAP) [RFC3748]); 384 (b) caller identity, such as might be determined from authentication 385 of the emergency caller at the VoIP application layer. 387 If the adversary did not authenticate itself to the VSP, then 388 accountability may depend on verification of the network access 389 identity. However, this also may not have been authenticated, such 390 as in the case where an open IEEE 802.11 Access Point is used to 391 initiate a hoax emergency call. Although endpoint information such 392 as the IP or MAC address may have been logged, tying this back to the 393 device owner may be challenging. 395 Unlike the existing telephone system, VoIP emergency calls can 396 provide an identity that need not necessarily be coupled to a 397 business relationship with the IAP, ISP or VSP. However, due to the 398 time-critical nature of emergency calls, multi-layer authentication 399 is undesirable, so that in most cases, only the device placing the 400 call will be able to be identified. Furthermore, deploying 401 additional credentials for emergency service purposes (such as 402 certificates) increases costs, introduces a significant 403 administrative overhead and is only useful if widely deployed. 405 3. Solutions 407 This section presents two mechanisms which can be used to enable 408 location to be authenticated: signed location by value (Section 3.1), 409 which provides for authentication and integrity protection of the 410 PIDF-LO, and location-by-reference (Section 3.2), which enables 411 location to be obtained by the PSAP via direct contact with the 412 location server. In addition, a mechanism is presented which 413 protects against location forgery by the end host: proxy added 414 location (Section 3.3). Since at the time of this writing there is 415 no completed specification for signed location by value, only an 416 expired straw-man proposal, it should be understood that only the 417 location-by-reference and proxy added location mechanisms are 418 suitable for deployment. 420 In order to provide authentication and integrity protection for the 421 Session Initiation Protocol (SIP) messages conveying location, 422 several security approaches are available. It is possible to ensure 423 that modification of the identity and location in transit can be 424 detected by the location recipient (e.g., the PSAP), using 425 cryptographic mechanisms, as described in "Enhancements for 426 Authenticated Identity Management in the Session Initiation Protocol" 427 [RFC4474]. However, compatibility with Session Border Controllers 428 (SBCs) that modify integrity-protected headers has proven to be an 429 issue in practice. As a result, SIP over Transport Layer Security 430 (TLS) is currently a more deployable mechanism to provide per-message 431 authentication and integrity protection hop-by-hop. 433 3.1. Signed Location by Value 435 With location signing, a location server signs the location 436 information before it is sent to the Target. The signed location 437 information is then sent to the location recipient, who verifies it. 439 Figure 1 shows the communication model with the target requesting 440 signed location in step (a), the location server returns it in step 441 (b) and it is then conveyed to the location recipient in step (c) who 442 verifies it. For SIP, the procedures described in "Location 443 Conveyance for the Session Initiation Protocol" [RFC6442] are 444 applicable for location conveyance. 446 +-----------+ +-----------+ 447 | | | Location | 448 | LIS | | Recipient | 449 | | | | 450 +-+-------+-+ +----+------+ 451 ^ | --^ 452 | | -- 453 Geopriv |Req. | -- 454 Location |Signed |Signed -- Protocol Conveying 455 Configuration |Loc. |Loc. -- Location (e.g. SIP) 456 Protocol |(a) |(b) -- (c) 457 | v -- 458 +-+-------+-+ -- 459 | Target / | -- 460 | End Host + 461 | | 462 +-----------+ 464 Figure 1: Location Signing 466 A straw-man proposal for location signing is provided in "Digital 467 Signature Methods for Location Dependability" [I-D.thomson-geopriv- 468 location-dependability]. Note that since this document is no longer 469 under development, location signing cannot be considered deployable 470 at the time of this writing. 472 In order to limit replay attacks, this document proposes the addition 473 of a "validity" element to the PIDF-LO, including a "from" sub- 474 element containing the time that location information was validated 475 by the signer, as well as an "until" sub-element containing the last 476 time that the signature can be considered valid. 478 One of the consequences of including an "until" element is that even 479 a stationary target would need to periodically obtain a fresh PIDF- 480 LO, or incur the additional delay of querying during an emergency 481 call. 483 Although privacy-preserving procedures may be disabled for emergency 484 calls, by design, PIDF-LO objects limit the information available for 485 real-time attribution. As noted in [RFC5985] Section 6.6: 487 The LIS MUST NOT include any means of identifying the Device in 488 the PIDF-LO unless it is able to verify that the identifier is 489 correct and inclusion of identity is expressly permitted by a Rule 490 Maker. Therefore, PIDF parameters that contain identity are 491 either omitted or contain unlinked pseudonyms [RFC3693]. A 492 unique, unlinked presentity URI SHOULD be generated by the LIS for 493 the mandatory presence "entity" attribute of the PIDF document. 495 Optional parameters such as the "contact" and "deviceID" elements 496 [RFC4479] are not used. 498 Also, the device referred to in the PIDF-LO may not necessarily be 499 the same entity conveying the PIDF-LO to the PSAP. As noted in 500 [RFC6442] Section 1: 502 In no way does this document assume that the SIP user agent client 503 that sends a request containing a location object is necessarily 504 the Target. The location of a Target conveyed within SIP 505 typically corresponds to that of a device controlled by the 506 Target, for example, a mobile phone, but such devices can be 507 separated from their owners, and moreover, in some cases, the user 508 agent may not know its own location. 510 Without the ability to tie the target identity to the identity 511 asserted in the SIP message, it is possible for an attacker to cut 512 and paste a PIDF-LO obtained by a different device or user into a SIP 513 INVITE and send this to the PSAP. This cut and paste attack could 514 succeed even when a PIDF-LO is signed, or [RFC4474] is implemented. 516 To address location-spoofing attacks, [I-D.thomson-geopriv-location- 517 dependability] proposes addition of an "identity" element which could 518 include a SIP URI (enabling comparison against the identity asserted 519 in the SIP headers) or an X.509v3 certificate. If the target was 520 authenticated by the LIS, an "authenticated" attribute is added. 521 However, inclusion of an "identity" attribute could enable location 522 tracking, so that a "hash" element is also proposed which could 523 contain a hash of the content of the "identity" element instead. In 524 practice, such a hash would not be much better for real-time 525 validation than a pseudonym. 527 Location signing cannot deter attacks in which valid location 528 information is provided. For example, an attacker in control of 529 compromised hosts could launch a denial-of-service attack on the PSAP 530 by initiating a large number of emergency calls, each containing 531 valid signed location information. Since the work required to verify 532 the location signature is considerable, this could overwhelm the PSAP 533 infrastructure. 535 However, while DDOS attacks are unlikely to be deterred by location 536 signing, accurate location information would limit the subset of 537 compromised hosts that could be used for an attack, as only hosts 538 within the PSAP serving area would be useful in placing emergency 539 calls. 541 Location signing is also difficult when the host obtains location via 542 mechanisms such as GPS, unless trusted computing approaches, with 543 tamper-proof GPS modules, can be applied. Otherwise, an end host can 544 pretend to have a GPS device, and the recipient will need to rely on 545 its ability to assess the level of trust that should be placed in the 546 end host location claim. 548 [NENA-i2] Section 3.7 includes operational recommendations relating 549 to location signing: 551 Location determination is out of scope for NENA, but we can offer 552 guidance on what should be considered when designing mechanisms to 553 report location: 555 1. The location object should be digitally signed. 557 2. The certificate for the signer (LIS operator) should be 558 rooted in VESA. For this purpose, VPC and ERDB operators 559 should issue certs to LIS operators. 561 3. The signature should include a timestamp. 563 4. Where possible, the Location Object should be refreshed 564 periodically, with the signature (and thus the timestamp) 565 being refreshed as a consequence. 567 5. Anti-spoofing mechanisms should be applied to the Location 568 Reporting method. 570 [Note: The term Valid Emergency Services Authority (VESA) refers 571 to the root certificate authority. VPC stands for VoIP 572 Positioning Center and ERDB stands for the Emergency Service Zone 573 Routing Database.] 575 As noted above, signing of location objects implies the development 576 of a trust hierarchy that would enable a certificate chain provided 577 by the LIS operator to be verified by the PSAP. Rooting the trust 578 hierarchy in VESA can be accomplished either by having the VESA 579 directly sign the LIS certificates, or by the creation of 580 intermediate Certificate Authorities (CAs) certified by the VESA, 581 which will then issue certificates to the LIS. In terms of the 582 workload imposed on the VESA, the latter approach is highly 583 preferable. However, this raises the question of who would operate 584 the intermediate CAs and what the expectations would be. 586 In particular, the question arises as to the requirements for LIS 587 certificate issuance, and how they would compare to requirements for 588 issuance of other certificates such as an SSL/TLS web certificate. 590 3.2. Location by Reference 592 Location-by-reference was developed so that end hosts can avoid 593 having to periodically query the location server for up-to-date 594 location information in a mobile environment. Additionally, if 595 operators do not want to disclose location information to the end 596 host without charging them, location-by-reference provides a 597 reasonable alternative. Also, since location-by-reference enables 598 the PSAP to directly contact the location server, it avoids potential 599 attacks by intermediaries. As noted in "A Location Dereference 600 Protocol Using HTTP-Enabled Location Delivery (HELD)" [RFC6753], a 601 location reference can be obtained via HTTP-Enabled Location Delivery 602 (HELD) [RFC5985]. 604 Figure 2 shows the communication model with the target requesting a 605 location reference in step (a), the location server returns the 606 reference in step (b), and it is then conveyed to the location 607 recipient in step (c). The location recipient needs to resolve the 608 reference with a request in step (d). Finally, location information 609 is returned to the Location Recipient afterwards. For location 610 conveyance in SIP, the procedures described in [RFC6442] are 611 applicable. 613 +-----------+ Geopriv +-----------+ 614 | | Location | Location | 615 | LIS +<------------->+ Recipient | 616 | | Dereferencing | | 617 +-+-------+-+ Protocol (d) +----+------+ 618 ^ | --^ 619 | | -- 620 Geopriv |Req. | -- 621 Location |LbyR |LbyR -- Protocol Conveying 622 Configuration |(a) |(b) -- Location (e.g. SIP) 623 Protocol | | -- (c) 624 | V -- 625 +-+-------+-+ -- 626 | Target / | -- 627 | End Host + 628 | | 629 +-----------+ 631 Figure 2: Location by Reference 633 Where location by reference is provided, the recipient needs to 634 deference the LbyR in order to obtain location. The details for the 635 dereferencing operations vary with the type of reference, such as a 636 HTTP, HTTPS, SIP, SIPS URI or a SIP presence URI. 638 For location-by-reference, the location server needs to maintain one 639 or several URIs for each target, timing out these URIs after a 640 certain amount of time. References need to expire to prevent the 641 recipient of such a Uniform Resource Locator (URL) from being able to 642 permanently track a host and to offer garbage collection 643 functionality for the location server. 645 Off-path adversaries must be prevented from obtaining the target's 646 location. The reference contains a randomized component that 647 prevents third parties from guessing it. When the location recipient 648 fetches up-to-date location information from the location server, it 649 can also be assured that the location information is fresh and not 650 replayed. However, this does not address location theft. 652 With respect to the security of the de-reference operation, [RFC6753] 653 Section 6 states: 655 TLS MUST be used for dereferencing location URIs unless 656 confidentiality and integrity are provided by some other 657 mechanism, as discussed in Section 3. Location Recipients MUST 658 authenticate the host identity using the domain name included in 659 the location URI, using the procedure described in Section 3.1 of 660 [RFC2818]. Local policy determines what a Location Recipient does 661 if authentication fails or cannot be attempted. 663 The authorization by possession model (Section 4.1) further relies 664 on TLS when transmitting the location URI to protect the secrecy 665 of the URI. Possession of such a URI implies the same privacy 666 considerations as possession of the PIDF-LO document that the URI 667 references. 669 Location URIs MUST only be disclosed to authorized Location 670 Recipients. The GEOPRIV architecture [RFC6280] designates the 671 Rule Maker to authorize disclosure of the URI. 673 Protection of the location URI is necessary, since the policy 674 attached to such a location URI permits anyone who has the URI to 675 view the associated location information. This aspect of security 676 is covered in more detail in the specification of location 677 conveyance protocols, such as [RFC6442]. 679 For authorizing access to location-by-reference, two authorization 680 models were developed: "Authorization by Possession" and 681 "Authorization via Access Control Lists". With respect to 682 "Authorization by Possession" [RFC6753] Section 4.1 notes: 684 In this model, possession -- or knowledge -- of the location URI 685 is used to control access to location information. A location URI 686 might be constructed such that it is hard to guess (see C8 of 687 [RFC5808]), and the set of entities that it is disclosed to can be 688 limited. The only authentication this would require by the LS is 689 evidence of possession of the URI. The LS could immediately 690 authorize any request that indicates this URI. 692 Authorization by possession does not require direct interaction 693 with Rule Maker; it is assumed that the Rule Maker is able to 694 exert control over the distribution of the location URI. 695 Therefore, the LIS can operate with limited policy input from a 696 Rule Maker. 698 Limited disclosure is an important aspect of this authorization 699 model. The location URI is a secret; therefore, ensuring that 700 adversaries are not able to acquire this information is paramount. 701 Encryption, such as might be offered by TLS [RFC5246] or S/MIME 702 [RFC5751], protects the information from eavesdroppers. 704 Using possession as a basis for authorization means that, once 705 granted, authorization cannot be easily revoked. Cancellation of 706 a location URI ensures that legitimate users are also affected; 707 application of additional policy is theoretically possible but 708 could be technically infeasible. Expiration of location URIs 709 limits the usable time for a location URI, requiring that an 710 attacker continue to learn new location URIs to retain access to 711 current location information. 713 In situations where "Authorization by Possession" is not suitable 714 (such as where location hiding [RFC6444] is required), the 715 "Authorization via Access Control Lists" model may be preferred. 717 Without the introduction of hierarchy, it would be necessary for the 718 PSAP to obtain client certificates or Digest credentials for all the 719 LISes in its coverage area, to enable it to successfully dereference 720 LbyRs. In situations with more than a few LISes per PSAP, this would 721 present operational challenges. 723 A certificate hierarchy providing PSAPs with client certificates 724 chaining to the VESA could be used to enable the LIS to authenticate 725 and authorize PSAPs for dereferencing. Note that unlike PIDF-LO 726 signing (which mitigates against modification of PIDF-LOs), this 727 merely provides the PSAP with access to a (potentially unsigned) 728 PIDF-LO, albeit over a protected TLS channel. 730 Another approach would be for the local LIS to upload location 731 information to a location aggregation point who would in turn manage 732 the relationships with the PSAP. This would shift the management 733 burden from the PSAPs to the location aggregation points. 735 3.3. Proxy Adding Location 737 Instead of relying upon the end host to provide location, is possible 738 for a proxy that has the ability to determine the location of the end 739 point (e.g., based on the end host IP or MAC address) to retrieve and 740 add or override location information. 742 The use of proxy-added location is primarily applicable in scenarios 743 where the end host does not provide location. As noted in [RFC6442] 744 Section 4.1: 746 A SIP intermediary SHOULD NOT add location to a SIP request that 747 already contains location. This will quite often lead to 748 confusion within LRs. However, if a SIP intermediary adds 749 location, even if location was not previously present in a SIP 750 request, that SIP intermediary is fully responsible for addressing 751 the concerns of any 424 (Bad Location Information) SIP response it 752 receives about this location addition and MUST NOT pass on 753 (upstream) the 424 response. A SIP intermediary that adds a 754 locationValue MUST position the new locationValue as the last 755 locationValue within the Geolocation header field of the SIP 756 request. 758 A SIP intermediary MAY add a Geolocation header field if one is 759 not present -- for example, when a user agent does not support the 760 Geolocation mechanism but their outbound proxy does and knows the 761 Target's location, or any of a number of other use cases (see 762 Section 3). 764 As noted in [RFC6442] Section 3.3: 766 This document takes a "you break it, you bought it" approach to 767 dealing with second locations placed into a SIP request by an 768 intermediary entity. That entity becomes completely responsible 769 for all location within that SIP request (more on this in Section 770 4). 772 While it is possible for the proxy to override location included by 773 the end host, [RFC6442] Section 3.4 notes the operational 774 limitations: 776 Overriding location information provided by the user requires a 777 deployment where an intermediary necessarily knows better than an 778 end user -- after all, it could be that Alice has an on-board GPS, 779 and the SIP intermediary only knows her nearest cell tower. Which 780 is more accurate location information? Currently, there is no way 781 to tell which entity is more accurate or which is wrong, for that 782 matter. This document will not specify how to indicate which 783 location is more accurate than another. 785 The disadvantage of this approach is the need to deploy application 786 layer entities, such as SIP proxies, at IAPs or associated with IAPs. 787 This requires a standardized VoIP profile to be deployed at every end 788 device and at every IAP. This might impose interoperability 789 challenges. 791 Additionally, the IAP needs to take responsibility for emergency 792 calls, even for customers they have no direct or indirect 793 relationship with. To provide identity information about the 794 emergency caller from the VSP it would be necessary to let the IAP 795 and the VSP to interact for authentication (see, for example, 796 "Diameter Session Initiation Protocol (SIP) Application" [RFC4740]). 797 This interaction along the Authentication, Authorization and 798 Accounting infrastructure is often based on business relationships 799 between the involved entities. An arbitrary IAP and VSP are unlikely 800 to have a business relationship. In case the interaction between the 801 IAP and the VSP fails due to the lack of a business relationship then 802 typically a fall-back would be provided where no emergency caller 803 identity information is made available to the PSAP and the emergency 804 call still has to be completed. 806 4. Location Trust Assessment 808 The ability to assess the level of trustworthiness of conveyed 809 location information is important, since this makes it possible to 810 understand how much value should be placed on location information, 811 as part of the decision making process. As an example, if automated 812 location information is understood to be highly suspect or is absent, 813 a call taker can put more effort into verifying the authenticity of 814 the call and to obtaining location information from the caller. 816 Location trust assessment has value regardless of whether the 817 location itself is authenticated (e.g. signed location) or is 818 obtained directly from the location server (e.g. location-by- 819 reference) over security transport, since these mechanisms do not 820 provide assurance of the validity or provenance of location data. 822 To prevent location-theft attacks, the "entity" element of the PIDF- 823 LO is of limited value if an unlinked pseudonym is provided in this 824 field. However, if the LIS authenticates the target, then the 825 linkage between the pseudonym and the target identity can be 826 recovered after the fact. 828 As noted in [I.D.thomson-geopriv-location-dependability], if the 829 location object was signed, the location recipient has additional 830 information on which to base their trust assessment, such as the 831 validity of the signature, the identity of the target, the identity 832 of the LIS, whether the LIS authenticated the target, and the 833 identifier included in the "entity" field. 835 Caller accountability is also an important aspect of trust 836 assessment. Can the individual purchasing the device or activating 837 service be identified or did the call originate from a non-service 838 initialized (NSI) device whose owner cannot be determined? Prior to 839 the call, was the caller authenticated at the network or application 840 layer? In the event of a hoax call, can audit logs be made available 841 to an investigator, or can information relating to the owner of an 842 unlinked pseudonym be provided, enabling investigators to unravel the 843 chain of events that lead to the attack? 845 In practice, the source of the location data is important for 846 location trust assessment. For example, location provided by a 847 Location Information Server (LIS) whose administrator has an 848 established history of meeting emergency location accuracy 849 requirements (e.g. Phase II) may be considered more reliable than 850 location information provided by a third party Location Service 851 Provider (LSP) that disclaims use of location information for 852 emergency purposes. 854 However, even where an LSP does not attempt to meet the accuracy 855 requirements for emergency location, it still may be able to provide 856 information useful in assessing about how reliable location 857 information is likely to be. For example, was location determined 858 based on the nearest cell tower or 802.11 Access Point (AP), or was a 859 triangulation method used? If based on cell tower or AP location 860 data, was the information obtained from an authoritative source (e.g. 861 the tower or AP owner) and when was the last time that the location 862 of the tower or access point was verified? 864 For real-time validation, information in the signaling and media 865 packets can be cross checked against location information. For 866 example, it may be possible to determine the city, state, country or 867 continent associated with the IP address included within SIP Via: or 868 Contact: headers, or the media source address, and compare this 869 against the location information reported by the caller or conveyed 870 in the PIDF-LO. However, in some situations only entities close to 871 the caller may be able to verify the correctness of location 872 information. 874 Real-time validation of the timestamp contained within PIDF-LO 875 objects (reflecting the time at which the location was determined) is 876 also challenging. To address time-shifting attacks, the "timestamp" 877 element of the PIDF-LO, defined in [RFC3863], can be examined and 878 compared against timestamps included within the enclosing SIP 879 message, to determine whether the location data is sufficiently 880 fresh. However, the timestamp only represents an assertion by the 881 LIS, which may or may not be trustworthy. For example, the recipient 882 of the signed PIDF-LO may not know whether the LIS supports time 883 synchronization, or whether it is possible to reset the LIS clock 884 manually without detection. Even if the timestamp was valid at the 885 time location was determined, a time period may elapse between when 886 the PIDF-LO was provided and when it is conveyed to the recipient. 887 Periodically refreshing location information to renew the timestamp 888 even though the location information itself is unchanged puts 889 additional load on LISes. As a result, recipients need to validate 890 the timestamp in order to determine whether it is credible. 892 While this document focuses on the discussion of real-time 893 determination of suspicious emergency calls, the use of audit logs 894 may help in enforcing accountability among emergency callers. For 895 example, in the event of a hoax call, information relating to the 896 owner of the unlinked pseudonym could be provided to investigators, 897 enabling them to unravel the chain of events that lead to the attack. 898 However, while auditability is an important deterrent, it is likely 899 to be of most benefit in situations where attacks on the emergency 900 services system are likely to be relatively infrequent, since the 901 resources required to pursue an investigation are likely to be 902 considerable. However, although real-time validation based on PIDF- 903 LO elements is challenging, where LIS audit logs are available (such 904 as where a law enforcement agency can present a subpoena), linking of 905 a pseudonym to the device obtaining location can be accomplished in a 906 post-mortem. 908 Where attacks are frequent and continuous, automated mechanisms are 909 required. For example, it might be valuable to develop mechanisms to 910 exchange audit trails information in a standardized format between 911 ISPs and PSAPs / VSPs and PSAPs or heuristics to distinguish 912 potentially fraudulent emergency calls from real emergencies. While 913 a Completely Automated Public Turing test to tell Computers and 914 Humans Apart (CAPTCHA) may be applied to suspicious calls to lower 915 the risk from bot-nets, this is quite controversial for emergency 916 services, due to the risk of delaying or rejecting valid calls. 918 5. Security Considerations 920 IP-based emergency services face a number of security threats that do 921 not exist within the legacy system. Mechanically placing a large 922 number of emergency calls that appear to come from different 923 locations is difficult in a legacy environment. Also, in the current 924 system, it would be very difficult for an attacker from country 'Foo' 925 to attack the emergency services infrastructure located in country 926 'Bar'. 928 However, within an IP-based emergency services a number of these 929 attacks become much easier to mount. Emergency services have three 930 finite resources subject to denial of service attacks: the network 931 and server infrastructure, call takers and dispatchers, and the first 932 responders, such as fire fighters and police officers. Protecting 933 the network infrastructure is similar to protecting other high-value 934 service providers, except that location information may be used to 935 filter call setup requests, to weed out requests that are out of 936 area. Even for large cities PSAPs may only have a handful of call 937 takers on duty. So even if call takers can, by questioning the 938 caller, eliminate many hoax calls, PSAPs can be overwhelmed even by a 939 small-scale attack. Finally, first responder resources are scarce, 940 particularly during mass-casualty events. 942 Attackers may want to modify, prevent or delay emergency calls. In 943 some cases, this will lead the PSAP to dispatch emergency personnel 944 to an emergency that does not exist and, hence, the personnel might 945 not be available to other callers. It might also be possible for an 946 attacker to impede the users from reaching an appropriate PSAP by 947 modifying the location of an end host or the information returned 948 from the mapping protocol. In some countries, regulators may not 949 require the authenticated identity of the emergency caller (e.g. 950 emergency calls placed from PSTN pay phones or SIM-less cell phones). 951 Furthermore, if identities can easily be crafted (as it is the case 952 with many VoIP offerings today), then the value of emergency caller 953 authentication itself might be limited. As a result, attackers can 954 forge emergency call information with a lower risk of being held 955 accountable. 957 The above-mentioned attacks are mostly targeting individual emergency 958 callers or a very small fraction of them. If attacks are, however, 959 launched against the mapping architecture (see "Location-URL Mapping 960 Architecture and Framework" [RFC5582] or against the emergency 961 services IP network (including PSAPs), a larger region and a large 962 number of potential emergency callers are affected. The call takers 963 themselves are a particularly scarce resource and if human 964 interaction by these call takers is required then this can very 965 quickly have severe consequences. 967 Although it is important to ensure that location information cannot 968 be faked there will be many GPS-enabled devices that will find it 969 difficult to utilize any of the solutions described in Section 3. It 970 is also unlikely that users will be willing to upload their location 971 information for "verification" to a nearby location server located in 972 the access network. 974 Nevertheless, it should be understood that mounting several of the 975 attacks described in this document is non-trivial. Location theft 976 requires the attacker to be in proximity to the location being 977 spoofed, or to either collude with another endhost or gain control of 978 an endhost so as to obtain its location. Time shifting attacks 979 require that the attacker visit the location and submit it before the 980 location information is considered stale, while travelling rapidly 981 away from that location to avoid apprehension. Obtaining a PIDF-LO 982 from a spoofed IP address requires that the attacker be on the path 983 between the HELD requester and the LIS. 985 6. IANA Considerations 987 This document does not require actions by IANA. 989 7. References 991 7.1. Informative References 993 [I-D.ietf-stir-problem-statement] 994 Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 995 Telephone Identity Problem Statement", Internet draft (work in 996 progress), draft-ietf-stir-problem-statement-05.txt, May 2014. 998 [I-D.ietf-stir-threats] 999 Peterson, J., "Secure Telephone Identity Threat Model", 1000 Internet draft (work in progress), draft-ietf-stir- 1001 threats-02.txt, February 2014. 1003 [EENA] EENA, "False Emergency Calls", EENA Operations Document, 1004 Version 1.1, May 2011, http://www.eena.org/ressource/static/ 1005 files/2012_05_04-3.1.2.fc_v1.1.pdf 1007 [GPSCounter] 1008 Warner, J. S. and R. G. Johnston, "GPS Spoofing 1009 Countermeasures", Los Alamos research paper LAUR-03-6163, 1010 December 2003. 1012 [NENA-i2] "08-001 NENA Interim VoIP Architecture for Enhanced 9-1-1 1013 Services (i2)", December 2005. 1015 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1016 Requirement Levels", BCP 14, RFC 2119, March 1997. 1018 [RFC2818] Rescorla, E., "HTTP over TLS", RFC 2818, May 2000. 1020 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. 1021 Polk, "Geopriv Requirements", RFC 3693, February 2004. 1023 [RFC3694] Danley, M., Mulligan, D., Morris, J. and J. Peterson, "Threat 1024 Analysis of the Geopriv Protocol", RFC 3694, February 2004. 1026 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1027 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 1028 3748, June 2004. 1030 [RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W. and 1031 J. Peterson, "Presence Information Data Format (PIDF)", RFC 1032 3863, August 2004. 1034 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated 1035 Identity Management in the Session Initiation Protocol (SIP)", 1036 RFC 4474, August 2006. 1038 [RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, July 1039 2006. 1041 [RFC4740] Garcia-Martin, M., Belinchon, M., Pallares-Lopez, M., Canales- 1042 Valenzuela, C., and K. Tammi, "Diameter Session Initiation 1043 Protocol (SIP) Application", RFC 4740, November 2006. 1045 [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for Emergency 1046 Context Resolution with Internet Technologies", RFC 5012, 1047 January 2008. 1049 [RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H. and M. Shanmugam, 1050 "Security Threats and Requirements for Emergency Call Marking 1051 and Mapping", RFC 5069, January 2008. 1053 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Level Security 1054 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1056 [RFC5491] Winterbottom, J., Thomson, M. and H. Tschofenig, "GEOPRIV 1057 Presence Information Data Format Location Object (PIDF-LO) 1058 Usage Clarification, Considerations, and Recommendations", RFC 1059 5491, March 2009. 1061 [RFC5582] Schulzrinne, H., "Location-to-URL Mapping Architecture and 1062 Framework", RFC 5582, September 2009. 1064 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail 1065 Extensions (S/MIME) Version 3.2 Message Specification", RFC 1066 5751, January 2010. 1068 [RFC5808] Marshall, R., "Requirements for a Location-by-Reference 1069 Mechanism", RFC 5808, May 2010. 1071 [RFC5985] Barnes, M., "HTTP Enabled Location Delivery (HELD)", RFC 5985, 1072 September 2010. 1074 [RFC6280] Barnes, R., et. al, "An Architecture for Location and Location 1075 Privacy in Internet Applications", RFC 6280, July 2011. 1077 [RFC6442] Polk, J., Rosen, B. and J. Peterson, "Location Conveyance for 1078 the Session Initiation Protocol", RFC 6442, December 2011. 1080 [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 1081 "Framework for Emergency Calling Using Internet Multimedia", 1082 RFC 6443, December 2011. 1084 [RFC6444] Schulzrinne, H., Liess, L., Tschofenig, H., Stark, B., and A. 1085 Kuett, "Location Hiding: Problem Statement and Requirements", 1086 RFC 6444, January 2012. 1088 [RFC6753] Winterbottom, J., Tschofenig. H., Schulzrinne, H. and M. 1089 Thomson, "A Location Dereference Protocol Using HTTP-Enabled 1090 Location Delivery (HELD)", RFC 6753, October 2012. 1092 [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for 1093 Communications Services in Support of Emergency Calling", BCP 1094 181, RFC 6881, March 2013. 1096 [RFC7090] Schulzrinne, H., Tschofenig, H., Holmberg, C. and M. Patel, 1097 "Public Safety Answering Point (PSAP) Callback", RFC 7090, 1098 April 2014. 1100 [SA] "Saudi Arabia - Illegal sale of SIMs blamed for surge in hoax 1101 calls", Arab News, May 4, 2010, 1102 http://www.menafn.com/qn_news_story_s.asp?StoryId=1093319384 1104 [STIR] IETF, "Secure Telephone Identity Revisited (stir) Working 1105 Group", http://datatracker.ietf.org/wg/stir/charter/, October 1106 2013. 1108 [Swatting] 1109 "Don't Make the Call: The New Phenomenon of 'Swatting', 1110 Federal Bureau of Investigation, February 4, 2008, 1111 http://www.fbi.gov/news/stories/2008/february/swatting020408 1113 [TASMANIA] 1114 "Emergency services seek SIM-less calls block", ABC News 1115 Online, August 18, 2006, 1116 http://www.abc.net.au/elections/tas/2006/news/stories/ 1117 1717956.htm?elections/tas/2006/ 1119 [UK] "Rapper makes thousands of prank 999 emergency calls to UK 1120 police", Digital Journal, June 24, 2010, 1121 http://www.digitaljournal.com/article/293796?tp=1 1123 Acknowledgments 1125 We would like to thank the members of the IETF ECRIT working group, 1126 including Marc Linsner and Brian Rosen, for their input at IETF 85 1127 that helped get this documented pointed in the right direction. We 1128 would also like to thank members of the IETF GEOPRIV WG, including 1129 Andrew Newton, Murugaraj Shanmugam, Martin Thomson, Richard Barnes 1130 and Matt Lepinski for their feedback to previous versions of this 1131 document. Thanks also to Pete Resnick, Adrian Farrel, Alissa Cooper, 1132 Bert Wijnen and Meral Shirazipour who provided review comments in 1133 IETF last call. 1135 Authors' Addresses 1137 Hannes Tschofenig 1138 ARM Ltd. 1139 110 Fulbourn Rd 1140 Cambridge CB1 9NJ 1141 Great Britain 1143 Email: Hannes.tschofenig@gmx.net 1144 URI: http://www.tschofenig.priv.at 1146 Henning Schulzrinne 1147 Columbia University 1148 Department of Computer Science 1149 450 Computer Science Building, New York, NY 10027 1150 US 1152 Phone: +1 212 939 7004 1153 Email: hgs@cs.columbia.edu 1154 URI: http://www.cs.columbia.edu 1156 Bernard Aboba 1157 Microsoft Corporation 1158 One Microsoft Way 1159 Redmond, WA 98052 1160 US 1162 Email: bernard_aboba@hotmail.com