idnits 2.17.1 draft-ietf-ecrit-trustworthy-location-09.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 (17 March 2014) is 3692 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- 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 (~~), 1 warning (==), 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: September 24, 2014 Columbia University 6 B. Aboba (ed.) 7 Microsoft Corporation 8 17 March 2014 10 Trustworthy Location 11 draft-ietf-ecrit-trustworthy-location-09.txt 13 Abstract 15 For some location-based applications, such as emergency calling or 16 roadside assistance, the trustworthiness of location information is 17 critically important. 19 This document describes how to convey location in a manner that is 20 inherently secure and reliable. It also provides guidelines for 21 assessing the trustworthiness of location information. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 24, 2014. 40 Copyright Notice 42 Copyright (c) 2014 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 2.1. Location Spoofing . . . . . . . . . . . . . . . . . . . . 6 61 2.2. Identity Spoofing . . . . . . . . . . . . . . . . . . . . 7 62 3. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 3.1. Signed Location by Value . . . . . . . . . . . . . . . . . 8 64 3.2. Location by Reference . . . . . . . . . . . . . . . . . . 11 65 3.3. Proxy Adding Location . . . . . . . . . . . . . . . . . . 14 66 4. Location Trust Assessment . . . . . . . . . . . . . . . . . . 16 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 70 7.1. Informative references . . . . . . . . . . . . . . . . . . 20 71 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 22 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 74 1. Introduction 76 Several public and commercial services depend upon location 77 information in their operations. This includes emergency services 78 (such as fire, ambulance and police) as well as commercial services 79 such as food delivery and roadside assistance. 81 Services that depend on location commonly experience security issues 82 today. While prank calls have been a problem for emergency services 83 dating back to the time of street corner call boxes, with the move to 84 IP-based emergency services, the ability to launch automated attacks 85 has increased. As the European Emergency Number Association (EENA) 86 has noted [EENA]: "False emergency calls divert emergency services 87 away from people who may be in life-threatening situations and who 88 need urgent help. This can mean the difference between life and 89 death for someone in trouble." 91 EENA [EENA] has attempted to define terminology and describe best 92 current practices for dealing with false emergency calls, which in 93 certain European countries can constitute as much as 70% of all 94 emergency calls. Reducing the number of prank calls represents a 95 challenge, since emergency services authorities in most countries are 96 required to answer every call (whenever possible). Where the caller 97 cannot be identified, the ability to prosecute is limited. 99 Since prank emergency calls can endanger bystanders or emergency 100 services personnel, or divert resources away from legitimate 101 emergencies, they can be life threatening. A particularly dangerous 102 form of prank call is "swatting" - a prank emergency call that draws 103 a response from law enforcement (e.g. a fake hostage situation that 104 results in dispatching of a "Special Weapons And Tactics" (SWAT) 105 team). In 2008 the Federal Bureau of Investigation (FBI) issued a 106 warning [Swatting] about an increase in the frequency and 107 sophistication of these attacks. 109 Many documented cases of "swatting" involve not only the faking of an 110 emergency, but also the absence of accurate caller identification and 111 the delivery of misleading location data. Today these attacks are 112 often carried out by providing false caller identification, since for 113 circuit-switched calls from landlines, location provided to the 114 Public Safety Answering Point (PSAP) is determined from a lookup 115 using the calling telephone number. With IP-based emergency 116 services, in addition to the potential for false caller 117 identification, it is also possible to attach misleading location 118 information to the emergency call. 120 Ideally, a call taker at a PSAP should be put in the position to 121 assess, in real-time, the level of trust that can be placed on the 122 information provided within a call. This includes automated location 123 conveyed along with the call and location information communicated by 124 the caller, as well as identity information about the caller. Where 125 real-time assessment is not possible, it is important to be able to 126 determine the source of the call in a post-mortem, so as to be able 127 to enforce accountability. 129 This document defines terminology (including the meaning of 130 "trustworthy location") in Section 1.1, investigates security threats 131 in Section 2, outlines potential solutions in Section 3, covers trust 132 assessment in Section 4 and discusses security considerations in 133 Section 5. 135 1.1. Terminology 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in [RFC2119]. 141 The definition for "Target" is taken from "Geopriv Requirements" 142 [RFC3693]. 144 The term "location determination method" refers to the mechanism used 145 to determine the location of a Target. This may be something 146 employed by a location information server (LIS), or by the Target 147 itself. It specifically does not refer to the location configuration 148 protocol (LCP) used to deliver location information either to the 149 Target or the Recipient. This term is re-used from "GEOPRIV PIDF-LO 150 Usage Clarification, Considerations, and Recommendations" [RFC5491]. 152 The term "source" is used to refer to the LIS, node, or device from 153 which a Recipient (Target or Third-Party) obtains location 154 information. 156 Additionally, the terms Location-by-Value (LbyV), Location-by- 157 Reference (LbyR), Location Configuration Protocol, Location 158 Dereference Protocol, and Location Uniform Resource Identifier (URI) 159 are re-used from "Requirements for a Location-by-Reference Mechanism" 160 [RFC5808]. 162 "Trustworthy Location" is defined as location information that can be 163 attributed to a trusted source, has been protected against 164 modification in transmit, and has been assessed as trustworthy. 166 "Location Trust Assessment" refers to the process by which the 167 reliability of location information can be assessed. This topic is 168 discussed in Section 4. 170 The following additional terms apply to location spoofing: 172 "Place Shifting" is where the attacker constructs a PIDF-LO for a 173 location other than where they are currently located. In some cases, 174 place shifting can be limited in range (e.g., within the coverage 175 area of a particular cell tower). 177 "Time Shifting" is where the attacker uses or re-uses location 178 information that was valid in the past, but is no longer valid 179 because the attacker has moved. 181 "Location Theft" is where the attacker captures a Target's location 182 information and presents it as their own. Location theft can occur 183 in a single instance, or may be continuous (e.g., where the attacker 184 has gained control over the victim's device). Location theft may 185 also be combined with time shifting to present someone else's 186 location information after the original Target has moved. Where the 187 Target and attacker collude, the term "location swapping" is used. 189 2. Threats 191 While previous IETF documents have analyzed aspects of the security 192 of emergency services or threats to geographic location privacy, 193 those documents do not cover the threats arising from unreliable 194 location information. 196 A threat analysis of the emergency services system is provided in 197 "Security Threats and Requirements for Emergency Call Marking and 198 Mapping" [RFC5069]. RFC 5069 describes attacks on the emergency 199 services system, such as attempting to deny system services to all 200 users in a given area, to gain fraudulent use of services and to 201 divert emergency calls to non-emergency sites. [RFC5069] also 202 describes attacks against individuals, including attempts to prevent 203 an individual from receiving aid, or to gain information about an 204 emergency. "Threat Analysis of the Geopriv Protocol" [RFC3694] 205 describes threats against geographic location privacy, including 206 protocol threats, threats resulting from the storage of geographic 207 location data, and threats posed by the abuse of information. 209 This document focuses on threats from attackers providing false 210 location information within emergency calls. Since we do not focus 211 on attackers gaining control of infrastructure elements (e.g., 212 location servers, call route servers) or the emergency services IP 213 network, the threats arise from end hosts. In addition to threats 214 arising from the intentional forging of caller identification or 215 location information, end hosts may be induced to provide 216 untrustworthy location information. For example, end hosts may 217 obtain location from civilian GPS, which is vulnerable to spoofing 219 [GPSCounter] or from third party Location Service Providers (LSPs) 220 which may be vulnerable to attack or may not provide location 221 accuracy suitable for emergency purposes. 223 To provide a structured analysis we distinguish between three 224 adversary models: 226 External adversary model: The end host, e.g., an emergency caller 227 whose location is going to be communicated, is honest and the 228 adversary may be located between the end host and the location 229 server or between the end host and the PSAP. None of the 230 emergency service intrastructure elements act maliciously. 232 Malicious infrastructure adversary model: The emergency call routing 233 elements, such as the Location Information Server (LIS), the 234 Location-to-Service Translation (LoST) infrastructure, used for 235 mapping locations to PSAP address, or call routing elements, may 236 act maliciously. 238 Malicious end host adversary model: The end host itself acts 239 maliciously, whether the owner is aware of this or whether it is 240 acting under the control of a third party. 242 In this document, we focus only on the malicious end host adversary 243 model. 245 2.1. Location Spoofing 247 An adversary can provide false location information in an emergency 248 call in order to misdirect emergency resources. For calls 249 originating within the Public Switched Telephone Network (PSTN) or 250 via a fixed Voice over Internet Protocol (VoIP) service, this attack 251 can be carried out via caller-id spoofing. For example, where a 252 Voice Service Provider enables setting of the outbound caller 253 identification without checking it against the authenticated 254 identity, forging caller identification is trivial. Where an 255 attacker can gain entry to a Private Branch Exchange (PBX), they can 256 then subsequently use that access to launch a denial of service 257 attack against the PSAP, or to make fraudulent emergency calls. 259 Where location is attached to the emergency call by an end host, 260 several avenues are available to provide false location information: 262 1. The end host could fabricate a Presence Information Data 263 Format Location Object (PIDF-LO) and convey it within an emergency 264 call; 266 2. The Voice Service Provider (VSP) (and indirectly a LIS) could 267 be fooled into using the wrong identity (such as an IP address) 268 for location lookup, thereby providing the end host with 269 misleading location information; 271 3. Inaccurate or out-of-date information (such as spoofed Global 272 Positioning System (GPS) signals, a stale wiremap or an inaccurate 273 access point location database) could be utilized by the LIS or 274 the end host in its location determination, thereby leading to an 275 inaccurate determination of location. 277 The following represent examples of location spoofing: 279 Place shifting: Trudy, the adversary, pretends to be at an 280 arbitrary location. 282 Time shifting: Trudy pretends to be at a location she was a 283 while ago. 285 Location theft: Trudy observes Alice's location and replays 286 it as her own. 288 Location swapping: Trudy and Malory collude and swap location 289 information, pretending to be in each other's location. 291 2.2. Identity Spoofing 293 With calls originating on an IP network, at least two forms of 294 identity are relevant, with the distinction created by the split 295 between the Internet Access Provider (IAP) and the VSP: 297 (a) network access identity such as might be determined via 298 authentication (e.g., using the Extensible Authentication Protocol 299 (EAP) [RFC3748]); 301 (b) caller identity, such as might be determined from authentication 302 of the emergency caller at the VoIP application layer. 304 If the adversary did not authenticate itself to the VSP, then 305 accountability may depend on verification of the network access 306 identity. However, this also may not have been authenticated, such 307 as in the case where an open IEEE 802.11 Access Point is used to 308 initiate a prank emergency call. Although endpoint information such 309 as the IP or MAC address may have been logged, tying this back to the 310 device owner may be challenging. 312 Unlike the existing telephone system, VoIP emergency calls can 313 provide a strong identity that need not necessarily be coupled to a 314 business relationship with the IAP, Internet Service Provider (ISP) 315 or VSP. However, due to the time-critical nature of emergency calls, 316 multi-layer authentication is undesirable, so that in most cases, 317 only the device placing the call will be able to be identified, 318 making the system vulnerable to bot-net attacks. Furthermore, 319 deploying additional credentials for emergency service purposes (such 320 as certificates) increases costs, introduces a significant 321 administrative overhead and is only useful if widely deployed. 323 3. Solutions 325 This section presents three mechanisms which can be used to convey 326 location securely: signed location by value (Section 3.1), location 327 by reference (Section 3.2) and proxy added location (Section 3.3). 329 In order to provide authentication and integrity protection for the 330 Session Initiation Protocol (SIP) messages conveying location, 331 several security approaches are available. It is possible to ensure 332 that modification of the identity and location in transit can be 333 detected by the location recipient (e.g., the PSAP), using 334 cryptographic mechanisms, as described in "Enhancements for 335 Authenticated Identity Management in the Session Initiation Protocol" 336 [RFC4474]. However, compatibility with Session Border Controllers 337 (SBCs) that modify integrity-protected headers has proven to be an 338 issue in practice. As a result, SIP over Transport Layer Security 339 (TLS) is currently a more deployable mechanism to provide per-message 340 authentication and integrity protection hop-by-hop. 342 3.1. Signed Location by Value 344 With location signing, a location server signs the location 345 information before it is sent to the end host, (the entity subject to 346 the location determination process). The signed location information 347 is then verified by the location recipient and not by the target. A 348 straw-man proposal for location signing is provided in "Digital 349 Signature Methods for Location Dependability" [I-D.thomson-geopriv- 350 location-dependability]. 352 Figure 1 shows the communication model with the target requesting 353 signed location in step (a), the location server returns it in step 354 (b) and it is then conveyed to the location recipient in step (c) who 355 verifies it. For SIP, the procedures described in "Location 356 Conveyance for the Session Initiation Protocol" [RFC6442] are 357 applicable for location conveyance. 359 +-----------+ +-----------+ 360 | | | Location | 361 | LIS | | Recipient | 362 | | | | 363 +-+-------+-+ +----+------+ 364 ^ | --^ 365 | | -- 366 Geopriv |Req. | -- 367 Location |Signed |Signed -- Geopriv 368 Configuration |Loc. |Loc. -- Using Protocol 369 Protocol |(a) |(b) -- (e.g., SIP) 370 | v -- (c) 371 +-+-------+-+ -- 372 | Target / | -- 373 | End Host + 374 | | 375 +-----------+ 377 Figure 1: Location Signing 379 In order to limit replay attacks, [I.D.thomson-geopriv-location- 380 dependability] proposes the addition of a "validity" element to the 381 PIDF-LO, including a "from" sub-element containing the time that 382 location information was validated by the signer, as well as an 383 "until" sub-element containing the last time that the signature can 384 be considered valid. 386 One of the consequences of including an "until" element is that even 387 a stationary target would need to periodically obtain a fresh PIDF- 388 LO, or incur the additional delay of querying during an emergency 389 call. 391 Although privacy-preserving procedures may be disabled for emergency 392 calls, by design, PIDF-LO objects limit the information available for 393 real-time attribution. As noted in [RFC5985] Section 6.6: 395 The LIS MUST NOT include any means of identifying the Device in 396 the PIDF-LO unless it is able to verify that the identifier is 397 correct and inclusion of identity is expressly permitted by a Rule 398 Maker. Therefore, PIDF parameters that contain identity are 399 either omitted or contain unlinked pseudonyms [RFC3693]. A 400 unique, unlinked presentity URI SHOULD be generated by the LIS for 401 the mandatory presence "entity" attribute of the PIDF document. 402 Optional parameters such as the "contact" and "deviceID" elements 403 [RFC4479] are not used. 405 Also, the device referred to in the PIDF-LO may not necessarily be 406 the same entity conveying the PIDF-LO to the PSAP. As noted in 408 [RFC6442] Section 1: 410 In no way does this document assume that the SIP user agent client 411 that sends a request containing a location object is necessarily 412 the Target. The location of a Target conveyed within SIP 413 typically corresponds to that of a device controlled by the 414 Target, for example, a mobile phone, but such devices can be 415 separated from their owners, and moreover, in some cases, the user 416 agent may not know its own location. 418 Without the ability to tie the target identity to the identity 419 asserted in the SIP message, it is possible for an attacker to cut 420 and paste a PIDF-LO obtained by a different device or user into a SIP 421 INVITE and send this to the PSAP. This cut and paste attack could 422 succeed even when a PIDF-LO is signed, or [RFC4474] is implemented. 424 To address location-swapping attacks, [I-D.thomson-geopriv-location- 425 dependability] proposes addition of an "identity" element which could 426 include a SIP URI (enabling comparison against the identity asserted 427 in the SIP headers) or an X.509v3 certificate. If the target was 428 authenticated by the LIS, an "authenticated" attribute is added. 429 However, inclusion of an "identity" attribute could enable location 430 tracking, so that a "hash" element is also proposed which could 431 contain a hash of the content of the "identity" element instead. In 432 practice, such a hash would not be much better for real-time 433 validation than a pseudonym. 435 Location signing is unlikely to deter attacks launched by bot-nets, 436 since the work required to verify the location signature is 437 considerable. However, while bot-nets are unlikely to be deterred by 438 location signing, accurate location information would limit the 439 subset of the bot-net that could be used for an attack, as only hosts 440 within the PSAP serving area would be useful in placing emergency 441 calls. 443 Location signing is also difficult when the host obtains location via 444 mechanisms such as GPS, unless trusted computing approaches, with 445 tamper-proof GPS modules, can be applied. Otherwise, an end host can 446 pretend to have a GPS device, and the recipient will need to rely on 447 its ability to assess the level of trust that should be placed in the 448 end host location claim. 450 [NENA-i2] Section 3.7 includes operational recommendations relating 451 to location signing: 453 Location determination is out of scope for NENA, but we can offer 454 guidance on what should be considered when designing mechanisms to 455 report location: 457 1. The location object should be digitally signed. 459 2. The certificate for the signer (LIS operator) should be 460 rooted in VESA. For this purpose, VPC and ERDB operators 461 should issue certs to LIS operators. 463 3. The signature should include a timestamp. 465 4. Where possible, the Location Object should be refreshed 466 periodically, with the signature (and thus the timestamp) 467 being refreshed as a consequence. 469 5. Anti-spoofing mechanisms should be applied to the Location 470 Reporting method. 472 [Note: The term Valid Emergency Services Authority (VESA) refers 473 to the root certificate authority. VPC stands for VoIP 474 Positioning Center and ERDB stands for the Emergency Service Zone 475 Routing Database.] 477 As noted above, signing of location objects implies the development 478 of a trust hierarchy that would enable a certificate chain provided 479 by the LIS operator to be verified by the PSAP. Rooting the trust 480 hierarchy in VESA can be accomplished either by having the VESA 481 directly sign the LIS certificates, or by the creation of 482 intermediate Certificate Authorities (CAs) certified by the VESA, 483 which will then issue certificates to the LIS. In terms of the 484 workload imposed on the VESA, the latter approach is highly 485 preferable. However, this raises the question of who would operate 486 the intermediate CAs and what the expectations would be. 488 In particular, the question arises as to the requirements for LIS 489 certificate issuance, and how they would compare to requirements for 490 issuance of other certificates such as an SSL/TLS web certificate. 492 3.2. Location by Reference 494 Location-by-reference was developed so that end hosts can avoid 495 having to periodically query the location server for up- to-date 496 location information in a mobile environment. Additionally, if 497 operators do not want to disclose location information to the end 498 host without charging them, location-by-reference provides a 499 reasonable alternative. As noted in "A Location Dereference Protocol 500 Using HTTP-Enabled Location Delivery (HELD)" [RFC6753], a location 501 reference can be obtained via HTTP-Enabled Location Delivery (HELD) 502 [RFC5985] or the Dynamic Host Configuration Protocol (DHCP) location 503 URI option [DHCP-URI-OPT]. 505 Figure 2 shows the communication model with the target requesting a 506 location reference in step (a), the location server returns the 507 reference in step (b), and it is then conveyed to the location 508 recipient in step (c). The location recipient needs to resolve the 509 reference with a request in step (d). Finally, location information 510 is returned to the Location Recipient afterwards. For location 511 conveyance in SIP, the procedures described in [RFC6442] are 512 applicable. 514 +-----------+ Geopriv +-----------+ 515 | | Location | Location | 516 | LIS +<------------->+ Recipient | 517 | | Dereferencing | | 518 +-+-------+-+ Protocol (d) +----+------+ 519 ^ | --^ 520 | | -- 521 Geopriv |Req. | -- 522 Location |LbyR |LbyR -- Geopriv 523 Configuration |(a) |(b) -- Using Protocol 524 Protocol | | -- (e.g., SIP) 525 | V -- (c) 526 +-+-------+-+ -- 527 | Target / | -- 528 | End Host + 529 | | 530 +-----------+ 532 Figure 2: Location by Reference 534 Where location by reference is provided, the recipient needs to 535 deference the LbyR in order to obtain location. The details for the 536 dereferencing operations vary with the type of reference, such as a 537 HTTP, HTTPS, SIP, SIPS URI or a SIP presence URI. 539 For location-by-reference, the location server needs to maintain one 540 or several URIs for each target, timing out these URIs after a 541 certain amount of time. References need to expire to prevent the 542 recipient of such a Uniform Resource Locator (URL) from being able to 543 permanently track a host and to offer garbage collection 544 functionality for the location server. 546 Off-path adversaries must be prevented from obtaining the target's 547 location. The reference contains a randomized component that 548 prevents third parties from guessing it. When the location recipient 549 fetches up-to-date location information from the location server, it 550 can also be assured that the location information is fresh and not 551 replayed. However, this does not address location swapping. 553 With respect to the security of the de-reference operation, [RFC6753] 554 Section 6 states: 556 TLS MUST be used for dereferencing location URIs unless 557 confidentiality and integrity are provided by some other 558 mechanism, as discussed in Section 3. Location Recipients MUST 559 authenticate the host identity using the domain name included in 560 the location URI, using the procedure described in Section 3.1 of 561 [RFC2818]. Local policy determines what a Location Recipient does 562 if authentication fails or cannot be attempted. 564 The authorization by possession model (Section 4.1) further relies 565 on TLS when transmitting the location URI to protect the secrecy 566 of the URI. Possession of such a URI implies the same privacy 567 considerations as possession of the PIDF-LO document that the URI 568 references. 570 Location URIs MUST only be disclosed to authorized Location 571 Recipients. The GEOPRIV architecture [RFC6280] designates the 572 Rule Maker to authorize disclosure of the URI. 574 Protection of the location URI is necessary, since the policy 575 attached to such a location URI permits anyone who has the URI to 576 view the associated location information. This aspect of security 577 is covered in more detail in the specification of location 578 conveyance protocols, such as [RFC6442]. 580 For authorizing access to location-by-reference, two authorization 581 models were developed: "Authorization by Possession" and 582 "Authorization via Access Control Lists". With respect to 583 "Authorization by Possession" [RFC6753] Section 4.1 notes: 585 In this model, possession -- or knowledge -- of the location URI 586 is used to control access to location information. A location URI 587 might be constructed such that it is hard to guess (see C8 of 588 [RFC5808]), and the set of entities that it is disclosed to can be 589 limited. The only authentication this would require by the LS is 590 evidence of possession of the URI. The LS could immediately 591 authorize any request that indicates this URI. 593 Authorization by possession does not require direct interaction 594 with Rule Maker; it is assumed that the Rule Maker is able to 595 exert control over the distribution of the location URI. 596 Therefore, the LIS can operate with limited policy input from a 597 Rule Maker. 599 Limited disclosure is an important aspect of this authorization 600 model. The location URI is a secret; therefore, ensuring that 601 adversaries are not able to acquire this information is paramount. 602 Encryption, such as might be offered by TLS [RFC5246] or S/MIME 603 [RFC5751], protects the information from eavesdroppers. 605 Using possession as a basis for authorization means that, once 606 granted, authorization cannot be easily revoked. Cancellation of 607 a location URI ensures that legitimate users are also affected; 608 application of additional policy is theoretically possible but 609 could be technically infeasible. Expiration of location URIs 610 limits the usable time for a location URI, requiring that an 611 attacker continue to learn new location URIs to retain access to 612 current location information. 614 In situations where "Authorization by Possession" is not suitable 615 (such as where location hiding [RFC6444] is required), the 616 "Authorization via Access Control Lists" model may be preferred. 618 Without the introduction of hierarchy, it would be necessary for the 619 PSAP to obtain client certificates or Digest credentials for all the 620 LISes in its coverage area, to enable it to successfully dereference 621 LbyRs. In situations with more than a few LISes per PSAP, this would 622 present operational challenges. 624 A certificate hierarchy providing PSAPs with client certificates 625 chaining to the VESA could be used to enable the LIS to authenticate 626 and authorize PSAPs for dereferencing. Note that unlike PIDF-LO 627 signing (which mitigates against modification of PIDF-LOs), this 628 merely provides the PSAP with access to a (potentially unsigned) 629 PIDF-LO, albeit over a protected TLS channel. 631 Another approach would be for the local LIS to upload location 632 information to a location aggregation point who would in turn manage 633 the relationships with the PSAP. This would shift the management 634 burden from the PSAPs to the location aggregation points. 636 3.3. Proxy Adding Location 638 Instead of relying upon the end host to provide location, is possible 639 for a proxy that has the ability to determine the location of the end 640 point (e.g., based on the end host IP or MAC address) to retrieve and 641 add or override location information. 643 The use of proxy-added location is primarily applicable in scenarios 644 where the end host does not provide location. As noted in [RFC6442] 645 Section 4.1: 647 A SIP intermediary SHOULD NOT add location to a SIP request that 648 already contains location. This will quite often lead to 649 confusion within LRs. However, if a SIP intermediary adds 650 location, even if location was not previously present in a SIP 651 request, that SIP intermediary is fully responsible for addressing 652 the concerns of any 424 (Bad Location Information) SIP response it 653 receives about this location addition and MUST NOT pass on 654 (upstream) the 424 response. A SIP intermediary that adds a 655 locationValue MUST position the new locationValue as the last 656 locationValue within the Geolocation header field of the SIP 657 request. 659 A SIP intermediary MAY add a Geolocation header field if one is 660 not present -- for example, when a user agent does not support the 661 Geolocation mechanism but their outbound proxy does and knows the 662 Target's location, or any of a number of other use cases (see 663 Section 3). 665 As noted in [RFC6442] Section 3.3: 667 This document takes a "you break it, you bought it" approach to 668 dealing with second locations placed into a SIP request by an 669 intermediary entity. That entity becomes completely responsible 670 for all location within that SIP request (more on this in Section 671 4). 673 While it is possible for the proxy to override location included by 674 the end host, [RFC6442] Section 3.4 notes the operational 675 limitations: 677 Overriding location information provided by the user requires a 678 deployment where an intermediary necessarily knows better than an 679 end user -- after all, it could be that Alice has an on-board GPS, 680 and the SIP intermediary only knows her nearest cell tower. Which 681 is more accurate location information? Currently, there is no way 682 to tell which entity is more accurate or which is wrong, for that 683 matter. This document will not specify how to indicate which 684 location is more accurate than another. 686 The disadvantage of this approach is the need to deploy application 687 layer entities, such as SIP proxies, at IAPs or associated with IAPs. 688 This requires a standardized VoIP profile to be deployed at every end 689 device and at every IAP. This might impose interoperability 690 challenges. 692 Additionally, the IAP needs to take responsibility for emergency 693 calls, even for customers they have no direct or indirect 694 relationship with. To provide identity information about the 695 emergency caller from the VSP it would be necessary to let the IAP 696 and the VSP to interact for authentication (see, for example, 697 "Diameter Session Initiation Protocol (SIP) Application" [RFC4740]). 698 This interaction along the Authentication, Authorization and 699 Accounting infrastructure is often based on business relationships 700 between the involved entities. An arbitrary IAP and VSP are unlikely 701 to have a business relationship. In case the interaction between the 702 IAP and the VSP fails due to the lack of a business relationship then 703 typically a fall-back would be provided where no emergency caller 704 identity information is made available to the PSAP and the emergency 705 call still has to be completed. 707 4. Location Trust Assessment 709 The ability to assess the level of trustworthiness of conveyed 710 location information is important, since this makes it possible to 711 understand how much value should be placed on location information, 712 as part of the decision making process. As an example, if automated 713 location information is understood to be highly suspect, a call taker 714 can put more effort into obtaining location information from the 715 caller. 717 Location trust assessment has value regardless of whether the 718 location has been conveyed securely (via signed location, location- 719 by-reference or proxy-added location) or not (via location-by-value 720 without location signing), since secure conveyance does not provide 721 assurance relating to the validity or provenance of location data. 723 To prevent location-swapping attacks, the "entity" element of the 724 PIDF-LO is of limited value if an unlinked pseudonym is provided in 725 this field. However, if the LIS authenticates the target, then the 726 linkage between the pseudonym and the target identity can be 727 recovered post-mortem. 729 As noted in [I.D.thomson-geopriv-location-dependability], if the 730 location object was signed, the location recipient has additional 731 information on which to base their trust assessment, such as the 732 validity of the signature, the identity of the target, the identity 733 of the LIS, whether the LIS authenticated the target, and the 734 identifier included in the "entity" field. 736 Caller accountability is also an important aspect of trust 737 assessment. Can the individual purchasing the device or activating 738 service be identified or did the call originate from a non-service 739 initialized (NSI) device whose owner cannot be determined? Prior to 740 the call, was the caller authenticated at the network or application 741 layer? In the event of a prank call, can audit logs be made 742 available to an investigator, or can information relating to the 743 owner of an unlinked pseudonym be provided, enabling investigators to 744 unravel the chain of events that lead to the attack? In practice, 745 the ability to identify a caller may decrease the likelihood of 746 caller misbehavior. For example, where emergency calls have been 747 allowed from handsets lacking a SIM card, or where ownership of the 748 SIM card cannot be determined, the frequency of nuisance calls has 749 often been unacceptably high [TASMANIA][UK][SA]. 751 In practice, the source of the location data is important for 752 location trust assessment. For example, location provided by a 753 Location Information Server (LIS) whose administrator has an 754 established history of meeting emergency location accuracy 755 requirements (e.g. Phase II) may be considered more reliable than 756 location information provided by a third party Location Service 757 Provider (LSP) that disclaims use of location information for 758 emergency purposes. 760 However, even where an LSP does not attempt to meet the accuracy 761 requirements for emergency location, it still may be able to provide 762 information useful in assessing about how reliable location 763 information is likely to be. For example, was location determined 764 based on the nearest cell tower or 802.11 Access Point (AP), or was a 765 triangulation method used? If based on cell tower or AP location 766 data, was the information obtained from an authoritative source (e.g. 767 the tower or AP owner) and when was the last time that the location 768 of the tower or access point was verified? 770 For real-time validation, information in the signaling and media 771 packets can be cross checked against location information. For 772 example, it may be possible to determine the city, state, country or 773 continent associated with the IP address included within SIP Via: or 774 Contact: headers, or the media source address, and compare this 775 against the location information reported by the caller or conveyed 776 in the PIDF-LO. However, in some situations only entities close to 777 the caller may be able to verify the correctness of location 778 information. 780 Real-time validation of the timestamp contained within PIDF-LO 781 objects (reflecting the time at which the location was determined) is 782 also challenging. To address time-shifting attacks, the "timestamp" 783 element of the PIDF-LO, defined in [RFC3863], can be examined and 784 compared against timestamps included within the enclosing SIP 785 message, to determine whether the location data is sufficiently 786 fresh. However, the timestamp only represents an assertion by the 787 LIS, which may or may not be trustworthy. For example, the recipient 788 of the signed PIDF-LO may not know whether the LIS supports time 789 synchronization, or whether it is possible to reset the LIS clock 790 manually without detection. Even if the timestamp was valid at the 791 time location was determined, a time period may elapse between when 792 the PIDF-LO was provided and when it is conveyed to the recipient. 794 Periodically refreshing location information to renew the timestamp 795 even though the location information itself is unchanged puts 796 additional load on LISes. As a result, recipients need to validate 797 the timestamp in order to determine whether it is credible. 799 While this document focuses on the discussion of real-time 800 determination of suspicious emergency calls, the use of audit logs 801 may help in enforcing accountability among emergency callers. For 802 example, in the event of a prank call, information relating to the 803 owner of the unlinked pseudonym could be provided to investigators, 804 enabling them to unravel the chain of events that lead to the attack. 805 However, while auditability is an important deterrent, it is likely 806 to be of most benefit in situations where attacks on the emergency 807 services system are likely to be relatively infrequent, since the 808 resources required to pursue an investigation are likely to be 809 considerable. However, although real-time validation based on PIDF- 810 LO elements is challenging, where LIS audit logs are available (such 811 as where a law enforcement agency can present a subpoena), linking of 812 a pseudonym to the device obtaining location can be accomplished in a 813 post-mortem. 815 Where attacks are frequent and continuous, automated mechanisms are 816 required. For example, it might be valuable to develop mechanisms to 817 exchange audit trails information in a standardized format between 818 ISPs and PSAPs / VSPs and PSAPs or heuristics to distinguish 819 potentially fraudulent emergency calls from real emergencies. While 820 a Completely Automated Public Touring test to tell Computers and 821 Humans Apart (CAPTCHA) may be applied to suspicious calls to lower 822 the risk from bot-nets, this is quite controversial for emergency 823 services, due to the risk of delaying or rejecting valid calls. 825 5. Security Considerations 827 IP-based emergency services face a number of security threats that do 828 not exist within the legacy system. In order to limit prank calls, 829 legacy emergency services rely on the ability to identify callers, as 830 well as on the difficulty of location spoofing for normal users. The 831 ability to ascertain identity is important, since the threat of 832 punishment reduces prank calls; as an example, calls from pay phones 833 are subject to greater scrutiny by the call taker. 835 Mechanically placing a large number of emergency calls that appear to 836 come from different locations is difficult in a legacy environment. 837 Also, in the current system, it would be very difficult for an 838 attacker from country 'Foo' to attack the emergency services 839 infrastructure located in country 'Bar'. 841 However, within an IP-based emergency services a number of these 842 attacks become much easier to mount. Emergency services have three 843 finite resources subject to denial of service attacks: the network 844 and server infrastructure, call takers and dispatchers, and the first 845 responders, such as fire fighters and police officers. Protecting 846 the network infrastructure is similar to protecting other high-value 847 service providers, except that location information may be used to 848 filter call setup requests, to weed out requests that are out of 849 area. PSAPs even for large cities may only have a handful of PSAP 850 call takers on duty, so even if they can, by questioning the caller, 851 eliminate a lot of prank calls, they are quickly overwhelmed by even 852 a small-scale attack. Finally, first responder resources are scarce, 853 particularly during mass-casualty events. 855 Attackers may want to modify, prevent or delay emergency calls. In 856 some cases, this will lead the PSAP to dispatch emergency personnel 857 to an emergency that does not exist and, hence, the personnel might 858 not be available to other callers. It might also be possible for an 859 attacker to impede the users from reaching an appropriate PSAP by 860 modifying the location of an end host or the information returned 861 from the mapping protocol. In some countries, regulators may not 862 require the authenticated identity of the emergency caller (e.g. 863 emergency calls placed from PSTN pay phones or SIM-less cell phones). 864 Furthermore, if identities can easily be crafted (as it is the case 865 with many VoIP offerings today), then the value of emergency caller 866 authentication itself might be limited. As a consequence, an 867 attacker can forge emergency call information without the chance of 868 being held accountable for its own actions. 870 The above-mentioned attacks are mostly targeting individual emergency 871 callers or a very small fraction of them. If attacks are, however, 872 launched against the mapping architecture (see "Location-URL Mapping 873 Architecture and Framework" [RFC5582] or against the emergency 874 services IP network (including PSAPs), a larger region and a large 875 number of potential emergency callers are affected. The call takers 876 themselves are a particularly scarce resource and if human 877 interaction by these call takers is required then this can very 878 quickly have severe consequences. 880 Although it is important to ensure that location information cannot 881 be faked there will be many GPS-enabled devices that will find it 882 difficult to utilize any of the solutions described in Section 3. It 883 is also unlikely that users will be willing to upload their location 884 information for "verification" to a nearby location server located in 885 the access network. 887 Nevertheless, it should be understood that mounting several of the 888 attacks described in this document is non-trivial. Location theft 889 requires the attacker to be in proximity to the location being 890 spoofed, and location swapping requires the attacker to collude with 891 someone who was at the spoofed location. Time shifting attacks 892 require that the attacker visit the location and submit it before the 893 location information is considered stale, while travelling rapidly 894 away from that location to avoid apprehension. Obtaining a PIDF-LO 895 from a spoofed IP address requires that the attacker be on the path 896 between the HELD requester and the LIS. 898 6. IANA Considerations 900 This document does not require actions by IANA. 902 7. References 904 7.1. Informative References 906 [DHCP-URI-OPT] 907 Polk, J., "Dynamic Host Configuration Protocol (DHCP) IPv4 and 908 IPv6 Option for a Location Uniform Resource Identifier (URI)", 909 Internet draft (work in progress), draft-ietf-geopriv-dhcp- 910 lbyr-uri-option-19, February 2013. 912 [EENA] EENA, "False Emergency Calls", EENA Operations Document, 913 Version 1.0, March 2011, 914 http://www.eena.org/ressource/static/files/ 915 2011_03_15_3.1.2.fc_v1.0.pdf 917 [GPSCounter] 918 Warner, J. S. and R. G. Johnston, "GPS Spoofing 919 Countermeasures", Los Alamos research paper LAUR-03-6163, 920 December 2003. 922 [NENA-i2] "08-001 NENA Interim VoIP Architecture for Enhanced 9-1-1 923 Services (i2)", December 2005. 925 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 926 Requirement Levels", BCP 14, RFC 2119, March 1997. 928 [RFC2818] Rescorla, E., "HTTP over TLS", RFC 2818, May 2000. 930 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. 931 Polk, "Geopriv Requirements", RFC 3693, February 2004. 933 [RFC3694] Danley, M., Mulligan, D., Morris, J. and J. Peterson, "Threat 934 Analysis of the Geopriv Protocol", RFC 3694, February 2004. 936 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 937 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 938 3748, June 2004. 940 [RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W. and 941 J. Peterson, "Presence Information Data Format (PIDF)", RFC 942 3863, August 2004. 944 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated 945 Identity Management in the Session Initiation Protocol (SIP)", 946 RFC 4474, August 2006. 948 [RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, July 949 2006. 951 [RFC4740] Garcia-Martin, M., Belinchon, M., Pallares-Lopez, M., Canales- 952 Valenzuela, C., and K. Tammi, "Diameter Session Initiation 953 Protocol (SIP) Application", RFC 4740, November 2006. 955 [RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H. and M. Shanmugam, 956 "Security Threats and Requirements for Emergency Call Marking 957 and Mapping", RFC 5069, January 2008. 959 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Level Security 960 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 962 [RFC5491] Winterbottom, J., Thomson, M. and H. Tschofenig, "GEOPRIV 963 Presence Information Data Format Location Object (PIDF-LO) 964 Usage Clarification, Considerations, and Recommendations", RFC 965 5491, March 2009. 967 [RFC5582] Schulzrinne, H., "Location-to-URL Mapping Architecture and 968 Framework", RFC 5582, September 2009. 970 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail 971 Extensions (S/MIME) Version 3.2 Message Specification", RFC 972 5751, January 2010. 974 [RFC5808] Marshall, R., "Requirements for a Location-by-Reference 975 Mechanism", RFC 5808, May 2010. 977 [RFC5985] Barnes, M., "HTTP Enabled Location Delivery (HELD)", RFC 5985, 978 September 2010. 980 [RFC6280] Barnes, R., et. al, "An Architecture for Location and Location 981 Privacy in Internet Applications", RFC 6280, July 2011. 983 [RFC6442] Polk, J., Rosen, B. and J. Peterson, "Location Conveyance for 984 the Session Initiation Protocol", RFC 6442, December 2011. 986 [RFC6444] Schulzrinne, H., Liess, L., Tschofenig, H., Stark, B., and A. 987 Kuett, "Location Hiding: Problem Statement and Requirements", 988 RFC 6444, January 2012. 990 [RFC6753] Winterbottom, J., Tschofenig. H., Schulzrinne, H. and M. 991 Thomson, "A Location Dereference Protocol Using HTTP-Enabled 992 Location Delivery (HELD)", RFC 6753, October 2012. 994 [SA] "Saudi Arabia - Illegal sale of SIMs blamed for surge in prank 995 calls", Arab News, May 4, 2010, 996 http://www.menafn.com/qn_news_story_s.asp?StoryId=1093319384 998 [Swatting] 999 "Don't Make the Call: The New Phenomenon of 'Swatting', 1000 Federal Bureau of Investigation, February 4, 2008, 1001 http://www.fbi.gov/news/stories/2008/february/swatting020408 1003 [TASMANIA] 1004 "Emergency services seek SIM-less calls block", ABC News 1005 Online, August 18, 2006, 1006 http://www.abc.net.au/elections/tas/2006/news/stories/ 1007 1717956.htm?elections/tas/2006/ 1009 [UK] "Rapper makes thousands of prank 999 emergency calls to UK 1010 police", Digital Journal, June 24, 2010, 1011 http://www.digitaljournal.com/article/293796?tp=1 1013 Acknowledgments 1015 We would like to thank the members of the IETF ECRIT working group, 1016 including Marc Linsner, Henning Schulzrinne and Brian Rosen, for 1017 their input at IETF 85 that helped get this documented pointed in the 1018 right direction. We would also like to thank members of the IETF 1019 GEOPRIV WG, including Andrew Newton, Murugaraj Shanmugam, Martin 1020 Thomson, Richard Barnes and Matt Lepinski for their feedback to 1021 previous versions of this document. Thanks also to Bert Wijnen and 1022 Meral Shirazipour who provided review comments in IETF last call. 1024 Authors' Addresses 1026 Hannes Tschofenig 1027 ARM Ltd. 1028 110 Fulbourn Rd 1029 Cambridge CB1 9NJ 1030 Great Britain 1032 Email: Hannes.tschofenig@gmx.net 1033 URI: http://www.tschofenig.priv.at 1035 Henning Schulzrinne 1036 Columbia University 1037 Department of Computer Science 1038 450 Computer Science Building, New York, NY 10027 1039 US 1041 Phone: +1 212 939 7004 1042 Email: hgs@cs.columbia.edu 1043 URI: http://www.cs.columbia.edu 1045 Bernard Aboba 1046 Microsoft Corporation 1047 One Microsoft Way 1048 Redmond, WA 98052 1049 US 1051 Email: bernard_aboba@hotmail.com