idnits 2.17.1 draft-ietf-nsis-threats-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 (February 2004) is 7375 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) == Missing Reference: 'Midcom' is mentioned on line 623, but not defined == Missing Reference: 'RFC3812' is mentioned on line 696, but not defined == Unused Reference: 'RFC3182' is defined on line 1011, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Brun03' Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NSIS 3 Internet Draft H. Tschofenig 4 D. Kroeselberg 5 Siemens 6 Document: 7 draft-ietf-nsis-threats-04.txt 8 Expires: August 2004 February 2004 10 Security Threats for NSIS 11 13 Status of this Memo 15 This document is an Internet-Draft and is subject to all provisions 16 of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 Abstract 36 This threats document provides a detailed analysis of the security 37 threats relevant for the NSIS protocol. It calls attention to and 38 helps with understanding of various security considerations in the 39 NSIS Requirements, Framework, and Protocol proposals. This document 40 does not describe vulnerabilities of specific NSIS protocols. 42 Table of Contents 44 1. Introduction..................................................2 45 2. Relevant Communications Models................................3 46 2.1 First-Peer Communications.................................5 47 2.2 End-to-Middle Communications..............................6 48 2.3 Intra-Domain Communications...............................6 49 2.4 Inter-Domain Communications...............................6 50 2.5 End-to-End Communications.................................7 51 2.6 Middle-to-Middle Communications...........................8 52 3. Generic Threats...............................................8 53 3.1 Man-in-the-Middle Attacks.................................8 54 3.2 Replay of Signaling Messages.............................10 55 3.3 Injecting or Modifying Messages..........................11 56 3.4 Insecure Parameter Exchange and Negotiation..............11 57 4. NSIS-Specific Threat Scenarios...............................11 58 4.1 NSIS SA Usage............................................12 59 4.2 Combining Signaling and SA Establishment.................12 60 4.3 Eavesdropping and Traffic Analysis.......................13 61 4.4 Identity Spoofing........................................13 62 4.5 Unprotected Authorization Information....................15 63 4.6 Missing Non-Repudiation..................................16 64 4.7 Malicious NSIS Entity....................................17 65 4.8 Denial of Service Attacks................................17 66 4.9 Disclosing the Network Topology..........................18 67 4.10 Unprotected Session or Reservation Ownership............19 68 4.11 Attacks against the Transport Mechanism.................20 69 5. Security Considerations......................................21 70 6. Normative References.........................................21 71 7. Informative References.......................................22 72 Author's Addresses..............................................23 73 Full Copyright Statement........................................23 75 1. Introduction 77 Whenever a new protocol has to be developed or existing protocols 78 have to be modified, threats to their security should be evaluated. 79 The process of securing protocols is broken down into discrete 80 steps. To address security in the NSIS working group, a number of 81 steps have been taken: 83 - NSIS Analysis Activities (e.g., RSVP Security Properties) 84 - Security Threats for NSIS 85 - NSIS Requirements 86 - NSIS Framework 87 - NSIS Protocol Proposals 88 This document identifies the basic security threats that need to be 89 addressed during the NSIS signaling protocol design. This document 90 cannot provide detailed threats for all possible NSIS NSLPs. QoS, 91 NAT/Firewall and other NSLPs documents need to provide a description 92 of their trust models and a threat description for their specific 93 application domain. In addition, although the base protocol might be 94 secure, certain extensions may cause problems when used in a 95 particular environment. Furthermore, it is necessary to investigate 96 the context in which a signaling protocol is used and the 97 architecture into which it is integrated. As an example of such 98 interaction, accounting and charging are taken into account in this 99 document, because without an appropriate integration of the two, it 100 is difficult to deploy any NSIS solution. This interaction is also a 101 subject of discussion within the NSIS Framework. 103 We use the NSIS terms defined in [Brun03]. 105 2. Relevant Communications Models 107 Signaling messages traverse different parts of a network, demand 108 different security protection, and raise different security 109 problems. The different needs for security protection are mainly due 110 to the fact that NSIS signaling messages cross trust boundaries into 111 domains where different trust relationships exist. Often, one may 112 describe this by categorizing communications as first-peer, last- 113 peer, intra-domain, or inter-domain (see Figure 1). 115 The main properties of the parts of a network listed here are 116 briefly described in this section, and the threats against them in 117 Sections 3 and 4 are classified as generic and NSIS specific. Figure 118 1 depicts a typical end-to-end communication scenario including 119 access parts between the NSIS end-entities and their nearest NSIS 120 hops. This "first-peer communications" commonly comes with specific 121 security requirements (as described below) that are especially 122 important for properly addressing security in mobile scenarios. 123 Differences in the trust relationship and the required security for 124 first-peer communication, compared with other parts of the signaling 125 path, might exist. 127 To refine the above differentiation based on the network parts that 128 NSIS signaling may traverse, we consider trust relationships between 129 different network parts. 131 Additional threats may apply to NSIS communications in which one 132 entity involved is an end-entity (Initiator or Responder) and the 133 other entity is any intermediate hop except the immediately adjacent 134 peer. This is typically called the end-to-middle scenario (see 135 Figure 2 for a description of relevant trust relations). 137 +------------------+ +---------------+ +------------------+ 138 | | | | | | 139 | Administrative | | Intermediate | | Administrative | 140 | Domain A | | Domains | | Domain B | 141 | | | | | | 142 | (Inter-domain Communication) | 143 | +---------+---+---------------+---+---------+ | 144 | (Intra-domain | | | | (Intra-domain | 145 | Communication) | | | | Communication) | 146 | | | | | | | | 147 | | | | | | | | 148 +--------+---------+ +---------------+ +---------+--------+ 149 ^ v 150 | | 151 First Peer Communication Last Peer Communication 152 | | 153 +-----+-----+ +-----+-----+ 154 | NSIS | | NSIS | 155 | Initiator | | Responder | 156 +-----------+ +-----------+ 158 Figure 1: NSIS Network Parts 160 The motivation for including this scenario stems, for example, from 161 the SIP [RFC3261] protocol. To counter a number of specific security 162 threats, any intermediate SIP hop may request a SIP end-entity (UA) 163 to authenticate. Such functionality seems generally useful for 164 intermediaries at the borders of trust domains that signaling 165 messages need to traverse. 167 Intermediate NSIS hops may have to deal as well with specific 168 security threats not (directly) involving any end-entities. This 169 scenario is called middle-to-middle. A typical example of middle-to- 170 middle communication is between two NSIS hops at the borders of 171 their respective trust domains (i.e., inter-domain communications). 172 NSIS messages may have to traverse one or more untrusted hops 173 between these NSIS entities. 175 Figure 2 illustrates these additional scenarios. The first-peer and 176 last-peer cases discussed above are covered by the peer-to-peer 177 trust relationships between end-entity and closest hop. 179 **************************************** 180 * * 181 +----+-----+ +----------+ +----+-----+ 182 +-----+ NSIS +-------+ NSIS +--------+ NSIS +-----+ 183 | | Node 1 | | Node 2 | | Node 3 | | 184 | +----------+ +----+-----+ +----------+ | 185 | ~ | 186 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 187 | ~ | 188 +--+--+-----+ +---------+-+ 189 | NSIS +//////////////////////////////////////////+ NSIS | 190 | Initiator | | Responder | 191 +-----------+ +-----------+ 193 Legend: 194 -----: Peer-to-Peer Trust Relationship 195 /////: End-to-End Trust Relationship 196 *****: Middle-to-Middle Trust Relationship 197 ~~~~~: End-to-Middle Trust Relationship 199 Figure 2: NSIS Trust Relationships 201 2.1 First-Peer Communications 203 First-peer communications refers to the peer-to-peer interaction 204 between a signaling message originator, the NSIS Initiator (NI), and 205 the first NSIS-aware entity along the path. Making assumptions about 206 the threats, security requirements, and available trust 207 relationships may be difficult here. 209 To illustrate this, in public mobile environments it is difficult to 210 assume the existence of a pre-established security association 211 directly available for NSIS peers involved in first-peer 212 communications, because these peers cannot be assumed to have any 213 pre-existing relationship between each other. For enterprise 214 networks, in contrast, the situation is different. Usually there is 215 a fairly strong (pre-established) trust relationship between the 216 peers. Enterprise network administrators usually have some degree of 217 freedom to select the appropriate security protection and to enforce 218 it. The choice of selecting a security mechanism is therefore often 219 influenced by the already available infrastructure, and per-session 220 negotiation of security mechanisms is often not required (which, in 221 contrast, is required for the public mobile case). 223 For first-peer communications, especially, threats related to 224 initial security association setup, or threats due to replay 225 attacks, lack of confidentiality, denial of service, integrity 226 violation, or identity spoofing are relevant, and potentially lead 227 to theft of service, fraud, or violations of privacy. 229 2.2 End-to-Middle Communications 231 End-to-middle interaction in signaling may be required, e.g., to 232 grant end-entities access to specific services in trust domains 233 different from the one to which the first peer belongs. Threats 234 specific to this scenario may be introduced by untrusted 235 intermediate NSIS hops that maliciously alter NSIS signaling. These 236 threats are still relevant if security mechanisms are in place 237 between the NSIS hops, but terminate at each hop (e.g., IPsec hop- 238 by-hop protection). 240 2.3 Intra-Domain Communications 242 After having been verified at the first peer, an NSIS signaling 243 message traverses the network within the same administrative domain 244 to which the first peer belongs. Because the request has already 245 been authenticated and authorized, the threats are different from 246 those described in the previous sections. To differentiate first- 247 peer communications from intra-domain communications (i.e., 248 communications internally within one administrative domain) we 249 assume that no external end hosts have direct access to the internal 250 network nodes, except to the first peer. We furthermore assume that 251 NSIS peers within the same administrative domain have at least some 252 sort of trust relationship. 254 2.4 Inter-Domain Communications 256 The threat assumptions between the borders of different 257 administrative domains largely depend on the authorization 258 procedures. If one domain forges QoS reservations, then this domain 259 may also have to pay for the reservation. Hence, in this case, there 260 is no real benefit for this domain to forge a QoS reservation. If an 261 end host is directly charged by intermediate domains (i.e., by a 262 domain different from the malicious domain), such an attack may be a 263 quite realistic threat. 265 Security protection of messages transmitted between different 266 administrative domains is necessary to tackle attacks like spoofing, 267 integrity violation, or denial of service between these domains, 268 e.g., to allow proper accounting. The number of neighboring domains 269 is usually rather limited (compared with first-peer communications), 270 which substantially reduces the key management considerations for 271 securing inter-domain NSIS signaling. 273 Signaling information other than QoS service parameters, such as 274 policy rules in the case of middlebox communications, places 275 different assumptions on inter-domain communications. Business 276 relationships and trust assumptions are of particular importance as 277 a basis for securing these communications. 279 If signaling messages are conveyed transparently in the core network 280 (i.e., they are neither intercepted nor processed in the core 281 network), then the signaling message communications effectively 282 takes place between potentially distant access networks. This might 283 place a burden on the key management infrastructure required between 284 these access networks, which might not know of each other in 285 advance. This might lead to an inability to secure signaling 286 messages for direct communications between the access networks. 287 Hence, this can be seen as a serious deployment problem, because it 288 might be unacceptable for an access network service provider to 289 perform processing (e.g., QoS reservations or policy rule 290 installation at firewalls) triggered by unprotected, 291 unauthenticated, and possibly unauthorized incoming signaling 292 messages. 294 2.5 End-to-End Communications 296 NSIS aims to signal information between the Initiator and the 297 Responder. This section refers to the trust relationships required 298 between the end points in cases where security protection is 299 required. Note that this security protection is likely to be 300 required only for certain objects such as those related to pricing 301 and charging. Protecting the entire signaling message end to end is 302 not normally regarded as feasible, because intermediate NSIS nodes 303 need (a) to inspect various objects and (b) to add, modify, or 304 delete objects from the signaling message. 306 The following example illustrates a possible application of end-to- 307 end protection for objects carried within the NSIS signaling 308 protocol. Alice, the data sender, wants Bob, the data receiver, to 309 pay for a QoS reservation (reverse charging). Bob wants to be 310 assured that the QoS signaling message he receives was indeed 311 transmitted by Alice, because he is only willing to pay for 312 particular users and not for everyone. Hence, Bob wants to verify 313 that the request came from Alice (authentication) and that the 314 included parameters are unmodified (integrity). Additionally it 315 might be necessary to secure a negotiation step and to deliver 316 authorization information securely to the parties involved. 317 Information required to render an authorization decision (such as 318 prices or QoS objects) also needs proper security protection. 320 Typical threats in such a scenario range from modification of QoS 321 objects or price information (i.e., making Bob pay too much), to 322 fraud (i.e., forcing Bob always to pay for the reservations), to 323 identity spoofing (i.e., an impostor claiming to be Alice). 325 Regarding end-to-end security, one additional issue needs to be 326 addressed: delegation. Whenever signaling is addressed end to end 327 and an arbitrary node along the path acts as a proxy on behalf of 328 the other endpoint, a delegation mechanism is required to provide 329 secure interaction. This might lead to additional complexity. 331 2.6 Middle-to-Middle Communications 333 The middle-to-middle case is not explicitly considered here, 334 although it is important, because it is already covered by either 335 intra- or inter-domain communications depending on the locations of 336 the entities involved. 338 3. Generic Threats 340 This section provides scenarios of threats that are applicable to 341 signaling protocols in general. Note that some of these scenarios 342 use the term user instead of NSIS Initiator. This is mainly because 343 security protocols allow differentiation between entities as hosts 344 and as users (based on the identifiers used). 346 For the following subsections, we use the general distinction into 347 two cases in which attacks may occur. These are according to the 348 separate steps, or phases, normally encountered when applying 349 protocol security (with, e.g., IPsec, TLS, Kerberos, or SSH). 350 Therefore, this section starts with a brief motivation for this 351 separation. 353 Security protection of protocols is often separated into two steps. 354 The first step provides primarily entity authentication and key 355 establishment (which result in a persistent state often called a 356 security association), whereas the second step provides message 357 protection (some combination of data origin authentication, data 358 integrity, confidentiality, and replay protection) using the 359 previously established security association. The first step tends to 360 be more expensive than the second, which is the main reason for the 361 separation. If messages are transmitted infrequently, then these two 362 steps may be collapsed into a single and usually rather costly one. 363 One such example is e-mail protection via S/MIME. The two steps may 364 be tightly bound into a single protocol, as in TLS, or defined in 365 separate protocols, as with IKE and IPsec. We use this separation to 366 cover the different threats in more detail. 368 3.1 Man-in-the-Middle Attacks 370 This section describes both (1) security threats that exist if two 371 peers do not already share a security association or do not use 372 security mechanisms at all, and (2) threats that are applicable when 373 a security association is already established. Note also that a 374 denial of service attack on a signaling protocol exists when no 375 separation between SA establishment and signaling protection takes 376 place. The discovery procedure, in particular, is vulnerable to a 377 number of such attacks. 379 - Attacks during NSIS SA Establishment 381 While establishing a security association, an adversary fools the 382 signaling message Initiator with respect to the entity to which it 383 has to authenticate. The Initiator authenticates to the man-in-the- 384 middle adversary, who is then able to modify signaling messages to 385 mount DoS attacks or steal services that get billed to the 386 Initiator. In addition, it may be able to terminate the Initiator's 387 NSIS messages of and inject messages to a peer itself, therefore 388 acting as the peer to the Initiator and as the Initiator to the 389 peer. This results in the Initiator wrongly believing that it is 390 talking to the "real" network, whereas it is actually attached to an 391 adversary. 392 For this attack to be successful, pre-conditions have to hold which 393 are described in the following two cases: 395 - Missing Authentication 397 In the first case, this threat can be carried out because of missing 398 authentication between neighboring peers: without authentication a 399 NI, NR, or NF is unable to detect an adversary. However, in some 400 practical cases authentication might be difficult to accomplish, 401 either because the next peer is unknown, because of misbelieved 402 trust relationships in parts of the network, or because of the 403 inability to establish proper security protection (inter-domain 404 signaling messages, dynamic establishment of a security association, 405 etc.). If one of the communicating endpoints is unknown, then for 406 some security mechanisms it is either impossible or impractical to 407 apply appropriate security protection. Sometimes network 408 administrators use intra-domain signaling messages without proper 409 security. Such a configuration would then allow an adversary on a 410 compromised non-NSIS-aware node to interfere with nodes running an 411 NSIS signaling protocol. Note that this type of threat goes beyond 412 those caused by malicious NSIS nodes (described in Section 4.7). 414 - Unilateral Authentication 416 In the case of unilateral authentication, the NSIS entity that does 417 not authenticate its peer is unable to discover a man-in-the-middle 418 adversary. Although mutual authentication of signaling messages 419 should take place between each peer participating in the protocol 420 operation, special attention is given here to first-peer 421 communications. Unilateral authentication between an end host and 422 the first peer (just authenticating the end host) is still common 423 today, but it certainly opens up many possibilities for man-in-the- 424 middle attackers impersonating either the end host or the 425 (administrative domain represented by the) first peer. 427 Missing or unilateral authentication, as described above, is part of 428 a general problem of network access with inadequate authentication, 429 and it should not be considered something unique to the NSIS 430 signaling protocol. Obviously, there is a strong need to correctly 431 address this in a future NSIS protocol. The signaling protocols 432 addressed by NSIS are different from other protocols, in which only 433 two entities are involved. Note that first-peer authentication is 434 especially important, because a security breach here could impact 435 nodes beyond the entities directly involved (or even beyond a local 436 network). 438 Finally it should be noted that the signaling protocol should be 439 considered as a peer-to-peer protocol, whereby the roles of 440 Initiator and Responder can be reversed at any time. Hence, 441 unilateral authentication is not particularly useful for such a 442 protocol. However, there might be a need to have some form of 443 asymmetry in the authentication process, whereby one entity uses a 444 different authentication mechanism than the other one. As an 445 example, the combination of symmetric and asymmetric cryptography 446 should be mentioned. 448 - Weak Authentication 450 In this case, the threat can be carried out because of weak 451 authentication mechanisms whereby information transmitted during the 452 NSIS SA establishment process may leak passwords or allow offline 453 dictionary attacks. This threat is applicable to NSIS for the 454 process of selecting certain security mechanisms. 456 3.2 Replay of Signaling Messages 458 This threat scenario covers the case in which an adversary 459 eavesdrops and collects signaling messages and replays them at a 460 later time (or at a different place, or uses parts of them at a 461 different place or in a different way, e.g., cut-and-paste attacks). 462 Without proper replay protection, an adversary might mount man-in- 463 the-middle, denial of service, and theft of service attacks. 465 A more difficult attack that may cause problems even in case of 466 replay protection requires the adversary to crash an NSIS-aware 467 node, cause it to lose state information (sequence numbers, security 468 associations, etc.), and then be able to replay old signaling 469 messages. This attack takes advantage of re-synchronization 470 deficiencies. 472 3.3 Injecting or Modifying Messages 474 This type of threat involves integrity violations, whereby an 475 adversary modifies signaling messages (e.g., by acting as a man-in- 476 the-middle) to cause unexpected network behavior. Possible actions 477 an adversary might consider for its attack are reordering, delaying, 478 dropping, injecting, truncating, and otherwise modifying messages. 480 An adversary may inject a signaling message requesting a large 481 amount of resources (possibly using a different user's identity). 482 Other resource requests may then be rejected. In combination with 483 identity spoofing, it is also possible to carry out fraud. This 484 attack is only feasible in the absence of authentication and 485 signaling message protection. 487 Some threats directly related to these are described in Sections 488 4.4, 4.7, and 4.8. 490 3.4 Insecure Parameter Exchange and Negotiation 492 First, protocols may be useful in a variety of scenarios with 493 different security requirements. Second, different users (e.g., a 494 university, a hospital, a commercial enterprise, or a government 495 ministry) have inherently different security requirements. Third, 496 different parts of a network (e.g., within a building, across a 497 public carrier's network, or over a private microwave link) may need 498 different levels of protection. It is often difficult to meet these 499 (sometimes conflicting) requirements with a single security 500 mechanism or fixed set of security parameters, so often a selection 501 of mechanisms and parameters is offered. Therefore, a protocol is 502 required to agree on certain security mechanisms and parameters. An 503 insecure parameter exchange or security negotiation protocol can 504 help an adversary mount a downgrading attack to force selection of 505 weaker mechanisms than mutually desired. Hence, without binding the 506 negotiation process to the legitimate parties and protecting it, an 507 NSIS protocol might be only as secure as the weakest mechanism 508 provided (e.g., weak authentication), and the benefits of defining 509 configuration parameters and a negotiation protocol are lost. 511 4. NSIS-Specific Threat Scenarios 513 This section describes 11 threat scenarios in terms of attacks on 514 and security deficiencies in the NSIS signaling protocol. A number 515 of security deficiencies might enable an attack. Fraud is an example 516 of an attack that might be enabled by missing replay protection, 517 missing protection of authorization tokens, identity spoofing, 518 missing authentication, and other deficiencies that help an 519 adversary steal resources. Different threat scenarios based on 520 deficiencies that could enable an attack are addressed in this 521 section. 523 The threat scenarios are not independent. Some of them, e.g., denial 524 of service, are well-established security terms and, as such, need 525 to be addressed, but are often enabled by one or more deficiencies 526 described under other scenarios. 528 4.1 NSIS SA Usage 530 Once a security association is established (and used) to protect 531 signaling messages, many basic attacks are prevented. However, a 532 malicious NSIS node is still able to perform various attacks as 533 described in Section 4.7. Replay attacks may be possible when an 534 NSIS node crashes, restarts, and performs state re-establishment. 535 Proper re-synchronization of the security mechanism must therefore 536 be provided to address this problem. 538 4.2 Combining Signaling and SA Establishment 540 This scenario describes attacks that allow an adversary to flood an 541 NSIS node with bogus signaling messages to cause a denial of service 542 attack. 544 When a signaling message arrives at an NSIS-aware network element, 545 certain processing is required. If this message contains security 546 objects such as digital signatures, and no security association is 547 already available, then some additional processing is required for 548 the cryptographic verification. Because NSIS signaling should not 549 require extra roundtrips between two NSIS peers, it is difficult to 550 provide the DoS protection mechanisms commonly found in 551 authentication and key agreement protocols. Signaling messages can 552 be idempotent, which means that they contain the same amount of 553 information as the original message. An example would be a refresh 554 message that is equivalent to a create message. This property allows 555 a refresh message to create new state along a new path, although no 556 previous state is available. For this to work, specific classes of 557 cryptographic mechanisms supporting this behavior are needed. An 558 example is a scheme based on digital signatures, which, however, 559 should be used with care due to possible denial of service attacks. 560 Problems with using these types of exchanges with public key based 561 protection are described in [AN97] and in [ALN00]. 563 In addition to the threat scenario described above, an incoming 564 signaling message might require time consuming processing 565 (computations, state maintenance, timer setting, etc.) and 566 communication with third-party nodes such as policy servers, LDAP 567 servers, etc. If an adversary is able to transmit a large number of 568 signaling messages (for example, with QoS reservation requests) with 569 invalid credentials, then the verifying node may not be able to 570 process other reservation messages from legitimate users. 572 Further attacks may be enabled by injecting error messages or 573 forcing the creation of error messages to extract additional 574 information. 576 4.3 Eavesdropping and Traffic Analysis 578 This section covers threats whereby an adversary is able to 579 eavesdrop on signaling messages. The signaling packets collected may 580 allow traffic analysis or be used later to mount replay attacks, as 581 described in Section 3.2. The eavesdropper might learn QoS 582 parameters, communication patterns, policy rules for firewall 583 traversal, policy information, application identifiers, user 584 identities, NAT bindings, authorization objects, network 585 configuration and performance information, and more. 587 An adversary's capability to eavesdrop on signaling messages might 588 violate a user's preference for privacy, particularly if unprotected 589 authentication or authorization information (including policies and 590 profile information) is exchanged. 592 Note that this threat scenario is not mitigated by applying 593 integrity protection to the messages, which is often considered 594 sufficient for signaling protocols. 596 Because the NSIS protocol signals messages through a number of 597 nodes, it is possible to differentiate between nodes actively 598 participating in the NSIS protocol and others that do not actively 599 participate in the NSIS protocol. For certain objects or messages it 600 might be desirable to permit actively participating intermediate 601 NSIS nodes to eavesdrop. On the other hand, it might be desirable 602 that only the intended end points (NSIS Initiator and NSIS 603 Responder) are able to read certain other objects. 605 4.4 Identity Spoofing 607 Identity spoofing relevant for NSIS occurs in two forms: first, 608 identity spoofing can happen during the establishment of a security 609 association based on a weak authentication mechanismn and, second, 610 it can consist of spoofing data traffic. 612 In the first case, Eve, acting as an adversary, may claim to be the 613 registered user Alice by spoofing Alice's identity. Eve thereby 614 causes the network to charge Alice for the network resources 615 consumed. This type of attack is possible if authentication is based 616 on a simple username identifier (i.e., in absence of cryptographic 617 authentication), or if authentication is provided for hosts, and 618 multiple users have access to a single host. This attack could also 619 be classified as theft of service. 621 In the second case, an adversary may be able to exploit the 622 established flow identifiers (required for QoS and middlebox 623 communication [Midcom] specific signaling protocols). Some 624 identifiers, among others, IP addresses, transport protocol 625 identifiers, port numbers, and flow labels (see [RFC1809] and 626 [RC+03]), are transported in these protocols. Modification of these 627 flow identifiers allows adversaries to exploit or to render 628 ineffective quality of service reservations or policy rules at 629 middleboxes. An adversary could mount an attack by modifying the 630 flow identifier of a signaling message. 632 NSIS signaling messages contain some sort of flow identifier, which 633 is associated with a specified behavior (e.g., a particular flow 634 experiences QoS treatment or allows packets to traverse a firewall). 635 An adversary might, therefore, use IP spoofing and inject data 636 packets to benefit from previously installed flow identifiers. 638 The following threat is carried out by spoofing the identity of 639 transmitted data traffic. The spoofed identity is the IP source 640 address. For this attack to be successful, accounting records are 641 collected based on the IP source address and not on a SPI due to 642 IPsec protection. After the network receives a properly protected 643 reservation request, transmitted by the legitimate user Alice, 644 Traffic Selectors are installed at the corresponding devices (for 645 example, the edge router). These Traffic Selectors are used for flow 646 identification and allow data traffic originated from a given source 647 address to be matched and assigned to a particular QoS reservation. 648 The adversary Eve now spoofs the IP address of the Alice. In 649 addition, Alice's host may be crashed by the adversary with a denial 650 of service attack or may lose connectivity, for example, because of 651 mobility considerations. If both nodes are located at the same link 652 and use the same IP address, then obviously a duplicate IP address 653 will be detected. Assuming that only Eve is now present at the link, 654 she is able to receive and transmit data (for example RTP data 655 traffic) that receives preferential QoS treatment based on the 656 previous reservation. Depending on the installed Traffic Selector 657 granularity, Eve might have more possibilities to exploit the QoS 658 reservation or a pin-holed firewall. Assuming the soft state 659 paradigm, whereby periodic refresh messages are required, the 660 absence of Alice will not be detected until the next signaling 661 message appears and forces Eve to respond with a protected signaling 662 message. Again, this attack is applicable not just to QoS traffic, 663 but the existence of a QoS reservation increases its impact, because 664 this type of traffic is more expensive. The same attack is also 665 applicable to a Middlebox protocol. 667 The ability for an adversary to inject data traffic that matches a 668 certain flow identifier established by a legitimate user often 669 requires the ability also to receive the data traffic. This is, 670 however, true only if the flow identifier consists of values that 671 contain addresses used for routing. If we imagine using attributes 672 of a flow identifier that do not require such a property, then 673 identity spoofing and injecting traffic are much easier. An 674 adversary can use a nearly arbitrary endpoint identifier to achieve 675 the desired result. Obviously, though, the endpoint identifiers are 676 not irrelevant, because the messages have to travel the same path 677 through the network. 679 Data traffic marking based on DiffServ is such an example. Whenever 680 an ingress router uses only marked incoming data traffic for 681 admission control procedures, then various attacks are possible. 682 These problems have been known in the DiffServ community for a long 683 time and have been documented in various DiffServ-related documents. 684 The IPsec protection of DiffServ Code Points is described in Section 685 6.2 of [RFC2745]. Related security issues (for example denial of 686 service attacks) are described in Section 6.1 of the same document. 688 4.5 Unprotected Authorization Information 690 Authorization is an important criterion for providing resources such 691 as QoS reservations, NAT bindings, and pin-holes through firewalls. 692 Authorization information might be delivered to the NSIS 693 participating entities in a number of ways. 695 Typically the authenticated identifier is used to assist during the 696 authorization procedure as, e.g., described in [RFC3812]. Depending 697 on the chosen authentication protocol, certain threats may exist. 698 Section 3 discusses a number of issues related to this approach when 699 the authentication and key exchange protocol is used to establish 700 session keys for signaling message protection. 702 Another approach is to use some sort of authorization token. The 703 functionality and structure of such an authorization token for RSVP 704 is described in [RFC3520] and [RFC3521]. 706 Achieving secure interaction between different protocols based on 707 authorization tokens, however, requires some care. By using such an 708 authorization token it is possible to link state information between 709 different protocols. Returning an unprotected authorization token to 710 the end host might allow an adversary (for example an eavesdropper) 711 to steal resources. An adversary might also use the token to monitor 712 communication patterns. Finally, an untrustworthy end host might 713 also modify the token content. 715 The Session/Reservation Ownership problem can also be regarded as an 716 authorization problem. Details are described in Section 4.10. In 717 enterprise networks, authorization is often coupled with membership 718 in a particular class of users or groups. This type of information 719 either can be delivered as part of the authentication and key 720 agreement procedure or has to be retrieved via separate protocols 721 from other entities. If an adversary manages to modify information 722 relevant for determining authorization or the outcome of the 723 authorization process itself, then theft of service might be 724 possible. 726 4.6 Missing Non-Repudiation 728 Repudiation in this context refers to a problem where one party 729 later denies having taken a certain action (such as requesting a QoS 730 reservation). Problems stemming from a lack of non-repudiation 731 appear in two forms: 733 On the one hand, from a service provider's point-of-view, the 734 following threat may be worth investigation. A user may deny having 735 issued a reservation request for which it was charged. The service 736 provider may then want to be able to prove that a particular user 737 issued the reservation request in question. 739 On the other hand, the same threat can be interpreted from a user's 740 point-of-view. A service provider may claim to have received a 741 number of reservation requests. The user in question thinks that it 742 never issued those requests and wants to see a proof of correct 743 service usage for a given set of QoS parameters. 745 In today's telecommunication networks, non-repudiation is not 746 provided. The user has to trust the network operator to meter the 747 traffic correctly, collect and merge accounting data, and ensure 748 that no unforeseen problems occur. If a signaling protocol with the 749 non-repudiation property is desired for establishing QoS 750 reservations for authorized resources, this impacts the protocol 751 design. 753 Non-repudiation poses additional requirements on the security 754 mechanisms, because it public-key cryptography is needed to provide 755 it. Because this would normally increase the overall cost for 756 security, threats related to missing non-repudiation are only 757 considered relevant in certain specific cases (e.g., specific 758 authorization mechanisms) and not for general NSIS signaling. 760 4.7 Malicious NSIS Entity 762 Network elements within a domain (intra-domain) experience a 763 different trust relationship with regard to the security protection 764 of signaling messages compared with edge NSIS entities. It is 765 assumed that edge NSIS entities are responsible for performing 766 cryptographic processing (authentication, integrity and replay 767 protection, authorization, and accounting) for signaling messages 768 arriving from the outside. This prevents unprotected signaling 769 messages from appearing within the internal network. If, however, an 770 adversary manages to take over an edge router, then the security of 771 the entire network is compromised. An adversary is then able to 772 launch a number of attacks including denial of service; integrity 773 violations; replay, reordering, and deletion of data packets; and 774 various others. A rogue firewall can harm other firewalls by 775 modifying policy rules. The chain-of-trust principle applied in 776 peer-to-peer security protection cannot protect against a malicious 777 NSIS node. An adversary with access to a NSIS router is also able to 778 get access to security associations and transmit secured signaling 779 messages. Note that even non-peer-to-peer security protection might 780 not be able to prevent this problem fully. Because an NSIS node 781 might issue signaling messages on behalf of someone else (by acting 782 as a proxy), additional problems need to be considered. 784 An NSIS-aware edge router is a critical component that requires 785 strong security protection. A strong security policy applied at the 786 edge does not imply that other routers within an intra-domain 787 network do not need to verify signaling messages cryptographically. 788 If the chain-of-trust principle is deployed, then the security 789 protection of the entire path (in this case within the network of a 790 single administrative domain) is as strong as the weakest link. In 791 the case under consideration, the edge router is the most critical 792 component of this network, and it may also act as a security gateway 793 or firewall for incoming and outgoing traffic. For outgoing traffic 794 this device has to implement the security policy of the local domain 795 and apply the appropriate security protection. 797 For an adversary to mount this attack, either an existing NSIS-aware 798 node along the path has to be attacked successfully, or an adversary 799 must succeed in convincing another NSIS node to be the next NSIS 800 peer (man-in-the-middle attack). 802 4.8 Denial of Service Attacks 804 A number of denial of service (DoS) attacks can cause NSIS nodes to 805 malfunction. Other attacks that could lead to DoS, such as man-in- 806 the-middle attacks, replay attacks, injection or modification of 807 signaling messages, etc., are mentioned throughout this document. 809 - Path Finding 811 This threat scenario includes potential DoS attacks that exist when 812 the reservation setup is split into two phases, i.e., path and 813 reservation (as used, for example, in receiver-based reservation 814 setup). In this case, assuming that the node transmitting the path 815 message is not charged for the path message itself, it may be able 816 to generate a large number of reservation requests (possibly in a 817 distributed fashion). Charging is activated only after successful 818 verification of the reservation request. The reservations are, 819 however, never intended to be successful for various reasons: the 820 destination node cannot be reached; it is not responding; or it 821 simply rejects the reservation. An adversary can succeed because 822 state has already been allocated along the path for various 823 processing tasks including path pinning. 825 - Discovery Phase 827 Conveying signaling information to a large number of entities along 828 a data path requires some sort of discovery. This discovery process 829 is vulnerable to a number of attacks, because it is difficult to 830 secure. An adversary can use the discovery mechanisms to convince 831 one entity to signal information to another entity not along the 832 data path or to cause the discovery process to fail. In the first 833 case, the signaling protocol could appear to continue correctly, 834 except that policy rules are installed at the incorrect firewalls or 835 QoS resource reservations take place at the wrong entities. For an 836 end host, this means that the protocol failed for unknown reasons. 838 - Faked Error or Response Messages 840 An adversary may be able to inject false error or response messages 841 as part of a DoS attack. This could be either at the signaling 842 message protocol layer (NTLP), at the layer of each client layer 843 protocol (NSLP: QoS, Midcom, etc.), or at the transport protocol 844 layer. An adversary might cause unexpected protocol behavior or 845 might succeed with a DoS attack. The discovery protocol, 846 especially, exhibits vulnerabilities with regard to this threat 847 scenario (see the above discussion on discovery). In the case in 848 which no separate discovery protocol is used and signaling 849 messages are addressed to end hosts only (with a Router Alert 850 Option to intercept message as NSIS aware nodes), an error 851 message might be used to indicate a path change. Such a design 852 combines a discovery protocol together with a signaling message 853 exchange protocol. 855 4.9 Disclosing the Network Topology 856 In some organizations or enterprises there is a desire not to reveal 857 internal network structure (or other related information) outside of 858 a closed community. An adversary might be able to use NSIS messages 859 for network mapping (e.g., discovering which nodes exist, which use 860 NSIS, what version, what resources are allocated, what capabilities 861 nodes along a path have, etc.). Discovery messages, traceroute, 862 diagnostic messages (see [RFC2745] for a description of diagnostic 863 message functionality for RSVP), and query messages, in addition to 864 record route and route objects, provide potential assistance to an 865 adversary. Hence, the requirement of not disclosing a network 866 topology might conflict with other requirements to provide means for 867 automatically discovering NSIS-aware nodes or to provide diagnostic 868 facilities (used for network monitoring and administration). 870 4.10 Unprotected Session or Reservation Ownership 872 Figure 3 shows an NSIS Initiator that has established state 873 information at NSIS nodes along a path as part of the signaling 874 procedure. As a result, Access Router 1, Router 3, and Router 4 (and 875 other nodes) have stored session state information including the 876 Session Identifier SID-x. 878 Session ID(SID-x) 879 +--------+ 880 +-----------------+ Router +------------> 881 Session ID(SID-x)| | 4 | 882 +---+----+ +--------+ 883 | Router | 884 +------+ 3 +******* 885 | +---+----+ * 886 | * 887 | Session ID(SID-x) * Session ID(SID-x) 888 +---+----+ +---+----+ 889 | Access | | Access | 890 | Router | | Router | 891 | 1 | | 2 | 892 +---+----+ +---+----+ 893 | * 894 | Session ID(SID-x) * Session ID(SID-x) 895 +----+------+ +----+------+ 896 | NSIS | | Adversary | 897 | Initiator | | | 898 +-----------+ +-----------+ 900 Figure 3: Session or Reservation Ownership 902 The Session Identifier is included in signaling messages to 903 reference to the established state. 905 If an adversary were able to obtain the Session Identifier, for 906 example by eavesdropping on signaling messages, it would be able to 907 add the same Session Identifier SID-x to a new signaling message. 908 When the new signaling message hits Router 3 (as shown in Figure 3), 909 existing state information can be modified. The adversary can then 910 modify or delete the established reservation and cause unexpected 911 behavior for the legitimate user. 913 The source of the problem is that Router 3 (a cross-over router) is 914 unable to decide whether the new signaling message was initiated 915 from the owner of the session or reservation. 917 In addition, nodes other than the initial signaling message 918 originator are allowed to signal information during the lifetime of 919 an established session. As part of the protocol, any NSIS-aware node 920 along the path (and the path might change over time) could initiate 921 a signaling message exchange. It might, for example, be necessary to 922 provide mobility support or to trigger a local repair procedure. If 923 only the initial signaling message originator were allowed to 924 trigger signaling message exchanges, some protocol behavior would 925 not be possible. 927 If this threat scenario is not addressed, an adversary can launch 928 DoS, theft of service, and various other attacks. 930 4.11 Attacks against the Transport Mechanism 932 In [BL01] a two-level architecture is proposed, which suggests 933 splitting an NSIS protocol into layers: a signaling message 934 transport-specific layer and an application-specific layer. This 935 architectural assumption is also considered within the NSIS 936 framework [HF+03]. Most of the threats described in this document 937 are applicable to the application-specific part (i.e., signaling QoS 938 or middlebox-specific information). There are, however, some threats 939 that are applicable to the transport of signaling messages. 941 Network or transport layer protocols lacking protection mechanisms 942 are vulnerable to certain attacks such as header manipulation, DoS, 943 spoofing of identities, session hijacking, unexpected aborts, etc. 945 Malicious nodes can attack the congestion control mechanism to force 946 NSIS nodes into a congestion avoidance state. 948 In the case in which existing protocols are used for exchanging NSIS 949 signaling messages, known threats scenarios applicable to these 950 protocols are relevant. 952 5. Security Considerations 954 This entire memo discusses security issues relevant for NSIS 955 protocol design. It begins by identifying the components of a 956 network running NSIS (Initiator, Responder, and different 957 Administrative Domains between them). It then considers five cases 958 in which communications take place between these components, and it 959 examines the trust relationships presumed to exist in each case: 960 First-Peer Communications, End-to-Middle Communications, Intra- 961 Domain Communications, Inter-Domain Communications, and End-to-End 962 Communications. This analysis helps determine the security needs and 963 the relative seriousness of different threats in the different 964 cases. 966 The document points out the need for different protocol security 967 measures: authentication, key exchange, message integrity, replay 968 protection, confidentiality, authorization, and some precautions 969 against denial of service. The threats are subdivided into generic 970 ones (e.g., man-in-the-middle attacks, replay attacks, tampering and 971 forgery, and attacks on security negotiation protocols) and 11 972 threat scenarios particularly applicable to the NSIS protocol. 973 Denial of service, for example, is covered in the NSIS-specific 974 section, not because it cannot be carried out against other 975 protocols, but because the methods used to carry out denial of 976 service attacks tend to be protocol specific. Numerous illustrative 977 examples provide insight into what can happen if these threats are 978 not mitigated. 980 This document points out repeatedly that not all of the threats are 981 equally serious in every context. It does attempt to identify the 982 scenarios in which security failures may have the highest impact. 983 However, it is difficult for the protocol designer to foresee all 984 the ways in which NSIS protocols will be used or to anticipate the 985 security concerns of a wide variety of likely users. Therefore, the 986 protocol designer needs to offer a full range of security 987 capabilities and ways for users to negotiate and select what they 988 need, case by case. To counter these threats, security requirements 989 have been listed in [Brun03]. Topics relevant to the NSIS Framework 990 have been incorporated into [HF+03]. 992 6. Normative References 994 [Brun03] M. Brunner, "Requirements for QoS signaling protocols," 995 Internet Draft, Internet Engineering Task Force, August 2003. Work 996 in progress. 998 7. Informative References 1000 [HF+03] R. Hancock, I. Freytsis, G. Karagiannis, J. Loughney, and S. 1001 V. den Bosch, "Next steps in signaling: Framework," Internet Draft, 1002 Internet Engineering Task Force, September 2003. Work in progress. 1004 [RFC1809] C. Partridge, "Using the flow label field in IPv6," RFC 1005 1809, Internet Engineering Task Force, June 1995. 1007 [RFC2745] A. Terzis, B. Braden, S. Vincent, and L. Zhang, "RSVP 1008 Diagnostic Messages," RFC 2745, Internet Engineering Task Force, 1009 Jan. 2000. 1011 [RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, 1012 T., Herzog, S., Hess, R.: "Identity Representation for RSVP", RFC 1013 3182, October, 2001. 1015 [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, 1016 J. Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session 1017 initiation protocol," RFC 3261, Internet Engineering Task Force, 1018 June 2002. 1020 [RFC3521] L. Hamer, B. Gage, and H. Shieh, "Framework for session 1021 set-up with media authorization," RFC 3521, Internet Engineering 1022 Task Force, April 2003. 1024 [RFC3520] L. Hamer, B. Gage, B. Kosinski, and H. Shieh, "Session 1025 Authorization Policy Element", RFC 3520, Internet Engineering Task 1026 Force, April 2003. 1028 [RC+03] J. Rajahalme, A. Conta, B. Carpenter, and S. Deering, "IPv6 1029 Flow Label Specification," Internet Draft, Internet Engineering Task 1030 Force, April 2003. Work in progress. 1032 [BL01] B. Braden and B. Lindell, "A two-level architecture for 1033 internet signaling," Internet Draft, Internet Engineering Task 1034 Force, Nov. 2001. (Expired). 1036 [AN97] T. Aura and P. Nikander: "Stateless Connections", In 1037 Proceedings of the International Conference on Information and 1038 Communications Security (ICICS'97), Lecture Notes in Computer 1039 Science 1334, Springer, 1997. 1041 [ALN00] T. Aura, J. Leiwo and P. Nikander: "Towards Network Denial 1042 of Service Resistant Protocols", In Proceedings of the 15th 1043 International Information Security Conference (IFIP/SEC 2000), 1044 Beijing, China, August 2000. 1046 Author's Addresses 1048 Hannes Tschofenig 1049 Siemens AG 1050 Corporate Technology 1051 CT IC 3 1052 Otto-Hahn-Ring 6 1053 81739 Munich 1054 Germany 1055 EMail: Hannes.Tschofenig@siemens.com 1057 Dirk Kroeselberg 1058 Siemens AG 1059 Otto-Hahn-Ring 6 1060 81739 Munich 1061 Germany 1062 EMail: Dirk.Kroeselberg@siemens.com 1064 Appendix A. Contributors 1066 We especially thank Richard Graveman, who provided text for the 1067 security considerations section, besides a detailed review of the 1068 document. 1070 Appendix B. Acknowledgments 1072 We would like to thank (in alphabetical order) Marcus Brunner, Jorge 1073 Cuellar, Mehmet Ersue, Xiaoming Fu, and Robert Hancock for their 1074 comments on an initial version of this draft. Jorge and Robert gave 1075 us an extensive list of comments and provided information on 1076 additional threats. 1078 Jukka Manner, Martin Buechli, Roland Bless, Marcus Brunner, Michael 1079 Thomas, Cedric Aoun, John Loughney, Rene Soltwisch, Cornelia 1080 Kappler, and Mohan Parthasarathy provided comments on a recent 1081 version of this draft. Their input helped improve the content of 1082 this document. Roland Bless, Michael Thomas, and Cornelia Kappler, 1083 in particular, provided good proposals for regrouping and 1084 restructuring the material. 1086 A final review was given by Michael Richardson. We thank him for the 1087 detailed comments. 1089 Full Copyright Statement 1091 Copyright (C) The Internet Society (2003). All Rights Reserved. 1093 This document and translations of it may be copied and furnished to 1094 others, and derivative works that comment on or otherwise explain it 1095 or assist in its implementation may be prepared, copied, published 1096 and distributed, in whole or in part, without restriction of any 1097 kind, provided that the above copyright notice and this paragraph 1098 are included on all such copies and derivative works. However, this 1099 document itself may not be modified in any way, such as by removing 1100 the copyright notice or references to the Internet Society or other 1101 Internet organizations, except as needed for the purpose of 1102 developing Internet standards in which case the procedures for 1103 copyrights defined in the Internet Standards process must be 1104 followed, or as required to translate it into languages other than 1105 English. 1107 The limited permissions granted above are perpetual and will not be 1108 revoked by the Internet Society or its successors or assignees. 1110 This document and the information contained herein is provided on an 1111 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1112 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1113 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1114 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1115 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1117 Acknowledgement 1119 Funding for the RFC Editor function is currently provided by the 1120 Internet Society.