idnits 2.17.1 draft-ietf-ecrit-trustworthy-location-04.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 (22 October 2012) is 4203 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 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: April 22, 2013 Columbia University 6 B. Aboba (ed.) 7 Microsoft Corporation 8 22 October 2012 10 Trustworthy Location 11 draft-ietf-ecrit-trustworthy-location-04.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 the problem of "trustworthy location" as well 20 as potential solutions. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 22, 2013. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Emergency Services Architecture . . . . . . . . . . . . . . . 4 59 3. Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.1. Location Spoofing . . . . . . . . . . . . . . . . . . . . 6 61 3.2. Identity Spoofing . . . . . . . . . . . . . . . . . . . . 7 62 4. Solution Proposals . . . . . . . . . . . . . . . . . . . . . . 8 63 4.1. Location Signing . . . . . . . . . . . . . . . . . . . . . 8 64 4.2. Location by Reference . . . . . . . . . . . . . . . . . . 10 65 4.3. Proxy Adding Location . . . . . . . . . . . . . . . . . . 11 66 5. Operational Considerations . . . . . . . . . . . . . . . . . . 12 67 5.1. Attribution to a Specific Trusted Source . . . . . . . . . 12 68 5.2. Application to a Specific Point in Time . . . . . . . . . 16 69 5.3. Linkage to a Specific Endpoint . . . . . . . . . . . . . . 17 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 72 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 74 9.1. Informative references . . . . . . . . . . . . . . . . . . 18 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 77 1. Introduction 79 Several public and commercial services depend upon location 80 information in their operations. This includes emergency services 81 (such as fire, ambulance and police) as well as commercial services 82 such as food delivery and roadside assistance. 84 Services that depend on accurate location commonly experience 85 security issues today. While prank calls have been a problem for 86 emergency services dating back to the time of street corner call 87 boxes, a recent increase in the frequency and sophistication of the 88 attacks has lead to the FBI issuing a warning [Swatting]. Since 89 prank emergency calls can endanger bystanders or emergency services 90 personnel, or divert resources away from legitimate emergencies, they 91 can be life threatening. 93 It should be kept in mind that issues of location trust and 94 attribution are closely linked. In situations where tracing of an 95 emergency call back to the originator is more difficult, experience 96 has shown that the frequency of nuisance calls can rise dramatically. 97 For example, where emergency calls have been allowed from handsets 98 lacking a SIM card, or where ownership of the SIM card cannot be 99 determined, the frequency of nuisance calls has often been 100 unacceptably high [TASMANIA][UK][SA]. 102 Conversely, where the ability exists enable an investigator to 103 determine the originator of a prank emergency call after the fact, 104 the trustworthiness of location is likely to improve, even without 105 the introduction of measures to limit location spoofing. Under a 106 court order, an investigator can have access to additional 107 information beyond the messages conveyed in the emergency call. For 108 example, in such a situation, audit logs will often be made available 109 and in addition, information relating to the owner of an unlinked 110 pseudonym could be provided to investigators, enabling them to 111 unravel the chain of events that lead to the attack. 113 This document reviews the emergency services architecture in Section 114 2, investigates security threats in Section 3, and outlines potential 115 solutions in Section 4. Operational considerations are provided in 116 Section 5 and security considerations are discussed in Section 6. 118 1.1. Terminology 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in [RFC2119]. 124 This document uses terms from [RFC5012] Section 3. 126 2. Emergency Services Architecture 128 Users of the telephone network can summon emergency services such as 129 ambulance, fire and police using a well-known emergency service 130 number (e.g., 9-1-1 in North America, 1-1-2 in Europe). Location 131 information is used to route emergency calls to the appropriate 132 regional Public Safety Answering Point (PSAP) that serves the caller 133 to dispatch first-level responders to the emergency site. 135 In emergency services deployments utilizing voice over IP, many of 136 the assumptions of the Plain Old Telephone Service (POTS) and public 137 land mobile network (PLMN) no longer hold. While both POTS and PLMN 138 service providers often both physical access as well as phone 139 service, with Voice over IP (VoIP) there is a split between the role 140 of the Access Infrastructure Provider (AIP), and the Application 141 (Voice) Service Provider (VSP). The VSP may be located far away from 142 the AIP and may either have no business relationship with the AIP or 143 may be a competitor. It is also likely that the VSP will have no 144 relationship with the PSAP. 146 In some situations it is possible for the end host to determine its 147 own location using technology such as the Global Positioning System 148 (GPS). Where the end host cannot determine location on its own, 149 mechanisms have been standardized to make civic and geodetic location 150 available to the end host, including LLDP-MED [LLDP-MED], DHCP 151 extensions [RFC4776][RFC6225], HELD [RFC5985], or link-layer 152 specifications such as [IEEE-802.11y]. The server offering this 153 information is known as a Location Information Server (LIS). The LIS 154 may be deployed by an AIP, or it may be run by a Location Service 155 Provider (LSP) which may have no relationship with the AIP, the VSP 156 or the PSAP. The location information, provided by reference or by 157 value, is then conveyed to the service-providing entities, i.e. 158 location recipients, via application protocols, such as HTTP, SIP or 159 XMPP. 161 Where the end host does not provide location, or is not trusted to do 162 so, it is possible for an intermediary to retrieve location 163 information on behalf of the endpoint. 165 3. Threats 167 This section focuses on threats deriving from the introduction of 168 untrustworthy location information, regardless of whether this occurs 169 intentionally or unintentionally. 171 In addition to threats arising from the intentional forging of 172 location information, end hosts may be induced to provide 173 untrustworthy location information. For example, end hosts may 174 obtain location from civilian GPS, which is vulnerable to spoofing 175 [GPSCounter] or from third party Location Service Providers (LSPs) 176 which may be vulnerable to attack or may not warrant the use of their 177 services for emergency purposes. 179 Emergency services have three finite resources subject to denial of 180 service attacks: the network and server infrastructure, call takers 181 and dispatchers, and the first responders, such as fire fighters and 182 police officers. Protecting the network infrastructure is similar to 183 protecting other high-value service providers, except that location 184 information may be used to filter call setup requests, to weed out 185 requests that are out of area. PSAPs even for large cities may only 186 have a handful of PSAP call takers on duty, so even if they can, by 187 questioning the caller, eliminate a lot of prank calls, they are 188 quickly overwhelmed by even a small-scale attack. Finally, first 189 responder resources are scarce, particularly during mass-casualty 190 events. 192 Legacy emergency services rely on the ability to identify callers, as 193 well as on the difficulty of location spoofing for normal users to 194 limit prank calls. The ability to ascertain identity is important, 195 since the threat of severe punishments reduces prank calls. 196 Mechanically placing a large number of emergency calls that appear to 197 come from different locations is difficult. Calls from pay phones 198 are subject to greater scrutiny by the call taker. In the current 199 system, it would be very difficult for an attacker from country 'Foo' 200 to attack the emergency services infrastructure located in country 201 'Bar'. 203 One of the main motivations of an adversary in the emergency services 204 context is to prevent callers from utilizing emergency service 205 support. This can be done by a variety of means, such as 206 impersonating a PSAP or directory servers, attacking SIP signaling 207 elements and location servers. 209 Attackers may want to modify, prevent or delay emergency calls. In 210 some cases, this will lead the PSAP to dispatch emergency personnel 211 to an emergency that does not exist and, hence, the personnel might 212 not be available to other callers. It might also be possible for an 213 attacker to impede the users from reaching an appropriate PSAP by 214 modifying the location of an end host or the information returned 215 from the mapping protocol. In some countries, regulators may not 216 require the authenticated identity of the emergency caller, as is 217 true for PSTN-based emergency calls placed from pay phones or SIM- 218 less cell phones today. Furthermore, if identities can easily be 219 crafted (as it is the case with many VoIP offerings today), then the 220 value of emergency caller authentication itself might be limited. As 221 a consequence, an attacker can forge emergency call information 222 without the chance of being held accountable for its own actions. 224 The above-mentioned attacks are mostly targeting individual emergency 225 callers or a very small fraction of them. If attacks are, however, 226 launched against the mapping architecture (see [RFC5582] or against 227 the emergency services IP network (including PSAPs), a larger region 228 and a large number of potential emergency callers are affected. The 229 call takers themselves are a particularly scarce resource and if 230 human interaction by these call takers is required then this can very 231 quickly have severe consequences. 233 To provide a structured analysis we distinguish between three 234 adversary models: 236 External adversary model: The end host, e.g., an emergency caller 237 whose location is going to be communicated, is honest and the 238 adversary may be located between the end host and the location 239 server or between the end host and the PSAP. None of the 240 emergency service infrastructure elements act maliciously. 242 Malicious infrastructure adversary model: The emergency call routing 243 elements, such as the LIS, the LoST infrastructure, used for 244 mapping locations to PSAP address, or call routing elements, may 245 act maliciously. 247 Malicious end host adversary model: The end host itself acts 248 maliciously, whether the owner is aware of this or whether it is 249 acting as a bot. 251 In this document, we focus only on the malicious end host adversary 252 model. 254 3.1. Location Spoofing 256 An adversary can provide false location information in an emergency 257 call in order to misdirect emergency resources. For calls 258 originating within the PSTN, this attack can be carried out via 259 caller-id spoofing. Where location is attached to the emergency call 260 by an end host, several avenues are available to provide false 261 location information: 263 1. The end host could fabricate a PIDF-LO and convey it within an 264 emergency call; 266 2. The VSP (and indirectly a LIS) could be fooled into using the 267 wrong identity (such as an IP address) for location lookup, 268 thereby providing the end host with misleading location 269 information; 270 3. Inaccurate or out-of-date information (such spoofed GPS 271 signals, a stale wiremap or an inaccurate access point location 272 database) could be utilized by the LIS or the endhost in its 273 location determination, thereby leading to an inaccurate 274 determination of location. 276 By analysis of the SIP headers, it may be possible to flag situations 277 where the conveyed location is suspect (e.g. potentially wrong city, 278 state, country or continent). However, in other situations only 279 entities close to the caller may be able to verify the correctness of 280 location information. 282 The following list presents threats specific to location information 283 handling: 285 Place shifting: Trudy, the adversary, pretends to be at an arbitrary 286 location. In some cases, place shifting can be limited in range, 287 e.g., to the coverage area of a particular cell tower. 289 Time shifting: Trudy pretends to be at a location she was a while 290 ago. 292 Location theft: Trudy observes Alice's location and replays it as 293 her own. 295 Location swapping: Trudy and Malory, located in different locations, 296 can collude and swap location information and pretend to be in 297 each other's location. 299 3.2. Identity Spoofing 301 With calls originating on an IP network, at least two forms of 302 identity are relevant, with the distinction created by the split 303 between the AIP and the VSP: 305 (a) network access identity such as might be determined via 306 authentication (e.g., using the Extensible Authentication Protocol 307 (EAP) [RFC3748]); 309 (b) caller identity, such as might be determined from authentication 310 of the emergency caller at the VoIP application layer. 312 If the adversary did not authenticate itself to the VSP, then 313 accountability may depend on verification of the network access 314 identity. However, this also may not have been authenticated, such 315 as in the case where an open IEEE 802.11 Access Point is used to 316 initiate a nuisance emergency call. Although endpoint information 317 such as the IP or MAC address may have been logged, tying this back 318 to the device owner may be challenging. 320 Unlike the existing telephone system, VoIP emergency calls could 321 require strong identity, which need not necessarily be coupled to a 322 business relationship with the AIP, ISP or VSP. However, due to the 323 time-critical nature of emergency calls, multi-layer authentication 324 is undesirable, so that in most cases, only the device placing the 325 call will be able to be identified, making the system vulnerable to 326 bot-net attacks. Furthermore, deploying additional credentials for 327 emergency service purposes (such as certificates) increases costs, 328 introduces a significant administrative overhead and is only useful 329 if widely deployed. 331 4. Solution Proposals 333 This section presents three potential solutions to the described 334 threats: location signing (Section 4.1), location by reference 335 (Section 4.2) and proxy added location (Section 4.3). 337 4.1. Location Signing 339 One way to avoid location spoofing is to let a trusted location 340 server sign the location information before it is sent to the end 341 host, i.e., the entity subject to the location determination process. 342 The signed location information is then verified by the location 343 recipient and not by the target. Figure 1 shows the communication 344 model with the target requesting signed location in step (a), the 345 location server returns it in step (b) and it is then conveyed to the 346 location recipient in step (c) who verifies it. For SIP, the 347 procedures described in [RFC6442] are applicable for location 348 conveyance. 350 +-----------+ +-----------+ 351 | | | Location | 352 | LIS | | Recipient | 353 | | | | 354 +-+-------+-+ +----+------+ 355 ^ | --^ 356 | | -- 357 Geopriv |Req. | -- 358 Location |Signed |Signed -- Geopriv 359 Configuration |Loc. |Loc. -- Using Protocol 360 Protocol |(a) |(b) -- (e.g., SIP) 361 | v -- (c) 362 +-+-------+-+ -- 363 | Target / | -- 364 | End Host + 365 | | 366 +-----------+ 368 Figure 1: Location Signing 370 Additional information, such as timestamps or expiration times, has 371 to be included together with the signed location to limit replay 372 attacks. If the location is retrieved from a location server, even a 373 stationary end host has to periodically obtain a fresh signed 374 location, or incur the additional delay of querying during the 375 emergency call. Bot nets are also unlikely to be deterred by 376 location signing. However, accurate location information would limit 377 the usable subset of the bot net, as only hosts within the PSAP 378 serving area would be useful in placing calls. 380 To prevent location-swapping attacks it is necessary to include some 381 some target specific identity information. The included information 382 depends on the purpose, namely either real-time verification by the 383 location recipient or for the purpose of a post-mortem analysis when 384 the location recipient wants to determine the legal entity behind the 385 target for prosecution (if this is possible). As argued in Section 6 386 the operational considerations make a real-time verification 387 difficult. A strawman proposal for location signing is provided by 388 [I-D.thomson-geopriv-location-dependability]. 390 Still, for large-scale attacks launched by bot nets, this is unlikely 391 to be helpful. Location signing is also difficult when the host 392 provides its own location via GPS, which is likely to be a common 393 occurrence for mobile devices. Trusted computing approaches, with 394 tamper-proof GPS modules, may be needed in that case. After all, a 395 device can always pretend to have a GPS device and the recipient has 396 no way of verifying this or forcing disclosure of non-GPS-derived 397 location information. 399 Location verification may be most useful if it is used in conjunction 400 with other mechanisms. For example, a call taker can verify that the 401 region that corresponds to the IP address of the media stream roughly 402 corresponds to the location information reported by the caller. To 403 make the use of bot nets more difficult, a CAPTCHA-style test may be 404 applied to suspicious calls, although this idea is quite 405 controversial for emergency services, at the danger of delaying or 406 even rejecting valid calls. 408 4.2. Location by Reference 410 The location-by-reference concept was developed so that end hosts 411 could avoid having to periodically query the location server for up- 412 to-date location information in a mobile environment. Additionally, 413 if operators do not want to disclose location information to the end 414 host without charging them, location-by-reference provides a 415 reasonable alternative. 417 Figure 2 shows the communication model with the target requesting a 418 location reference in step (a), the location server returns the 419 reference in step (b), and it is then conveyed to the location 420 recipient in step (c). The location recipient needs to resolve the 421 reference with a request in step (d). Finally, location information 422 is returned to the Location Recipient afterwards. For location 423 conveyance in SIP, the procedures described in [I-D.ietf-sip- 424 location-conveyance] are applicable. 426 +-----------+ Geopriv +-----------+ 427 | | Location | Location | 428 | LIS +<------------->+ Recipient | 429 | | Dereferencing | | 430 +-+-------+-+ Protocol (d) +----+------+ 431 ^ | --^ 432 | | -- 433 Geopriv |Req. | -- 434 Location |LbyR |LbyR -- Geopriv 435 Configuration |(a) |(b) -- Using Protocol 436 Protocol | | -- (e.g., SIP) 437 | V -- (c) 438 +-+-------+-+ -- 439 | Target / | -- 440 | End Host + 441 | | 442 +-----------+ 444 Figure 2: Location by Reference 446 The details for the dereferencing operations vary with the type of 447 reference, such as a HTTP, HTTPS, SIP, SIPS URI or a SIP presence 448 URI. HTTP-Enabled Location Delivery (HELD) [RFC5985] is an example 449 of a protocol that is able to return such references. 451 For location-by-reference, the location server needs to maintain one 452 or several URIs for each target, timing out these URIs after a 453 certain amount of time. References need to expire to prevent the 454 recipient of such a URL from being able to permanently track a host 455 and to offer garbage collection functionality for the location 456 server. 458 Off-path adversaries must be prevented from obtaining the target's 459 location. The reference contains a randomized component that 460 prevents third parties from guessing it. When the location recipient 461 fetches up-to-date location information from the location server, it 462 can also be assured that the location information is fresh and not 463 replayed. However, this does not address location swapping. 465 However, location-by-reference does not offer significant security 466 benefits if the end host uses GPS to determine its location. At 467 best, a network provider can use cell tower or triangulation 468 information to limit the inaccuracy of user-provided location 469 information. 471 4.3. Proxy Adding Location 473 Instead of making location information available to the end host, it 474 is possible to allow an entity in the AIP, or associated with the 475 AIP, to retrieve the location information on behalf of the end point. 476 This solution is possible when the application layer messages are 477 routed through an entity with the ability to determine the location 478 information of the end point, for example based on the end host's IP 479 or MAC address. 481 When the untrustworthy end host does not have the ability to access 482 location information, it cannot modify it either. Proxies can use 483 various authentication security techniques, including SIP Identity 484 [RFC4474], to ensure that modifications to the location in transit 485 can be detected by the location recipient (e.g., the PSAP). As noted 486 above, this is unlikely to work for GPS-based location determination 487 techniques. 489 The obvious disadvantage of this approach is that there is a need to 490 deploy application layer entities, such as SIP proxies, at AIPs or 491 associated with AIPs. This requires a standardized VoIP profile to 492 be deployed at every end device and at every AIP, for example, based 493 on SIP. This might impose a certain interoperability challenge. 494 Additionally, the AIP more or less takes the responsibility for 495 emergency calls, even for customers they have no direct or indirect 496 relationship with. To provide identity information about the 497 emergency caller from the VSP it would be necessary to let the AIP 498 and the VSP to interact for authentication (see, for example, 499 [RFC4740]). This interaction along the Authentication, Authorization 500 and Accounting infrastructure (see ) is often based on business 501 relationships between the involved entities. The AIP and the VSP are 502 very likely to have no such business relationship, particularly when 503 talking about an arbitrary VSP somewhere on the Internet. In case 504 that the interaction between the AIP and the VSP fails due to the 505 lack of a business relationship then typically a fall-back would be 506 provided where no emergency caller identity information is made 507 available to the PSAP and the emergency call still has to be 508 completed. 510 5. Operational Considerations 512 5.1. Attribution to a Specific Trusted Source 514 [NENA-i2] Section 3.7 describes some of the aspects of attribution as 515 follows: 517 The i2 solution proposes a Location Information Server (LIS) be 518 the source for distributing location information within an access 519 network. Furthermore the validity, integrity and authenticity of 520 this information are directly attributed to the LIS operator. 522 Section 5.1.1 describes the issues that arise in ensuring the 523 validity of location information provided by the LIS operator. 524 Section 5.1.2 and Section 5.1.3 describe operational issues that 525 arise in ensuring the integrity and authenticity of location 526 information provided by the LIS operator. 528 5.1.1. Validity 530 In existing networks where location information is both determined by 531 the access/voice service provider as well as communicated by the AIP/ 532 VSP, responsibility for location validity can be attributed entirely 533 to a single party, namely the AIP/VSP. 535 However, on the Internet, not only may the AIP and VSP represent 536 different parties, but location determination may depend on 537 information contributed by parties trusted by neither the AIP nor 538 VSP, or even the operator of the Location Information Server (LIS). 539 In such circumstances, mechanisms for enhancing the integrity or 540 authenticity of location data contribute little toward ensuring the 541 validity of that data. 543 It should be understood that the means by which location is 544 determined may not necessarily relate to the means by which the 545 endpoint communicates with the LIS. Just because a Location 546 Configuration Protocol (LCP) operates at a particular layer does not 547 imply that the location data communicated by that protocol is derived 548 solely based on information obtained at that layer. In some 549 circumstances, LCP implementations may base their location 550 determination on information gathered from a variety of sources which 551 may merit varying levels of trust, such as information obtained from 552 the calling endpoint, or wiremap information that is time consuming 553 to verify or may rapidly go out of date. 555 For example, consider the case of a Location Information Server (LIS) 556 that utilizes LLDP-MED [LLDP-MED] endpoint move detection 557 notifications in determining calling endpoint location. Regardless 558 of whether the LIS implementation utilizes an LCP operating above the 559 link layer (such as an application layer protocol such as HELD 560 [RFC5985]), the validity of the location information conveyed would 561 be dependent on the security properties of LLDP-MED. 563 [LLDP-MED] Section 13.3 defines the endpoint move detection 564 notification as follows: 566 lldpXMedTopologyChangeDetected NOTIFICATION-TYPE 567 OBJECTS { lldpRemChassisIdSubtype, 568 lldpRemChassisId, 569 lldpXMedRemDeviceClass 570 } 571 STATUS current 572 DESCRIPTION 573 "A notification generated by the local device 574 sensing a change in the topology that 575 indicates a new remote device attached to a 576 local port, or a remote device disconnected 577 or moved from one port to another." 578 ::= { lldpXMedNotifications 1 } 580 Figure 3: Interworking Architecture 582 As noted in Section 7.4 of [LLDP-MED], the lldpRemChassisIdSubtype, 583 lldpRemChassisId and lldpXMedRemDeviceClass variables are determined 584 from the Chassis ID (1) and LLDP-MED Device Type Type-Length-Value 585 (TLV) tuples provided within the LLDP advertisement of the calling 586 device. As noted in [LLDP-MED] Section 9.2.3, all Endpoint Devices 587 use the Network address ID subtype (5) by default. In order to 588 provide topology change notifications in a timely way, it cannot 589 necessarily be assumed that a Network Connectivity devices will 590 validate the network address prior to transmission of the move 591 detection notification. As a result, there is no guarantee that the 592 network address reported by the endpoint will correspond to that 593 utilized by the device. 595 The discrepancy need not be due to nefarious reasons. For example, 596 an IPv6-capable endpoint may utilize multiple IPv6 addresses. 597 Similarly, an IPv4-capable endpoint may initially utilize a Link- 598 Local IPv4 address [RFC3927] and then may subsequently acquire a 599 DHCP-assigned routable address. All addresses utilized by the 600 endpoint device may not be advertised in LLDP, or even if they are, 601 endpoint move detection notification may not be triggered, either 602 because no LinkUp/LinkDown notifications occur (e.g. the host adds or 603 changes an address without rebooting) or because these notifications 604 were not detectable by the Network Connectivity device (the endpoint 605 device was connected to a hub rather than directly to a switch). 607 Similar issues may arise in situations where the LIS utilizes DHCP 608 lease data to obtain location information. Where the endpoint 609 address was not obtained via DHCP (such as via manual assignment, 610 stateless auto-configuration [RFC4862] or Link-Local IPv4 self- 611 assignment), no lease information will be available to enable 612 determination of device location. This situation should be expected 613 to become increasingly common as IPv6-capable endpoints are deployed, 614 and Location Configuration Protocol (LCP) interactions occur over 615 IPv6. 617 Even in scenarios in which the LIS relies on location data obtained 618 from the IP MIB [RFC4293] and the Bridge MIB [RFC4188], availability 619 of location determination information is not assured. In an 620 enterprise scale network, maintenance of current location information 621 depends on the ability of the management station to retrieve data via 622 polling of network devices. As the number of devices increases, 623 constraints of network latency and packet loss may make it 624 increasingly difficult to ensure that all devices are polled on a 625 sufficiently frequent interval. In addition, in large networks, it 626 is likely that tables will be large so that when UDP transport is 627 used, query responses will fragment, resulting in increasing packet 628 loss or even difficulties in firewall or NAT traversal. 630 Furthermore, even in situations where the location data can be 631 presumed to exist and be valid, there may be issues with the 632 integrity of the retrieval process. For example, where the LIS 633 depends on location information obtained from a MIB notification or 634 query, unless SNMPv3 [RFC3411] is used, data integrity and 635 authenticity is not assured in transit between the network 636 connectivity device and the LIS. 638 From these examples, it should be clear that the availability or 639 validity of location data is a property of the LIS system design and 640 implementation rather than an inherent property of the LCP. As a 641 result, mechanisms utilized to protect the integrity and authenticity 642 of location data do not necessarily provide assurances relating to 643 the validity or provenance of that data. 645 5.1.2. Location Signing 647 [NENA-i2] Section 3.7 includes recommendations relating to location 648 signing: 650 Location determination is out of scope for NENA, but we can offer 651 guidance on what should be considered when designing mechanisms to 652 report location: 654 1. The location object should be digitally signed. 656 2. The certificate for the signer (LIS operator) should be 657 rooted in VESA. For this purpose, VPC and ERDB operators 658 should issue certs to LIS operators. 660 3. The signature should include a timestamp. 662 4. Where possible, the Location Object should be refreshed 663 periodically, with the signature (and thus the timestamp) 664 being refreshed as a consequence. 666 5. Anti-spoofing mechanisms should be applied to the Location 667 Reporting method. 669 [Note: The term Valid Emergency Services Authority (VESA) refers 670 to the root certificate authority.] 672 Signing of location objects implies the development of a trust 673 hierarchy that would enable a certificate chain provided by the LIS 674 operator to be verified by the PSAP. Rooting the trust hierarchy in 675 VESA can be accomplished either by having the VESA directly sign the 676 LIS certificates, or by the creation of intermediate CAs certified by 677 the VESA, which will then issue certificates to the LIS. In terms of 678 the workload imposed on the VESA, the latter approach is highly 679 preferable. However, this raises the question of who would operate 680 the intermediate CAs and what the expectations would be. 682 In particular, the question arises as to the requirements for LIS 683 certificate issuance, and whether they are significantly different 684 from say, requirements for issuance of an SSL/TLS web certificate. 686 5.1.3. Location by Reference 688 Where location by reference is provided, the recipient needs to 689 deference the LbyR in order to obtain location. With the 690 introduction of location by reference concept two authorization 691 models were developed, see [I-D.ietf-geopriv-deref-protocol], namely 692 the "Authorization by Possession" and "Authorization via Access 693 Control Lists" model. With the "Authorization by Possession" model 694 everyone in possession of the reference is able to obtain the 695 corresponding location information. This might, however, be 696 incompatible with other requirements typically imposed by AIPs, such 697 as location hiding (see [RFC6444]). As such, the "Authorization via 698 Access Control Lists" model is likely to be the preferred model for 699 many AIPs and subject for discussion in the subsequent paragraphs. 701 Just as with PIDF-LO signing, the operational considerations in 702 managing credentials for use in LbyR dereferencing can be 703 considerable without the introduction of some kind of hierarchy. It 704 does not seem reasonable for a PSAP to manage client certificates or 705 Digest credentials for all the LISes in its coverage area, so as to 706 enable it to successfully dereference LbyRs. In some respects, this 707 issue is even more formidable than the validation of signed PIDF- 708 LOs. While PIDF-LO signing credentials are provided to the LIS 709 operator, in the case of de-referencing, the PSAP needs to be obtain 710 credentials compatible with the LIS configuration, a potentially more 711 complex operational problem. 713 As with PIDF-LO signing, the operational issues of LbyR can be 714 addressed to some extent by introduction of hierarchy. Rather than 715 requiring the PSAP to obtain credentials for accessing each LIS, the 716 local LIS could be required to upload location information to 717 location aggregation points who would in turn manage the 718 relationships with the PSAP. This would shift the management burden 719 from the PSAPs to the location aggregation points. 721 5.2. Application to a Specific Point in Time 723 PIDF-LO objects contain a timestamp, which reflects the time at which 724 the location was determined. Even if the PIDF-LO is signed, the 725 timestamp only represents an assertion by the LIS, which may or may 726 not be trustworthy. For example, the recipient of the signed PIDF-LO 727 may not know whether the LIS supports time synchronization, or 728 whether it is possible to reset the LIS clock manually without 729 detection. Even if the timestamp was valid at the time location was 730 determined, a time period may elapse between when the PIDF-LO was 731 provided and when it is conveyed to the recipient. Periodically 732 refreshing location information to renew the timestamp even though 733 the location information itself is unchanged puts additional load on 734 LISes. As a result, recipients need to validate the timestamp in 735 order to determine whether it is credible. 737 5.3. Linkage to a Specific Endpoint 739 As noted in the "HTTP Enabled Location Delivery (HELD)" [RFC5985] 740 Section 6.6: 742 The LIS MUST NOT include any means of identifying the Device in 743 the PIDF-LO unless it is able to verify that the identifier is 744 correct and inclusion of identity is expressly permitted by a Rule 745 Maker. Therefore, PIDF parameters that contain identity are 746 either omitted or contain unlinked pseudonyms [RFC3693]. A 747 unique, unlinked presentity URI SHOULD be generated by the LIS for 748 the mandatory presence "entity" attribute of the PIDF document. 749 Optional parameters such as the "contact" element and the 750 "deviceID" element [RFC4479] are not used. 752 Given the restrictions on inclusion of identification information 753 within the PIDF-LO, it may not be possible for a recipient to verify 754 that the entity on whose behalf location was determined represents 755 the same entity conveying location to the recipient. 757 Where "Enhancements for Authenticated Identity Management in the 758 Session Initiation Protocol (SIP)" [RFC4474] is used, it is possible 759 for the recipient to verify the identity assertion in the From: 760 header. However, if PIDF parameters that contain identity are 761 omitted or contain an unlinked pseudonym, then it may not be possible 762 for the recipient to verify whether the conveyed location actually 763 relates to the entity identified in the From: header. 765 This lack of binding between the entity obtaining the PIDF-LO and the 766 entity conveying the PIDF-LO to the recipient enables cut and paste 767 attacks which would enable an attacker to assert a bogus location, 768 even where both the SIP message and PIDF-LO are signed. As a result, 769 even implementation of both [RFC4474] and location signing does not 770 guarantee that location can be tied to a specific endpoint. 772 6. Security Considerations 774 IP-based emergency services face many security threats. "Security 775 Threats and Requirements for Emergency Call Marking and Mapping" 776 [RFC5069] describes attacks on the emergency services system, such as 777 attempting to deny system services to all users in a given area, to 778 gain fraudulent use of services and to divert emergency calls to non- 779 emergency sites. [RFC5069] also describes attacks against 780 individuals, including attempts to prevent an individual from 781 receiving aid, or to gain information about an emergency. 783 "Threat Analysis of the Geopriv Protocol" [RFC3694] describes threats 784 against geographic location privacy, including protocol threats, 785 threats resulting from the storage of geographic location data, and 786 threats posed by the abuse of information. 788 Although it is important to ensure that location information cannot 789 be faked there will be many GPS-enabled devices that will find it 790 difficult to utilize any of the security mechanisms described in 791 Section 5. It is also unlikely that users will be willing to upload 792 their location information for "verification" to a nearby location 793 server located in the access network. 795 While auditability is an important deterrent, it is likely to be of 796 most benefit in situations where attacks on the emergency services 797 system are likely to be relatively infrequent, since the resources 798 required to pursue an investigation are likely to be considerable. 800 Where attacks are frequent and continuous, automated mechanisms are 801 required. For example, mechanisms to exchange audit trails 802 information in a standardized format between ISPs and PSAPs / VSPs 803 and PSAPs or heuristics to distinguish potentially fraudulent 804 emergency calls from real emergencies might be valuable. 806 7. IANA Considerations 808 This document does not require actions by IANA. 810 8. Acknowledgments 812 We would like to thank the members of the IETF ECRIT and the IETF 813 GEOPRIV working group for their input to the discussions related to 814 this topic. We would also like to thank Andrew Newton, Murugaraj 815 Shanmugam, Richard Barnes and Matt Lepinski for their feedback to 816 previous versions of this document. Martin Thomson provided valuable 817 input to version -02 of this document. 819 9. References 821 9.1. Informative References 823 [GPSCounter] 824 Warner, J. S. and R. G. Johnston, "GPS Spoofing 825 Countermeasures", Los Alamos research paper LAUR-03-6163, 826 December 2003. 828 [I-D.thomson-geopriv-location-dependability] 829 Thomson, M. and J. Winterbottom, "Digital Signature Methods 830 for Location Dependability", draft-thomson-geopriv-location- 831 dependability-07 (work in progress), March 2011. 833 [I-D.ietf-geopriv-deref-protocol] 834 Winterbottom, J., Tschofenig, H., Schulzrinne, H. and M. 835 Thomson, "A Location Dereferencing Protocol Using HELD", 836 draft-ietf-geopriv-deref-protocol-07 (work in progress), July 837 2012. 839 [IEEE-802.11y] 840 Information technology - Telecommunications and information 841 exchange between systems - Local and metropolitan area 842 networks - Specific requirements - Part 11: Wireless LAN 843 Medium Access Control (MAC) and Physical Layer (PHY) 844 specifications Amendment 3: 3650-3700 MHz Operation in USA, 845 November 2008. 847 [LLDP-MED] 848 "Telecommunications: IP Telephony Infrastructure: Link Layer 849 Discovery Protocol for Media Endpoint Devices, ANSI/ 850 TIA-1057-2006", April 2006. 852 [NENA-i2] "08-001 NENA Interim VoIP Architecture for Enhanced 9-1-1 853 Services (i2)", December 2005. 855 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 856 Requirement Levels", BCP 14, RFC 2119, March 1997. 858 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture 859 for Describing Simple Network Management Protocol (SNMP) 860 Management Frameworks", STD 62, RFC 3411, December 2002. 862 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. 863 Polk, "Geopriv Requirements", RFC 3693, February 2004. 865 [RFC3694] Danley, M., Mulligan, D., Morris, J. and J. Peterson, "Threat 866 Analysis of the Geopriv Protocol", RFC 3694, February 2004. 868 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 869 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 870 3748, June 2004. 872 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 873 Configuration of IPv4 Link-Local Addresses", RFC 3927, May 874 2005. 876 [RFC4188] Norseth, K. and E. Bell, "Definitions of Managed Objects for 877 Bridges", RFC 4188, September 2005. 879 [RFC4293] Routhier, S., "Management Information Base for the Internet 880 Protocol (IP)", RFC 4293, April 2006. 882 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated 883 Identity Management in the Session Initiation Protocol (SIP)", 884 RFC 4474, August 2006. 886 [RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, July 887 2006. 889 [RFC4740] Garcia-Martin, M., Belinchon, M., Pallares-Lopez, M., Canales- 890 Valenzuela, C., and K. Tammi, "Diameter Session Initiation 891 Protocol (SIP) Application", RFC 4740, November 2006. 893 [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 894 and DHCPv6) Option for Civic Addresses Configuration 895 Information", RFC 4776, November 2006. 897 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 898 Address Autoconfiguration", RFC 4862, September 2007. 900 [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for Emergency 901 Context Resolution with Internet Technologies", RFC 5012, 902 January 2008. 904 [RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H. and M. Shanmugam, 905 "Security Threats and Requirements for Emergency Call Marking 906 and Mapping", RFC 5069, January 2008. 908 [RFC5582] Schulzrinne, H., "Location-to-URL Mapping Architecture and 909 Framework", RFC 5582, September 2009. 911 [RFC5985] Barnes, M., "HTTP Enabled Location Delivery (HELD)", RFC 5985, 912 September 2010. 914 [RFC6225] Polk, J., Linsner, M., Thomson, M. and B. Aboba, "Dynamic Host 915 Configuration Protocol Options for Coordinate-based Location 916 Configuration Information", RFC 6225, July 2011. 918 [RFC6442] Polk, J., Rosen, B. and J. Peterson, "Location Conveyance for 919 the Session Initiation Protocol", RFC 6442, December 2011. 921 [RFC6444] Schulzrinne, H., Liess, L., Tschofenig, H., Stark, B., and A. 922 Kuett, "Location Hiding: Problem Statement and Requirements", 923 RFC 6444, January 2012. 925 [SA] "Saudi Arabia - Illegal sale of SIMs blamed for surge in prank 926 calls", Arab News, May 4, 2010, 927 http://www.menafn.com/qn_news_story_s.asp?StoryId=1093319384 929 [Swatting] 930 "Don't Make the Call: The New Phenomenon of 'Swatting', 931 Federal Bureau of Investigation, February 4, 2008, 932 http://www.fbi.gov/news/stories/2008/february/swatting020408 934 [TASMANIA] 935 "Emergency services seek SIM-less calls block", ABC News 936 Online, August 18, 2006, 937 http://www.abc.net.au/news/newsitems/200608/s1717956.htm 939 [UK] "Rapper makes thousands of prank 999 emergency calls to UK 940 police", Digital Journal, June 24, 2010, 941 http://www.digitaljournal.com/article/293796?tp=1 943 Authors' Addresses 945 Hannes Tschofenig 946 Nokia Siemens Networks 947 Linnoitustie 6 948 Espoo 02600 949 Finland 951 Phone: +358 (50) 4871445 952 Email: Hannes.Tschofenig@gmx.net 953 URI: http://www.tschofenig.priv.at 955 Henning Schulzrinne 956 Columbia University 957 Department of Computer Science 958 450 Computer Science Building, New York, NY 10027 959 US 961 Phone: +1 212 939 7004 962 Email: hgs@cs.columbia.edu 963 URI: http://www.cs.columbia.edu 965 Bernard Aboba 966 Microsoft Corporation 967 One Microsoft Way 968 Redmond, WA 98052 969 US 971 Email: bernard_aboba@hotmail.com