idnits 2.17.1 draft-tschofenig-ecrit-security-threats-00.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 736. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 713. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 720. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 726. ** 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (May 9, 2005) is 6927 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: 4 errors (**), 0 flaws (~~), 2 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: November 10, 2005 H. Schulzrinne 5 Columbia U. 6 M. Shanmugam 7 TUHH 8 May 9, 2005 10 Security Threats and Requirements for Emergency Calling 11 draft-tschofenig-ecrit-security-threats-00.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 November 10, 2005. 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 its IP-based counterpart the 46 functionality of emergency services also needs to be offered using 47 IP-based technologies. Since the PSTN and the Internet follow 48 different design principles, their architecture is quite different. 50 This fact has to be considered and security threats for an IP-based 51 emergency environment have to be re-evaluated. This document 52 investigates the potential threats for the end hosts and the 53 infrastructure that aims to support emergency services. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Basic Actors . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4. Security Threats . . . . . . . . . . . . . . . . . . . . . . . 8 61 4.1 Denial of Service Attacks . . . . . . . . . . . . . . . . 8 62 4.2 Call Identity Spoofing . . . . . . . . . . . . . . . . . . 8 63 4.3 Location Spoofing . . . . . . . . . . . . . . . . . . . . 9 64 4.4 Impersonating a PSAP . . . . . . . . . . . . . . . . . . . 9 65 4.5 Signaling Message Modification . . . . . . . . . . . . . . 10 66 4.6 Modification of the Emergency Call . . . . . . . . . . . . 10 67 4.7 Loss of confidentiality . . . . . . . . . . . . . . . . . 10 68 4.8 Replay Attack . . . . . . . . . . . . . . . . . . . . . . 10 69 4.9 Corrupting Configuration Information . . . . . . . . . . . 11 70 5. Security Requirements . . . . . . . . . . . . . . . . . . . . 12 71 5.1 Denial of Service Attacks . . . . . . . . . . . . . . . . 12 72 5.2 Call Identity Spoofing . . . . . . . . . . . . . . . . . . 13 73 5.3 Location Spoofing . . . . . . . . . . . . . . . . . . . . 13 74 5.4 Impersonating a PSAP . . . . . . . . . . . . . . . . . . . 15 75 5.5 Signaling Message Modification . . . . . . . . . . . . . . 15 76 5.6 Replay Attack . . . . . . . . . . . . . . . . . . . . . . 16 77 5.7 Loss of confidentiality . . . . . . . . . . . . . . . . . 16 78 5.8 Modification of the Emergency Call . . . . . . . . . . . . 16 79 5.9 Corrupting Configuration Information . . . . . . . . . . . 16 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 81 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 82 7.1 Normative References . . . . . . . . . . . . . . . . . . . 19 83 7.2 Informative References . . . . . . . . . . . . . . . . . . 19 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19 85 Intellectual Property and Copyright Statements . . . . . . . . 20 87 1. Introduction 89 This document provides an overview of security mechanisms and 90 motivations for using them in the VoIP-based emergency services. 91 PSTN users can summon help for emergency services such as ambulance, 92 fire and police using a well known unique number (e.g., 911 in North 93 America, 112 in in Europe). With the introduction of IP-based 94 telephony support for emergency service also has to be provided. A 95 number of protocols and protocol extensions need to interwork in 96 order to provide emergency functionality. 98 Since the Internet is hostile place, it is important to understand 99 the security threats for emergency services. Otherwise, an adversary 100 can use the infrastructure to place fraudulent calls, mount denial of 101 service attacks, etc. 103 This document focuses on the security threats and security 104 requirements for the IP-based emergency service infrastructure only 105 without interaction with PSTN infrastructure elements. 107 A few discussions within this document are related to emergency 108 handling but solutions will not be developed as part of the ECRIT 109 working group. Hence, the are included mainly for completeness and 110 to point to the need to investigate additional aspects. Depending on 111 the chosen protocols (for the emergency call itself, for directory 112 access related to emergency call routing, for obtaining location 113 information from the network, etc.) various solutions might also 114 already be available to fulfill these security requirements and to 115 address the threats appropriately. 117 This document is organized as follows: Section 2 describes basic 118 terminology, Section 4 illustrates security threats and Section 5 119 lists security requirements. 121 2. Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in [RFC2119]. 127 Emergency Caller, Public Safety Answering Point (PSAP), Access 128 Infrastructure Provider, Application (Voice) Service Provider, 129 Emergency Call Taker, etc. is taken from [I-D.schulzrinne-ecrit- 130 requirements]. 132 Additionally, we use the following terms throughout the document: 134 Emergency Call Routing Support: This term refers to entities that 135 route the emergency call to the appropriate PSAP based on 136 information like location information, language, etc. If SIP is 137 used as a protocol for session setup and call routing, for 138 example, then this entity would correspond to a SIP proxy. 140 Directory: This entity refers to a distributed directory protocol. 141 DNS is one example of such as distributed directory but there are 142 other protocols that might fulfill the requirements listed in 143 [I-D.schulzrinne-ecrit-requirements] for such a protocol. 145 Asserted Location Information: The term asserted location information 146 refers to the property that the recipient of such an object is 147 able to verify that it was generated by a particular party that is 148 authorized todo so. 150 3. Basic Actors 152 In order to support emergency services covering a large physical area 153 various infrastructure elements are necessary: Access Infrastructure 154 Providers, Application (Voice) Service Provider, PSAPs as endpoints 155 for emergency calls, directory services or other infrastructure 156 elements that assist in during the call routing and potentially many 157 other entities. 159 This section outlines which entities will be considered in the threat 160 analysis and shows the high level architecture. 162 Location 163 Information +-----------------+ 164 |(1) |Access | +-----------+ 165 v |Infrastructure | | | 166 +-----------+ |Provider | | Directory | 167 | | | (3) | | | 168 | Emergency |<---+-----------------+-->| | 169 | Caller | | (2) | +-----------+ 170 | |<---+-------+ | ^ 171 +-----------+ | +----|---------+------+ | 172 ^ | | Location | | | 173 | | | Information<-+ | | 174 | +--+--------------+ |(8) | | (5) 175 | | +-----------v+ | | 176 | (4) | |Emergency | | | 177 +--------------+--->|Call Routing|<--+---+ 178 | | |Support | | 179 | | +------------+ | 180 | | ^ | 181 | | (6) | +----+--+ 182 | (7) | +------->| | 183 +--------------+--------------->| PSAP | 184 | | | 185 |Application +----+--+ 186 |(Voice) | 187 |Service | 188 |Provider | 189 +---------------------+ 191 Figure 1: Framework 193 Figure 1 shows the interaction between the entities involved in the 194 call. There are a number of different deployment choices, as it can 195 be easily seen from the figure. The following deployment choices 196 need to be highlighted: 198 o How is location information provided to the end host? It might 199 either be known to the end host itself (due to manual 200 configuration or provided via GPS) or available via a third party. 201 Even if location information is known to the network it might be 202 made available to the end host. Alternatively, location 203 information is used as part of call routing and inserted by 204 intermediaries. 206 o Is the Access Infrastructure Provider also the Application (Voice) 207 Service Provider? In the Internet today these roles are typically 208 provided by different entities. As a consequence, the Application 209 (Voice) Service Provider is typically not able to learn the 210 physical location of the Emergency Caller. 212 Please note that the overlapping squares aim to indicate that certain 213 functionality can be collapsed into a single entity. As an example, 214 the Application (Voice) Service Provider might be the same entity as 215 the Access Infrastructure Provider and they might also operate the 216 PSAP. There is, however, no requirement that this must be the case. 217 Additionally it is worth pointing out that end systems might be its 218 own VoSP, e.g., for enterprises or residential users. 220 Below, we describe various interactions between the entities shown in 221 Figure 1 are described: 223 o (1) Location information might be available to the end host 224 itself. 226 o (2) Location information might, however, also be obtained from the 227 Access Infrastructure Provider (e.g., using DHCP or application 228 layer signaling protocols). 230 o (3) The Emergency Caller might need to consult a directory to 231 determine the PSAP that is appropriate for the physical location 232 of the emergency caller (and considering other attributes such as 233 a certain language support by the Emergency Call Takers). 235 o (4) The Emergency Caller might get assistance for emergency call 236 routing by infrastructure elements (referred as Emergency Call 237 Routing Support entities). In case of SIP these enities are 238 proxies. 240 o (5) Individual Emergency Call Routing Support entities might need 241 to consult a directory to determine where to route the emergency 242 call. 244 o (6) The Emergency Call Routing Support entities need to finally 245 forward the call, if infrastructure based emergency call routing 246 is used. 248 o (7) The emergency caller might interact directly with the PSAP 249 without any Emergency Call Routing Support entities. 251 4. Security Threats 253 This section discusses various security threats related to emergency 254 call handling. 256 4.1 Denial of Service Attacks 258 A (distributed) denial-of-service attack (DoS attack) on a PSAP, for 259 example, might make the PSAP unreachable for emergency calls. Since 260 a particular PSAP is responsible for a certain geopraphical area, the 261 entire area might be affected (if no other backup PSAP is available). 262 DoS attacks might appear in many different flavors ranging from 263 standard SYN flooding attacks to attacks where a human operator is 264 involved and needs to determine whether a call is in fact a true 265 emergency call. In some cases this might lead the case where the 266 emergency staff (police, ambulance, etc.) might need to rush to the 267 indicated emergency scene (potentionally an arbitrary location) and 268 will therefore not be available for other rescue assignments during 269 that time. 271 As such, PSAPs can be seen as a particularly valuable target since 272 the consequences of an unreachable PSAP has severe consequences. 274 Attacks against the routing infrastructure enables an adversary to 275 prevent all nodes attached to this network to sent emergency calls. 276 Attacks against entities that assist in the call routing (such as 277 attacks against the directory service) might make it difficult or 278 impossible for emergency call to reach its intended PSAP. 280 4.2 Call Identity Spoofing 282 If an adversary is able to make emergency calls without the need to 283 disclose its identity (such as a SIP URI or NAI) then prank calls 284 cannot be traced back. If the call is proxy-routed, the PSAP will 285 not see the IP address of the caller in signaling. Additionally, it 286 might be necessary for the Emergency Call Taker to initiate a voice, 287 video or instant messaging exchange towards the Emergency Caller. 289 Trying to find an adversary that placed a crank call is difficult if 290 somebody uses an open 802.11 access point, even if you can find the 291 owner of that access point. This problem is no different than 292 somebody placing an emergency call from a payphone. 294 If the adversary is never authenticated (neither to the PSAP nor to 295 the Access Infrastructure Provider) then it is possible to trace the 296 call back to a make a particular entity accountable. 298 A standard requirement for emergency systems is that emergency calls 299 must also be placed in absence of any authentication. An adversary 300 will typically exploit these weaknesses and he will always find 301 networks that do not perform network access authentication of the 302 user prior to providing network access. As such, the emergency 303 infrastructure cannot neither rely on network access authentication 304 nor on authentication of the caller towards the PSAP or the 305 Application (Voice) Service Provider. 307 It is necessary to point to the fact that authentication in the 308 emergency case might require the authorization procedure to be 309 skipped. For example, in an emergency case it is still possible to 310 authenticate the user of an emergency call but without considering 311 that its credits are exhausted. 313 4.3 Location Spoofing 315 An adversary might want to made-up faked location information in 316 order to fool the emergency personnel. This is made particularly 317 easy if the location information is provided by the Emergency Caller 318 either via manual configuration or via GPS. Spoofing is more 319 difficult if an entity proving Emergency Call Routing Support inserts 320 location information into emergency call signaling. In this case the 321 adversary needs to route the call via some intermediaries. This is 322 possible since these devices are often, by their nature as IP 323 devices, addressable from an arbitary physical location. The usage 324 of VPN (or other tunneling mechanisms) and proxies further 325 complicates the ability to infer the physical location from the IP 326 address seen by the PSAP. 328 4.4 Impersonating a PSAP 330 An adversary might pretend to operate a PSAP. When either an end 331 host or an intermediate device wants to determine the PSAP that is 332 responsible for a particular geographical area by sending a query to 333 the directory an adversary might return a faked response. Returning 334 an incorrect response message does not require the adversary to be 335 somewhere along the path. It is sufficient for an adversary to be 336 located in a broadcast medium and the adversary has to reply as soon 337 as a query is observed (if no security protection is utilized). If 338 the response indicates a legitimate but inappropriate (i.e., a PSAP 339 that is authoritive for a different geographical area) then the 340 emergency call interaction will be able to continue but will suffer 341 from delays until the emergency call can be forwarded to the correct 342 PSAP, potentially involving human interation (by the Emergency Call 343 Taker). 345 4.5 Signaling Message Modification 347 An adversary that is located along the signaling path might modify 348 the content of emergency calls, such as location information or 349 identity information. This might lead to a denial of service attack 350 against the emergency personell, disruption of the emergency call, 351 delayed call setup, etc. 353 An adversary might want to inject signaling messages to terminate or 354 redirect the call to another location. Dropping or delaying 355 signaling messages is also possible for an on-path adversary. 357 Depending on the capability of the signaling protocol the range of 358 possible attacks might have been documented already. 360 4.6 Modification of the Emergency Call 362 An adversary along the media path might want to modify the data 363 traffic part of the emergency call (voice, video or instant message). 364 An attacker can change the message on-the-fly and fool the PSAP to 365 receive meaningless or bogus messages. The response messages to 366 Emergency Caller might also be subject to change, for example by 367 injecting a recorded failure message. 369 4.7 Loss of confidentiality 371 An adversary might eavesdrop an emergency call and use the 372 information to future sessions as part of replay attacks. The 373 ability to eavesdrop also allows to learn details about the emergency 374 situation which might be of interest for the press or other media 375 organizations. Please note that the location of the adversary is 376 important regarding the eavesdropped area. For example, an adversary 377 in a WLAN is typically able to see a small amount of traffic due to 378 the coverage area of typical WLAN network. 380 Reavealing the true identity of the user as part of the privacy 381 override mechanism might conflict with the users privacy settings. 383 4.8 Replay Attack 385 An adversary might want to use eavesdropped information to mount 386 attacks in the future. This might be necessary if information cannot 387 be re-created by the adversary (for example, asserted location 388 information). The ability to replay messages or individual objects 389 the specific property of these messages and objects is important. 390 For example, asserted location information might bind location 391 information and a timestamp with a digital signature together that 392 makes it difficult to reuse this object beyonds its lifetime. 394 [Editor's Note: It is sometimes hard to tell what are real threats 395 and what security threats are addressed already by certain solutions 396 outside the scope of the working group. Addressing all standard 397 security threats is a long process if certain mechanisms are required 398 in an case that largely or completely mitigate against these 399 threats.] 401 4.9 Corrupting Configuration Information 403 An adversary might overide all locally configured emergency numbers. 404 This might be particular problematic if these emergency numbers are 405 dynamically retrieved using some mechanisms. As such, an Emergency 406 Caller would start a call that either leads to a blackhole (as such 407 it is a DoS attack), the Emergency Caller connects to a rogue PSAP or 408 to an inappropriate PSAP. 410 5. Security Requirements 412 [Editor's Note: A few requirements below are already addressed by a 413 number of requirements and solution specific documents today. In 414 order to keep the document short it would be reasonable to focus only 415 on the difficult security threats and requiremens for emergency calls 416 rather than enumerating everything that could happen to an emergency 417 call. The working group should decide how to proceed with this 418 particular issue and what threats and requirements should be 419 elaborated in more detail.] 421 Compiling security requirements to address the threats listed in the 422 previous section might is impacted by several constraints: 424 Security mechanisms may lead to a certain performance overhead 425 (e.g., several roundtrips). 427 A certain security infrastructure is required that might lead to 428 deployment problems. For example, end user certificates, 429 certificates for networks, usage of authorization certificate, 430 etc. might need to be deployed before any of these mechanisms are 431 useful. 433 Many of these aspects are related to regulatory and legal 434 requirements that may vary from country to country. Typically, 435 these mechanisms cannot be mandated by an IETF specification. 437 Some of the requirements impose solutions that are out-of-scope of 438 the ECRIT working group. 440 Given the above-listed constraints the requirements that have to be 441 addressed by work that is done within ECRIT have to be highlighted. 442 Other requirements have to be read as 'if you would like to address 443 this threat, then you might want to consider this requirement' rather 444 than 'any solution must address fulfill this requirement'. 446 5.1 Denial of Service Attacks 448 It is difficult to address all possible denial of service attacks 449 that might lead to disruption of an emergency call since a number of 450 IETF protocols are used in order to provide this functionality. 451 Hence, care must be taken when protocol extensions are developed that 452 the chance for a denial of service attack is not increased. Even 453 without using any security mechanisms (such as authentication and key 454 exchange protocols) some degree of security has to be provided. 456 It is important to understand that the ability to mount DoS attacks 457 must also be considered as part of the architecture work when legal 458 and regulatory requirements are known and need to be fulfilled. 460 5.2 Call Identity Spoofing 462 A standard requirement to prevent identity spoofing is to 463 authenticate the Emergency Caller. Authentication mechanisms that 464 require multiple roundtrips and as such might delay the call are 465 often not desirable or cannot be mandated. 467 5.3 Location Spoofing 469 An Emergency Caller might in many cases know its own location 470 information because it was obtained via civic or geospatial location 471 extensions for DHCP, via manual configuration or via GPS. 472 Unfortunately, information provided by the end host is untrustworthy 473 particularly when it is as important as location information. Two 474 approaches have been discussed in the past that place lead to a few 475 requirements: 477 o Location Information is asserted by the Access Infrastructure 478 Provider. As such, the end host might use GPS but uses a protocol 479 to allow the network to assert the location information. This 480 approach also has its limitations if the coverage area of the 481 wireless network is fairly large. 483 o Location Information is added to the emergency call via an 484 Emergency Call Routing Support entity. Depending on the protocol 485 used for call routing and on the properties of this protocol it 486 might be necessary to return the asserted location information to 487 the end host since intermediate nodes might not be allowed to 488 insert objects into the call setup messages (at least not in all 489 parts of the messages, such as bodies). These signaling entities, 490 in general, do not know the physiscal location of the user. Thus, 491 they have to rely on somebody else to actually provide the 492 location, e.g., the Access Infrastructure Provider. 494 As it can be seen from these two options the main difference is based 495 on the type of protocol that is used in the message communication. 496 This has an impact on the semantic and on the availability of certain 497 attributes (such as identities that are used by these protocols) and 498 on deployment constraints. Based on the observation that the Access 499 Infrastructure Provider is closest to the end host and is therefore 500 the most likely entity that knows something about the physical 501 location of the end host it seems to be reasonable to assume that 502 some entity that asserts the location information is actually 503 available in this particular network. 505 The following requirements need to be provided in order for asserted 506 location information to accomplish its goals: 508 o Location Information MUST be integrity protected to prevent 509 modifications by third parties. 511 o The recipient of the asserted location information object MUST be 512 able to determine the party that asserted the location information 513 in order to verify the assertion. As such, authentication of the 514 asserting party (the entity that created the assertion) MUST be 515 provided. 517 o The asserted location information MUST include a timestamp to 518 limit its validity in order to reduce replay attacks. 520 o The recipient of the asserted location information MUST have a way 521 to verify that the asserting party is indeed authorized to create 522 such an assertion. As such, authentication is insufficient if not 523 further authorization decision can be associated to the 524 authenticated identity. 526 o The recipient of the asserted location information SHOULD have a 527 mechanism to determine the Emergency Caller based on the provided 528 assertion. 530 The last bullet deserves further discussion: If some information 531 about the Emergency Caller identity has to be included then only for 532 the purpose of tracability and this functionality might not of 533 general use since an adversary will always find networks that do not 534 authenticate the user prior to providing network access. 535 Furthermore, the goal of a number of network access authentication 536 protocols is to prevent disclosure of the user identity to entities 537 other than to the user's home network. Note that the term 'user 538 idenity' does not require that this identity directly points to the 539 'real' identity of a user. A court might want to require this 540 identity to be resolved and to determine the user behind this 541 identity. Even if the access network would like to assertain the 542 user's identity as part of the asserted location information it is, 543 in many cases, not even possible for the Access Infrastructure 544 Provider. 546 If the authenticated user identity is not available to the Access 547 Infrastructure Provider then only a few other identities might be 548 useful, such as the IP address or the MAC address. Other identities, 549 such as the Host Identity, might not be available since they are only 550 used by very few protocols. An assertion that indicates the network 551 in combination with the IP and/or MAC address (together with a 552 timestamp) might provide some limited degree of traceability only if 553 the user was authenticated directly to this particular network. 555 Providing the IP address allows some obvious attempts to cheat to be 556 caught. Hence, there is the question whether some identity should be 557 added at all given the potential limitations and the potential small 558 amounts of cut-and-paste attacks. Using end user based 559 authentication in addition to the asserted location information would 560 be helpful (e.g., using end user certificates) but will impose a 561 serious deployment problem. Given the fact that emergency calls must 562 still be allowed even without end user authentication certainly 563 defeats the purpose of these mechanisms. A partical attempt to 564 address some phrank calls is to classify emergency calls based on the 565 availability of the provided attributes. If suspicious information 566 is being provided that may well be wrong then additional verification 567 steps need to be taken. For example, if a report of a large fire on 568 a Manhattan street is received then the PSAP may wait to dispatch 569 until it gets a second person to call in. This approach obviously 570 has some limitations as well. 572 5.4 Impersonating a PSAP 574 The Emergency Caller SHOULD be able to determine conclusively that he 575 has reached an "authorized" or "legitimate" emergency call center. 576 This requirement is meant to address the threat that a rogue, 577 possibly criminal, entity pretends to accept emergency calls and 578 disrupts the emergency infrastructure. Particularly the caching 579 properties of a distributed directy might be expoited. Typically, 580 the following properties are assumed: 582 o The interaction between the directory access client and the 583 directory access server MUST be integrity and replay protected. 585 o The directory access server MUST be provide data origin 586 authentication thereby ensuring that the provided data items are 587 indeed from the claimed source. 589 o The directory server MUST provide information to ensure that it is 590 authoritive for the provided information. 592 Unlike in the PSTN case IP based networks provide a better 593 opportunity to spoof a PSAP since physical access to the cable plant 594 is required in the PSTN case, while this may not true for the IP 595 case. 597 5.5 Signaling Message Modification 599 To protect signaling messages against modifications either individual 600 attributes SHOULD be protected (such as location objects) or the 601 entire signaling message communication SHOULD experience end-to-end 602 protection. This requires integrity and replay protection to be 603 applied. Authentication of the data sender and the data receiver 604 SHOULD be provided to prevent a man-in-the-middle attack. 606 5.6 Replay Attack 608 In order to protect signaling messages (or individual attributes) to 609 be replayed in future protocol sessions integrity and replay 610 protection mechanisms SHOULD be provided. 612 5.7 Loss of confidentiality 614 In order to prevent leakage of information exchanged during the 615 emergency call (both signaling and data traffic) confidentiality 616 protection SHOULD be provided. The mechanisms to accomplish this 617 functionality are typically different for the data traffic and for 618 the signaling messages and various scenarios, such as hop-by-hop, 619 end-to-middle, middle-to-middle and end-to-end security, need to be 620 considered. Particularly the key management aspects for end-to-end 621 security mechansisms imposes a deployment burden and hence need to be 622 critically analysed in order to determine its applicability in the 623 given context. 625 5.8 Modification of the Emergency Call 627 To protect a man-in-the-middle attack to modify or inject data 628 traffic into the communication between the Emergency Caller and the 629 PSAP integrity, replay and data origin authentication SHOULD be 630 provided. Since the signaling messages are used to authenticate the 631 end points and to distribute the required keying material it is 632 necessary that either the key exchange protocol itself and the 633 signaling messages experience appropriate security protection. The 634 term 'appropriate' refers to the given context, the used signaling 635 protocol and the key exchange protocol. 637 Please note that the interactive nature of a voice communication 638 already provides a some degree of protection. However, with the 639 introduction of instant messaging the freshness of the Emergency Call 640 needs to be provided by other means. 642 5.9 Corrupting Configuration Information 644 Devices SHOULD be assured of the correctness of the local emergency 645 numbers that are automatically configured. If we assume a fixed, 646 global emergency service identifier that requires no configuration 647 and only configure local "traditional" emergency numbers, users are 648 not likely to suddenly dial some random number if a rogue 649 configuration server introduces this as an additional emergency 650 number. The ability to override all locally configured emergency 651 number is of more concern. If the Emergency Caller does not use the 652 infrastructure to route the call to the appropriate PSAP then the 653 security of the directory service is of importance for security. 655 6. Security Considerations 657 This document addresses security threats and security requirements. 658 Therefore, security is considered throughout this document. 660 7. References 662 7.1 Normative References 664 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 665 Requirement Levels", March 1997. 667 7.2 Informative References 669 [I-D.schulzrinne-ecrit-requirements] 670 Schulzrinne, H. and R. Marshall, "Requirements for 671 Emergency Context Resolution with Internet Technologies", 672 May 2005. 674 Authors' Addresses 676 Hannes Tschofenig 677 Siemens 678 Otto-Hahn-Ring 6 679 Munich, Bayern 81739 680 Germany 682 Email: Hannes.Tschofenig@siemens.com 684 Henning Schulzrinne 685 Columbia University 686 Department of Computer Science 687 450 Computer Science Building 688 New York, NY 10027 689 USA 691 Phone: +1 212 939 7042 692 Email: schulzrinne@cs.columbia.edu 693 URI: http://www.cs.columbia.edu/~hgs 695 Murugaraj Shanmugam 696 Technische Universitat Hamburg-Harburg 697 Department of Security in Distributed applications 698 Harburger Schlossstrasse 20 699 Hamburg-Harburg 21079 700 Germany 702 Email: murugaraj.shanmugam@tuhh.de 704 Intellectual Property Statement 706 The IETF takes no position regarding the validity or scope of any 707 Intellectual Property Rights or other rights that might be claimed to 708 pertain to the implementation or use of the technology described in 709 this document or the extent to which any license under such rights 710 might or might not be available; nor does it represent that it has 711 made any independent effort to identify any such rights. Information 712 on the procedures with respect to rights in RFC documents can be 713 found in BCP 78 and BCP 79. 715 Copies of IPR disclosures made to the IETF Secretariat and any 716 assurances of licenses to be made available, or the result of an 717 attempt made to obtain a general license or permission for the use of 718 such proprietary rights by implementers or users of this 719 specification can be obtained from the IETF on-line IPR repository at 720 http://www.ietf.org/ipr. 722 The IETF invites any interested party to bring to its attention any 723 copyrights, patents or patent applications, or other proprietary 724 rights that may cover technology that may be required to implement 725 this standard. Please address the information to the IETF at 726 ietf-ipr@ietf.org. 728 Disclaimer of Validity 730 This document and the information contained herein are provided on an 731 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 732 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 733 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 734 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 735 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 736 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 738 Copyright Statement 740 Copyright (C) The Internet Society (2005). This document is subject 741 to the rights, licenses and restrictions contained in BCP 78, and 742 except as set forth therein, the authors retain all their rights. 744 Acknowledgment 746 Funding for the RFC Editor function is currently provided by the 747 Internet Society.