idnits 2.17.1 draft-ietf-ecrit-trustworthy-location-05.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 (13 March 2013) is 4060 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: September 12, 2013 Columbia University 6 B. Aboba (ed.) 7 Microsoft Corporation 8 13 March 2013 10 Trustworthy Location 11 draft-ietf-ecrit-trustworthy-location-05.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 12, 2013. 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 3.1. Signed Location by Value . . . . . . . . . . . . . . . . . 8 64 3.2. Location by Reference . . . . . . . . . . . . . . . . . . 10 65 3.3. Proxy Adding Location . . . . . . . . . . . . . . . . . . 13 66 4. Location Trust Assessment . . . . . . . . . . . . . . . . . . 15 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 70 7.1. Informative references . . . . . . . . . . . . . . . . . . 19 71 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 21 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 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 PSAP should be put in the position to 119 assess, in real-time, the level of trust that can be placed on the 120 information provided within a call. This includes automated location 121 conveyed along with the call and location information communicated by 122 the caller, as well as identity information about the caller. Where 123 real-time assessment is not possible, it is important to be able to 124 determine the source of the call in a post-mortem, so as to be able 125 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 2. Threats 169 While previous IETF documents have analyzed aspects of the security 170 of emergency services or threats to geographic location privacy, 171 those documents do not cover the threats arising from unreliable 172 location information. 174 A threat analysis of the emergency services system is provided in 175 "Security Threats and Requirements for Emergency Call Marking and 176 Mapping" [RFC5069]. RFC 5069 describes attacks on the emergency 177 services system, such as attempting to deny system services to all 178 users in a given area, to gain fraudulent use of services and to 179 divert emergency calls to non-emergency sites. [RFC5069] also 180 describes attacks against individuals, including attempts to prevent 181 an individual from receiving aid, or to gain information about an 182 emergency. "Threat Analysis of the Geopriv Protocol" [RFC3694] 183 describes threats against geographic location privacy, including 184 protocol threats, threats resulting from the storage of geographic 185 location data, and threats posed by the abuse of information. 187 This document focuses on threats from attackers providing false 188 location information within emergency calls. Since we do not focus 189 on attackers gaining control of infrastructure elements (e.g., 190 location servers, call route servers) or the emergency services IP 191 network, the threats are derived from the introduction of 192 untrustworthy location information by end hosts. In addition to 193 threats arising from the intentional forging of location information, 194 end hosts may be induced to provide untrustworthy location 195 information. For example, end hosts may obtain location from 196 civilian GPS, which is vulnerable to spoofing [GPSCounter] or from 197 third party Location Service Providers (LSPs) which may be vulnerable 198 to attack or may not warrant the use of their services for emergency 199 purposes. 201 To provide a structured analysis we distinguish between three 202 adversary models: 204 External adversary model: The end host, e.g., an emergency caller 205 whose location is going to be communicated, is honest and the 206 adversary may be located between the end host and the location 207 server or between the end host and the PSAP. None of the 208 emergency service infrastructure elements act maliciously. 210 Malicious infrastructure adversary model: The emergency call routing 211 elements, such as the LIS, the LoST infrastructure, used for 212 mapping locations to PSAP address, or call routing elements, may 213 act maliciously. 215 Malicious end host adversary model: The end host itself acts 216 maliciously, whether the owner is aware of this or whether it is 217 acting as a bot. 219 In this document, we focus only on the malicious end host adversary 220 model. 222 2.1. Location Spoofing 224 An adversary can provide false location information in an emergency 225 call in order to misdirect emergency resources. For calls 226 originating within the PSTN, this attack can be carried out via 227 caller-id spoofing. Where location is attached to the emergency call 228 by an end host, several avenues are available to provide false 229 location information: 231 1. The end host could fabricate a PIDF-LO and convey it within an 232 emergency call; 234 2. The VSP (and indirectly a LIS) could be fooled into using the 235 wrong identity (such as an IP address) for location lookup, 236 thereby providing the end host with misleading location 237 information; 239 3. Inaccurate or out-of-date information (such spoofed GPS 240 signals, a stale wiremap or an inaccurate access point location 241 database) could be utilized by the LIS or the end host in its 242 location determination, thereby leading to an inaccurate 243 determination of location. 245 By analysis of the SIP headers, it may be possible to flag situations 246 where the conveyed location is suspect (e.g. potentially wrong city, 247 state, country or continent). However, in other situations only 248 entities close to the caller may be able to verify the correctness of 249 location information. 251 The following list presents threats specific to location information 252 handling: 254 Place shifting: Trudy, the adversary, pretends to be at an arbitrary 255 location. In some cases, place shifting can be limited in range, 256 e.g., to the coverage area of a particular cell tower. 258 Time shifting: Trudy pretends to be at a location she was a while 259 ago. 261 Location theft: Trudy observes Alice's location and replays it as 262 her own. 264 Location swapping: Trudy and Malory, located in different locations, 265 can collude and swap location information and pretend to be in 266 each other's location. 268 2.2. Identity Spoofing 270 With calls originating on an IP network, at least two forms of 271 identity are relevant, with the distinction created by the split 272 between the AIP and the VSP: 274 (a) network access identity such as might be determined via 275 authentication (e.g., using the Extensible Authentication Protocol 276 (EAP) [RFC3748]); 278 (b) caller identity, such as might be determined from authentication 279 of the emergency caller at the VoIP application layer. 281 If the adversary did not authenticate itself to the VSP, then 282 accountability may depend on verification of the network access 283 identity. However, this also may not have been authenticated, such 284 as in the case where an open IEEE 802.11 Access Point is used to 285 initiate a nuisance emergency call. Although endpoint information 286 such as the IP or MAC address may have been logged, tying this back 287 to the device owner may be challenging. 289 Unlike the existing telephone system, VoIP emergency calls could 290 require strong identity, which need not necessarily be coupled to a 291 business relationship with the AIP, ISP or VSP. However, due to the 292 time-critical nature of emergency calls, multi-layer authentication 293 is undesirable, so that in most cases, only the device placing the 294 call will be able to be identified, making the system vulnerable to 295 bot-net attacks. Furthermore, deploying additional credentials for 296 emergency service purposes (such as certificates) increases costs, 297 introduces a significant administrative overhead and is only useful 298 if widely deployed. 300 3. Solutions 302 This section presents three mechanisms which can be used to convey 303 location: signed location by value (Section 3.1), location by 304 reference (Section 3.2) and proxy added location (Section 3.3). 306 In order for to provide authentication and integrity protection for 307 the SIP messages conveying location, several security approaches are 308 available. While it is possible for proxies to use security 309 mechanisms such as SIP Identity [RFC4474] to ensure that 310 modifications to the location in transit can be detected by the 311 location recipient (e.g., the PSAP), compatibility with Session 312 Border Controllers (SBCs) that modify integrity-protected headers has 313 proven to be an issue in practice. As a result, the use of SIP over 314 TLS is at present a more likely mechanism to provide per-message 315 authentication and integrity protection. 317 3.1. Signed Location by Value 319 With location signing, a location server signs the location 320 information before it is sent to the end host, (the entity subject to 321 the location determination process). 323 The signed location information is then verified by the location 324 recipient and not by the target. Figure 1 shows the communication 325 model with the target requesting signed location in step (a), the 326 location server returns it in step (b) and it is then conveyed to the 327 location recipient in step (c) who verifies it. For SIP, the 328 procedures described in "Location Conveyance for the Session 329 Initiation Protocol" [RFC6442] are applicable for location 330 conveyance. 332 +-----------+ +-----------+ 333 | | | Location | 334 | LIS | | Recipient | 335 | | | | 336 +-+-------+-+ +----+------+ 337 ^ | --^ 338 | | -- 339 Geopriv |Req. | -- 340 Location |Signed |Signed -- Geopriv 341 Configuration |Loc. |Loc. -- Using Protocol 342 Protocol |(a) |(b) -- (e.g., SIP) 343 | v -- (c) 344 +-+-------+-+ -- 345 | Target / | -- 346 | End Host + 347 | | 348 +-----------+ 350 Figure 1: Location Signing 352 In order to limit replay attacks, additional information, such as 353 timestamps or expiration times, has to be included together with the 354 signed location. If the location is retrieved from a location 355 server, even a stationary end host has to periodically obtain a fresh 356 signed location, or incur the additional delay of querying during the 357 emergency call. 359 While bot-nets are unlikely to be deterred by location signing, 360 accurate location information would limit the subset of the bot-net 361 that could be used for an attack, as only hosts within the PSAP 362 serving area would be useful in placing emergency calls. 364 To prevent location-swapping attacks it is necessary to include some 365 some target-specific identity information. The required information 366 depends on whether the goal is real-time verification by the location 367 recipient or post-mortem analysis (where the goal is determination of 368 the legal entity responsible for the attack). As argued in Section 369 4, real-time verification is not always possible. 371 Location signing is unlikely to deter attacks launched by bot-nets, 372 since the work required to verify the location signature is 373 considerable. Location signing is also difficult when the host 374 obtains location via mechanisms such as GPS, unless trusted computing 375 approaches, with tamper-proof GPS modules, can be applied. 376 Otherwise, an end host can pretend to have a GPS device, and the 377 recipient will need to rely on its ability to assess the level of 378 trust that should be placed in the end host location claim. 380 A straw-man proposal for location signing is provided in [I- 381 D.thomson-geopriv-location-dependability], and [NENA-i2] Section 3.7 382 includes operational recommendations relating to location signing: 384 Location determination is out of scope for NENA, but we can offer 385 guidance on what should be considered when designing mechanisms to 386 report location: 388 1. The location object should be digitally signed. 390 2. The certificate for the signer (LIS operator) should be 391 rooted in VESA. For this purpose, VPC and ERDB operators 392 should issue certs to LIS operators. 394 3. The signature should include a timestamp. 396 4. Where possible, the Location Object should be refreshed 397 periodically, with the signature (and thus the timestamp) 398 being refreshed as a consequence. 400 5. Anti-spoofing mechanisms should be applied to the Location 401 Reporting method. 403 [Note: The term Valid Emergency Services Authority (VESA) refers 404 to the root certificate authority.] 406 As noted above, signing of location objects implies the development 407 of a trust hierarchy that would enable a certificate chain provided 408 by the LIS operator to be verified by the PSAP. Rooting the trust 409 hierarchy in VESA can be accomplished either by having the VESA 410 directly sign the LIS certificates, or by the creation of 411 intermediate CAs certified by the VESA, which will then issue 412 certificates to the LIS. In terms of the workload imposed on the 413 VESA, the latter approach is highly preferable. However, this raises 414 the question of who would operate the intermediate CAs and what the 415 expectations would be. 417 In particular, the question arises as to the requirements for LIS 418 certificate issuance, and whether they are significantly different 419 from say, requirements for issuance of an SSL/TLS web certificate. 421 3.2. Location by Reference 423 Location-by-reference was developed so that end hosts can avoid 424 having to periodically query the location server for up- to-date 425 location information in a mobile environment. Additionally, if 426 operators do not want to disclose location information to the end 427 host without charging them, location-by-reference provides a 428 reasonable alternative. As noted in "A Location Dereference Protocol 429 Using HTTP-Enabled Location Delivery (HELD)" [RFC6753], a location 430 reference can be obtained via HTTP-Enabled Location Delivery (HELD) 431 [RFC5985] or the Dynamic Host Configuration Protocol (DHCP) location 432 URI option [DHCP-URI-OPT]. 434 Figure 2 shows the communication model with the target requesting a 435 location reference in step (a), the location server returns the 436 reference in step (b), and it is then conveyed to the location 437 recipient in step (c). The location recipient needs to resolve the 438 reference with a request in step (d). Finally, location information 439 is returned to the Location Recipient afterwards. For location 440 conveyance in SIP, the procedures described in [RFC6442] are 441 applicable. 443 +-----------+ Geopriv +-----------+ 444 | | Location | Location | 445 | LIS +<------------->+ Recipient | 446 | | Dereferencing | | 447 +-+-------+-+ Protocol (d) +----+------+ 448 ^ | --^ 449 | | -- 450 Geopriv |Req. | -- 451 Location |LbyR |LbyR -- Geopriv 452 Configuration |(a) |(b) -- Using Protocol 453 Protocol | | -- (e.g., SIP) 454 | V -- (c) 455 +-+-------+-+ -- 456 | Target / | -- 457 | End Host + 458 | | 459 +-----------+ 461 Figure 2: Location by Reference 463 Where location by reference is provided, the recipient needs to 464 deference the LbyR in order to obtain location. The details for the 465 dereferencing operations vary with the type of reference, such as a 466 HTTP, HTTPS, SIP, SIPS URI or a SIP presence URI. 468 For location-by-reference, the location server needs to maintain one 469 or several URIs for each target, timing out these URIs after a 470 certain amount of time. References need to expire to prevent the 471 recipient of such a URL from being able to permanently track a host 472 and to offer garbage collection functionality for the location 473 server. 475 Off-path adversaries must be prevented from obtaining the target's 476 location. The reference contains a randomized component that 477 prevents third parties from guessing it. When the location recipient 478 fetches up-to-date location information from the location server, it 479 can also be assured that the location information is fresh and not 480 replayed. However, this does not address location swapping. 482 With respect to the security of the de-reference operation, [RFC6753] 483 Section 6 states: 485 TLS MUST be used for dereferencing location URIs unless 486 confidentiality and integrity are provided by some other 487 mechanism, as discussed in Section 3. Location Recipients MUST 488 authenticate the host identity using the domain name included in 489 the location URI, using the procedure described in Section 3.1 of 490 [RFC2818]. Local policy determines what a Location Recipient does 491 if authentication fails or cannot be attempted. 493 The authorization by possession model (Section 4.1) further relies 494 on TLS when transmitting the location URI to protect the secrecy 495 of the URI. Possession of such a URI implies the same privacy 496 considerations as possession of the PIDF-LO document that the URI 497 references. 499 Location URIs MUST only be disclosed to authorized Location 500 Recipients. The GEOPRIV architecture [RFC6280] designates the 501 Rule Maker to authorize disclosure of the URI. 503 Protection of the location URI is necessary, since the policy 504 attached to such a location URI permits anyone who has the URI to 505 view the associated location information. This aspect of security 506 is covered in more detail in the specification of location 507 conveyance protocols, such as [RFC6442]. 509 For authorizing access to location-by-reference, two authorization 510 models were developed: "Authorization by Possession" and 511 "Authorization via Access Control Lists". With respect to 512 "Authorization by Possession" [RFC6753] Section 4.1 notes: 514 In this model, possession -- or knowledge -- of the location URI 515 is used to control access to location information. A location URI 516 might be constructed such that it is hard to guess (see C8 of 517 [RFC5808]), and the set of entities that it is disclosed to can be 518 limited. The only authentication this would require by the LS is 519 evidence of possession of the URI. The LS could immediately 520 authorize any request that indicates this URI. 522 Authorization by possession does not require direct interaction 523 with Rule Maker; it is assumed that the Rule Maker is able to 524 exert control over the distribution of the location URI. 525 Therefore, the LIS can operate with limited policy input from a 526 Rule Maker. 528 Limited disclosure is an important aspect of this authorization 529 model. The location URI is a secret; therefore, ensuring that 530 adversaries are not able to acquire this information is paramount. 531 Encryption, such as might be offered by TLS [RFC5246] or S/MIME 532 [RFC5751], protects the information from eavesdroppers. 534 Using possession as a basis for authorization means that, once 535 granted, authorization cannot be easily revoked. Cancellation of 536 a location URI ensures that legitimate users are also affected; 537 application of additional policy is theoretically possible but 538 could be technically infeasible. Expiration of location URIs 539 limits the usable time for a location URI, requiring that an 540 attacker continue o learn new location URIs to retain access to 541 current location information. 543 In situations where "Authorization by Possession" is not suitable 544 (such as where location hiding [RFC6444] is required), the 545 "Authorization via Access Control Lists" model may be preferred. 547 Without the introduction of hierarchy, it would be necessary for the 548 PSAP to obtain client certificates or Digest credentials for all the 549 LISes in its coverage area, to enable it to successfully dereference 550 LbyRs. In situations with more than a few LISes per PSAP, this would 551 present operational challenges. 553 A certificate hierarchy providing PSAPs with client certificates 554 chaining to the VESA could be used to enable the LIS to authenticate 555 and authorize PSAPs for dereferencing. Note that unlike PIDF-LO 556 signing (which mitigates against modification of PIDF-LOs), this 557 merely provides the PSAP with access to a (potentially unsigned) 558 PIDF-LO, albeit over a protected TLS channel. 560 Another approach would be for the local LIS to upload location 561 information to a location aggregation point who would in turn manage 562 the relationships with the PSAP. This would shift the management 563 burden from the PSAPs to the location aggregation points. 565 3.3. Proxy Adding Location 567 Instead of relying upon the end host to provide location, is possible 568 for a proxy that has the ability to determine the location of the end 569 point (e.g., based on the end host IP or MAC address) to retrieve and 570 add or override location information. 572 The use of proxy-added location is primarily applicable in scenarios 573 where the end host does not provide location. As noted in [RFC6442] 574 Section 4.1: 576 A SIP intermediary SHOULD NOT add location to a SIP request that 577 already contains location. This will quite often lead to 578 confusion within LRs. However, if a SIP intermediary adds 579 location, even if location was not previously present in a SIP 580 request, that SIP intermediary is fully responsible for addressing 581 the concerns of any 424 (Bad Location Information) SIP response it 582 receives about this location addition and MUST NOT pass on 583 (upstream) the 424 response. A SIP intermediary that adds a 584 locationValue MUST position the new locationValue as the last 585 locationValue within the Geolocation header field of the SIP 586 request. 588 A SIP intermediary MAY add a Geolocation header field if one is 589 not present -- for example, when a user agent does not support the 590 Geolocation mechanism but their outbound proxy does and knows the 591 Target's location, or any of a number of other use cases (see 592 Section 3). 594 As noted in [RFC6442] Section 3.3: 596 This document takes a "you break it, you bought it" approach to 597 dealing with second locations placed into a SIP request by an 598 intermediary entity. That entity becomes completely responsible 599 for all location within that SIP request (more on this in Section 600 4). 602 While it is possible for the proxy to override location included by 603 the end host, [RFC6442] Section 3.4 notes the operational 604 limitations: 606 Overriding location information provided by the user requires a 607 deployment where an intermediary necessarily knows better than an 608 end user -- after all, it could be that Alice has an on-board GPS, 609 and the SIP intermediary only knows her nearest cell tower. Which 610 is more accurate location information? Currently, there is no way 611 to tell which entity is more accurate or which is wrong, for that 612 matter. This document will not specify how to indicate which 613 location is more accurate than another. 615 The disadvantage of this approach is the need to deploy application 616 layer entities, such as SIP proxies, at AIPs or associated with AIPs. 617 This requires a standardized VoIP profile to be deployed at every end 618 device and at every AIP. This might impose interoperability 619 challenges. 621 Additionally, the AIP needs to take responsibility for emergency 622 calls, even for customers they have no direct or indirect 623 relationship with. To provide identity information about the 624 emergency caller from the VSP it would be necessary to let the AIP 625 and the VSP to interact for authentication (see, for example, 626 [RFC4740]). This interaction along the Authentication, Authorization 627 and Accounting infrastructure is often based on business 628 relationships between the involved entities. The AIP and the VSP are 629 very likely to have no such business relationship, particularly when 630 talking about an arbitrary VSP somewhere on the Internet. In case 631 that the interaction between the AIP and the VSP fails due to the 632 lack of a business relationship then typically a fall-back would be 633 provided where no emergency caller identity information is made 634 available to the PSAP and the emergency call still has to be 635 completed. 637 4. Location Trust Assessment 639 The ability to assess the level of trustworthiness of conveyed 640 location information is important, since this makes it possible to 641 understand how much value should be placed on location information, 642 as part of the decision making process. As an example, if automated 643 location information is understood to be highly suspect, a call taker 644 can put more effort into obtaining location information from the 645 caller. 647 Caller accountability is another important aspect of trust 648 assessment. Can the individual purchasing the device or activating 649 service be identified or did the call originate from a non-service 650 initialized (NSI) device whose owner cannot be determined? Prior to 651 the call, was the caller authenticated at the network or application 652 layer? In the event of a prank call, can audit logs be made 653 available to an investigator, or can information relating to the 654 owner of an unlinked pseudonym be provided, enabling investigators to 655 unravel the chain of events that lead to the attack? In practice, 656 the ability to identify a caller may decrease the likelihood of 657 caller misbehavior. For example, where emergency calls have been 658 allowed from handsets lacking a SIM card, or where ownership of the 659 SIM card cannot be determined, the frequency of nuisance calls has 660 often been unacceptably high [TASMANIA][UK][SA]. 662 Note that location trust assessment has value regardless of whether 663 the location has been conveyed securely (via signed location, 664 location-by-reference or proxy-added location) or not (via location- 665 by-value without location signing), since secure conveyance does not 666 provide assurance relating to the validity or provenance of location 667 data. 669 In practice, the source of the location data is important for 670 location trust assessment. For example, location provided by a 671 Location Information Server (LIS) whose administrator has an 672 established history of meeting emergency location accuracy 673 requirements (e.g. Phase II) may be considered more reliable than 674 location information provided by a third party Location Service 675 Provider (LSP) that disclaims use of location information for 676 emergency purposes. 678 However, even where an LSP does not attempt to meet the accuracy 679 requirements for emergency location, it still may be able to provide 680 information useful in assessing about how reliable location 681 information is likely to be. For example, was location determined 682 based on the nearest cell tower or 802.11 Access Point (AP), or was a 683 triangulation method used? If based on cell tower or AP location 684 data, was the information obtained from an authoritative source (e.g. 686 the tower or AP owner) and when was the last time that the location 687 of the tower or access point was verified? 689 For real-time validation, information in the signaling and media 690 packets can be cross checked against location information. For 691 example, it may be possible to determine the region associated with 692 the IP address included within SIP Via: or Contact: headers, or the 693 media source address, and compare this against the location 694 information reported by the caller or conveyed in the PIDF-LO. While 695 a CAPTCHA-style test may be applied to suspicious calls to lower the 696 risk from bot-nets, this is quite controversial for emergency 697 services, due to the risk of delaying or rejecting valid calls. 699 Although privacy-preserving procedures may be disabled for emergency 700 calls, by design, PIDF-LO objects limit the information available for 701 real-time attribution. As noted in [RFC5985] Section 6.6: 703 The LIS MUST NOT include any means of identifying the Device in 704 the PIDF-LO unless it is able to verify that the identifier is 705 correct and inclusion of identity is expressly permitted by a Rule 706 Maker. Therefore, PIDF parameters that contain identity are 707 either omitted or contain unlinked pseudonyms [RFC3693]. A 708 unique, unlinked presentity URI SHOULD be generated by the LIS for 709 the mandatory presence "entity" attribute of the PIDF document. 710 Optional parameters such as the "contact" and "deviceID" elements 711 [RFC4479] are not used. 713 Also, the device referred to in the PIDF-LO may not necessarily be 714 the same entity conveying the PIDF-LO to the PSAP. As noted in 715 [RFC6442] Section 1: 717 In no way does this document assume that the SIP user agent client 718 that sends a request containing a location object is necessarily 719 the Target. The location of a Target conveyed within SIP 720 typically corresponds to that of a device controlled by the 721 Target, for example, a mobile phone, but such devices can be 722 separated from their owners, and moreover, in some cases, the user 723 agent may not know its own location. 725 Due to these design choices, it is possible for an attacker to cut 726 and paste a PIDF-LO obtained by a different device or user into a SIP 727 INVITE and send this to the PSAP. While PIDF-LO signing would 728 prevent modification of a PIDF-LO or invention of one out of whole 729 cloth, it would not prevent this cut and paste attack. Neither would 730 implementation of "Enhancements for Authenticated Identity Management 731 in the Session Initiation Protocol (SIP)" [RFC4474], allowing the 732 recipient to verify the identity assertion in the From: header. 733 However, while it might not be possible to detect the cut and paste 734 in real-time, examination of the audit logs might provide enough 735 information to enable events to be reconstructed. 737 Real-time validation of the timestamp contained within PIDF-LO 738 objects (reflecting the time at which the location was determined) is 739 also challenging. Even if the PIDF-LO is signed the timestamp only 740 represents an assertion by the LIS, which may or may not be 741 trustworthy. For example, the recipient of the signed PIDF-LO may 742 not know whether the LIS supports time synchronization, or whether it 743 is possible to reset the LIS clock manually without detection. Even 744 if the timestamp was valid at the time location was determined, a 745 time period may elapse between when the PIDF-LO was provided and when 746 it is conveyed to the recipient. Periodically refreshing location 747 information to renew the timestamp even though the location 748 information itself is unchanged puts additional load on LISes. As a 749 result, recipients need to validate the timestamp in order to 750 determine whether it is credible. 752 While this document focuses on the discussion of real-time 753 determination of suspicious emergency calls, the use of audit logs 754 may help in enforcing accountability among emergency callers. For 755 example, in the event of a prank call, information relating to the 756 owner of the unlinked pseudonym could be provided to investigators, 757 enabling them to unravel the chain of events that lead to the attack. 758 However, while auditability is an important deterrent, it is likely 759 to be of most benefit in situations where attacks on the emergency 760 services system are likely to be relatively infrequent, since the 761 resources required to pursue an investigation are likely to be 762 considerable. However, although real-time validation based on PIDF- 763 LO elements is challenging, where LIS audit logs are available (such 764 as where a law enforcement agency can present a subpoena), linking of 765 a pseudonym to the device obtaining location can be accomplished in a 766 post-mortem. 768 Where attacks are frequent and continuous, automated mechanisms are 769 required. For example, it might be valuable to develop mechanisms to 770 exchange audit trails information in a standardized format between 771 ISPs and PSAPs / VSPs and PSAPs or heuristics to distinguish 772 potentially fraudulent emergency calls from real emergencies. 774 5. Security Considerations 776 IP-based emergency services face a number of security threats that do 777 not exist within the legacy system. In order to limit prank calls, 778 legacy emergency services rely on the ability to identify callers, as 779 well as on the difficulty of location spoofing for normal users. The 780 ability to ascertain identity is important, since the threat of 781 punishment reduces prank calls; as an example, calls from pay phones 782 are subject to greater scrutiny by the call taker. 784 Mechanically placing a large number of emergency calls that appear to 785 come from different locations is difficult in a legacy environment. 786 Also, in the current system, it would be very difficult for an 787 attacker from country 'Foo' to attack the emergency services 788 infrastructure located in country 'Bar'. 790 However, within an IP-based emergency services a number of these 791 attacks become much easier to mount. Emergency services have three 792 finite resources subject to denial of service attacks: the network 793 and server infrastructure, call takers and dispatchers, and the first 794 responders, such as fire fighters and police officers. Protecting 795 the network infrastructure is similar to protecting other high-value 796 service providers, except that location information may be used to 797 filter call setup requests, to weed out requests that are out of 798 area. PSAPs even for large cities may only have a handful of PSAP 799 call takers on duty, so even if they can, by questioning the caller, 800 eliminate a lot of prank calls, they are quickly overwhelmed by even 801 a small-scale attack. Finally, first responder resources are scarce, 802 particularly during mass-casualty events. 804 Attackers may want to modify, prevent or delay emergency calls. In 805 some cases, this will lead the PSAP to dispatch emergency personnel 806 to an emergency that does not exist and, hence, the personnel might 807 not be available to other callers. It might also be possible for an 808 attacker to impede the users from reaching an appropriate PSAP by 809 modifying the location of an end host or the information returned 810 from the mapping protocol. In some countries, regulators may not 811 require the authenticated identity of the emergency caller, as is 812 true for PSTN-based emergency calls placed from pay phones or SIM- 813 less cell phones today. Furthermore, if identities can easily be 814 crafted (as it is the case with many VoIP offerings today), then the 815 value of emergency caller authentication itself might be limited. As 816 a consequence, an attacker can forge emergency call information 817 without the chance of being held accountable for its own actions. 819 The above-mentioned attacks are mostly targeting individual emergency 820 callers or a very small fraction of them. If attacks are, however, 821 launched against the mapping architecture (see [RFC5582] or against 822 the emergency services IP network (including PSAPs), a larger region 823 and a large number of potential emergency callers are affected. The 824 call takers themselves are a particularly scarce resource and if 825 human interaction by these call takers is required then this can very 826 quickly have severe consequences. 828 Although it is important to ensure that location information cannot 829 be faked there will be many GPS-enabled devices that will find it 830 difficult to utilize any of the solutions described in Section 3. It 831 is also unlikely that users will be willing to upload their location 832 information for "verification" to a nearby location server located in 833 the access network. 835 6. IANA Considerations 837 This document does not require actions by IANA. 839 7. References 841 7.1. Informative References 843 [DHCP-URI-OPT] 844 Polk, J., "Dynamic Host Configuration Protocol (DHCP) IPv4 and 845 IPv6 Option for a Location Uniform Resource Identifier (URI)", 846 Internet draft (work in progress), draft-ietf-geopriv-dhcp- 847 lbyr-uri-option-19, February 2013. 849 [EENA] EENA, "False Emergency Calls", EENA Operations Document, 850 Version 1.0, March 2011, 851 http://www.eena.org/ressource/static/files/ 852 2011_03_15_3.1.2.fc_v1.0.pdf 854 [GPSCounter] 855 Warner, J. S. and R. G. Johnston, "GPS Spoofing 856 Countermeasures", Los Alamos research paper LAUR-03-6163, 857 December 2003. 859 [NENA-i2] "08-001 NENA Interim VoIP Architecture for Enhanced 9-1-1 860 Services (i2)", December 2005. 862 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 863 Requirement Levels", BCP 14, RFC 2119, March 1997. 865 [RFC2818] Rescorla, E., "HTTP over TLS", RFC 2818, May 2000. 867 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. 868 Polk, "Geopriv Requirements", RFC 3693, February 2004. 870 [RFC3694] Danley, M., Mulligan, D., Morris, J. and J. Peterson, "Threat 871 Analysis of the Geopriv Protocol", RFC 3694, February 2004. 873 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 874 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 875 3748, June 2004. 877 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated 878 Identity Management in the Session Initiation Protocol (SIP)", 879 RFC 4474, August 2006. 881 [RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, July 882 2006. 884 [RFC4740] Garcia-Martin, M., Belinchon, M., Pallares-Lopez, M., Canales- 885 Valenzuela, C., and K. Tammi, "Diameter Session Initiation 886 Protocol (SIP) Application", RFC 4740, November 2006. 888 [RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H. and M. Shanmugam, 889 "Security Threats and Requirements for Emergency Call Marking 890 and Mapping", RFC 5069, January 2008. 892 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Level Security 893 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 895 [RFC5491] Winterbottom, J., Thomson, M. and H. Tschofenig, "GEOPRIV 896 Presence Information Data Format Location Object (PIDF-LO) 897 Usage Clarification, Considerations, and Recommendations", RFC 898 5491, March 2009. 900 [RFC5582] Schulzrinne, H., "Location-to-URL Mapping Architecture and 901 Framework", RFC 5582, September 2009. 903 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail 904 Extensions (S/MIME) Version 3.2 Message Specification", RFC 905 5751, January 2010. 907 [RFC5808] Marshall, R., "Requirements for a Location-by-Reference 908 Mechanism", RFC 5808, May 2010. 910 [RFC5985] Barnes, M., "HTTP Enabled Location Delivery (HELD)", RFC 5985, 911 September 2010. 913 [RFC6280] Barnes, R., et. al, "An Architecture for Location and Location 914 Privacy in Internet Applications", RFC 6280, July 2011. 916 [RFC6442] Polk, J., Rosen, B. and J. Peterson, "Location Conveyance for 917 the Session Initiation Protocol", RFC 6442, December 2011. 919 [RFC6444] Schulzrinne, H., Liess, L., Tschofenig, H., Stark, B., and A. 920 Kuett, "Location Hiding: Problem Statement and Requirements", 921 RFC 6444, January 2012. 923 [RFC6753] Winterbottom, J., Tschofenig. H., Schulzrinne, H. and M. 924 Thomson, "A Location Dereference Protocol Using HTTP-Enabled 925 Location Delivery (HELD)", RFC 6753, October 2012. 927 [SA] "Saudi Arabia - Illegal sale of SIMs blamed for surge in prank 928 calls", Arab News, May 4, 2010, 929 http://www.menafn.com/qn_news_story_s.asp?StoryId=1093319384 931 [Swatting] 932 "Don't Make the Call: The New Phenomenon of 'Swatting', 933 Federal Bureau of Investigation, February 4, 2008, 934 http://www.fbi.gov/news/stories/2008/february/swatting020408 936 [TASMANIA] 937 "Emergency services seek SIM-less calls block", ABC News 938 Online, August 18, 2006, 939 http://www.abc.net.au/news/newsitems/200608/s1717956.htm 941 [UK] "Rapper makes thousands of prank 999 emergency calls to UK 942 police", Digital Journal, June 24, 2010, 943 http://www.digitaljournal.com/article/293796?tp=1 945 Acknowledgments 947 We would like to thank the members of the IETF ECRIT working group, 948 including Marc Linsner, Henning Schulzrinne and Brian Rosen, for 949 their input at IETF 85 that helped get this documented pointed in the 950 right direction. We would also like to thank members of the IETF 951 GEOPRIV WG, including Andrew Newton, Murugaraj Shanmugam, Martin 952 Thomson, Richard Barnes and Matt Lepinski for their feedback to 953 previous versions of this document. 955 Authors' Addresses 957 Hannes Tschofenig 958 Nokia Siemens Networks 959 Linnoitustie 6 960 Espoo 02600 961 Finland 963 Phone: +358 (50) 4871445 964 Email: Hannes.Tschofenig@gmx.net 965 URI: http://www.tschofenig.priv.at 967 Henning Schulzrinne 968 Columbia University 969 Department of Computer Science 970 450 Computer Science Building, New York, NY 10027 971 US 973 Phone: +1 212 939 7004 974 Email: hgs@cs.columbia.edu 975 URI: http://www.cs.columbia.edu 977 Bernard Aboba 978 Microsoft Corporation 979 One Microsoft Way 980 Redmond, WA 98052 981 US 983 Email: bernard_aboba@hotmail.com