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