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