idnits 2.17.1 draft-ietf-ecrit-security-threats-05.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 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 547. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 558. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 565. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 571. 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 IETF Trust 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 (August 21, 2007) is 6085 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 issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT T. Taylor, Ed. 3 Internet-Draft Nortel 4 Expires: February 22, 2008 H. Tschofenig 5 Nokia Siemens Networks 6 H. Schulzrinne 7 Columbia University 8 M. Shanmugam 9 Detecon 10 August 21, 2007 12 Security Threats and Requirements for Emergency Call Marking and Mapping 13 draft-ietf-ecrit-security-threats-05.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on February 22, 2008. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2007). 44 Abstract 46 This document reviews the security threats associated with the 47 marking of signalling messages to indicate that they are related to 48 an emergency, and the process of mapping from locations to Universal 49 Resource Identifiers (URIs) pointing to Public Safety Answering 50 Points (PSAPs). This mapping occurs as part of the process of 51 routing emergency calls through the IP network. 53 Based on the identified threats, this document establishes a set of 54 security requirements for the mapping protocol and for the handling 55 of emergency-marked calls. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Marking, Mapping, and the Emergency Call Routing Process . . . 5 62 3.1. Call Marking . . . . . . . . . . . . . . . . . . . . . . . 5 63 3.2. Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 4. Objectives of Attackers . . . . . . . . . . . . . . . . . . . 6 65 5. Potential Attacks . . . . . . . . . . . . . . . . . . . . . . 7 66 5.1. Attacks Involving the Emergency Identifier . . . . . . . . 7 67 5.2. Attacks Against or Using the Mapping Process . . . . . . . 7 68 5.2.1. Attacks Against the Emergency Response System . . . . 8 69 5.2.2. Attacks To Prevent a Specific Individual From 70 Receiving Aid . . . . . . . . . . . . . . . . . . . . 9 71 5.2.3. Attacks To Gain Information About an Emergency . . . . 9 72 6. Security Requirements Relating To Emergency Marking and 73 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 75 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 76 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 78 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 79 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 81 Intellectual Property and Copyright Statements . . . . . . . . . . 18 83 1. Introduction 85 Legacy telephone network users can summon help for emergency services 86 such as ambulance, fire and police using a well known number (e.g., 87 911 in North America, 112 in Europe). A key factor in the handling 88 of such calls is the ability of the system to determine caller 89 location and to route the call to the appropriate Public Safety 90 Answering Point (PSAP) based on that location. With the introduction 91 of IP-based telephony and multimedia services, support for emergency 92 calling via the Internet also has to be provided. As one of the 93 steps to achieve this, an emergency marker is being defined that can 94 be attached to call signalling to indicate that the call relates to 95 an emergency. In addition, a protocol is being developed to allow a 96 client entity to submit a location and receive a URI pointing to the 97 applicable PSAP for that location. 99 Attacks against the PSTN have taken place for decades. The Internet 100 is seen as an even more hostile environment. Thus it is important to 101 understand the types of attacks that might be mounted against the 102 infrastructure providing emergency services, and to develop security 103 mechanisms to counter those attacks. While this can be a broad 104 topic, the present document restricts itself to attacks on the 105 mapping of locations to PSAP URIs and attacks based on emergency 106 marking. Verification of the truthfulness of a reported incident by 107 the PSAP operator and various other attacks against the PSAP 108 infrastructure related to the usage of faked location information are 109 outside the scope of the document. 111 This document is organized as follows: Section 2 describes basic 112 terminology. Section 3 briefly describes how emergency marking and 113 mapping fit within the process of routing emergency calls. Section 4 114 describes some motivations of attackers in the context of emergency 115 calling, Section 5 describes and illustrates the attacks that might 116 be used, and Section 6 lists the security-related requirements that 117 must be met if these attacks are to be mitigated. 119 2. Terminology 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in [RFC2119], with the 124 qualification that unless otherwise stated they apply to the design 125 of the mapping protocol, not its implementation or application. 127 The terms call taker, mapping service, emergency caller, emergency 128 identifier, mapping, mapping client, mapping server, mapping 129 protocol, and Public Safety Answering Point (PSAP) are taken from 130 [I-D.ietf-ecrit-requirements]. 132 The term "location information" is taken from RFC 3693 [RFC3693]. 134 The term "emergency caller's device" designates the IP host closest 135 to the emergency caller in the signalling path between the emergency 136 caller and the PSAP. Examples include an IP phone running SIP, 137 H.323, or a proprietary signalling protocol, a PC running a soft 138 client, or an analogue terminal adapter or a residential gateway 139 controlled by a softswitch. 141 3. Marking, Mapping, and the Emergency Call Routing Process 143 This memo deals with two topics relating to the routing of emergency 144 calls to their proper destination: call marking and mapping. 146 3.1. Call Marking 148 Marking of call signalling enables entities along the signalling path 149 to recognize that a particular signalling message is associated with 150 an emergency call. Signalling containing the emergency identifier 151 may be given priority treatment, special processing, and/or special 152 routing. 154 3.2. Mapping 156 An important goal of emergency call routing is to ensure that any 157 emergency call is routed to a PSAP. Preferably the call is routed to 158 the PSAP responsible for the caller's location, since misrouting 159 consumes valuable time while the call taker locates and forwards the 160 call to the right PSAP. As described in 161 [I-D.ietf-ecrit-requirements], mapping is part of the process of 162 achieving this preferable outcome. 164 In brief, mapping involves a mapping client, a mapping server, and 165 the protocol that passes between them. The protocol allows the 166 client to pass location information to the mapping server and to 167 receive back a URI which can be used to direct call signalling to a 168 PSAP. 170 Since mapping requires location information for input, when and where 171 the location information is acquired imposes constraints upon when 172 mapping can be done and which devices can act as mapping clients. 173 The key distinction in "when" is before the emergency or during the 174 emergency. The key distinction in "where" is at the emergency 175 caller's device or at another device in the signalling path between 176 the emergency caller and the PSAP. The mapping client can be the 177 device that acquires the location information or any device 178 downstream of that point. It is even possible for a PSAP itself to 179 initiate mapping, to determine whether an arriving call should be 180 handled by a call taker at that PSAP or should be proxied to another 181 PSAP. 183 4. Objectives of Attackers 185 Attackers may direct their efforts either against a portion of the 186 emergency response system or against an individual. Attacks against 187 the emergency response system have three possible objectives: 189 o to deny system services to all users in a given area. The 190 motivation may range from thoughtless vandalism, to wide-scale 191 criminality, to terrorism. One interesting variant on this 192 motivation is the case where a victim of a large emergency hopes 193 to gain faster service by blocking others' competing calls for 194 help. 196 o to gain fraudulent use of services, by using an emergency 197 identifier to bypass normal authentication, authorization, and 198 accounting procedures; 200 o to divert emergency calls to non-emergency sites. This is a form 201 of denial of service attack similar to the first item but quite 202 likely more confusing for the caller itself since it expects to 203 talk to a PSAP operator but instead gets connected to someone 204 else. 206 Attacks against an individual fall into two classes: 208 o attacks to prevent an individual from receiving aid; 210 o attacks to gain information about an emergency that can be applied 211 either against an individual involved in that emergency or to the 212 profit of the attacker. 214 5. Potential Attacks 216 5.1. Attacks Involving the Emergency Identifier 218 The main attack possibility involving the emergency identifier is to 219 use it to bypass normal procedures in order to achieve fraudulent use 220 of services. An attack of this sort is possible only if the 221 following conditions are true: 223 a. The attacker is the emergency caller. 225 b. The call routing system assumes that the emergency caller's 226 device signals the correct PSAP URI for the caller's location. 228 c. The call enters the domain of a service provider, which accepts 229 it without applying normal procedures for authentication and 230 authorization because the signalling carries the emergency 231 identifier. 233 d. The service provider routes it according to the called address 234 (e.g., SIP Request-URI), without verifying that this is the 235 address of a PSAP (noting that a URI by itself does not indicate 236 the nature of the entity it is pointing to). 238 If these conditions are satisfied, the attacker can bypass normal 239 service provider authorization procedures for arbitrary destinations, 240 simply by reprogramming the emergency caller's device to add the 241 emergency identifier to non-emergency call signalling. Most probably 242 in this case, the call signalling will not include any location 243 information, or there could be location information, but it is false. 245 An attacker wishing to disrupt the emergency call routing system may 246 use a similar technique to target components of that system for a 247 denial of service attack. The attacker will find this attractive to 248 reach components that handle emergency calls only. Flooding attacks 249 are the most likely application of the technique, but it may also be 250 used to identify target components for other attacks by analyzing the 251 content of responses to the original signalling messages. 253 5.2. Attacks Against or Using the Mapping Process 255 This section describes classes of attacks involving the mapping 256 process that could be used to achieve the attacker goals described in 257 Section 4. 259 5.2.1. Attacks Against the Emergency Response System 261 This section considers attacks intended to reduce the effectiveness 262 of the emergency response system for all callers in a given area. If 263 the mapping operation is disabled, then the emergency caller's device 264 might not have the correct PSAP URI. As a consequence, the 265 probability that emergency calls are routed to the wrong PSAP is 266 increased. In the worst case the emergency caller's device might not 267 be able to obtain a PSAP URI at all. Routing to the wrong PSAP has a 268 double consequence: emergency response to the affected calls is 269 delayed, and PSAP call taker resources outside the immediate area of 270 the emergency are consumed due to the extra effort required to 271 redirect the calls. Alternatively, attacks that cause the client to 272 receive a URI that does not lead to a PSAP have the immediate effect 273 of causing emergency calls to fail. 275 Three basic attacks on the mapping process can be identified: denial 276 of service, impersonation of the mapping server, or corruption of the 277 mapping database. Denial of service can be achieved in several ways: 279 o by a flooding attack on the mapping server; 281 o by taking control of the mapping server and either preventing it 282 from responding or causing it to send incorrect responses; or 284 o by taking control of any intermediary node (for example, a router) 285 through which the mapping queries and responses pass and using 286 that control to block them. An adversary may also attempt to 287 modify the mapping protocol signaling messages. Additionally, the 288 adversary may be able to replay past communication exchanges to 289 fool an emergency caller by returning incorrect results. 291 In an impersonation attack, the attacker induces the mapping client 292 to direct its queries to a host under the attacker's control rather 293 than the real mapping server or the attacker suppress the response 294 from the real mapping server, and send a spoofed response. 296 The former type of impersonation attack itself is an issue of mapping 297 server discovery rather than for the mapping protocol directly. 298 However, the mapping protocol may allow impersonation to be detected, 299 thereby preventing acceptance of responses from an impersonating 300 entity and possibly triggering a more secure discovery procedure. 302 Corruption of the mapping database cannot be mitigated directly by 303 mapping protocol design. The mapping protocol may have a role to 304 play in analysis of which records have been corrupted, once that 305 corruption has been detected. 307 Beyond these attacks on the mapping operation itself, it is possible 308 to use mapping to attack other entities. One possibility is that 309 mapping clients are misled into sending mapping queries to the target 310 of the attack instead of the mapping server. Prevention of such an 311 attack is an operational issue rather than one of protocol design. 312 Another possible attack is one where the the mapping server is 313 tricked into sending responses to the target of the attack through 314 spoofing of the source address in the query. 316 5.2.2. Attacks To Prevent a Specific Individual From Receiving Aid 318 If an attacker wishes to deny emergency service to a specific 319 individual the mass attacks described in Section 5.2.1 will obviously 320 work provided that the target individual is within the affected 321 population. Except for the flooding attack on the mapping server, 322 the attacker can in theory limit these attacks to the target, but 323 this requires extra effort that the attacker is unlikely to expend. 324 It is more likely, if the attacker is using a mass attack but does 325 not wish it to have too broad an effect, that it is used for a 326 carefully limited period of time. 328 If the attacker wants to be selective, however, it may make more 329 sense to attack the mapping client rather than the mapping server. 330 This is particularly so if the mapping client is the emergency 331 caller's device. The choices available to the attacker are similar 332 to those for denial of service on the server side: 334 o a flooding attack on the mapping client; 336 o taking control of any intermediary node (for example, a router) 337 through which the mapping queries and responses pass and using 338 that control to block or modify them. 340 Taking control of the mapping client is also a logical possibility, 341 but raises no issues for the mapping protocol. 343 5.2.3. Attacks To Gain Information About an Emergency 345 This section discusses attacks used to gain information about an 346 emergency. The attacker may be seeking the location of the caller 347 (e.g., to effect a criminal attack). Alternatively, the attacker may 348 be seeking information that could be used to link an individual (the 349 caller or someone else involved in the emergency) with embarrassing 350 information related to the emergency (e.g., "Who did the police take 351 away just now?"). Finally, the attacker could be seeking to profit 352 from the emergency, perhaps by offering his or her services (e.g., 353 news reporter, lawyer aggressively seeking new business). 355 The primary information that interceptions of mapping requests and 356 responses will reveal are a location, a URI identifying a PSAP, the 357 emergency service identifier, and the addresses of the mapping client 358 and server. The location information can be directly useful to an 359 attacker if the attacker has high assurance that the observed query 360 is related to an emergency involving the target. The type of 361 emergency (fire, police or ambulance) might also be revealed by the 362 emergency service identifier in the mapping query. The other pieces 363 of information may provide the basis for further attacks on emergency 364 call routing, but because of the time factor, are unlikely to be 365 applicable to the routing of the current call. However, if the 366 mapping client is the emergency caller's device, the attacker may 367 gain information that allows for interference with the call after it 368 has been set up or for interception of the media stream between the 369 caller and the PSAP. 371 6. Security Requirements Relating To Emergency Marking and Mapping 373 This section describes the security requirements which must be 374 fulfilled to prevent or reduce the effectiveness of the attacks 375 described in Section 5. The requirements are presented in the same 376 order as the attacks. 378 From Section 5.1: 380 Attack A1: fraudulent calls. 382 Requirement R1: for calls which meet conditions a) to c) of 383 Section 5.1, the service provider's call routing entity MUST verify 384 that the destination address (e.g., SIP Request-URI) presented in the 385 call signalling is that of a PSAP. 387 Attack A2: use of emergency identifier to probe in order to identify 388 emergency call routing entities for attack by other means. 390 Requirement: none identified, beyond the ordinary operational 391 requirement to defend emergency call routing entities by means such 392 as firewalls and, where possible, authentication and authorization. 394 From Section 5.2.1: 396 Attack A3: flooding attack on the mapping client, mapping server, or 397 a third entity. 399 Requirement R2: The mapping protocol MUST NOT create new 400 opportunities for flooding attacks, including amplification attacks. 402 Attack A4: insertion of interfering messages. 404 Requirement R3: The protocol MUST permit the mapping client to verify 405 that the response it receives is responding to the query it sent out. 407 Attack A5: man-in-the-middle modification of messages. 409 Requirement R4: The mapping protocol MUST provide integrity 410 protection of requests and responses. 412 Requirement R5: The mapping protocol or the system within which the 413 protocol is implemented MUST permit the mapping client to 414 authenticate the source of mapping responses. 416 Attack A6: impersonation of the mapping server. 418 Requirement R6: the security considerations for any discussion of 419 mapping server discovery MUST address measures to prevent 420 impersonation of the mapping server. 422 Requirement R5 also follows from this attack. 424 Attack A7: corruption of the mapping database. 426 Requirement R7: the security considerations for the mapping protocol 427 MUST address measures to prevent database corruption by an attacker. 429 Requirement R8: the protocol SHOULD include information in the 430 response that allows subsequent correlation of that response with 431 internal logs that may be kept on the mapping server, to allow 432 debugging of mis-directed calls. One example of a way to meet this 433 requirement would be by means of an opaque parameter in the returned 434 URI. 436 From Section 5.2.2: no new requirements. 438 From Section 5.2.3: 440 Attack A8: snooping of location and other information. 442 Requirement R9: the protocol and the system within which it is 443 implemented MUST maintain confidentiality of the request and 444 response. 446 7. Security Considerations 448 This document addresses security threats and security requirements. 449 Therefore, security is considered throughout this document. 451 8. IANA Considerations 453 This document does not require actions by the IANA. 455 9. Acknowledgements 457 The writing of this document has been a task made difficult by the 458 temptation to consider the security concerns of the entire personal 459 emergency calling system, not just the specific pieces of work within 460 the scope of the ECRIT Working Group. Hannes Tschofenig performed 461 the initial security analysis for ECRIT, but it has been shaped since 462 then by the comments and judgement of the ECRIT WG at large. At an 463 earlier stage in the evolution of this document, Stephen Kent of the 464 Security Directorate was asked to review it and provided extensive 465 comments which led to a complete rewriting of it. Brian Rosen, Roger 466 Marshall, Andrew Newton, and most recently, Spencer Dawkins, Kamran 467 Aquil, and Ron Watro have also provided detailed reviews of this 468 document at various stages. The authors thank them. 470 We would like to thank the Donald Eastlake for his review on behalf 471 of the Security Area Directorate and Christian Vogt for his review as 472 part of the General Area Review Team. 474 Finally, we would like to think Jari Arkko, Jon Peterson, and Russ 475 Housley for their IETF Last Call comments. 477 10. References 479 10.1. Normative References 481 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 482 Requirement Levels", BCP 14, RFC 2119, March 1997. 484 10.2. Informative References 486 [I-D.ietf-ecrit-requirements] 487 Schulzrinne, H. and R. Marshall, "Requirements for 488 Emergency Context Resolution with Internet Technologies", 489 draft-ietf-ecrit-requirements-13 (work in progress), 490 March 2007. 492 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 493 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 495 Authors' Addresses 497 Tom Taylor (editor) 498 Nortel 499 1852 Lorraine Ave 500 Ottawa, Ontario K1H 6Z8 501 Canada 503 Email: tom.taylor@rogers.com 505 Hannes Tschofenig 506 Nokia Siemens Networks 507 Otto-Hahn-Ring 6 508 Munich, Bavaria 81739 509 Germany 511 Email: Hannes.Tschofenig@nsn.com 512 URI: http://www.tschofenig.com 514 Henning Schulzrinne 515 Columbia University 516 Department of Computer Science 517 450 Computer Science Building 518 New York, NY 10027 519 US 521 Phone: +1 212 939 7004 522 Email: hgs+ecrit@cs.columbia.edu 523 URI: http://www.cs.columbia.edu 525 Murugaraj Shanmugam 526 Detecon International GmbH 527 Oberkasseler str 2 528 Bonn, NRW 53227 529 Germany 531 Email: murugaraj.shanmugam@detecon.com 533 Full Copyright Statement 535 Copyright (C) The IETF Trust (2007). 537 This document is subject to the rights, licenses and restrictions 538 contained in BCP 78, and except as set forth therein, the authors 539 retain all their rights. 541 This document and the information contained herein are provided on an 542 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 543 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 544 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 545 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 546 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 547 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 549 Intellectual Property 551 The IETF takes no position regarding the validity or scope of any 552 Intellectual Property Rights or other rights that might be claimed to 553 pertain to the implementation or use of the technology described in 554 this document or the extent to which any license under such rights 555 might or might not be available; nor does it represent that it has 556 made any independent effort to identify any such rights. Information 557 on the procedures with respect to rights in RFC documents can be 558 found in BCP 78 and BCP 79. 560 Copies of IPR disclosures made to the IETF Secretariat and any 561 assurances of licenses to be made available, or the result of an 562 attempt made to obtain a general license or permission for the use of 563 such proprietary rights by implementers or users of this 564 specification can be obtained from the IETF on-line IPR repository at 565 http://www.ietf.org/ipr. 567 The IETF invites any interested party to bring to its attention any 568 copyrights, patents or patent applications, or other proprietary 569 rights that may cover technology that may be required to implement 570 this standard. Please address the information to the IETF at 571 ietf-ipr@ietf.org. 573 Acknowledgment 575 Funding for the RFC Editor function is provided by the IETF 576 Administrative Support Activity (IASA).