idnits 2.17.00 (12 Aug 2021) /tmp/idnits64599/draft-ietf-ecrit-security-threats-04.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 535. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 546. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 553. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 559. 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 (April 16, 2007) is 5514 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-ecrit-requirements - is the name correct? Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT T. Taylor 3 Internet-Draft (Editor) Nortel 4 Expires: October 18, 2007 H. Tschofenig 5 Siemens 6 H. Schulzrinne 7 Columbia U. 8 M. Shanmugam 9 Siemens 10 April 16, 2007 12 Security Threats and Requirements for Emergency Call Marking and Mapping 13 draft-ietf-ecrit-security-threats-04.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 October 18, 2007. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2007). 44 Abstract 46 This document reviews the security threats associated with: 48 o the marking of signalling messages to indicate that they are 49 related to an emergency; and 51 o the process of mapping from locations to Universal Resource 52 Identifiers (URIs) pointing to Public Safety Answering Points 53 (PSAPs). This mapping occurs as part of the process of routing 54 emergency calls through the IP network. 56 Based on the identified threats, this document establishes a set of 57 security requirements for the mapping protocol and for the handling 58 of emergency-marked calls. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Marking, Mapping, and the Emergency Call Routing Process . . . 5 65 3.1. Call Marking . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.2. Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 4. Objectives of Attackers . . . . . . . . . . . . . . . . . . . 6 68 5. Potential Attacks . . . . . . . . . . . . . . . . . . . . . . 7 69 5.1. Attacks Involving the Emergency Identifier . . . . . . . . 7 70 5.2. Attacks Against or Using the Mapping Process . . . . . . . 7 71 5.2.1. Attacks Against the Emergency Response System . . . . 8 72 5.2.2. Attacks To Prevent a Specific Individual From 73 Receiving Aid . . . . . . . . . . . . . . . . . . . . 9 74 5.2.3. Attacks To Gain Information About an Emergency . . . . 9 75 6. Security Requirements Relating To Emergency Marking and 76 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 79 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 81 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 82 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 84 Intellectual Property and Copyright Statements . . . . . . . . . . 18 86 1. Introduction 88 Legacy telephone network users can summon help for emergency services 89 such as ambulance, fire and police using a well known number (e.g., 90 911 in North America, 112 in Europe). A key factor in the handling 91 of such calls is the ability of the system to determine caller 92 location and to route the call to the appropriate Public Safety 93 Answering Point (PSAP) based on that location. With the introduction 94 of IP-based telephony and multimedia services, support for emergency 95 calling via the Internet also has to be provided. As one of the 96 steps to achieve this, an emergency marker is being defined that can 97 be attached to call signalling to indicate that the call relates to 98 an emergency. In addition, a protocol is being developed to allow a 99 client entity to submit a location and receive a URI pointing to the 100 applicable PSAP for that location. 102 Attacks against the PSTN have taken place for decades. The Internet 103 is seen as an even more hostile environment. Thus it is important to 104 understand the types of attacks that might be mounted against the 105 infrastructure providing emergency services, and to develop security 106 mechanisms to counter those attacks. While this can be a broad 107 topic, the present document restricts itself to attacks on the 108 mapping of locations to PSAP URIs and attacks based on emergency 109 marking. 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.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 [I-D.ecrit-requirements], 161 mapping is part of the process of achieving this preferable outcome. 163 In brief, mapping involves a mapping client, a mapping server, and 164 the protocol that passes between them. The protocol allows the 165 client to pass location information to the mapping server and to 166 receive back a URI which can be used to direct call signalling to a 167 PSAP. 169 Since mapping requires location information for input, when and where 170 the location information is acquired imposes constraints upon when 171 mapping can be done and which devices can act as mapping clients. 172 The key distinction in "when" is before the emergency or during the 173 emergency. The key distinction in "where" is at the emergency 174 caller's device or at another device in the signalling path between 175 the emergency caller and the PSAP. The mapping client can be the 176 device that acquires the location information or any device 177 downstream of that point. It is even possible for a PSAP itself to 178 initiate mapping, to determine whether an arriving call should be 179 handled by a call taker at that PSAP or should be proxied to another 180 PSAP. 182 4. Objectives of Attackers 184 Attackers may direct their efforts either against a portion of the 185 emergency response system or against an individual. Attacks against 186 the emergency response system have three possible objectives: 188 o to deny system services to all users in a given area. The 189 motivation may range from thoughtless vandalism, to wide-scale 190 criminality, to terrorism. One interesting variant on this 191 motivation is the case where a victim of a large emergency hopes 192 to gain faster service by blocking others' competing calls for 193 help. 195 o to gain fraudulent use of services, by using an emergency 196 identifier to bypass normal authentication, authorization, and 197 accounting procedures; 199 o to divert emergency responders to non-emergency sites. This memo 200 has not identified any attacks within its intended scope that 201 achieve this objective, so it will not be mentioned further. 203 Attacks against an individual fall into two classes: 205 o attacks to prevent an individual from receiving aid; 207 o attacks to gain information about an emergency that can be applied 208 either against an individual involved in that emergency or to the 209 profit of the attacker. 211 5. Potential Attacks 213 5.1. Attacks Involving the Emergency Identifier 215 The main attack possibility involving the emergency identifier is to 216 use it to bypass normal procedures in order to achieve fraudulent use 217 of services. An attack of this sort is possible only if the 218 following conditions are true: 220 a. The attacker is the emergency caller. 222 b. The call routing system assumes that the emergency caller's 223 device signals the correct PSAP URI for the caller's location. 225 c. The call enters the domain of a service provider, which accepts 226 it without applying normal procedures for authentication and 227 authorization because the signalling carries the emergency 228 identifier. 230 d. The service provider routes it according to the called address 231 (e.g., SIP Request-URI), without verifying that this is the 232 address of a PSAP (noting that a URI by itself does not indicate 233 the nature of the entity it is pointing to). 235 If these conditions are satisfied, the attacker can bypass normal 236 service provider authorization procedures for arbitrary destinations, 237 simply by reprogramming the emergency caller's device to add the 238 emergency identifier to non-emergency call signalling. Most probably 239 in this case, the call signalling will not include any location 240 information, or there could be location information, but it is false. 242 An attacker wishing to disrupt the emergency call routing system may 243 use a similar technique to target components of that system for a 244 denial of service attack. The attacker will find this attractive to 245 reach components that handle emergency calls only. Flooding attacks 246 are the most likely application of the technique, but it may also be 247 used to identify target components for other attacks by analyzing the 248 content of responses to the original signalling messages. 250 5.2. Attacks Against or Using the Mapping Process 252 This section describes classes of attacks involving the mapping 253 process that could be used to achieve the attacker goals described in 254 Section 4. 256 5.2.1. Attacks Against the Emergency Response System 258 This section considers attacks intended to reduce the effectiveness 259 of the emergency response system for all callers in a given area. If 260 the mapping operation is disabled, then the emergency caller's device 261 might not have the correct PSAP URI. As a consequence, the 262 probability that emergency calls are routed to the wrong PSAP is 263 increased. In the worst case the emergency caller's device might not 264 be able to obtain a PSAP URI at all. Routing to the wrong PSAP has a 265 double consequence: emergency response to the affected calls is 266 delayed, and PSAP call taker resources outside the immediate area of 267 the emergency are consumed due to the extra effort required to 268 redirect the calls. Alternatively, attacks that cause the client to 269 receive a URI that does not lead to a PSAP have the immediate effect 270 of causing emergency calls to fail. 272 Three basic attacks on the mapping process can be identified: denial 273 of service, impersonation of the mapping server, or corruption of the 274 mapping database. Denial of service can be achieved in several ways: 276 o by a flooding attack on the mapping server; 278 o by taking control of the mapping server and either preventing it 279 from responding or causing it to send incorrect responses; or 281 o by taking control of any intermediary node (for example, a router) 282 through which the mapping queries and responses pass and using 283 that control to block them. An adversary may also attempt to 284 modify the mapping protocol signaling messages. Additionally, the 285 adversary may be able to replay past communication exchanges to 286 fool an emergency caller by returning incorrect results. 288 In an impersonation attack, the attacker induces the mapping client 289 to direct its queries to a host under the attacker's control rather 290 than the real mapping server or the attacker suppress the response 291 from the real mapping server, and send a spoofed response. 293 The former type of impersonation attack itself is an issue of mapping 294 server discovery rather than for the mapping protocol directly. 295 However, the mapping protocol may allow impersonation to be detected, 296 thereby preventing acceptance of responses from an impersonating 297 entity and possibly triggering a more secure discovery procedure. 299 Corruption of the mapping database cannot be mitigated directly by 300 mapping protocol design. The mapping protocol may have a role to 301 play in analysis of which records have been corrupted, once that 302 corruption has been detected. 304 Beyond these attacks on the mapping operation itself, it is possible 305 to use mapping to attack other entities. One possibility is that 306 mapping clients are misled into sending mapping queries to the target 307 of the attack instead of the mapping server. Prevention of such an 308 attack is an operational issue rather than one of protocol design. 309 Another possible attack is one where the the mapping server is 310 tricked into sending responses to the target of the attack through 311 spoofing of the source address in the query. 313 5.2.2. Attacks To Prevent a Specific Individual From Receiving Aid 315 If an attacker wishes to deny emergency service to a specific 316 individual the mass attacks described in Section 5.2.1 will obviously 317 work provided that the target individual is within the affected 318 population. Except for the flooding attack on the mapping server, 319 the attacker can in theory limit these attacks to the target, but 320 this requires extra effort that the attacker is unlikely to expend. 321 It is more likely, if the attacker is using a mass attack but does 322 not wish it to have too broad an effect, that it is used for a 323 carefully limited period of time. 325 If the attacker wants to be selective, however, it may make more 326 sense to attack the mapping client rather than the mapping server. 327 This is particularly so if the mapping client is the emergency 328 caller's device. The choices available to the attacker are similar 329 to those for denial of service on the server side: 331 o a flooding attack on the mapping client; 333 o taking control of any intermediary node (for example, a router) 334 through which the mapping queries and responses pass and using 335 that control to block or modify them. 337 Taking control of the mapping client is also a logical possibility, 338 but raises no issues for the mapping protocol. 340 5.2.3. Attacks To Gain Information About an Emergency 342 This section discusses attacks used to gain information about an 343 emergency. The attacker may be seeking the location of the caller 344 (e.g., to effect a criminal attack). Alternatively, the attacker may 345 be seeking information that could be used to link an individual (the 346 caller or someone else involved in the emergency) with embarrassing 347 information related to the emergency (e.g., "Who did the police take 348 away just now?"). Finally, the attacker could be seeking to profit 349 from the emergency, perhaps by offering his or her services (e.g., 350 news reporter, lawyer aggressively seeking new business). 352 The primary information that interceptions of mapping requests and 353 responses will reveal are a location, a URI identifying a PSAP, the 354 emergency service identifier, and the addresses of the mapping client 355 and server. The location information can be directly useful to an 356 attacker if the attacker has high assurance that the observed query 357 is related to an emergency involving the target. The type of 358 emergency (fire, police or ambulance) might also be revealed by the 359 emergency service identifier in the mapping query. The other pieces 360 of information may provide the basis for further attacks on emergency 361 call routing, but because of the time factor, are unlikely to be 362 applicable to the routing of the current call. However, if the 363 mapping client is the emergency caller's device, the attacker may 364 gain information that allows for interference with the call after it 365 has been set up or for interception of the media stream between the 366 caller and the PSAP. 368 6. Security Requirements Relating To Emergency Marking and Mapping 370 This section describes the security requirements which must be 371 fulfilled to prevent or reduce the effectiveness of the attacks 372 described in Section 5. The requirements are presented in the same 373 order as the attacks. 375 From Section 5.1: 377 Attack A1: fraudulent calls. 379 Requirement R1: for calls which meet conditions a) to c) of 380 Section 5.1, the service provider's call routing entity MUST verify 381 that the destination address (e.g., SIP Request-URI) presented in the 382 call signalling is that of a PSAP. 384 Attack A2: use of emergency identifier to probe in order to identify 385 emergency call routing entities for attack by other means. 387 Requirement: none identified, beyond the ordinary operational 388 requirement to defend emergency call routing entities by means such 389 as firewalls and, where possible, authentication and authorization. 391 From Section 5.2.1: 393 Attack A3: flooding attack on the mapping client, mapping server, or 394 a third entity. 396 Requirement R2: The mapping protocol MUST NOT create new 397 opportunities for flooding attacks, including amplification attacks. 399 Attack A4: insertion of interfering messages. 401 Requirement R3: The protocol MUST permit the mapping client to verify 402 that the response it receives is responding to the query it sent out. 404 Attack A5: man-in-the-middle modification of messages. 406 Requirement R4: The mapping protocol MUST provide integrity 407 protection of requests and responses. 409 Requirement R5: The mapping protocol or the system within which the 410 protocol is implemented MUST permit the mapping client to 411 authenticate the source of mapping responses. 413 Attack A6: impersonation of the mapping server. 415 Requirement R6: the security considerations for any discussion of 416 mapping server discovery MUST address measures to prevent 417 impersonation of the mapping server. 419 Requirement R5 also follows from this attack. 421 Attack A7: corruption of the mapping database. 423 Requirement R7: the security considerations for the mapping protocol 424 MUST address measures to prevent database corruption by an attacker. 426 Requirement R8: the protocol SHOULD include information in the 427 response that allows subsequent correlation of that response with 428 internal logs that may be kept on the mapping server, to allow 429 debugging of mis-directed calls. One example of a way to meet this 430 requirement would be by means of an opaque parameter in the returned 431 URI. 433 From Section 5.2.2: no new requirements. 435 From Section 5.2.3: 437 Attack A8: snooping of location and other information. 439 Requirement R9: the protocol or the system within which it is 440 implemented MUST maintain confidentiality of the request and 441 response. 443 7. Security Considerations 445 This document addresses security threats and security requirements. 446 Therefore, security is considered throughout this document. 448 8. IANA Considerations 450 This document does not require actions by the IANA. 452 9. Acknowledgements 454 The writing of this document has been a task made difficult by the 455 temptation to consider the security concerns of the entire personal 456 emergency calling system, not just the specific pieces of work within 457 the scope of the ECRIT Working Group. Hannes Tschofenig performed 458 the initial security analysis for ECRIT, but it has been shaped since 459 then by the comments and judgement of the ECRIT WG at large. At an 460 earlier stage in the evolution of this document, Stephen Kent of the 461 Security Directorate was asked to review it and provided extensive 462 comments which led to a complete rewriting of it. Brian Rosen, Roger 463 Marshall, Andrew Newton, and most recently, Spencer Dawkins, Kamran 464 Aquil, and Ron Watro have also provided detailed reviews of this 465 document at various stages. The authors thank them. 467 10. References 469 10.1. Normative References 471 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 472 Requirement Levels", BCP 14, RFC 2119, March 1997. 474 10.2. Informative References 476 [I-D.ecrit-requirements] 477 Schulzrinne, H. and R. Marshall, "Requirements for 478 Emergency Context Resolution with Internet Technologies", 479 March 2006. 481 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 482 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 484 Authors' Addresses 486 Tom Taylor 487 Nortel 488 1852 Lorraine Ave 489 Ottawa, Ontario K1H 6Z8 490 Canada 492 Email: taylor@nortel.com 494 Hannes Tschofenig 495 Siemens 496 Otto-Hahn-Ring 6 497 Munich, Bayern 81739 498 Germany 500 Email: Hannes.Tschofenig@siemens.com 502 Henning Schulzrinne 503 Columbia University 504 Department of Computer Science 505 450 Computer Science Building 506 New York, NY 10027 507 USA 509 Phone: +1 212 939 7042 510 Email: schulzrinne@cs.columbia.edu 511 URI: http://www.cs.columbia.edu/~hgs 513 Murugaraj Shanmugam 514 Siemens 515 Otto-Hahn-Ring 6 516 Munich, Bayern 81739 517 Germany 519 Email: murugaraj.shanmugam@siemens.com 521 Full Copyright Statement 523 Copyright (C) The IETF Trust (2007). 525 This document is subject to the rights, licenses and restrictions 526 contained in BCP 78, and except as set forth therein, the authors 527 retain all their rights. 529 This document and the information contained herein are provided on an 530 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 531 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 532 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 533 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 534 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 535 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 537 Intellectual Property 539 The IETF takes no position regarding the validity or scope of any 540 Intellectual Property Rights or other rights that might be claimed to 541 pertain to the implementation or use of the technology described in 542 this document or the extent to which any license under such rights 543 might or might not be available; nor does it represent that it has 544 made any independent effort to identify any such rights. Information 545 on the procedures with respect to rights in RFC documents can be 546 found in BCP 78 and BCP 79. 548 Copies of IPR disclosures made to the IETF Secretariat and any 549 assurances of licenses to be made available, or the result of an 550 attempt made to obtain a general license or permission for the use of 551 such proprietary rights by implementers or users of this 552 specification can be obtained from the IETF on-line IPR repository at 553 http://www.ietf.org/ipr. 555 The IETF invites any interested party to bring to its attention any 556 copyrights, patents or patent applications, or other proprietary 557 rights that may cover technology that may be required to implement 558 this standard. Please address the information to the IETF at 559 ietf-ipr@ietf.org. 561 Acknowledgment 563 Funding for the RFC Editor function is provided by the IETF 564 Administrative Support Activity (IASA).