idnits 2.17.00 (12 Aug 2021) /tmp/idnits60006/draft-ietf-ecrit-security-threats-03.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 on line 543. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 520. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 527. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 533. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 12, 2006) is 5791 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) == Unused Reference: 'RFC3552' is defined on line 470, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3693 -- No information found for draft-ecrit-requirements - is the name correct? Summary: 4 errors (**), 0 flaws (~~), 3 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: January 13, 2007 H. Tschofenig 5 Siemens 6 H. Schulzrinne 7 Columbia U. 8 M. Shanmugam 9 Siemens 10 July 12, 2006 12 Security Threats and Requirements for Emergency Call Marking and Mapping 13 draft-ietf-ecrit-security-threats-03.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 January 13, 2007. 40 Copyright Notice 42 Copyright (C) The Internet Society (2006). 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 4. Objectives of Attackers . . . . . . . . . . . . . . . . . . . 6 66 5. Potential Attacks . . . . . . . . . . . . . . . . . . . . . . 7 67 5.1. Attacks Involving the Emergency Identifier . . . . . . . . 7 68 5.2. Attacks Against or Using the Mapping Process . . . . . . . 7 69 5.2.1. Attacks Against the Emergency Response System . . . . 7 70 5.2.2. Attacks To Prevent a Specific Individual From 71 Receiving Aid . . . . . . . . . . . . . . . . . . . . 9 72 5.2.3. Attacks To Gain Information About an Emergency . . . . 9 73 6. Security Requirements Relating To Emergency Marking and 74 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 76 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 77 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 79 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 80 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 82 Intellectual Property and Copyright Statements . . . . . . . . . . 18 84 1. Introduction 86 Legacy telephone network users can summon help for emergency services 87 such as ambulance, fire and police using a well known number (e.g., 88 911 in North America, 112 in Europe). A key factor in the handling 89 of such calls is the ability of the system to determine caller 90 location and to route the call to the appropriate Public Safety 91 Answering Point (PSAP) based on that location. With the introduction 92 of IP-based telephony and multimedia services, support for emergency 93 calling via the Internet also has to be provided. As one of the 94 steps to achieve this, an emergency marker is being defined that can 95 be attached to call signalling to indicate that the call relates to 96 an emergency. In addition, a protocol is being developed to allow a 97 client entity to submit a location and receive a URI pointing to the 98 applicable PSAP for that location. 100 Attacks against the PSTN have taken place for decades. The Internet 101 is seen as an even more hostile environment. Thus it is important to 102 understand the types of attacks that might be mounted against the 103 infrastructure providing emergency services, and to develop security 104 mechanisms to counter those attacks. While this can be a broad 105 topic, the present document restricts itself to attacks on the 106 mapping of locations to PSAP URIs and attacks based on emergency 107 marking. 109 This document is organized as follows: Section 2 describes basic 110 terminology. Section 3 briefly describes how emergency marking and 111 mapping fit within the process of routing emergency calls. Section 4 112 describes some motivations of attackers in the context of emergency 113 calling, Section 5 describes and illustrates the attacks that might 114 be used, and Section 6 lists the security-related requirements that 115 must be met if these attacks are to be mitigated. 117 2. Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119], with the 122 qualification that unless otherwise stated they apply to the design 123 of the mapping protocol, not its implementation or application. 125 The terms call taker, mapping service, emergency caller, emergency 126 identifier, mapping, mapping client, mapping server, mapping 127 protocol, and Public Safety Answering Point (PSAP) are taken from 128 [I-D.ecrit-requirements]. 130 The term "location information" is taken from RFC 3693 [RFC3693]. 132 The term "emergency caller's device" designates the IP host closest 133 to the emergency caller in the signalling path between the emergency 134 caller and the PSAP. Examples include an IP phone running SIP, 135 H.323, or a proprietary signalling protocol, a PC running a soft 136 client, or an analogue terminal adapter or a residential gateway 137 controlled by a softswitch. 139 3. Marking, Mapping, and the Emergency Call Routing Process 141 This memo deals with two topics relating to the routing of emergency 142 calls to their proper destination. The first is the marking of call 143 signalling to enable entities along the signalling path to recognize 144 that a particular signalling message is associated with an emergency 145 call. Signalling containing the emergency identifier may be given 146 priority treatment, special processing, and/or special routing. 148 The first goal of emergency call routing is to ensure that any 149 emergency call is routed to a PSAP. Preferably the call is routed to 150 the PSAP responsible for the caller's location, since misrouting 151 consumes valuable time while the call taker locates and forwards the 152 call to the right PSAP. As described in [I-D.ecrit-requirements], 153 mapping is part of the process of achieving this preferable outcome. 155 In brief, mapping involves a mapping client, a mapping server, and 156 the protocol that passes between them. The protocol allows the 157 client to pass location information to the mapping server and to 158 receive back a URI which can be used to direct call signalling to a 159 PSAP. 161 Since mapping requires location information for input, when and where 162 the location information is acquired imposes constraints upon when 163 mapping can be done and which devices can act as mapping clients. 164 The key distinction in "when" is before the emergency or during the 165 emergency. The key distinction in "where" is at the emergency 166 caller's device or at another device in the signalling path between 167 the emergency caller and the PSAP. The mapping client can be the 168 device that acquires the location information or any device 169 downstream of that point. It is even possible for a PSAP itself to 170 initiate mapping, to determine whether an arriving call should be 171 handled by a call taker at that PSAP or should be proxied to another 172 PSAP. 174 4. Objectives of Attackers 176 Attackers may direct their efforts either against a portion of the 177 emergency response system or against an individual. Attacks against 178 the emergency response system have three possible objectives: 180 o to deny system services to all users in a given area. The 181 motivation may range from thoughtless vandalism, to wide-scale 182 criminality, to terrorism. One interesting variant on this 183 motivation is the case where a victim of a large emergency hopes 184 to gain faster service by blocking others' competing calls for 185 help. 187 o to gain fraudulent use of services, by using an emergency 188 identifier to bypass normal authentication, authorization, and 189 accounting procedures; 191 o to divert emergency responders to non-emergency sites. This memo 192 has not identified any attacks within its intended scope that 193 achieve this objective, so it will not be mentioned further. 195 Attacks against an individual fall into two classes: 197 o attacks to prevent an individual from receiving aid; 199 o attacks to gain information about an emergency that can be applied 200 either against an individual involved in that emergency or to the 201 profit of the attacker. 203 5. Potential Attacks 205 5.1. Attacks Involving the Emergency Identifier 207 The main attack possibility involving the emergency identifier is to 208 use it to bypass normal procedures in order to achieve fraudulent use 209 of services. An attack of this sort is possible only if the 210 following conditions are true: 212 a. The attacker is the emergency caller. 214 b. The call routing system assumes that the emergency caller's 215 device signals the correct PSAP URI for the caller's location. 217 c. The call enters the domain of a service provider, which accepts 218 it without applying normal procedures for authentication and 219 authorization because the signalling carries the emergency 220 identifier. 222 d. The service provider routes it according to the called address 223 (e.g., SIP Request-URI), without verifying that this is the 224 address of a PSAP (noting that a URI by itself does not indicate 225 the nature of the entity it is pointing to). 227 If these conditions are satisfied, the attacker can bypass normal 228 service provider authorization procedures for arbitrary destinations, 229 simply by reprogramming the emergency caller's device to add the 230 emergency identifier to non-emergency call signalling. Most probably 231 in this case, the call signalling will not include any location 232 information, or there could be location information, but it is false. 234 An attacker wishing to disrupt the emergency call routing system may 235 use a similar technique to target components of that system for a 236 denial of service attack. The attacker will find this attractive to 237 reach components that handle emergency calls only. Flooding attacks 238 are the most likely application of the technique, but it may also be 239 used to identify target components for other attacks by analyzing the 240 content of responses to the original signalling messages. 242 5.2. Attacks Against or Using the Mapping Process 244 This section describes classes of attacks involving the mapping 245 process that could be used to achieve the attacker goals described in 246 Section 4. 248 5.2.1. Attacks Against the Emergency Response System 250 This section considers attacks intended to reduce the effectiveness 251 of the emergency response system for all callers in a given area. If 252 the mapping operation is disabled, then the emergency caller's device 253 might not have the correct PSAP URI. As a consequence, the 254 probability that emergency calls are routed to the wrong PSAP is 255 increased. In the worst case the emergency caller's device might not 256 be able to obtain a PSAP URI at all. Routing to the wrong PSAP has a 257 double consequence: emergency response to the affected calls is 258 delayed, and PSAP call taker resources outside the immediate area of 259 the emergency are consumed due to the extra effort required to 260 redirect the calls. Alternatively, attacks that cause the client to 261 receive a URI that does not lead to a PSAP have the immediate effect 262 of causing emergency calls to fail. 264 Three basic attacks on the mapping process can be identified: denial 265 of service, impersonation of the mapping server, or corruption of the 266 mapping database. Denial of service can be achieved in several ways: 268 o by a flooding attack on the mapping server; 270 o by taking control of the mapping server and either preventing it 271 from responding or causing it to send incorrect responses; or 273 o by taking control of a router through which the mapping queries 274 and responses pass and using that control to block them. An 275 adversary may also attempt to modify the mapping protocol 276 signaling messages. Additionally, the adversary may be able to 277 replay past communication exchanges to fool an emergency caller by 278 returning incorrect results. 280 In an impersonation attack, the attacker induces the mapping client 281 to direct its queries to a host under the attacker's control rather 282 than the real mapping server. Impersonation itself is an issue for 283 mapping server discovery rather than for the mapping protocol 284 directly. However, the mapping protocol may allow impersonation to 285 be detected, thereby preventing acceptance of responses from an 286 impersonating entity and possibly triggering a more secure discovery 287 procedure. 289 Corruption of the mapping database cannot be mitigated directly by 290 mapping protocol design. The mapping protocol may have a role to 291 play in analysis of which records have been corrupted, once that 292 corruption has been detected. 294 Beyond these attacks on the mapping operation itself, it is possible 295 to use mapping to attack other entities. One possibility is that 296 mapping clients are misled into sending mapping queries to the target 297 of the attack instead of the mapping server. Prevention of such an 298 attack is an operational issue rather than one of protocol design. 300 The other possible attack is one where the the mapping server is 301 tricked into sending responses to the target of the attack through 302 spoofing of the source address in the query. 304 5.2.2. Attacks To Prevent a Specific Individual From Receiving Aid 306 If an attacker wishes to deny emergency service to a specific 307 individual the mass attacks described in Section 5.2.1 will obviously 308 work provided that the target individual is within the affected 309 population. Except for the flooding attack on the mapping server, 310 the attacker can in theory limit these attacks to the target, but 311 this requires extra effort that the attacker is unlikely to expend. 312 It is more likely, if the attacker is using a mass attack but does 313 not wish it to have too broad an effect, that it is used for a 314 carefully limited period of time. 316 If the attacker wants to be selective, however, it may make more 317 sense to attack the mapping client rather than the mapping server. 318 This is particularly so if the mapping client is the emergency 319 caller's device. The choices available to the attacker are similar 320 to those for denial of service on the server side: 322 o a flooding attack on the mapping client; 324 o taking control of a router through which the mapping queries and 325 responses pass and using that control to block or modify them. 327 Taking control of the mapping client is also a logical possibility, 328 but raises no issues for the mapping protocol. 330 5.2.3. Attacks To Gain Information About an Emergency 332 This section discusses attacks used to gain information about an 333 emergency. The attacker may be seeking the location of the caller 334 (e.g., to effect a criminal attack). Alternatively, the attacker may 335 be seeking information that could be used to link an individual (the 336 caller or someone else involved in the emergency) with embarrassing 337 information related to the emergency (e.g., "Who did the police take 338 away just now?"). Finally, the attacker could be seeking to profit 339 from the emergency, perhaps by offering his or her services (e.g., 340 news reporter, lawyer aggressively seeking new business). 342 The primary information that interceptions of mapping requests and 343 responses will reveal are a location, a URI identifying a PSAP, and 344 the addresses of the mapping client and server. The location 345 information can be directly useful to an attacker if the attacker has 346 high assurance that the observed query is related to an emergency 347 involving the target. The other pieces of information may provide 348 the basis for further attacks on emergency call routing, but because 349 of the time factor, are unlikely to be applicable to the routing of 350 the current call. However, if the mapping client is the emergency 351 caller's device, the attacker may gain information that allows for 352 interference with the call after it has been set up or for 353 interception of the media stream between the caller and the PSAP. 355 6. Security Requirements Relating To Emergency Marking and Mapping 357 This section describes the security requirements which must be 358 fulfilled to prevent or reduce the effectiveness of the attacks 359 described in Section 5. The requirements are presented in the same 360 order as the attacks. 362 From Section 5.1: 364 Attack: fraudulent calls. 366 Requirement: for calls which meet conditions a) to c) of Section 5.1, 367 the service provider's call routing entity MUST verify that the 368 destination address (e.g., SIP Request-URI) presented in the call 369 signalling is that of a PSAP. 371 Attack: use of emergency identifier to probe in order to identify 372 emergency call routing entities. 374 Requirement: topology hiding SHOULD be applied to call signalling 375 returned to the emergency caller, so that the identity of 376 intermediate routing entities is not disclosed. The obvious 377 exception is where these entities are already visible to the caller. 378 Note that there is little point in hiding the PSAP itself. 380 From Section 5.2.1: 382 Attack: flooding attack on the mapping client, mapping server, or a 383 third entity. 385 Requirement: The mapping protocol MUST NOT create new opportunities 386 for flooding attacks, including amplification attacks. 388 Attack: insertion of interfering messages. 390 Requirement: The protocol MUST permit the mapping client to verify 391 that the response it receives is responding to the query it sent out. 393 Attack: man-in-the-middle alteration of messages. 395 Requirement: The protocol or the system within which it is 396 implemented MUST maintain request and response integrity. 398 Attack: impersonation of the mapping server. 400 Requirement: the security considerations for any discussion of 401 mapping server discovery MUST address measures to prevent 402 impersonation of the mapping server. 404 Requirement: the protocol or the system within which it is 405 implemented MUST permit the mapping client to authenticate the source 406 of mapping responses. 408 Attack: corruption of the mapping database. 410 Requirement: the security considerations for the mapping protocol 411 MUST address measures to prevent database corruption by an attacker. 413 Requirement: the protocol SHOULD include information in the response 414 that allows subsequent correlation of that response with internal 415 logs that may be kept on the mapping server, to allow debugging of 416 mis-directed calls. One example of a way to meet this requirement 417 would be by means of an opaque parameter in the returned URI. 419 From Section 5.2.2: no new requirements. 421 From Section 5.2.3: 423 Attack: snooping of location and other information. 425 Requirement: the protocol or the system within which it is 426 implemented MUST maintain confidentiality of the request and 427 response. 429 7. Security Considerations 431 This document addresses security threats and security requirements. 432 Therefore, security is considered throughout this document. 434 8. Acknowledgements 436 The writing of this document has been a task made difficult by the 437 temptation to consider the security concerns of the entire personal 438 emergency calling system, not just the specific pieces of work within 439 the scope of the ECRIT Working Group. Hannes Tschofenig performed 440 the initial security analysis for ECRIT, but it has been shaped since 441 then by the comments and judgement of the ECRIT WG at large. At an 442 earlier stage in the evolution of this document, Stephen Kent of the 443 Security Directorate was asked to review it and provided extensive 444 comments which led to a complete rewriting of it. Brian Rosen, Roger 445 Marshall, Andrew Newton, and most recently, Spencer Dawkins, Kamran 446 Aquil, and Ron Watro have also provided detailed reviews of this 447 document at various stages. The authors thank them. 449 9. IANA Considerations 451 This document does not require actions by the IANA. 453 10. References 455 10.1. Normative References 457 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 458 Requirement Levels", BCP 14, RFC 2119, March 1997. 460 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 461 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 463 10.2. Informative References 465 [I-D.ecrit-requirements] 466 Schulzrinne, H. and R. Marshall, "Requirements for 467 Emergency Context Resolution with Internet Technologies", 468 March 2006. 470 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 471 Text on Security Considerations", BCP 72, RFC 3552, 472 July 2003. 474 Authors' Addresses 476 Tom Taylor 477 Nortel 478 1852 Lorraine Ave 479 Ottawa, Ontario K1H 6Z8 480 Canada 482 Email: taylor@nortel.com 484 Hannes Tschofenig 485 Siemens 486 Otto-Hahn-Ring 6 487 Munich, Bayern 81739 488 Germany 490 Email: Hannes.Tschofenig@siemens.com 492 Henning Schulzrinne 493 Columbia University 494 Department of Computer Science 495 450 Computer Science Building 496 New York, NY 10027 497 USA 499 Phone: +1 212 939 7042 500 Email: schulzrinne@cs.columbia.edu 501 URI: http://www.cs.columbia.edu/~hgs 503 Murugaraj Shanmugam 504 Siemens 505 Otto-Hahn-Ring 6 506 Munich, Bayern 81739 507 Germany 509 Email: murugaraj.shanmugam@siemens.com 511 Intellectual Property Statement 513 The IETF takes no position regarding the validity or scope of any 514 Intellectual Property Rights or other rights that might be claimed to 515 pertain to the implementation or use of the technology described in 516 this document or the extent to which any license under such rights 517 might or might not be available; nor does it represent that it has 518 made any independent effort to identify any such rights. Information 519 on the procedures with respect to rights in RFC documents can be 520 found in BCP 78 and BCP 79. 522 Copies of IPR disclosures made to the IETF Secretariat and any 523 assurances of licenses to be made available, or the result of an 524 attempt made to obtain a general license or permission for the use of 525 such proprietary rights by implementers or users of this 526 specification can be obtained from the IETF on-line IPR repository at 527 http://www.ietf.org/ipr. 529 The IETF invites any interested party to bring to its attention any 530 copyrights, patents or patent applications, or other proprietary 531 rights that may cover technology that may be required to implement 532 this standard. Please address the information to the IETF at 533 ietf-ipr@ietf.org. 535 Disclaimer of Validity 537 This document and the information contained herein are provided on an 538 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 539 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 540 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 541 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 542 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 543 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 545 Copyright Statement 547 Copyright (C) The Internet Society (2006). This document is subject 548 to the rights, licenses and restrictions contained in BCP 78, and 549 except as set forth therein, the authors retain all their rights. 551 Acknowledgment 553 Funding for the RFC Editor function is currently provided by the 554 Internet Society.