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