idnits 2.17.1 draft-tschofenig-ecrit-security-threats-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 843. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 820. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 827. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 833. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 45 has weird spacing: '...rk, the core...' == Line 177 has weird spacing: '...nce the regul...' == Line 674 has weird spacing: '...dify or to in...' == Line 707 has weird spacing: '...ocation infor...' -- 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 (July 18, 2005) is 6856 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- No information found for draft-schulzrinne-ecrit-requirements - is the name correct? Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT H. Tschofenig 3 Internet-Draft Siemens 4 Expires: January 19, 2006 H. Schulzrinne 5 Columbia U. 6 M. Shanmugam 7 TUHH 8 July 18, 2005 10 Security Threats and Requirements for Emergency Calling 11 draft-tschofenig-ecrit-security-threats-01.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on January 19, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 With the increasing interest to replace parts of the public switched 45 telephone network (PSTN) with the IP-based network, the core 46 functionality of PSTN such as emergency services, has to be offered 47 when using IP-based technologies. Since the PSTN and the Internet 48 follow different design principles their architecture is quite 49 different. This fact has to be considered and security threats for 50 an IP-based emergency environment have to be re-evaluated. This 51 document investigates the potential threats against the IP based 52 emergency architecture. It focuses on some analysis of threats for 53 both the end hosts and the infrastructure that aims to support 54 emergency services. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Motivations of Attackers of ECRIT . . . . . . . . . . . . . 5 61 4. Basic Actors . . . . . . . . . . . . . . . . . . . . . . . . 6 62 5. Security Threats . . . . . . . . . . . . . . . . . . . . . . 9 63 5.1 Denial of Service Attacks . . . . . . . . . . . . . . . . 9 64 5.2 Call Identity Spoofing . . . . . . . . . . . . . . . . . . 9 65 5.3 Location Spoofing . . . . . . . . . . . . . . . . . . . . 10 66 5.4 Impersonating a PSAP . . . . . . . . . . . . . . . . . . . 10 67 5.5 Signaling Message Modification . . . . . . . . . . . . . . 11 68 5.6 Modification of the Emergency Call . . . . . . . . . . . . 11 69 5.7 Loss of confidentiality . . . . . . . . . . . . . . . . . 11 70 5.8 Replay Attack . . . . . . . . . . . . . . . . . . . . . . 11 71 5.9 Corrupting Configuration Information . . . . . . . . . . . 12 72 5.10 Corrupting Database Information . . . . . . . . . . . . 12 73 6. Security Requirements . . . . . . . . . . . . . . . . . . . 13 74 6.1 Denial of Service Attacks . . . . . . . . . . . . . . . . 13 75 6.2 Call Identity Spoofing . . . . . . . . . . . . . . . . . . 14 76 6.3 Location Spoofing . . . . . . . . . . . . . . . . . . . . 14 77 6.4 Impersonating a PSAP . . . . . . . . . . . . . . . . . . . 16 78 6.5 Signaling Message Modification . . . . . . . . . . . . . . 16 79 6.6 Replay Attack . . . . . . . . . . . . . . . . . . . . . . 17 80 6.7 Loss of confidentiality . . . . . . . . . . . . . . . . . 17 81 6.8 Modification of the Emergency Call . . . . . . . . . . . . 17 82 6.9 Corrupting Configuration Information . . . . . . . . . . . 17 83 6.10 Corrupting Database Information . . . . . . . . . . . . 18 84 6.11 Location Validation and Verification . . . . . . . . . . 18 85 7. Security Considerations . . . . . . . . . . . . . . . . . . 20 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 21 87 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 88 9.1 Normative References . . . . . . . . . . . . . . . . . . . 22 89 9.2 Informative References . . . . . . . . . . . . . . . . . . 22 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 22 91 Intellectual Property and Copyright Statements . . . . . . . 23 93 1. Introduction 95 This document provides an overview of security mechanisms and 96 motivations for using them in the VoIP-based emergency services. 97 PSTN users can summon help for emergency services such as ambulance, 98 fire and police using a well known unique number (e.g., 911 in North 99 America, 112 in in Europe). With the introduction of IP-based 100 telephony support for emergency service also has to be provided. A 101 number of protocols and protocol extensions need to interwork in 102 order to provide emergency functionality. 104 Since the Internet is hostile place, it is important to understand 105 the security threats for emergency services. Otherwise, an adversary 106 can use the infrastructure to place fraudulent calls, mount denial of 107 service attacks, etc. 109 This document focuses on the security threats and security 110 requirements for the IP-based emergency service infrastructure only 111 without interaction with PSTN infrastructure elements. 113 A few discussions within this document are related to emergency 114 handling but solutions will not be developed as part of the ECRIT 115 working group. Hence, the are included mainly for completeness and 116 to point to the need to investigate additional aspects. Depending on 117 the chosen protocols (for the emergency call itself, for directory 118 access related to emergency call routing, for obtaining location 119 information from the network, etc.) various solutions might also 120 already be available to fulfill these security requirements and to 121 address the threats appropriately. 123 This document is organized as follows: Section 2 describes basic 124 terminology, Section 5 illustrates security threats and Section 6 125 lists security requirements. 127 2. Terminology 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [RFC2119]. 133 Emergency Caller, Public Safety Answering Point (PSAP), Access 134 Infrastructure Provider, Application (Voice) Service Provider, 135 Emergency Call Taker, etc. is taken from [I-D.schulzrinne-ecrit- 136 requirements]. 138 Additionally, we use the following terms throughout the document: 140 Emergency Call Routing Support: This term refers to entities that 141 route the emergency call to the appropriate PSAP based on 142 information like location information, language, etc. If SIP is 143 used as a protocol for session setup and call routing, for 144 example, then this entity would correspond to a SIP proxy. 146 Directory: This entity refers to a distributed directory protocol. 147 DNS is one example of such as distributed directory but there are 148 other protocols that might fulfill the requirements listed in 149 [I-D.schulzrinne-ecrit-requirements] for such a protocol. 151 Asserted Location Information: The term asserted location information 152 refers to the property that the recipient of such an object is 153 able to verify that it was generated by a particular party that is 154 authorized todo so. 156 3. Motivations of Attackers of ECRIT 158 The most obvious motivation for an attacker, in the context of 159 emergency, is to hinder user(s) not to avail the emergency service. 160 This can be done by variety of means such as impersonating a PSAP, 161 directory server, forging or spoofing location, identity etc., 162 However,there are several other potential motivations that cause 163 concern. Attackers might also wish to learn the nature emergency 164 information by eavesdropping an emergency call in order to reuse or 165 extract the relevant information that might cause potential problems 166 to the end hosts such as replay attacks, revealing the identity of 167 the user. 169 Attackers may want to prevent or delay an emergency caller by 170 modifying some information in the message typically modifying the 171 loation of the caller, while placing the emergency call. In some 172 cases, this will lead the emergency repsonders to dispatch the 173 services to the spoofed ara and might not be available to the other 174 callers. It might also be possible for an attacker to impede the 175 users not to reach an appropriate PSAP by corrupting or modifying the 176 location of an end host or the information returned from the mapping 177 protocol. Since the regulatory aspects of the emergency call often 178 does not manadate authentication of the caller, it is easy for an 179 attacker to forge some data(location information) to an PSAP, thereby 180 forcing the emergency responders to dispatch the services, which 181 might cause a denial of service to its legitimate users. 183 Finally, some attackers may simply want to halt the operation of an 184 entire emergency architecture through denial-of-service attacks. 186 4. Basic Actors 188 In order to support emergency services covering a large physical area 189 various infrastructure elements are necessary: Access Infrastructure 190 Providers, Application (Voice) Service Provider, PSAPs as endpoints 191 for emergency calls, directory services or other infrastructure 192 elements that assist in during the call routing and potentially many 193 other entities. 195 This section outlines which entities will be considered in the threat 196 analysis and shows the high level architecture. 198 Location 199 Information +-----------------+ 200 |(1) |Access | +-----------+ 201 v |Infrastructure | | | 202 +-----------+ |Provider | | Directory | 203 | | | (3) | | | 204 | Emergency |<---+-----------------+-->| | 205 | Caller | | (2) | +-----------+ 206 | |<---+-------+ | ^ 207 +-----------+ | +----|---------+------+ | 208 ^ | | Location | | | 209 | | | Information<-+ | | 210 | +--+--------------+ |(8) | | (5) 211 | | +-----------v+ | | 212 | (4) | |Emergency | | | 213 +--------------+--->|Call Routing|<--+---+ 214 | | |Support | | 215 | | +------------+ | 216 | | ^ | 217 | | (6) | +----+--+ 218 | (7) | +------->| | 219 +--------------+--------------->| PSAP | 220 | | | 221 |Application +----+--+ 222 |(Voice) | 223 |Service | 224 |Provider | 225 +---------------------+ 227 Figure 1: Framework 229 Figure 1 shows the interaction between the entities involved in the 230 call. There are a number of different deployment choices, as it can 231 be easily seen from the figure. The following deployment choices 232 need to be highlighted: 234 o How is location information provided to the end host? It might 235 either be known to the end host itself (due to manual 236 configuration or provided via GPS) or available via a third party. 237 Even if location information is known to the network it might be 238 made available to the end host. Alternatively, location 239 information is used as part of call routing and inserted by 240 intermediaries. 242 o Is the Access Infrastructure Provider also the Application (Voice) 243 Service Provider? In the Internet today these roles are typically 244 provided by different entities. As a consequence, the Application 245 (Voice) Service Provider is typically not able to learn the 246 physical location of the Emergency Caller. 248 Please note that the overlapping squares aim to indicate that certain 249 functionality can be collapsed into a single entity. As an example, 250 the Application (Voice) Service Provider might be the same entity as 251 the Access Infrastructure Provider and they might also operate the 252 PSAP. There is, however, no requirement that this must be the case. 253 Additionally it is worth pointing out that end systems might be its 254 own VoSP, e.g., for enterprises or residential users. 256 Below, we describe various interactions between the entities shown in 257 Figure 1 are described: 259 o (1) Location information might be available to the end host 260 itself. 262 o (2) Location information might, however, also be obtained from the 263 Access Infrastructure Provider (e.g., using DHCP or application 264 layer signaling protocols). 266 o (3) The Emergency Caller might need to consult a directory to 267 determine the PSAP that is appropriate for the physical location 268 of the emergency caller (and considering other attributes such as 269 a certain language support by the Emergency Call Takers). 271 o (4) The Emergency Caller might get assistance for emergency call 272 routing by infrastructure elements (referred as Emergency Call 273 Routing Support entities). In case of SIP these enities are 274 proxies. 276 o (5) Individual Emergency Call Routing Support entities might need 277 to consult a directory to determine where to route the emergency 278 call. 280 o (6) The Emergency Call Routing Support entities need to finally 281 forward the call, if infrastructure based emergency call routing 282 is used. 284 o (7) The emergency caller might interact directly with the PSAP 285 without any Emergency Call Routing Support entities. 287 5. Security Threats 289 This section discusses various security threats related to emergency 290 call handling. 292 5.1 Denial of Service Attacks 294 A (distributed) denial-of-service attack (DoS attack) on a PSAP, for 295 example, might isolate the PSAP from the Internet, for a while, thus 296 unable to receive the emergency calls at that time. Since a 297 particular PSAP is responsible for a certain geopraphical boundary, 298 attacking a single PSAP means denying the service to the entire area 299 (if no other backup PSAP is available). DoS attacks might appear in 300 many different flavors ranging from standard SYN floodings to attacks 301 where a human operator is involved then he has to determine whether 302 a call is in fact a true emergency call. In some cases this might 303 lead the case where the emergency staff (police, ambulance, etc.,) 304 might need to rush to the indicated emergency scene (potentionally an 305 arbitrary location) and will therefore not be available for other 306 rescue assignments during that time. 308 As such, PSAPs can be seen as a particularly valuable target since 309 the consequences of an unreachable PSAP has severe consequences. 311 Attacks against the routing infrastructure enables an adversary to 312 prevent all nodes attached to this network to sent emergency calls. 313 Attacks against entities that assist in the call routing (such as 314 attacks against the directory service) might make it difficult or 315 impossible for emergency call to reach its intended PSAP. 317 5.2 Call Identity Spoofing 319 If an adversary is able to make emergency calls without the need to 320 disclose its identity (such as a SIP URI or NAI) then prank calls 321 cannot be traced back. If the call is proxy-routed, the PSAP will 322 not see the IP address of the caller in signaling. Additionally, it 323 might be necessary for the Emergency Call Taker to initiate a voice, 324 video or instant messaging exchange towards the Emergency Caller. 326 Trying to find an adversary that placed a crank call is difficult if 327 somebody uses an open 802.11 access point, even if you can find the 328 owner of that access point. This problem is no different than 329 somebody placing an emergency call from a payphone. 331 If the adversary is never authenticated (neither to the PSAP nor to 332 the Access Infrastructure Provider) then it is possible to trace the 333 call back to a make a particular entity accountable. 335 A standard requirement for emergency systems is that emergency calls 336 must also be placed in absence of any authentication. An adversary 337 will typically exploit these weaknesses and he will always find 338 networks that do not perform network access authentication of the 339 user prior to providing network access. As such, the emergency 340 infrastructure cannot neither rely on network access authentication 341 nor on authentication of the caller towards the PSAP or the 342 Application (Voice) Service Provider. 344 It is necessary to point to the fact that authentication in the 345 emergency case might require the authorization procedure to be 346 skipped. For example, in an emergency case it is still possible to 347 authenticate the user of an emergency call but without considering 348 that its credits are exhausted. 350 5.3 Location Spoofing 352 An adversary might want to made-up faked location information in 353 order to fool the emergency personnel. This is made particularly 354 easy if the location information is provided by the Emergency Caller 355 either via manual configuration or via GPS. Spoofing is more 356 difficult if an entity proving Emergency Call Routing Support inserts 357 location information into emergency call signaling. In this case the 358 adversary needs to route the call via some intermediaries. This is 359 possible since these devices are often, by their nature as IP 360 devices, addressable from an arbitary physical location. The usage 361 of VPN (or other tunneling mechanisms) and proxies further 362 complicates the ability to infer the physical location from the IP 363 address seen by the PSAP. 365 5.4 Impersonating a PSAP 367 An adversary might pretend to operate a PSAP. When either an end 368 host or an intermediate device wants to determine the PSAP that is 369 responsible for a particular geographical area by sending a query to 370 the directory an adversary might return a faked response. Returning 371 an incorrect response message does not require the adversary to be 372 somewhere along the path. It is sufficient for an adversary to be 373 located in a broadcast medium and the adversary has to reply as soon 374 as a query is observed (if no security protection is utilized). If 375 the response indicates a legitimate but inappropriate (i.e., a PSAP 376 that is authoritive for a different geographical area) then the 377 emergency call interaction will be able to continue but will suffer 378 from delays until the emergency call can be forwarded to the correct 379 PSAP, potentially involving human interaction (by the Emergency Call 380 Taker). 382 5.5 Signaling Message Modification 384 An adversary that is located along the signaling path might modify 385 the content of emergency calls, such as location information or 386 identity information. This might lead to a denial of service attack 387 against the emergency personell, disruption of the emergency call, 388 delayed call setup, etc. 390 An adversary might want to inject signaling messages to terminate or 391 redirect the call to another location. Dropping or delaying 392 signaling messages is also possible for an on-path adversary. 394 Depending on the capability of the signaling protocol the range of 395 possible attacks might have been documented already. 397 5.6 Modification of the Emergency Call 399 An adversary along the media path might want to modify the data 400 traffic part of the emergency call (voice, video or instant message). 401 An attacker can change the message on-the-fly and fool the PSAP to 402 receive meaningless or bogus messages. The response messages to 403 Emergency Caller might also be subject to change, for example by 404 injecting a recorded failure message. 406 5.7 Loss of confidentiality 408 An adversary might eavesdrop an emergency call and use the 409 information to future sessions as part of replay attacks. The 410 ability to eavesdrop also allows to learn details about the emergency 411 situation which might be of interest for the press or other media 412 organizations. Please note that the location of the adversary is 413 important regarding the eavesdropped area. For example, an adversary 414 in a WLAN is typically able to see a small amount of traffic due to 415 the coverage area of typical WLAN network. 417 Reavealing the true identity of the user as part of the privacy 418 override mechanism might conflict with the users privacy settings. 420 5.8 Replay Attack 422 An adversary might want to use eavesdropped information to mount 423 attacks in the future. This might be necessary if information cannot 424 be re-created by the adversary (for example, asserted location 425 information). The ability to replay messages or individual objects 426 the specific property of these messages and objects is important. 427 For example, asserted location information might bind location 428 information and a timestamp with a digital signature together that 429 makes it difficult to reuse this object beyonds its lifetime. 431 [Editor's Note: It is sometimes hard to tell what are real threats 432 and what security threats are addressed already by certain solutions 433 outside the scope of the working group. Addressing all standard 434 security threats is a long process if certain mechanisms are required 435 in an case that largely or completely mitigate against these 436 threats.] 438 5.9 Corrupting Configuration Information 440 An adversary might override all locally configured emergency numbers. 441 This might be particular problematic if these emergency numbers are 442 dynamically retrieved using some mechanisms. As such, an Emergency 443 Caller would start a call that either leads to a blackhole (as such 444 it is a DoS attack), the Emergency Caller connects to a rogue PSAP or 445 to an inappropriate PSAP. 447 5.10 Corrupting Database Information 449 An attacker might want to provide emergency callers with wrong 450 information about emergency service contact URIs. An adversary can 451 accomplish this goal in various ways, including message modification, 452 spoofing or corrupting the database. Since the database provides a 453 pointer(e.g., SIP URI) to an appropriate PSAP, care must be taken 454 when retrieving emergency URI. A succesfull forging will lead the 455 user to reach either a false PSAP or to a black hole. 457 6. Security Requirements 459 [Editor's Note: A few requirements below are already addressed by a 460 number of requirements and solution specific documents today. In 461 order to keep the document short it would be reasonable to focus only 462 on the difficult security threats and requiremens for emergency calls 463 rather than enumerating everything that could happen to an emergency 464 call. The working group should decide how to proceed with this 465 particular issue and what threats and requirements should be 466 elaborated in more detail.] 468 Compiling security requirements to address the threats listed in the 469 previous section might is impacted by several constraints: 471 Security mechanisms may lead to a certain performance overhead 472 (e.g., several roundtrips). 474 A certain security infrastructure is required that might lead to 475 deployment problems. For example, end user certificates, 476 certificates for networks, usage of authorization certificate, 477 etc. might need to be deployed before any of these mechanisms are 478 useful. 480 Many of these aspects are related to regulatory and legal 481 requirements that may vary from country to country. Typically, 482 these mechanisms cannot be mandated by an IETF specification. 484 Some of the requirements impose solutions that are out-of-scope of 485 the ECRIT working group. 487 Given the above-listed constraints the requirements that have to be 488 addressed by work that is done within ECRIT have to be highlighted. 489 Other requirements have to be read as 'if you would like to address 490 this threat, then you might want to consider this requirement' rather 491 than 'any solution must address fulfill this requirement'. 493 6.1 Denial of Service Attacks 495 It is difficult to address all possible denial of service attacks 496 that might lead to disruption of an emergency call since a number of 497 IETF protocols are used in order to provide this functionality. 498 Hence, care must be taken when protocol extensions are developed that 499 the chance for a denial of service attack is not increased. Even 500 without using any security mechanisms (such as authentication and key 501 exchange protocols) some degree of security has to be provided. 503 It is important to understand that the ability to mount DoS attacks 504 must also be considered as part of the architecture work when legal 505 and regulatory requirements are known and need to be fulfilled. 507 6.2 Call Identity Spoofing 509 A standard requirement to prevent identity spoofing is to 510 authenticate the Emergency Caller. Authentication mechanisms that 511 require multiple roundtrips and as such might delay the call are 512 often not desirable or cannot be mandated. 514 6.3 Location Spoofing 516 An Emergency Caller might in many cases know its own location 517 information because it was obtained via civic or geospatial location 518 extensions for DHCP, via manual configuration or via GPS. 519 Unfortunately, information provided by the end host is untrustworthy 520 particularly when it is as important as location information. Two 521 approaches have been discussed in the past that place lead to a few 522 requirements: 524 o Location Information is asserted by the Access Infrastructure 525 Provider. As such, the end host might use GPS but uses a protocol 526 to allow the network to assert the location information. This 527 approach also has its limitations if the coverage area of the 528 wireless network is fairly large. 530 o Location Information is added to the emergency call via an 531 Emergency Call Routing Support entity. Depending on the protocol 532 used for call routing and on the properties of this protocol it 533 might be necessary to return the asserted location information to 534 the end host since intermediate nodes might not be allowed to 535 insert objects into the call setup messages (at least not in all 536 parts of the messages, such as bodies). These signaling entities, 537 in general, do not know the physiscal location of the user. Thus, 538 they have to rely on somebody else to actually provide the 539 location, e.g., the Access Infrastructure Provider. 541 As it can be seen from these two options the main difference is based 542 on the type of protocol that is used in the message communication. 543 This has an impact on the semantic and on the availability of certain 544 attributes (such as identities that are used by these protocols) and 545 on deployment constraints. Based on the observation that the Access 546 Infrastructure Provider is closest to the end host and is therefore 547 the most likely entity that knows something about the physical 548 location of the end host it seems to be reasonable to assume that 549 some entity that asserts the location information is actually 550 available in this particular network. 552 In the context of emergency, spoofing can be loosely divided into 553 o wide-area spoofing - users pretend to be in Germany but actually 554 in US. 556 o local-area spoofing - users spoof location information to an 557 extend (few miles). 559 o local-area cloning - users pretend to be in place X if they were 560 actually there, a while ago. 562 The following requirements need to be provided in order for asserted 563 location information to accomplish its goals: 565 o Location Information MUST be integrity protected to prevent 566 modifications by third parties. 568 o The recipient of the asserted location information object MUST be 569 able to determine the party that asserted the location information 570 in order to verify the assertion. As such, authentication of the 571 asserting party (the entity that created the assertion) MUST be 572 provided. 574 o The asserted location information MUST include a timestamp to 575 limit its validity in order to reduce replay attacks. 577 o The recipient of the asserted location information MUST have a way 578 to verify that the asserting party is indeed authorized to create 579 such an assertion. As such, authentication is insufficient if not 580 further authorization decision can be associated to the 581 authenticated identity. 583 o The recipient of the asserted location information SHOULD have a 584 mechanism to determine the Emergency Caller based on the provided 585 assertion. 587 The last bullet deserves further discussion: If some information 588 about the Emergency Caller identity has to be included, which is only 589 for the purpose of traceability then this functionality might not be 590 of general use. This is because an adversary will always find 591 networks that do not authenticate the user prior to providing network 592 access. Furthermore, the goal of a number of network access 593 authentication protocols is to prevent disclosure of the user 594 identity to entities other than to the user's home network. Note 595 that the term 'user idenity' does not require that this identity 596 directly points to the 'real' identity of a user. A court might want 597 to require this identity to be resolved and to determine the user 598 behind this identity. Even if the access network would like to 599 assertain the user's identity as part of the asserted location 600 information it is, in many cases, not even possible for the Access 601 Infrastructure Provider. 603 If the authenticated user identity is not available to the Access 604 Infrastructure Provider then only a few other identities might be 605 useful, such as the IP address or the MAC address. Other identities, 606 such as the Host Identity, might not be available since they are only 607 used by very few protocols. An assertion that indicates the network 608 in combination with the IP and/or MAC address (together with a 609 timestamp) might provide some limited degree of traceability only if 610 the user was authenticated directly to this particular network. 611 Providing the IP address allows some obvious attempts to cheat to be 612 caught. Hence, there is the question whether some identity should be 613 added at all given the potential limitations and the potential small 614 amounts of cut-and-paste attacks. Using end user based 615 authentication in addition to the asserted location information would 616 be helpful (e.g., using end user certificates) but will impose a 617 serious deployment problem. Given the fact that emergency calls must 618 still be allowed even without end user authentication certainly 619 defeats the purpose of these mechanisms. A partical attempt to 620 address some prank calls is to classify emergency calls based on the 621 availability of the provided attributes. If suspicious information 622 is being provided that may well be wrong then additional verification 623 steps need to be taken. For example, if a report of a large fire on 624 a Manhattan street is received then the PSAP may wait to dispatch 625 until it gets a second person to call in. This approach obviously 626 has some limitations as well. 628 6.4 Impersonating a PSAP 630 The Emergency Caller SHOULD be able to determine conclusively that he 631 has reached an accredited emergency call center. This requirement is 632 meant to address the threat that a rogue, possibly criminal, entity 633 pretends to accept emergency calls and disrupts the emergency 634 infrastructure. 636 o A user agent must be able to authenticate a PSAP. 638 Unlike in the PSTN case IP based networks provide a better 639 opportunity to spoof a PSAP since physical access to the cable plant 640 is required in the PSTN case, while this may not true for the IP 641 case. 643 6.5 Signaling Message Modification 645 To protect signaling messages against modifications either individual 646 attributes SHOULD be protected (such as location objects) or the 647 entire signaling message communication SHOULD experience end-to-end 648 protection. This requires integrity and replay protection to be 649 applied. Authentication of the data sender and the data receiver 650 SHOULD be provided to prevent a man-in-the-middle attack. 652 6.6 Replay Attack 654 In order to protect signaling messages (or individual attributes) to 655 be replayed in future protocol sessions integrity and replay 656 protection mechanisms SHOULD be provided. 658 6.7 Loss of confidentiality 660 In order to prevent leakage of information exchanged during the 661 emergency call (both signaling and data traffic) confidentiality 662 protection SHOULD be provided. The mechanisms to accomplish this 663 functionality are typically different for the data traffic and for 664 the signaling messages and various scenarios, such as hop-by-hop, 665 end-to-middle, middle-to-middle and end-to-end security, need to be 666 considered. Particularly the key management aspects for end-to-end 667 security mechansisms imposes a deployment burden and hence need to be 668 critically analysed in order to determine its applicability in the 669 given context. 671 6.8 Modification of the Emergency Call 673 To protect a man-in-the-middle attack i.e disallow the adversary to 674 modify or to inject data traffic into the communication between the 675 Emergency Caller and the PSAP, the mechanisms like integrity, replay 676 and data origin authentication SHOULD be provided. Since the 677 signaling messages are used to authenticate the end points and to 678 distribute the required keying material it is necessary that either 679 the key exchange protocol itself and the signaling messages 680 experience appropriate security protection. The term 'appropriate' 681 refers to the given context, the used signaling protocol and the key 682 exchange protocol. 684 Please note that the interactive nature of a voice communication 685 already provides a some degree of protection. However, with the 686 introduction of instant messaging the freshness of the Emergency Call 687 needs to be provided by other means. 689 6.9 Corrupting Configuration Information 691 Devices SHOULD be assured of the correctness of the local emergency 692 numbers that are automatically configured. If we assume a fixed, 693 global emergency service identifier that requires no configuration 694 and only configure local "traditional" emergency numbers, users are 695 not likely to suddenly dial some random number if a rogue 696 configuration server introduces this as an additional emergency 697 number. The ability to override all locally configured emergency 698 number is of more concern. If the Emergency Caller does not use the 699 infrastructure to route the call to the appropriate PSAP then the 700 security of the directory service is of importance for security. 702 6.10 Corrupting Database Information 704 If the mapping client i.e., the entity that requests location 705 information using a mapping protocol accepts the emergency contact 706 information from an unauthenticated mapping server i.e., the entity 707 that provides location information, it is highly possible to receive 708 bogus or prank emergency contact URIs. Particularly the caching 709 properties of a distributed directory might be exploited. To ensure 710 the secure retrieval of information, the following properties are 711 assumed: 713 o The maping client MUST be able to authenticate the mapping server. 715 o The interaction between the mapping client and the mapping server 716 MUST be integrity and replay protected. 718 o The mapping server MUST be provide data origin authentication 719 thereby ensuring that the provided data items are indeed from the 720 claimed source. 722 o The mapping server MUST provide information to ensure that it is 723 authoritive for the provided information. 725 6.11 Location Validation and Verification 727 location validation ensures that an address exists and is mappable to 728 a PSAP. A valid address, however, does not imply that the call 729 actually originated from that location. We refer to location 730 verification as the assurance that the call was placed at the 731 location claimed, including any error margins provided. 733 Verifying a location is generally more difficult than location 734 validation as there is currently no generally trusted service that 735 can vouch for the location of the caller. In some cases, AIPs or 736 ISPs may be able to indicate the location of the caller with high 737 confidence and they may possess cryptographic certificates that are 738 trusted by the PSAP. This may not require a global certification 739 authority (CA), as a regional PSAP typically only deals with a modest 740 number of larger enterprises and thus could obtain their public keys 741 even if self-signed. 743 However, even if the AIP or ISP provides a signed location, it is 744 difficult to ensure that such a signed location object is only used 745 for calls from that location, as it will have to be copied from a 746 location delivery protocol to the call signaling protocol. For 747 example, a third party could obtain such a signed location object and 748 use it elsewhere. Naturally, timestamps will restrict such usage to 749 the order of minutes or hours, depending on how often location 750 information is updated. A PSAP may want to be able to answer the 751 following questions: 753 o Who originally provided this particular location information? 755 o Did the call originate from that particular geospatial or civic 756 address and who says so and how do they know? 758 7. Security Considerations 760 This document addresses security threats and security requirements. 761 Therefore, security is considered throughout this document. 763 8. IANA Considerations 765 This document does not require actions by the IANA. 767 9. References 769 9.1 Normative References 771 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 772 Requirement Levels", March 1997. 774 9.2 Informative References 776 [I-D.schulzrinne-ecrit-requirements] 777 Schulzrinne, H. and R. Marshall, "Requirements for 778 Emergency Context Resolution with Internet Technologies", 779 May 2005. 781 Authors' Addresses 783 Hannes Tschofenig 784 Siemens 785 Otto-Hahn-Ring 6 786 Munich, Bayern 81739 787 Germany 789 Email: Hannes.Tschofenig@siemens.com 791 Henning Schulzrinne 792 Columbia University 793 Department of Computer Science 794 450 Computer Science Building 795 New York, NY 10027 796 USA 798 Phone: +1 212 939 7042 799 Email: schulzrinne@cs.columbia.edu 800 URI: http://www.cs.columbia.edu/~hgs 802 Murugaraj Shanmugam 803 Technische Universitat Hamburg-Harburg 804 Department of Security in Distributed applications 805 Harburger Schlossstrasse 20 806 Hamburg-Harburg 21079 807 Germany 809 Email: murugaraj.shanmugam@tuhh.de 811 Intellectual Property Statement 813 The IETF takes no position regarding the validity or scope of any 814 Intellectual Property Rights or other rights that might be claimed to 815 pertain to the implementation or use of the technology described in 816 this document or the extent to which any license under such rights 817 might or might not be available; nor does it represent that it has 818 made any independent effort to identify any such rights. Information 819 on the procedures with respect to rights in RFC documents can be 820 found in BCP 78 and BCP 79. 822 Copies of IPR disclosures made to the IETF Secretariat and any 823 assurances of licenses to be made available, or the result of an 824 attempt made to obtain a general license or permission for the use of 825 such proprietary rights by implementers or users of this 826 specification can be obtained from the IETF on-line IPR repository at 827 http://www.ietf.org/ipr. 829 The IETF invites any interested party to bring to its attention any 830 copyrights, patents or patent applications, or other proprietary 831 rights that may cover technology that may be required to implement 832 this standard. Please address the information to the IETF at 833 ietf-ipr@ietf.org. 835 Disclaimer of Validity 837 This document and the information contained herein are provided on an 838 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 839 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 840 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 841 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 842 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 843 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 845 Copyright Statement 847 Copyright (C) The Internet Society (2005). This document is subject 848 to the rights, licenses and restrictions contained in BCP 78, and 849 except as set forth therein, the authors retain all their rights. 851 Acknowledgment 853 Funding for the RFC Editor function is currently provided by the 854 Internet Society.