idnits 2.17.1 draft-ietf-ecrit-trustworthy-location-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 731: '... The LIS MUST NOT include any mea...' RFC 2119 keyword, line 736: '...d presentity URI SHOULD be generated b...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 21, 2010) is 4966 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-13) exists of draft-ietf-ecrit-framework-11 == 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: 2 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT H. Tschofenig 3 Internet-Draft Nokia Siemens Networks 4 Intended status: Informational H. Schulzrinne 5 Expires: March 25, 2011 Columbia University 6 B. Aboba 7 Microsoft Corporation 8 September 21, 2010 10 Trustworthy Location Information 11 draft-ietf-ecrit-trustworthy-location-00.txt 13 Abstract 15 For some location-based applications, such as emergency calling or 16 roadside assistance, it appears that the identity of the requestor is 17 less important than accurate and trustworthy location information. 18 To ensure adequate help location has to be left untouched by the end 19 point or by entities in transit. 21 This document lists different threats, an adversary model, outlines 22 three frequentlly discussed solutions and discusses operational 23 considerations. Finally, the document concludes with a suggestion on 24 how to move forward. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on March 25, 2011. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Emergency Services . . . . . . . . . . . . . . . . . . . . . . 5 63 4. Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 4.1. Location Spoofing . . . . . . . . . . . . . . . . . . . . 8 65 4.2. Call Identity Spoofing . . . . . . . . . . . . . . . . . . 8 66 5. Solution Proposals . . . . . . . . . . . . . . . . . . . . . . 10 67 5.1. Location Signing . . . . . . . . . . . . . . . . . . . . . 10 68 5.2. Location by Reference . . . . . . . . . . . . . . . . . . 11 69 5.3. Proxy Adding Location . . . . . . . . . . . . . . . . . . 13 70 6. Operations Considerations . . . . . . . . . . . . . . . . . . 14 71 6.1. Attribution to a Specific Trusted Source . . . . . . . . . 14 72 6.2. Application to a Specific Point in Time . . . . . . . . . 18 73 6.3. Linkage to a Specific Endpoint . . . . . . . . . . . . . . 18 74 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 20 75 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 76 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 78 10.1. Normative References . . . . . . . . . . . . . . . . . . . 24 79 10.2. Informative references . . . . . . . . . . . . . . . . . . 24 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 82 1. Introduction 84 Much of the focus in trustable networks has been on ensuring the 85 reliability of personal identity information or verifying privileges. 86 However, in some cases, access to trustworthy location information is 87 more important than identity since some services are meant to be 88 widely available, regardless of the identity of the requestor. 89 Emergency services, such as fire department, ambulance and police, 90 but also commercial services such as food delivery and roadside 91 assistance are among those. Customers, competitors or emergency 92 callers lie about their location to harm the service provider or to 93 deny services to others, by tying up the service capacity. In 94 addition, if third parties can modify the information, they can deny 95 services to the requestor. 97 Physical security is often based on location. As a trivial example, 98 light switches in buildings are not typically protected by keycards 99 or passwords, but are only accessible to those within the perimeter 100 of the building. Merchants processing credit card payments already 101 use location information to estimate the risk that a transaction is 102 fraudulent, based on the HTTP client's IP address (that is then 103 translated to location). In all these cases, trustworthy location 104 information can be used to augment identity information or, in some 105 cases, avoid the need for role-based authorization. 107 A number of standardization organizations have developed mechanisms 108 to make civic and geodetic location available to the end host. 109 Examples for these protocols are LLDP-MED [LLDP-MED], DHCP extensions 110 (see [RFC4776], [RFC3825]), HELD 111 [I-D.ietf-geopriv-http-location-delivery], or the protocols developed 112 within the IEEE as part of their link-layer specifications. The 113 server offering this information is usually called a Location 114 Information Server (LIS). More common with high-quality cellular 115 devices is the ability for the end host itself to determine its own 116 location using GPS. The location information is then provided, by 117 reference or value, to the service-providing entities, i.e. location 118 recipients, via application protocols, such as HTTP, SIP or XMPP. 120 This document investigates the security threats in Section 4, and 121 outlines three solutions that are frequently mentioned in Section 5. 122 We use emergency services an example to illustrate the security 123 problems, as the problems have been typically discussed in that 124 context since the stakes are high, but the issues apply also to other 125 examples as cited earlier. We also take a look at the operational 126 considerations in Section 6 since there is a cost associated with the 127 estbalishment of the necessary infrastructure. With the pros of the 128 available technology being described and the cons of the operational 129 complexity highlighted we offer a conclusion in Section 7. 131 2. Terminology 133 This document re-uses a lot of the terminology defined in Section 3 134 of [RFC5012]. 136 3. Emergency Services 138 Users of the legacy telephone network can summon emergency services 139 such as ambulance, fire and police using a well-known emergency 140 service number (e.g., 9-1-1 in North America, 1-1-2 in Europe). 141 Location information is used to route emergency calls to the 142 appropriate regional Public Safety Answering Point (PSAP) that serves 143 the caller to dispatch first-level responders to the emergency site. 145 Regulators have already started to demand emergency service support 146 for voice over IP. However, enabling such critical public services 147 using the Internet is challenging, as many of the assumptions of the 148 public switched telephone network (PSTN) / public land mobile network 149 (PLMN) no longer hold. In particular, while the local telephone 150 company provides both the physical access and the phone service, VoIP 151 allows and encourages to split these two roles between the Access 152 Infrastructure Provider (AIP) and Application (Voice) Service 153 Provider (VSP). The VSP may be located far away from the AIP and may 154 either have no business relationship with that AIP or may be a 155 competitor. It is also likely that the VSP will have no relationship 156 with the PSAP and will therefore be unknown. 158 4. Threats 160 IP-based emergency calling faces many security threats, most of which 161 are well-known from other realms, such as protecting the privacy of 162 communications or against denial-of-service attacks using packet 163 flooding. Here, we focus specifically on a higher-layer threat that 164 is unique to services where semi-anonymous users can request 165 expensive services. 167 Prank calls have been a problem for emergency services, dating back 168 to the time of street corner call boxes. Individual prank calls 169 waste emergency services and possibly endanger bystanders or 170 emergency service personnel as they rush to the reported scene of a 171 fire or accident. A more recent concern is that massive prank calls 172 can be used to disrupt emergency services, e.g., during a mass- 173 casualty event and thus be used as a means to amplify the effect of a 174 terror attack, for example. 176 Emergency services have three finite resources subject to denial of 177 service attacks: the network and server infrastructure, call takers 178 and dispatchers, and the first responders, such as fire fighters and 179 police officers. Protecting the network infrastructure is similar to 180 protecting other high-value service providers, except that 181 trustworthy location information may be used to filter call setup 182 requests, to weed out requests that are out of area. PSAPs even for 183 large cities may only have a handful of PSAP call takers on duty, so 184 even if they can, by questioning the caller, eliminate a lot of prank 185 calls, they are quickly overwhelmed by even a small-scale attack. 186 Finally, first responder resources are scarce, particularly during 187 mass-casualty events. 189 Currently, emergency services rely on the fact that location spoofing 190 is difficult for normal users. Additionally, the identity of most 191 callers can be ascertained, so that the threat of severe punishments 192 reduces prank calls. Mechanically placing a large number of 193 emergency calls that appear to come from different locations is also 194 difficult. Calls from payphones are subject to greater scrutiny by 195 the call taker. In the current system, it would be very difficult 196 for an attacker from country 'Foo' to attack the emergency services 197 infrastructure located in country 'Bar'. 199 One of the main motivations of an adversary in the emergency services 200 context is to prevent callers from utilizing emergency service 201 support. This can be done by a variety of means, such as 202 impersonating a PSAP or directory servers, attacking SIP signaling 203 elements and location servers. 205 Attackers may want to modify, prevent or delay emergency calls. In 206 some cases, this will lead the PSAP to dispatch emergency personnel 207 to an emergency that does not exist and, hence, the personnel might 208 not be available to other callers. It might also be possible for an 209 attacker to impede the users from reaching an appropriate PSAP by 210 modifying the location of an end host or the information returned 211 from the mapping protocol. In some countries, regulators may not 212 require the authenticated identity of the emergency caller, as is 213 true for PSTN-based emergency calls placed from payphones or SIM-less 214 cell phones today. Furthermore, if identities can easily be crafted 215 (as it is the case with many VoIP offerings today), then the value of 216 emergency caller authentication itself might be limited. As a 217 consequence, an attacker can forge emergency call information without 218 the chance of being held accountable for its own actions. 220 The above-mentioned attacks are mostly targeting individual emergency 221 callers or a very small fraction of them. If attacks are, however, 222 launched against the mapping architecture (see 223 [I-D.ietf-ecrit-mapping-arch] or against the emergency services IP 224 network (including PSAPs), a larger region and a large number of 225 potential emergency callers are affected. The call takers themselves 226 are a particularly scarce resource and if human interaction by these 227 call takers is required then this can very quickly have severe 228 consequences. 230 To provide a structured analysis we distinguish between three 231 adversary models: 233 External adversary model: The end host, e.g., an emergency caller 234 whose location is going to be communicated, is honest and the 235 adversary may be located between the end host and the location 236 server or between the end host and the PSAP. None of the 237 emergency service infrastructure elements act maliciously. 239 Malicious infrastructure adversary model: The emergency call routing 240 elements, such as the LIS, the LoST infrastructure, used for 241 mapping locations to PSAP address, or call routing elements, may 242 act maliciously. 244 Malicious end host adversary model: The end host itself acts 245 maliciously, whether the owner is aware of this or whether it is 246 acting as a bot. 248 We will focus only on the malicious end host adversary model since it 249 follows today's most common adversary model on the Internet that 250 includes bot nets. 252 4.1. Location Spoofing 254 An adversary can provide false location information in order to fool 255 the emergency personnel. Such an attack is particularly easy if 256 location information is attached to the emergency call by the end 257 host and is either not verified or cannot be verified by anyone. 258 Only entities that are close to the caller can verify the correctness 259 of location information. Another form of this attack is to fool a 260 VSP (and indirectly a LIS) in using a wrong identity (such as an IP 261 address) for the location lookup. This type of attack can be 262 accomplished in the PSTN today with the help of caller-id spoofing. 264 The following list presents threats specific to location information 265 handling: 267 Place shifting: Trudy, the adversary, pretends to be at an arbitrary 268 location. In some cases, place shifting can be limited in range, 269 e.g., to the coverage area of a particular cell tower. 271 Time shifting: Trudy pretends to be at a location she was a while 272 ago. 274 Location theft: Trudy observes Alice's location and replays it as 275 her own. 277 Location swapping: Trudy and Malory, located in different locations, 278 can collude and swap location information and pretend to be in 279 each other's location. 281 4.2. Call Identity Spoofing 283 If an adversary can place emergency calls without disclosing its 284 identity, then prank calls are more difficult to be traced. There 285 are at least two different forms of authentication in this context: 286 (a) network access authentication (e.g., using the Extensible 287 Authentication Protocol (EAP) [RFC3748] and (b) authentication of the 288 emergency caller at the VoIP application layer. This differentiation 289 is created by the split between the AIP and the VSP. Note that 290 different identities are involved and that the are also managed by 291 different parties and thus making the linkage between the two quite 292 difficult. 294 Trying to find an adversary that did not authenticate itself to the 295 VSP is difficult even though there is still a chance if network 296 access authentication was executed. If there is no authentication 297 (neither to the PSAP, to the VSP nor to the AIP) then it is very 298 challenging to trace the call back in order to a make a particular 299 entity accountable. This might, for example, be the case with an 300 open IEEE 802.11 WLAN access point even if the owner of the access 301 point can be determined. 303 However, unlike for the existing telephone system, it is possible to 304 imagine that VoIP emergency calls could require strong identity, as 305 providing such identity information is not necessarily coupled to 306 having a business relationship with the AIP, ISP or VSP. However, 307 due to the time-critical nature of emergency calls, it is unlikely 308 that multi-layers authentication can be used, so that in most cases, 309 only the device placing the call will be able to be identified, 310 making the system vulnerable to botnet attacks. Furthermore, 311 deploying additional credentials for emergency service purposes, such 312 as dedicated certificates, increases costs, introduces a significant 313 administrative overhead and is only useful if widely used. 315 5. Solution Proposals 317 This section presents three solution approaches that have been 318 discussed in order to mitigate the threats discussed. 320 5.1. Location Signing 322 One way to avoid location spoofing is to let a trusted location 323 server sign the location information before it is sent to the end 324 host, i.e., the entity subject to the location determination process. 325 The signed location information is then verified by the location 326 recipient and not by the target. Figure 1 shows the communication 327 model with the target requesting signed location in step (a), the 328 location server returns it in step (b) and it is then conveyed to the 329 location recipient in step (c) who verifies it. For SIP, the 330 procedures described in [I-D.ietf-sip-location-conveyance] are 331 applicable for location conveyance. 333 +-----------+ +-----------+ 334 | | | Location | 335 | LIS | | Recipient | 336 | | | | 337 +-+-------+-+ +----+------+ 338 ^ | --^ 339 | | -- 340 Geopriv |Req. | -- 341 Location |Signed |Signed -- Geopriv 342 Configuration |Loc. |Loc. -- Using Protocol 343 Protocol |(a) |(b) -- (e.g., SIP) 344 | v -- (c) 345 +-+-------+-+ -- 346 | Target / | -- 347 | End Host + 348 | | 349 +-----------+ 351 Figure 1: Location Signing 353 Additional information, such as timestamps or expiration times, has 354 to be included together with the signed location to limit replay 355 attacks. If the location is retrieved from a location server, even a 356 stationary end host has to periodically obtain a fresh signed 357 location, or incur the additional delay of querying during the 358 emergency call. 360 Bot nets are also unlikely to be deterred by location signing. 361 However, accurate location information would limit the usable subset 362 of the bot net, as only hosts within the PSAP serving area would be 363 useful in placing calls. 365 To prevent location-swapping attacks it is necessary to include some 366 some target specific identity information. The included information 367 depends on the purpose, namely either real-time verification by the 368 location recipient or for the purpose of a post-mortem analysis when 369 the location recipient wants to determine the legal entity behind the 370 target for prosecution (if this is possible). As argued in Section 6 371 the operational considerations make a real-time verification 372 difficult. A strawman proposal for location signing is provided by 373 [I-D.thomson-geopriv-location-dependability]. 375 Still, for large-scale attacks launched by bot nets, this is unlikely 376 to be helpful. Location signing is also difficult when the host 377 provides its own location via GPS, which is likely to be a common 378 occurrence for mobile devices. Trusted computing approaches, with 379 tamper-proof GPS modules, may be needed in that case. After all, a 380 device can always pretend to have a GPS device and the recipient has 381 no way of verifying this or forcing disclosure of non-GPS-derived 382 location information. 384 Location verification may be most useful if it is used in conjunction 385 with other mechanisms. For example, a call taker can verify that the 386 region that corresponds to the IP address of the media stream roughly 387 corresponds to the location information reported by the caller. To 388 make the use of bot nets more difficult, a CAPTCHA-style test may be 389 applied to suspicious calls, although this idea is quite 390 controversial for emergency services, at the danger of delaying or 391 even rejecting valid calls. 393 5.2. Location by Reference 395 The location-by-reference concept was developed so that end hosts 396 could avoid having to periodically query the location server for up- 397 to-date location information in a mobile environment. Additionally, 398 if operators do not want to disclose location information to the end 399 host without charging them, location-by-reference provides a 400 reasonable alternative. 402 Figure 2 shows the communication model with the target requesting a 403 location reference in step (a), the location server returns the 404 reference in step (b), and it is then conveyed to the location 405 recipient in step (c). The location recipient needs to resolve the 406 reference with a request in step (d). Finally, location information 407 is returned to the Location Recipient afterwards. For location 408 conveyance in SIP, the procedures described in 409 [I-D.ietf-sip-location-conveyance] are applicable. 411 +-----------+ Geopriv +-----------+ 412 | | Location | Location | 413 | LIS +<------------->+ Recipient | 414 | | Dereferencing | | 415 +-+-------+-+ Protocol (d) +----+------+ 416 ^ | --^ 417 | | -- 418 Geopriv |Req. | -- 419 Location |LbyR |LbyR -- Geopriv 420 Configuration |(a) |(b) -- Using Protocol 421 Protocol | | -- (e.g., SIP) 422 | V -- (c) 423 +-+-------+-+ -- 424 | Target / | -- 425 | End Host + 426 | | 427 +-----------+ 429 Figure 2: Location by Reference 431 The details for the dereferencing operations vary with the type of 432 reference, such as a HTTP, HTTPS, SIP, SIPS URI or a SIP presence 433 URI. HTTP-Enabled Location Delivery (HELD) 434 [I-D.ietf-geopriv-http-location-delivery] is an example of a protocol 435 that is able to return such references. 437 For location-by-reference, the location server needs to maintain one 438 or several URIs for each target, timing out these URIs after a 439 certain amount of time. References need to expire to prevent the 440 recipient of such a URL from being able to permanently track a host 441 and to offer garbage collection functionality for the location 442 server. 444 Off-path adversaries must be prevented from obtaining the target's 445 location. The reference contains a randomized component that 446 prevents third parties from guessing it. When the location recipient 447 fetches up-to-date location information from the location server, it 448 can also be assured that the location information is fresh and not 449 replayed. However, this does not address location swapping. 451 However, location-by-reference does not offer significant security 452 benefits if the end host uses GPS to determine its location. At 453 best, a network provider can use cell tower or triangulation 454 information to limit the inaccuracy of user-provided location 455 information. 457 5.3. Proxy Adding Location 459 Instead of making location information available to the end host, it 460 is possible to allow an entity in the AIP, or associated with the 461 AIP, to retrieve the location information on behalf of the end point. 462 This solution is possible when the application layer messages are 463 routed through an entity with the ability to determine the location 464 information of the end point, for example based on the end host's IP 465 or MAC address. 467 When the untrustworthy end host does not have the ability to access 468 location information, it cannot modify it either. Proxies can use 469 various authentication security techniques, including SIP Identity 470 [RFC4474], to ensure that modifications to the location in transit 471 can be detected by the location recipient (e.g., the PSAP). As noted 472 above, this is unlikely to work for GPS-based location determination 473 techniques. 475 The obvious disadvantage of this approach is that there is a need to 476 deploy application layer entities, such as SIP proxies, at AIPs or 477 associated with AIPs. This requires a standardized VoIP profile to 478 be deployed at every end device and at every AIP, for example, based 479 on SIP. This might impose a certain interoperability challenge. 480 Additionally, the AIP more or less takes the responsibility for 481 emergency calls, even for customers they have no direct or indirect 482 relationship with. To provide identity information about the 483 emergency caller from the VSP it would be necessary to let the AIP 484 and the VSP to interact for authentication (see, for example, 485 [RFC4740]). This interaction along the Authentication, Authorization 486 and Accounting infrastructure (see ) is often based on business 487 relationships between the involved entities. The AIP and the VSP are 488 very likely to have no such business relationship, particularly when 489 talking about an arbitrary VSP somewhere on the Internet. In case 490 that the interaction between the AIP and the VSP fails due to the 491 lack of a business relationship then the procedures described in 492 [I-D.schulzrinne-ecrit-unauthenticated-access] are applicable and 493 typically a fall-back would be provided where no emergency caller 494 identity information is made available to the PSAP and the emergency 495 call still has to be completed. 497 6. Operations Considerations 499 6.1. Attribution to a Specific Trusted Source 501 [NENA-i2] Section 3.7 describes some of the aspects of attribution as 502 follows: 504 The i2 solution proposes a Location Information Server (LIS) be 505 the source for distributing location information within an access 506 network. Furthermore the validity, integrity and authenticity of 507 this information are directly attributed to the LIS operator. 509 Section 6.1.1 describes the issues that arise in ensuring the 510 validity of location information provided by the LIS operator. 511 Section 6.1.2 and Section 6.1.3 describe operational issues that 512 arise in ensuring the integrity and authenticity of location 513 information provided by the LIS operator. 515 6.1.1. Validity 517 In existing networks where location information is both determined by 518 the access/voice service provider as well as communicated by the AIP/ 519 VSP, responsibility for location validity can be attributed entirely 520 to a single party, namely the AIP/VSP. 522 However, on the Internet, not only may the AIP and VSP represent 523 different parties, but location determination may depend on 524 information contributed by parties trusted by neither the AIP nor 525 VSP, or even the operator of the Location Information Server (LIS). 526 In such circumstances, mechanisms for enhancing the integrity or 527 authenticity of location data contribute little toward ensuring the 528 validity of that data. 530 It should be understood that the means by which location is 531 determined may not necessarily relate to the means by which the 532 endpoint communicates with the LIS. Just because a Location 533 Configuration Protocol (LCP) operates at a particular layer does not 534 imply that the location data communicated by that protocol is derived 535 solely based on information obtained at that layer. In some 536 circumstances, LCP implementations may base their location 537 determination on information gathered from a variety of sources which 538 may merit varying levels of trust, such as information obtained from 539 the calling endpoint, or wiremap information that is time consuming 540 to verify or may rapidly go out of date. 542 For example, consider the case of a Location Information Server (LIS) 543 that utilizes LLDP-MED [LLDP-MED] endpoint move detection 544 notifications in determining calling endpoint location. Regardless 545 of whether the LIS implementation utilizes an LCP operating above the 546 link layer (such as an application layer protocol such as HELD 547 [I-D.ietf-geopriv-http-location-delivery]), the validity of the 548 location information conveyed would be dependent on the security 549 properties of LLDP-MED. 551 [LLDP-MED] Section 13.3 defines the endpoint move detection 552 notification as follows: 554 lldpXMedTopologyChangeDetected NOTIFICATION-TYPE 555 OBJECTS { lldpRemChassisIdSubtype, 556 lldpRemChassisId, 557 lldpXMedRemDeviceClass 558 } 559 STATUS current 560 DESCRIPTION 561 "A notification generated by the local device 562 sensing a change in the topology that 563 indicates a new remote device attached to a 564 local port, or a remote device disconnected 565 or moved from one port to another." 566 ::= { lldpXMedNotifications 1 } 568 Figure 3: Interworking Architecture 570 As noted in Section 7.4 of [LLDP-MED], the lldpRemChassisIdSubtype, 571 lldpRemChassisId and lldpXMedRemDeviceClass variables are determined 572 from the Chassis ID (1) and LLDP-MED Device Type Type-Length-Value 573 (TLV) tuples provided within the LLDP advertisement of the calling 574 device. As noted in [LLDP-MED] Section 9.2.3, all Endpoint Devices 575 use the Network address ID subtype (5) by default. In order to 576 provide topology change notifications in a timely way, it cannot 577 necessarily be assumed that a Network Connectivity devices will 578 validate the network address prior to transmission of the move 579 detection notification. As a result, there is no guarantee that the 580 network address reported by the endpoint will correspond to that 581 utilized by the device. 583 The discrepancy need not be due to nefarious reasons. For example, 584 an IPv6-capable endpoint may utilize multiple IPv6 addresses. 585 Similarly, an IPv4-capable endpoint may initially utilize a Link- 586 Local IPv4 address [RFC3927] and then may subsequently acquire a 587 DHCP-assigned routable address. All addresses utilized by the 588 endpoint device may not be advertised in LLDP, or even if they are, 589 endpoint move detection notification may not be triggered, either 590 because no LinkUp/LinkDown notifications occur (e.g. the host adds or 591 changes an address without rebooting) or because these notifications 592 were not detectable by the Network Connectivity device (the endpoint 593 device was connected to a hub rather than directly to a switch). 595 Similar issues may arise in situations where the LIS utilizes DHCP 596 lease data to obtain location information. Where the endpoint 597 address was not obtained via DHCP (such as via manual assignment, 598 stateless autoconfiguration [RFC4862] or Link-Local IPv4 self- 599 assignment), no lease information will be available to enable 600 determination of device location. This situation should be expected 601 to become increasingly common as IPv6-capable endpoints are deployed, 602 and Location Configuration Protocol (LCP) interactions occur over 603 IPv6. 605 Even in scenarios in which the LIS relies on location data obtained 606 from the IP MIB [RFC4293] and the Bridge MIB [RFC4188], availability 607 of location determination information is not assured. In an 608 enterprise scale network, maintenance of current location information 609 depends on the ability of the management station to retrieve data via 610 polling of network devices. As the number of devices increases, 611 constraints of network latency and packet loss may make it 612 increasingly difficult to ensure that all devices are polled on a 613 sufficiently frequent interval. In addition, in large networks, it 614 is likely that tables will be large so that when UDP transport is 615 used, query responses will fragment, resulting in increasing packet 616 loss or even difficulties in firewall or NAT traversal. 618 Furthermore, even in situations where the location data can be 619 presumed to exist and be valid, there may be issues with the 620 integrity of the retrieval process. For example, where the LIS 621 depends on location information obtained from a MIB notification or 622 query, unless SNMPv3 [RFC3411] is used, data integrity and 623 authenticity is not assured in transit between the network 624 connectivity device and the LIS. 626 From these examples, it should be clear that the availability or 627 validity of location data is a property of the LIS system design and 628 implementation rather than an inherent property of the LCP. As a 629 result, mechanisms utilized to protect the integrity and authenticity 630 of location data do not necessarily provide assurances relating to 631 the validity or provenance of that data. 633 6.1.2. Location Signing 635 [NENA-i2] Section 3.7 includes recommendations relating to location 636 signing: 638 Location determination is out of scope for NENA, but we can offer 639 guidance on what should be considered when designing mechanisms to 640 report location: 642 1. The location object should be digitally signed. 644 2. The certificate for the signer (LIS operator) should be rooted 645 in VESA. For this purpose, VPC and ERDB operators should issue 646 certs to LIS operators. 648 3. The signature should include a timestamp. 650 4. Where possible, the Location Object should be refreshed 651 periodically, with the signature (and thus the timestamp) being 652 refreshed as a consequence. 654 5. Antispoofing mechanisms should be applied to the Location 655 Reporting method. 657 [Note: The term Valid Emergency Services Authority (VESA) refers to 658 the root certificate authority.] 660 Signing of location objects implies the development of a trust 661 hierarchy that would enable a certificate chain provided by the LIS 662 operator to be verified by the PSAP. Rooting the trust hierarchy in 663 VESA can be accomplished either by having the VESA directly sign the 664 LIS certificates, or by the creation of intermediate CAs certified by 665 the VESA, which will then issue certificates to the LIS. In terms of 666 the workload imposed on the VESA, the latter approach is highly 667 preferable. However, this raises the question of who would operate 668 the intermediate CAs and what the expectations would be. 670 In particular, the question arises as to the requirements for LIS 671 certificate issuance, and whether they are significantly different 672 from say, requirements for issuance of an SSL/TLS web certificate. 674 6.1.3. Location by Reference 676 Where location by reference is provided, the recipient needs to 677 deference the LbyR in order to obtain location. With the 678 introduction of location by reference concept two authorization 679 models were developed, see [I-D.winterbottom-geopriv-deref-protocol], 680 namely the "Authorization by Possession" and "Authorization via 681 Access Control Lists" model. With the "Authorization by Possession" 682 model everyone in possession of the reference is able to obtain the 683 corresponding location information. This might, however, be 684 incompatible with other requirements typically imposed by AIPs, such 685 as location hiding (see [I-D.ietf-ecrit-location-hiding-req]). As 686 such, the "Authorization via Access Control Lists" model is likely to 687 be the preferred model for many AIPs and subject for discussion in 688 the subsequent paragraphs. 690 Just as with PIDF-LO signing, the operational considerations in 691 managing credentials for use in LbyR dereferencing can be 692 considerable without the introduction of some kind of hierarchy. It 693 does not seem reasonable for a PSAP to manage client certificates or 694 Digest credentials for all the LISes in its coverage area, so as to 695 enable it to successfully dereference LbyRs. In some respects, this 696 issue is even more formidable than the validation of signed PIDF- 697 LOs. While PIDF-LO signing credentials are provided to the LIS 698 operator, in the case of de-referencing, the PSAP needs to be obtain 699 credentials compatible with the LIS configuration, a potentially more 700 complex operational problem. 702 As with PIDF-LO signing, the operational issues of LbyR can be 703 addressed to some extent by introduction of hierarchy. Rather than 704 requiring the PSAP to obtain credentials for accessing each LIS, the 705 local LIS could be required to upload location information to 706 location aggregation points who would in turn manage the 707 relationships with the PSAP. This would shift the management burden 708 from the PSAPs to the location aggregation points. 710 6.2. Application to a Specific Point in Time 712 PIDF-LO objects contain a timestamp, which reflects the time at which 713 the location was determined. Even if the PIDF-LO is signed, the 714 timestamp only represents an assertion by the LIS, which may or may 715 not be trustworthy. For example, the recipient of the signed PIDF-LO 716 may not know whether the LIS supports time synchronization, or 717 whether it is possible to reset the LIS clock manually without 718 detection. Even if the timestamp was valid at the time location was 719 determined, a time period may elapse between when the PIDF-LO was 720 provided and when it is conveyed to the recipient. Periodically 721 refreshing location information to renew the timestamp even though 722 the location information itself is unchanged puts additional load on 723 LISs. As a result, recipients need to validate the timestamp in 724 order to determine whether it is credible. 726 6.3. Linkage to a Specific Endpoint 728 As noted in the "HTTP Enabled Location Delivery (HELD)" 729 [I-D.ietf-geopriv-http-location-delivery] Section 6.6: 731 The LIS MUST NOT include any means of identifying the Device in 732 the PIDF-LO unless it is able to verify that the identifier is 733 correct and inclusion of identity is expressly permitted by a Rule 734 Maker. Therefore, PIDF parameters that contain identity are 735 either omitted or contain unlinked pseudonyms [RFC3693]. A 736 unique, unlinked presentity URI SHOULD be generated by the LIS for 737 the mandatory presence "entity" attribute of the PIDF document. 738 Optional parameters such as the "contact" element and the 739 "deviceID" element [RFC4479] are not used. 741 Given the restrictions on inclusion of identification information 742 within the PIDF-LO, it may not be possible for a recipient to verify 743 that the entity on whose behalf location was determined represents 744 the same entity conveying location to the recipient. 746 Where "Enhancements for Authenticated Identity Management in the 747 Session Initiation Protocol (SIP)" [RFC4474] is used, it is possible 748 for the recipient to verify the identity assertion in the From: 749 header. However, if PIDF parameters that contain identity are 750 omitted or contain an unlinked pseudonym, then it may not be possible 751 for the recipient to verify whether the conveyed location actually 752 relates to the entity identified in the From: header. 754 This lack of binding between the entity obtaining the PIDF-LO and the 755 entity conveying the PIDF-LO to the recipient enables cut and paste 756 attacks which would enable an attacker to assert a bogus location, 757 even where both the SIP message and PIDF-LO are signed. As a result, 758 even implementation of both [RFC4474] and location signing does not 759 guarantee that location can be tied to a specific endpoint. 761 7. Conclusion 763 Emergency services raise a number of architectural questions, see 764 [I-D.ietf-ecrit-framework], 765 [I-D.schulzrinne-ecrit-unauthenticated-access], 766 [I-D.ietf-ecrit-location-hiding-req], and 767 [I-D.tschofenig-ecrit-architecture-overview]. With the generalized 768 emergency architecture considered within the ECRIT working group 769 various security challenges need to be addressed, including the 770 ability to report faked location and other attacks against the 771 emergency services infrastructure. These types of attacks also show 772 that the attack characteristics play an important role when dealing 773 with the problems and lower-layer solutions, as they have been 774 proposed as solutions for Denial of Service prevention (for example 775 using cryptographic puzzles), have limited applicability. 777 Although it is important to ensure that location information cannot 778 be faked there will be a larger number of GPS-enabled devices out 779 there that make it difficult to utilize any of the security 780 mechanisms described in Section 5. It will be very unlikely that end 781 users will upload their location information for "verification" to a 782 nearby location server located in the access network. 784 Given the practical and operational limitations in the technology, it 785 may be worthwhile to consider whether the goals of trustworthy 786 location, as for example defined by NENA i2 [NENA-i2], are 787 attainable, or whether lesser goals (such as auditability) should be 788 substituted instead. 790 The goal of auditability is to enable an investigator to determine 791 the source of a rogue emergency call after the fact. Since such an 792 investigation can rely on audit logs provided under court order, the 793 information available to the investigator could be considerably 794 greater than that present in messages conveyed in the emergency call. 795 As a consequence the emergency caller becomes accountable for his 796 actions. For example, in such a situation, information relating to 797 the owner of the unlinked pseudonym could be provided to 798 investigators, enabling them to unravel the chain of events that lead 799 to the attack. Auditability is likely to be of most benefits in 800 situations where attacks on the emergency services system are likely 801 to be relatively infrequent, since the resources required to pursue 802 an investigation are likely to be considerable. 804 Where attacks are frequent and continuous, a reliance on non- 805 automated mechanisms is unlikely to be satisfactory. As such, 806 mechanisms to exchange audit trails information in a standardized 807 format between ISPs and PSAPs / VSPs and PSAPs or heuristics to 808 distinguish potentially fraudulent emergency calls from real 809 emergencies might be valuable for the emergency services community. 811 8. IANA Considerations 813 This document does not require actions by IANA. 815 9. Acknowledgments 817 We would like to thank the members of the IETF ECRIT and the IETF 818 GEOPRIV working group for their input to the discussions related to 819 this topic. We would also like to thank Andrew Newton, Murugaraj 820 Shanmugam, Richard Barnes and Matt Lepinski for their feedback to 821 previous versions of this document. Martin Thomson provided valuable 822 input to version -02 of this document. 824 10. References 826 10.1. Normative References 828 [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for 829 Emergency Context Resolution with Internet Technologies", 830 RFC 5012, January 2008. 832 10.2. Informative references 834 [I-D.ietf-ecrit-framework] 835 Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 836 "Framework for Emergency Calling using Internet 837 Multimedia", draft-ietf-ecrit-framework-11 (work in 838 progress), July 2010. 840 [I-D.ietf-ecrit-location-hiding-req] 841 Schulzrinne, H., Liess, L., Tschofenig, H., Stark, B., and 842 A. Kuett, "Location Hiding: Problem Statement and 843 Requirements", draft-ietf-ecrit-location-hiding-req-04 844 (work in progress), February 2010. 846 [I-D.ietf-ecrit-mapping-arch] 847 Schulzrinne, H., "Location-to-URL Mapping Architecture and 848 Framework", draft-ietf-ecrit-mapping-arch-04 (work in 849 progress), March 2009. 851 [I-D.ietf-geopriv-http-location-delivery] 852 Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, 853 "HTTP Enabled Location Delivery (HELD)", 854 draft-ietf-geopriv-http-location-delivery-16 (work in 855 progress), August 2009. 857 [I-D.ietf-sip-location-conveyance] 858 Polk, J. and B. Rosen, "Location Conveyance for the 859 Session Initiation Protocol", 860 draft-ietf-sip-location-conveyance-13 (work in progress), 861 March 2009. 863 [I-D.schulzrinne-ecrit-unauthenticated-access] 864 Schulzrinne, H., McCann, S., Bajko, G., Tschofenig, H., 865 and D. Kroeselberg, "Extensions to the Emergency Services 866 Architecture for dealing with Unauthenticated and 867 Unauthorized Devices", 868 draft-schulzrinne-ecrit-unauthenticated-access-08 (work in 869 progress), July 2010. 871 [I-D.thomson-geopriv-location-dependability] 872 Thomson, M. and J. Winterbottom, "Digital Signature 873 Methods for Location Dependability", 874 draft-thomson-geopriv-location-dependability-06 (work in 875 progress), August 2010. 877 [I-D.tschofenig-ecrit-architecture-overview] 878 Tschofenig, H. and H. Schulzrinne, "Emergency Services 879 Architecture Overview: Sharing Responsibilities", 880 draft-tschofenig-ecrit-architecture-overview-00 (work in 881 progress), July 2007. 883 [I-D.winterbottom-geopriv-deref-protocol] 884 Winterbottom, J., Tschofenig, H., Schulzrinne, H., 885 Thomson, M., and M. Dawson, "A Location Dereferencing 886 Protocol Using HELD", 887 draft-winterbottom-geopriv-deref-protocol-05 (work in 888 progress), January 2010. 890 [LLDP-MED] 891 "Telecommunications: IP Telephony Infrastructure: Link 892 Layer Discovery Protocol for Media Endpoint Devices, ANSI/ 893 TIA-1057-2006", April 2006. 895 [NENA-i2] "08-001 NENA Interim VoIP Architecture for Enhanced 9-1-1 896 Services (i2)", December 2005. 898 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 899 Architecture for Describing Simple Network Management 900 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 901 December 2002. 903 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 904 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 906 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 907 Levkowetz, "Extensible Authentication Protocol (EAP)", 908 RFC 3748, June 2004. 910 [RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host 911 Configuration Protocol Option for Coordinate-based 912 Location Configuration Information", RFC 3825, July 2004. 914 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 915 Configuration of IPv4 Link-Local Addresses", RFC 3927, 916 May 2005. 918 [RFC4188] Norseth, K. and E. Bell, "Definitions of Managed Objects 919 for Bridges", RFC 4188, September 2005. 921 [RFC4293] Routhier, S., "Management Information Base for the 922 Internet Protocol (IP)", RFC 4293, April 2006. 924 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 925 Authenticated Identity Management in the Session 926 Initiation Protocol (SIP)", RFC 4474, August 2006. 928 [RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, 929 July 2006. 931 [RFC4740] Garcia-Martin, M., Belinchon, M., Pallares-Lopez, M., 932 Canales-Valenzuela, C., and K. Tammi, "Diameter Session 933 Initiation Protocol (SIP) Application", RFC 4740, 934 November 2006. 936 [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol 937 (DHCPv4 and DHCPv6) Option for Civic Addresses 938 Configuration Information", RFC 4776, November 2006. 940 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 941 Address Autoconfiguration", RFC 4862, September 2007. 943 Authors' Addresses 945 Hannes Tschofenig 946 Nokia Siemens Networks 947 Linnoitustie 6 948 Espoo 02600 949 Finland 951 Phone: +358 (50) 4871445 952 Email: Hannes.Tschofenig@gmx.net 953 URI: http://www.tschofenig.priv.at 955 Henning Schulzrinne 956 Columbia University 957 Department of Computer Science 958 450 Computer Science Building, New York, NY 10027 959 US 961 Phone: +1 212 939 7004 962 Email: hgs@cs.columbia.edu 963 URI: http://www.cs.columbia.edu 965 Bernard Aboba 966 Microsoft Corporation 967 One Microsoft Way 968 Redmond, WA 98052 969 US 971 Email: bernarda@microsoft.com