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