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