idnits 2.17.1 draft-ietf-nsis-threats-01.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 24 longer pages, the longest (page 2) being 61 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 25 pages 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 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 (23 January 2003) is 7757 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 section? '1' on line 1038 looks like a reference -- Missing reference section? '2' on line 1042 looks like a reference -- Missing reference section? '3' on line 1045 looks like a reference -- Missing reference section? '4' on line 1048 looks like a reference -- Missing reference section? '5' on line 1051 looks like a reference -- Missing reference section? '6' on line 1055 looks like a reference -- Missing reference section? '7' on line 1058 looks like a reference -- Missing reference section? '8' on line 1062 looks like a reference -- Missing reference section? '9' on line 1067 looks like a reference -- Missing reference section? '10' on line 1070 looks like a reference -- Missing reference section? '11' on line 1074 looks like a reference -- Missing reference section? '12' on line 1078 looks like a reference -- Missing reference section? '13' on line 1081 looks like a reference -- Missing reference section? '14' on line 1085 looks like a reference -- Missing reference section? '15' on line 1088 looks like a reference -- Missing reference section? '16' on line 1092 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force NSIS 3 Internet Draft H. Tschofenig, D. Kroeselberg 4 Siemens AG 5 draft-ietf-nsis-threats-01.txt 6 23 January 2003 7 Expires: August 2003 9 Security Threats for NSIS 11 STATUS OF THIS MEMO 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering Task 17 Force (IETF), its areas, and its working groups. Note that other groups 18 may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference material 23 or to cite them other than as "work in progress". 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 To view the list Internet-Draft Shadow Directories, see 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This threats document provides a detailed analysis of the security 34 threats relevant for the NSIS working group. It motivates and helps to 35 understand various security considerations in the NSIS Requirements, 36 Framework and Protocol proposals. This document does not describe 37 vulnerabilities of specific NSIS protocols. 39 1 Introduction 41 Section 1.1 introduces the overall process of addressing the security 42 work done in the NSIS working group. Section 1.2 gives a high-level 43 picture of the different network parts, which are traversed by NSIS 44 signaling. Each part is characterized by a different set of requirements 45 and different trust relationships. The threats described in Section 2 46 can be assigned to these individual parts. 48 1.1 NSIS Security Process 50 Whenever a new protocol has to be developed or existing protocols have 51 to be modified their security threats should be evaluated. The process 52 of securing protocols in separated into individual steps. To address 53 security in the NSIS working group a number of documents have been 54 produced: 56 +----------------------------------------------+ 57 | NSIS Analysis Activities | 58 | (e.g. RSVP Security Properties) | 59 +----------------------------------------------+ 60 +----------------------------------------------+ 61 | Security Threats for NSIS | 62 | | 63 +----------------------------------------------+ 64 +----------------------------------------------+ 65 | NSIS Requirements | 66 | | 67 +----------------------------------------------+ 68 +----------------------------------------------+ 69 | NSIS Framework | 70 | | 71 +----------------------------------------------+ 72 +----------------------------------------------+ 73 | | 74 | NSIS Protocol Proposals | 75 +----------------------------------------------+ 77 Figure 1: NSIS Security related Documents 78 All the documents depicted in Figure 1 contribute to the NSIS security 79 approach. The purpose of each of these documents is briefly described 80 below to give the reader insight into the development process. 82 NSIS Analysis Activities: 84 The primary goal of the NSIS analysis activity is the 85 investigation of existing approaches in the area of quality of 86 service signaling protocols. Several of the published 87 approaches directly identify security threats and 88 requirements, whereas other threats and requirements can be 89 derived from the different scenarios in which these protocols 90 are used. For instance, [1] points to the reduced complexity 91 if RSVP is used without multicast support. This modification 92 also results in simplified security requirements. In [2], 93 security issues in some example configurations are given. In 94 [3], the security properties of RSVP are described. 95 Furthermore an analysis of the interaction between RSVP and 96 Mobile IP is provided by Michael Thomas in [4] and an analysis 97 of existing QoS protocols is described in [5]. 99 NSIS Requirements: 101 To address the security threats relevant for NSIS described in 102 this document, security requirements have been specified as 103 part of the NSIS Requirements document [6]. In addition to 104 these requirements [6] describes basic scenarios where the 105 NSIS signaling protocol might be deployed. 107 NSIS Framework: 109 Signaling information to a number of devices located in 110 different parts in the network with different trust 111 assumptions and possible interactions with a large number of 112 other protocols require some framework thoughts, which is 113 especially true for security. In [7] a security framework is 114 provided for NSIS. 116 NSIS Protocol: 118 Finally there are documents describing concrete protocol 119 proposals. These proposals either rely on existing security 120 mechanisms or develop their own if the existing mechanisms 121 cannot counter all relevant security threats or if they are 122 inappropriate for other reasons. In practice, a protocol 123 proposal might use established security mechanisms or 124 protocols for basic protection, but is likely to require some 125 additional protection mechanisms, or a combination of both for 126 enhanced security. 128 Note that the process of developing the above-mentioned 129 documents is not linear. Instead it takes various iterations 130 to reach a satisfactory NSIS security solution. 132 Security Threats for NSIS: 134 This document identifies the basic threats that need to be 135 addressed by the NSIS signaling protocol design. In addition, 136 although the base protocol might be secure, some extensions 137 may cause problems when used in a particular environment. 138 Furthermore it is necessary to investigate the context in 139 which a signaling protocol is used and the architecture where 140 it is integrated. As an example of such interaction accounting 141 and charging are taken into account in this document, since 142 without an appropriate integration of the two it is difficult 143 to deploy any NSIS solution. This interaction is also subject 144 of the NSIS framework and some aspects are discussed in [7]. 146 1.2 Relevant communication models 148 Independent of the threat scenarios described in Section 2 signaling 149 messages traverse different network parts, which demand different 150 security means. The difference in security protection is mainly caused 151 by the fact that the NSIS signaling messages cross trust boundaries 152 where different trust relationships are prevalent. Often a 153 categorization into first-peer/last-peer, intra-domain and inter-domain 154 communication is applicable (see Figure 2). Depending on the concrete 155 security requirements end-to-end security protection across trust 156 boundaries might be required for certain scenarios but is usually not 157 easily addressable by standard means. The main properties of the listed 158 network parts are briefly described in this section and the threat 159 scenarios of Section 2 are classified accordingly. Figure 2 depicts a 160 typical end-to-end communication scenario including an access part 161 between the NSIS end entities and the nearest NSIS hops, respectively. 162 This "first-peer communication" commonly comes with specific security 163 requirements, especially important for properly addressing security in 164 mobile scenarios. Differences in the trust relationship and the required 165 security for first-peer communication, compared to other parts of the 166 signaling path, might exist. 168 If signaling messages are not exchanged end-to-end and only parts of the 169 signaling path are affected, some threats may not be relevant. 171 To further refine the above differentiation based on network parts that 172 NSIS signaling may traverse, we consider trust relationships between 173 +------------------+ +---------------+ +------------------+ 174 | | | | | | 175 | Administrative | | Intermediate | | Administrative | 176 | Domain A | | Domains | | Domain B | 177 | | | | | | 178 | (Inter-domain Communication) | 179 | +---------+---+---------------+---+---------+ | 180 | (Intra-domain | | | | (Intra-domain | 181 | Communication) | | | | Communication) | 182 | | | | | | | | 183 | | | | | | | | 184 +--------+---------+ +---------------+ +---------+--------+ 185 ^ v 186 | | 187 First Peer Communication Last Peer Communication 188 | | 189 +-----+-----+ +-----+-----+ 190 | NSIS | | NSIS | 191 | Initiator | | Responder | 192 +-----------+ +-----------+ 194 Figure 2: Involved Network Parts 196 NSIS hops. Additional threats may apply to NSIS communication where one 197 entity involved is an end-entity (initiator or responder) and the other 198 entity is any intermediate hop not being the first peer. This is 199 typically called end-to-middle scenario. The motivation for including 200 this configuration stems for example from the SIP [8] protocol. Any 201 intermediate SIP proxy may request a SIP end entity (UA) to 202 authenticate, countering a number of specific security threats. Such 203 functionality in general seems to be useful for intermediaries at the 204 borders of trust domains that signaling messages need to traverse. 205 Intermediate NSIS hops as well may have to deal with specific security 206 threats that do not (directly) relate to end-entities. Between such 207 intermediate hops, other such NSIS hops will typically be in the 208 signaling path. This scenario is called middle-to-middle. A generic 209 example are two NSIS hops at the border of their respective trust 210 domains with some form of trust relation. NSIS messages between these 211 hops may have to traverse one or more intermediate untrusted hops. 212 Figure 3 illustrates these additional scenarios. The first-peer case 213 discussed further above is covered by the peer-to-peer trust 214 relationships between end entity and closest hop, respectively. 216 **************************************** 217 * * 218 +----+-----+ +----------+ +----+-----+ 219 +-----+ NSIS +-------+ NSIS +--------+ NSIS +-----+ 220 | | Node 1 | | Node 2 | | Node 3 | | 221 | +----------+ +----+-----+ +----------+ | 222 | ~ | 223 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 224 | ~ | 225 +--+--+-----+ +---------+-+ 226 | NSIS +//////////////////////////////////////////+ NSIS | 227 | Initiator | | Responder | 228 +-----------+ +-----------+ 230 Legend: 231 -----: Peer-to-Peer Trust Relationship 232 /////: End-to-End Trust Relationship 233 *****: Middle-to-Middle Trust Relationship 234 ~~~~~: End-to-Middle Trust Relationship 236 Figure 3: Trust Relationships 238 First-Peer Communication: 240 First peer communication refers to the peer-to-peer 241 interaction between a signaling message originator, the NSIS 242 Initiator (NI), and the first NSIS aware entity along the 243 path. Assumptions about the threats, security requirements and 244 the available trust relationships may be difficult here. To 245 illustrate this, in many mobility environments it is difficult 246 to assume the existence of a pre-established security 247 association directly available for NSIS peers involved in 248 first-peer communication, as these peers cannot be assumed to 249 have any relation between each other in advance. For 250 enterprise networks, in contrast, the situation is different. 251 Usually there is a fairly strong (pre-established) trust 252 relationship between the peers. Enterprise network 253 administrators usually have some degree of freedom to select 254 the appropriate security protection and to enforce it. The 255 choice of selecting a security mechanism is therefore often 256 influenced by the already available infrastructure. Per- 257 session negotiation of security mechanisms is therefore often 258 not required (which, in contrast, is required for the mobility 259 case). 261 For first-peer communication, especially threats related to 262 initial security association setup, replay attacks, lack of 263 confidentiality, denial of service, integrity violation, 264 identity spoofing and fraud are applicable. 266 End-to-Middle Communication: 268 End-to-middle interaction in signaling may be required to e.g. 269 grant end-entities access to, or specific services in trust 270 domains different from the one the first peer belongs to. 271 Threats, in addition to these already discussed for first-hop 272 communication, may be untrusted intermediate NSIS hops that 273 maliciously alter NSIS signaling. These threats are still 274 relevant if security mechanisms are in place between the NSIS 275 hops, but terminate at each hop (e.g. IPsec hop-by-hop 276 protection). 278 Intra-Domain Communication: 280 After having been verified at the first peer, an NSIS 281 signaling message traverses the network within the same 282 administrative domain the first peer belongs to. Since the 283 request has already been authenticated and authorized threats 284 are different to those described above in a). To differentiate 285 first-peer communication with the intra-domain communication 286 (i.e. communication internally within one administrative 287 domain) we assume that no end hosts have direct access to the 288 internal network nodes, except the first peer. We furthermore 289 assume that NSIS peers within the same administrative domain 290 have at least some sort of trust relationship. 292 Inter-Domain Communication: 294 The threat assumptions between the borders of different 295 administrative domains largely depend on accounting procedures 296 (and therefore business relationships) in case of QoS 297 signaling, which is an important example application of NSIS 298 signaling. If one domain transmits forged QoS reservations 299 (for example stating a higher QoS reservation than a 300 aggregated number of user did) to the next domain then the 301 originating domain may also have to pay for the reservation. 302 Hence in this case, there is no real benefit for the first 303 network domain to forge a QoS reservation. If an end host is 304 directly charged by domains different to the first peer's 305 domain, then such an attack may be quite a reasonable threat. 306 However, security protection of messages transmitted between 307 different administrative domains is still necessary to tackle 308 attacks like spoofing, integrity violation, or denial of 309 service between these domains, e.g. to allow for proper 310 accounting. In case of securing signaling messages between 311 administrative domains, the number of domains is usually 312 rather limited (compared to first-peer communication) which 313 causes fewer problems for the key management. 315 Signaling information other than QoS service parameters such 316 as policy rules in case of middlebox communication demands 317 different assumptions for inter-domain communication. Trust 318 assumptions and business relationships are of particular 319 importance for their communication. 321 If signaling messages are transparent in the core network 322 (i.e. the are not intercepted and processed in the core 323 network) then the signaling message communication effectively 324 takes place between access networks. This might place a burden 325 on the key management infrastructure because of the global PKI 326 requirements. Hence this can be seen as a serious deployment 327 threat since it might be unacceptable for an access network 328 service provider to perform processing (QoS reservations, 329 policy rule installation at firewalls) due to unprotected 330 incoming signaling messages. 332 End-to-End Communication: 334 Providing end-to-end signaling message protection for NSIS 335 would cause difficulties for authentication and key 336 establishment procedures. It would furthermore limit the 337 flexibility of a signaling protocol in general. Functionality 338 such as terminating at an arbitrary location along the path, 339 delegating a signaling message exchange to other nodes, etc. 340 would be difficult to achieve in a secure fashion. Protecting 341 signaling messages end-to-end (in addition to peer-to-peer 342 security) is in our opinion rarely required. This is based on 343 the observation that end-to-end issues like charging and 344 payment selection (i.e. which user has to pay for which part 345 of a QoS reservation) are already securely negotiated by 346 preceding upper layer protocols (for example SIP). Information 347 carried within an NSIS signaling protocol for the purpose of 348 charging is therefore assumed opaque to the NSIS protocol 349 itself. Note that this observation makes some assumptions 350 about the charging model and about the existence of a protocol 351 interaction with AAA, QoS and an application layer protocol. 353 It is however possible to imagine a charging solution that 354 requires end-to-end protection of information delivered within 355 the NSIS signaling protocol. The following example requires 356 some sort of end-to-end protection: Alice wants Bob to pay for 357 a QoS reservation (reverse charging). Bob wants to be assured 358 that the QoS signaling message he receives was transmitted by 359 Alice because he is only willing to pay for particular users 360 and not for everyone. Hence Bob requires Alice to protect the 361 reservation request. 363 Regarding end-to-end security one additional issue needs to be 364 addressed - delegation. Whenever a signaling is addressed end- 365 to-end and an arbitrary node along the path acts as a proxy on 366 behalf of the other endpoint a delegation mechanism is 367 required to provide secure interaction. This obviously leads 368 to additional complexity in the area of end-to-end security, 369 as an additional set of threats becomes relevant. 371 Middle-to-middle: 373 We do not explicitly consider the middle-to-middle case here, 374 as this is already covered by either intra- or inter-domain 375 communication depending on the location of the involved 376 entities. 378 2 Threat Scenarios 380 This section provides threat scenarios that are applicable to signaling 381 protocols. Note that some threat scenarios use the term user instead of 382 NSIS Initiator. This is mainly because security protocols allow a 383 differentiation between entities being hosts and users (based on the 384 identities used). 386 2.1 MITM Attacks 388 Security protection of protocols is often separated into two steps. The 389 first step provides entity authentication and key establishment whereas 390 the second step provides message protection using the previously 391 established security association. The first step usually tends to be 392 more expensive than the second which is also the main reason for 393 separation. If messages are transmitted very infrequently then these two 394 steps are collapsed into a single and usually rather costly step. One 395 such example is e-mail protection via S/MIME. A good example for an 396 efficient two-step approach is provided by IPsec [9]. We use this 397 separation to cover the different threats in more detail. The first 398 paragraph describes security threats where two peers do not already 399 share a security association, or do not use security mechanisms at all. 400 The next paragraph describes threats which are applicable when a 401 security association is already established. Finally a denial of service 402 attack is described which is applicable to a signaling message when no 403 separation between SA establishment and signaling protection takes 404 place. 406 Various security threat are caused by a protocol performing dynamic node 407 discovery. These threats include Denial of Service attacks, which are 408 among other threats described in Section 2.9. Note that the threats are 409 largely independently of the discovery procedure (path discovery, next 410 peer discovery or topology discovery). 412 1. Attacks during NSIS SA Establishment 414 During the process of establishing a security association an 415 adversary fools the signaling message initiator with respect 416 to the entity to which it has to authenticate. The man-in-the- 417 middle adversary is able to modify signaling messages to mount 418 e.g. DoS attacks. In addition, it may be able to terminate 419 NSIS messages of the Initiator and inject messages to a peer 420 itself, therefore acting as the peer to the initiator and as 421 the initiator to the peer. This results in the initiator 422 wrongly believing that it talks to the "real" network whereas 423 it is actually attached to an adversary. For this attack to 424 be successful, pre-conditions have to hold which are described 425 with the following two cases: 427 - Missing Authentication 429 The first case addresses missing authentication between the 430 neighboring peers: Without authentication a NI, NR or NF is 431 unable to detect an adversary. However in some cases 432 protection available might be difficult to accomplish in a 433 practical environment either because the next peer is 434 unknown, because of misbelieved trust relationships in parts 435 of the network or because of the inability to establish 436 proper security protection (inter-domain signaling messages, 437 dynamic establishment of a security association, etc.). If 438 one of the communication endpoints is unknown then for some 439 security mechanisms it is either not possible or very 440 difficult to apply appropriate security protection. 441 Sometimes network administrators use intra-domain signaling 442 messages without proper security. Such a configuration would 443 then allow an adversary on a compromised non-NSIS aware node 444 to interfere with nodes running an NSIS signaling protocol. 445 Note that this type of threat goes beyond a threat caused by 446 malicious NSIS nodes (described in Section 2.8). 448 - Unilateral Authentication 449 In case of a unilateral authentication the NSIS entity that 450 does not authenticate its peer is unable to discover the 451 man-in-the-middle adversary. Although authentication of 452 signaling messages should take place between each peer 453 participating in the protocol operation special attention is 454 given here to first-peer communication. Unilateral 455 authentication between end hosts and the first peer is still 456 common today, but certainly opens up many possibilities for 457 MITM attackers impersonating either the end host or the 458 (administrative domain represented by the) first peer. 460 The two threats described above are a general problem of 461 network access without appropriate authentication, not only 462 for an NSIS signaling protocol. Obviously there is a strong 463 need to correctly address them in a future NSIS protocol. 464 The signaling protocols addressed by NSIS are different to 465 other protocols where only two entities are involved. Note, 466 that especially first-peer authentication is important, as 467 the impacts of a security breach likely reach beyond the 468 directly involved entities (or even beyond a local network). 470 Finally it should be noted that the signaling protocol 471 should be considered as a peer-to-peer protocol where the 472 roles of initiator and responder can be reversed at any 473 time. This leads to the conclusion that unilateral 474 authentication is not very useful for such a protocol. 475 However there might be a need to have some form of asymmetry 476 in the authentication process whereby one entity uses a 477 different authentication mechanism than the other one. As an 478 example the combination of symmetric and asymmetric 479 cryptography should be mentioned. 481 - Weak Authentication 483 This threat addresses weak authentication mechanisms whereby 484 information transmitted during the NSIS SA establishment 485 process may leak passwords and/or may allow offline 486 dictionary attacks. This threat is not specific to NSIS 487 signaling protocols but may also be applicable and 488 countermeasures must be taken. 490 2. Attacks during NSIS SA Usage 492 Once a security association is establish (and used to protect 493 signaling messages) basic attacks are prevented. However, a 494 malicious NSIS node is still able to perform various attacks 495 as described in Section 2.8. Replay attacks, which can be a 496 problem when a NSIS node crashes, restarts and performs state 497 re-establishment. Proper re-synchronization capability of the 498 security mechanism must therefore address this problem. 500 3. Combining Signaling and SA Establishment 502 This threat covers an attack which allows an adversary to 503 flood an NSIS node with bogus signaling messages to cause a 504 denial of service attack. 506 When a signaling message arrives at a NSIS aware network 507 element some processing is required. If this message contains 508 security objects such as digital signatures and not security 509 association is already available then some processing is 510 required for the cryptographic verification. Since NSIS 511 signaling should not require several roundtrips between two 512 NSIS peers it is difficult to provide DoS protection 513 mechanisms commonly found in authentication and key agreement 514 protocols. If signaling messages furthermore aim to be 515 idempotent and no security association should be created then 516 some cryptographic mechanisms should be used with precaution 517 (for example public key cryptography). 519 Additionally to the threat described above an incoming 520 signaling message might require time consuming processing 521 (computations, state maintenance, timer setting, etc) and 522 communication with third-party nodes including policy servers, 523 LDAP servers, etc. If an adversary is able to transmit a large 524 number of signaling message (for example with QoS reservation 525 requests) with invalid credentials then the verifying node may 526 not be able to process further reservation messages by 527 legitimate users. 529 2.2 Eavesdropping and Traffic Analysis 531 This threat cases covers adversaries which are able to eavesdrop 532 signaling messages but are unable to actively participate in signaling 533 message exchange (i.e. passive adversary). The collected signaling 534 packets may serve for the purpose of traffic analysis or to later mount 535 replay attacks as described in the Section 2.3. The eavesdropper might 536 learn QoS parameters, communication patterns, policy rules for firewall 537 traversal, policy information, application identifiers, user identities, 538 NAT bindings and more. 540 2.3 Adversary being able to replay signaling messages 542 This threat scenario covers the case where an adversary eavesdrops and 543 collects signaling messages and replays them at a latter point in time 544 (or at a different place, or uses parts of them at a different place or 545 in a different way - e.g. cut and paste attacks). Without proper replay 546 protection an adversary might mount man-in-the-middle, denial of service 547 and theft of service attacks. 549 A more difficult attack that may cause problems even in case of replay 550 protection requires the adversary to crash an NSIS aware node to loose 551 state information (sequence numbers, security associations, etc.) and to 552 be able to replay old signaling messages. This attack addresses re- 553 synchronization deficiencies. 555 2.4 Missing Protection of Authorization Information 557 Authorization is an important step for providing resources such as QoS 558 reservations, NAT bindings and pin-holed firewalls. Authorization 559 information might be delivered to the NSIS participating entities in a 560 number of ways. 562 One such approach is to use a successful authorization step done by a 563 different protocol in a later NSIS signaling message by providing some 564 sort of token. The functionality and structure of such an authorization 565 token for RSVP is described in [10] and in [11]. 567 The interaction between different protocols based on authorization 568 tokens, however, requires some care. Using such an authorization token 569 it is possible to link state information between different protocols. 570 Returning an unprotected authorization token to the end host might allow 571 an adversary (for example an eavesdropper) to steal resources. An 572 adversary might also use the token to learn communication patters. An 573 untrustworthy end host might also modify the token content. 575 Other authorization mechanisms might depend on availability of 576 sufficient funds and therefore real-time information. Deployment threats 577 of this kind are described in Section 2.14. The Session/Reservation 578 Ownership problem can also be considered as an authorization problem. 579 Details are described in Section 2.11. In enterprise networks 580 authorization is often coupled with membership to a particular class 581 user of users/groups. This type of information can either be delivered 582 as part of the authentication and key agreement procedure or has to be 583 retrieved via separate protocols from other entities. If an adversary 584 manages to modify information relevant for determining authorization or 585 the outcome of the authorization process itself then theft of service 586 might be the consequence. 588 2.5 Identity Spoofing 590 Identity spoofing relevant for NSIS appears in two flavors: First, 591 identity spoofing can appear during the establishment of a security 592 association if based on a weak authentication mechanism. 594 Eve, acting as an adversary, claims to be the registered user Alice by 595 spoofing the identity of Alice. Thereby Eve causes the network to charge 596 Alice for the consumed network resources. This type of attack is 597 possible if authentication is done based on a simple username identifier 598 (i.e. in absence of cryptographic authentication) or if authentication 599 is provided for hosts and multiple users have access to a single host. 600 This attack could also be classified as theft of service. 602 Second, an adversary is able to perform identity spoofing on transmitted 603 data packets. This type of attack is often labeled as IP spoofing. Since 604 most NSIS signaling messages contain some sort of flow identifier for 605 which a certain behavior is performed (e.g. particular flow experiences 606 QoS treatment or is allowed to bypass a firewall, etc.) an adversary 607 could mount an attack by modifying the flow identifier of a signaling 608 message. The following example tries to show an adversary using identity 609 spoofing of the first category: 611 An adversary is able to exploit the established flow identifiers 612 (required for QoS and Midcom specific signaling protocols). Some 613 identifiers such as IP addresses, transport protocol identifiers, port 614 numbers, flow labels (see [12] and [13]) and others are communicated in 615 these protocols. Modification of these flow identifiers cause quality of 616 service reservations or policy rules at middleboxes to be either 617 ineffective or beneficial for adversaries. 619 The following paragraph describes a possible threat caused by identity 620 spoofing of transmitted data traffic. The spoofed identity is thereby 621 the source IP addresses. For this attack to be successful accounting 622 records are collected based on the source IP address and not on a SPI 623 due to IPSec protection. After the network receives a properly protected 624 reservation request, transmitted by the legitimate user Alice, Traffic 625 Selectors are installed at the corresponding devices (for example edge 626 router). These Traffic Selectors are used for flow identification and 627 allow to match data traffic originated from a given source address to be 628 assigned to a particular QoS reservation. The adversary Eve now spoofs 629 the IP address of the Alice. Additionally Alice's host may be crashed by 630 the adversary as a result of a denial of service attack or lost 631 connectivity for example because of mobility reasons. If both nodes are 632 located at the same link and use the same IP address then obviously a 633 duplicate IP address will be detected. Assuming that only Eve is present 634 at the link then she is able to receive and transmit data (for example 635 RTP data traffic), which receives preferential QoS treatment based on 636 the previous reservation. Depending on the installed Traffic Selector 637 granularity Eve might have more possibilities to exploit the QoS 638 reservation or a pin-holed firewall. Assuming the soft state paradigm, 639 where periodical refresh messages are required, the absence of Alice 640 will not be detected until the next signaling message appears and forces 641 Eve to respond with a protected signaling message. Again this issue is 642 not only applicable to QoS traffic but the existence of QoS reservation 643 causes more difficulties since this type of traffic is more expensive. 644 The same procedure is also applicable to a Middlebox communication 645 protocol. 647 The ability for an adversary to inject data traffic which matches a 648 certain Traffic Selector established by a legitimate user often requires 649 the ability to also receive the data traffic. This is, however, only 650 true if the Traffic Selector consists of values which contain addresses 651 used for routing. If we imagine to use attributes for a Traffic Selector 652 where such a property is not required then identity spoofing and 653 injecting traffic is much easier. An adversary can use a nearly 654 arbitrary endpoint identifier to experience the desired result. 655 Obviously the endpoint identifiers are still not irrelevant since the 656 messages have to travel the same path through the network. DiffServ 657 marking of IP packets is such an example and others can be constructed 658 very easily. 660 Data traffic marking based on DiffServ is such an example. Whenever an 661 ingress router uses only marked incoming data traffic for admission 662 control procedures then various attacks are possible. These problems are 663 known in the DiffServ community for a long time and documented in 664 various DiffServ related documents. The IPSec protection of DiffServ 665 Code Points is described in Section 6.2 of [14]. Related security issues 666 (for example denial of service attacks) are described in Section 6.1 of 667 the same document. 669 2.6 Adversary being able to inject/modify messages 671 This type of threat addresses integrity violations whereby an adversary 672 modifies signaling messages (e.g. by acting as a man-in-the-middle 673 attacker) to cause an unexpected network behavior. Possible actions an 674 adversary might consider for its attack are reordering, delaying, 675 dropping, injecting and modifying. 677 An adversary may inject a signaling message requesting a large amount of 678 resources (possibly using a different user identity). Other resource 679 requests could then be rejected. In combination with identity spoofing 680 it is also possible accomplish fraud. This attack is only successful in 681 absence of signaling message protection. 683 Some directly related threats are described in Section 2.8, 2.5, 2.8 and 684 2.9. 686 2.7 Missing Non-Repudiation 688 Repudiation in this context refers to a problem where one party later 689 denies to have requested a certain action (such as a QoS reservation). 691 The problem of a missing non-repudiation property appears in two 692 flavors: 694 >From a service provider point-of-view the following threat may be worth 695 an investigation. A user may deny to have issued reservation request for 696 which it was charged. A service provider may then like to prove that a 697 particular user issued reservation requests. 699 The same threat can be interpreted from the users point-of-view. A 700 service provider claims to have received a number of reservation 701 requests. The user in question thinks that he never issued those 702 requests and wants to have a proof for correct service usage for a given 703 set of QoS parameters. 705 In today's telecommunication networks non-repudiation is not provided. 706 The user has to trust the network operator to correctly meter the 707 traffic, collect and merge accounting data and that no unforeseen 708 problems occur. If a signaling protocol is used to establish QoS 709 reservations with a higher volume (for example service level agreements) 710 then it might impact protocol design. 712 Looking at threats based on missing non-repudiation it must be carefully 713 considered whether non-repudiation is needed. Non-repudiation poses 714 additional requirements on the security mechanisms as it can only be 715 provided through public-key cryptography. As this would often increase 716 the overall cost for security, threats related to missing non- 717 repudiation are only considered relevant for certain specific scenarios 718 but not for the general NSIS scenario. 720 2.8 Malicious NSIS Entity 722 Network elements within a domain (intra-domain) experience a different 723 trust relationship with regard to the security protection of signaling 724 messages compared to edge routers. We assume that edge routers have the 725 responsibility to perform cryptographic processing (authentication, 726 integrity and replay protection, authorization and accounting) for 727 signaling message arriving from outside. This prevents signaling 728 messages to appear unprotected within the internal network. If however 729 an adversary manages to take over an edge router then the security of 730 the entire network is affected. An adversary is then able to launch a 731 number of attacks including denial of service, integrity violation, 732 replay attacks etc. In case of policy rule installation a rogue firewall 733 can cause harm to other firewalls by modifying the policy rules 734 accordingly. The chain-of-trust principle applied in the peer-to-peer 735 security protection cannot provide protection against a malicious NSIS 736 node. An adversary with access an NSIS router is then also able to get 737 access to security associations to transmit secured signaling messages. 738 Note that even non peer-to-peer security protection might not be able to 739 fully prevent this problem. Since an NSIS node might issue signaling 740 message on behalf of someone else (by acting as a proxy) additional 741 problems are the consequence. 743 An NSIS aware edge router is a critical component that requires strong 744 security protection. A strong security policy applied at edge does not 745 imply that all routers within an intra-domain network do not need to 746 cryptographically verify signaling messages. If the chain-of-trust 747 principle is deployed then the security protection of the entire path 748 (in this case within the network of a single administrative domain) is 749 as strong as the weakest link. In our case the edge router is the most 750 critical component of this network that may also act as a security 751 gateway/firewall for incoming/outgoing traffic. For outgoing traffic 752 this device has to act according to the security policy of the local 753 domain to apply the appropriate security protection. 755 For an adversary to mount this attack either an existing NSIS aware node 756 along the path has to be successfully attacked or an adversary succeeds 757 to convince another NSIS node to be the next NSIS peer (man-in-the- 758 middle attack). 760 2.9 Denial of Service Attacks 762 A number of denial of service attacks can cause NSIS nodes to 763 malfunction. Other attacks that could lead to DoS, such as man-in-the- 764 middle attacks, replay attacks, injection or modification of signaling 765 messages etc., are mentioned throughout this document. 767 1. Path Finding 769 This threat tries to address potential denial of service 770 attacks when the reservation setup is split into two phases 771 i.e. path and reservation (as for example used in receiver 772 based reservation setup). For this example we assume that the 773 node transmitting the path message is not charged for the path 774 message itself and is able to issue a high number of 775 reservation request (possibly in a distributed fashion). 776 Charging is activated only after successful verification of 777 the reservation request. The reservations are however never 778 intended to be successful because of various reasons: the 779 destination node cannot be reached; it is not responding or 780 simply rejects the reservation. An adversary can benefit from 781 the fact that resources are already consumed along the path 782 for various processing tasks including path pinning. 784 2. Discovery Phase 785 Signaling information to a large number of entities along a 786 data path requires some sort of discovery. This discovery 787 process is vulnerable to a number of attacks since it is 788 difficult to secure. An adversary can use the discovery 789 mechanisms to convince an entity to signal information to 790 another entity which is not along the data path or to cause 791 the discovery process to fail. In the first case the signaling 792 protocol could be correctly continued with the problem that 793 policy rules are installed at incorrect firewalls or QoS 794 resource reservations take place at the wrong entities. For an 795 end host this means that the protocol failed for unknown 796 reasons. 798 3. Faked Error/Response messages 800 An adversary may be able to use false error/response messages 801 as part of a denial of service attack. This could be either at 802 the message signaling protocol level, at the level of each 803 client layer protocol (QoS, Midcom, etc.) or at the transport 804 level protocol. An adversary might cause unexpected protocol 805 behavior or produce denial of service attacks. Especially the 806 discovery protocol shows vulnerabilities with regard to this 807 threat. In case that no separate discovery protocol is used by 808 addressing signaling messages to end hosts only (with a Router 809 Alert Option to intercept message as NSIS aware nodes) then an 810 error message might be used to indicate a path change. Such a 811 design is a combination of a discovery protocol together with 812 a signaling message exchange protocol. 814 2.10 Disclosing the network topology 816 In some architectures there is a desire not to reveal the internal 817 network structure (or other related information) to the outside world. 818 An adversary might be able to use NSIS messages for network mapping 819 (e.g. discovering which nodes exist, which use NSIS, what version, what 820 resources are allocated, capabilities of nodes along a paths etc.). 821 Discovery messages, traceroute, diagnostic messages (see [14] for a 822 description of diagnostic message functionality for RSVP), query 823 messages in addition to record route and route objects provide the 824 potential to assist an adversary. Hence the requirement of not 825 disclosing a network topology might conflict with another requirement to 826 provide means for automatically discovering NSIS aware nodes or to 827 provide diagnostic facilities (used for network monitoring and 828 administration). 830 2.11 Session/Reservation Ownership 831 Figure 4 shows an NSIS Initiator which established state information at 832 NSIS nodes along the path as part of the signaling procedure. As a 833 result the Access Router1 Router 3 and Router 4 (and other nodes) store 834 session state information including the Session Identifier SID-x. 836 Session ID(SID-x) 837 +--------+ 838 +-----------------+ Router +------------> 839 Session ID(SID-x)| | 4 | 840 +---+----+ +--------+ 841 | Router | 842 +------+ 3 +******* 843 | +---+----+ * 844 | * 845 | Session ID(SID-x) * Session ID(SID-x) 846 +---+----+ +---+----+ 847 | Access | | Access | 848 | Router | | Router | 849 | 1 | | 2 | 850 +---+----+ +---+----+ 851 | * 852 | Session ID(SID-x) * Session ID(SID-x) 853 +----+------+ +----+------+ 854 | NSIS | | Adversary | 855 | Initiator | | | 856 +-----------+ +-----------+ 858 Figure 4: Session/Reservation Ownership 860 The Session Identifier is included in signaling messages to reference to 861 the established state. 863 If an adversary was able to obtain the Session Identifier for example by 864 eavesdropping signaling messages it is able to add the same Session 865 Identifier SID-x to a new a signaling message. When the signaling 866 message hits Router3 (as shown in Figure 3) then existing state 867 information can be modified. The adversary can then modify or delete the 868 established reservation causing unexpected behavior for the legitimate 869 user. 871 The source of the problem is that Router3 (cross-over router) is unable 872 to decide whether the new signaling message was initiated from the owner 873 of the session/reservation. 875 To make processing even more difficult it must be mentioned that not 876 only the initial signaling message originator is allowed to signal 877 information during the lifetime of an established session. As part of 878 the protocol any NSIS aware node along the path (and the path might 879 change over time) could be involved in the signaling message exchange 880 and it might be necessary to provide mobility support or to trigger a 881 local repair procedure. Hence if only the initial signaling message 882 originator is allowed to trigger signaling message exchange some 883 protocol behavior will not be possible. 885 In case that this threat is not addressed an adversary can launch denial 886 of service, theft of service, and various other attacks. 888 2.12 Security Parameter Exchange/Negotiation 890 Protocols, which should be useful for a variety of scenarios, tend to 891 have different security requirements. It is often difficult to meet 892 these (sometimes conflicting requirements) with a single security 893 mechanism or a fixed security parameter. Hence often a few selected 894 mechanisms/parameters are supported. Therefore some protocol exchange is 895 required to agree on some security mechanisms/parameters. This protocol 896 exchanged can be the misused by an adversary to mount a downgrading 897 attack by selecting weaker mechanisms than desired. Hence without 898 protecting the negotiation process the security of an NSIS protocol 899 might be as secure as the weakest mechanism if no configuration 900 parameters (for example a security policy disallowing the weakest 901 mechanism, etc.) are used otherwise. 903 2.13 Attacks against the signaling message transport mechanism 905 In [15] a two-level architecture is proposed which suggests to split an 906 NSIS protocol into layers: a signaling message transport specific layer 907 and an application specific layer. This architectural assumptions is 908 also considered within the NSIS framework [7]. Most of the threats 909 described in this document are applicable to the application specific 910 part for signaling QoS or middlebox specific information. There are, 911 however, some threats which are applicable to the transport of signaling 912 messages. 914 Network or transport layer protocols which experience no protected are 915 vulnerable to certain attacks such as header manipulation, DoS, spoofing 916 of identities, session hijacking, unexpected aborts etc. 918 In case that an existing protocol is used for exchanging NSIS signaling 919 messages then threats known from these protocols are relevant. 921 2.14 Deployment Threats 923 This section addresses problems which could appear during the deployment 924 of an NSIS protocol in a real-world environment. Although these problems 925 are theoretically not an obstacle for practical reasons they can 926 represent threats worth a consideration. 928 Missing Authorization: 930 Authentication is a very important step for providing the 931 foundation of authorization and accounting. Unlike some other 932 protocols (for example HTTPS) where an authorization 933 verification step is fairly easy (and efficient) QoS and 934 middlebox communication requires more care. First, there is 935 the question what authorization means in the context of NSIS 936 signaling. For quality of service signaling the possible range 937 is broad and could range from pure monetary policies to 938 traditional role-based access control policies. Second, there 939 is a question where this authorization data can be retrieved. 940 Especially in a mobile environment this might be more 941 complicated to securely exchange this information between 942 different network domains. Finally there is an issue of 943 authorization representation (i.e. a language describing 944 authorization policies). If authorization information is 945 exchanged between a large number of networks then this issue 946 deserves further consideration. 948 In the discovery phase an additional issue of authorization 949 was raised. Whenever a node wants to discover the next NSIS 950 aware node then authentication might not be sufficient. In 951 many cases the IP address or FQDN of a particular router in an 952 unknown network does not add too much trust. An end host for 953 example might want some assurance that this node belongs to a 954 network which has some sort of business relationship which is 955 known and acceptable (from an accounting, charging, security 956 and privacy point of view). 958 Missing Cost Control: 960 There is a risk that a large number of service providers with 961 complex roaming agreements create a non-transparent cost- 962 structure. In a traditional subscription-based scenario users 963 are registered with their home networks and use this trust 964 relationship to dynamically establishment other security 965 associations. This is the typical AAA deployment scenario. In 966 these scenarios users do not learn the identity of the access 967 network as part of a regular authentication and key exchange 968 protocol message exchange. The identity of the access network 969 is possibly never revealed (in a secure fashion). The user is 970 therefore only authenticated to the home network (and 971 hopefully vice versa). When issuing a QoS reservation request 972 to the next NSIS peer (for example in the access network) the 973 end host is typically unaware of the cost of such a 974 reservation. Due to mobility and route changes along the path 975 the cost for an end-to-end QoS reservation might not be 976 transparent for the end host or even become unacceptable. 978 Today there is no standarized protocol available which allows 979 users to communicate cost limits, to request cost information 980 for network resources or to learn already accumulated costs 981 for a particular reservation. 983 Especially in mobility environments where an end host is 984 likely to have access to a large number of networks within a 985 short time period cost control is even more complicated. 987 Some mobility/QoS protocol proposals try to merge existing 988 mobility protocols with QoS signaling (i.e. to apply in-band 989 signaling). Thereby the access network is queried (towards the 990 cross-over router or the MAP) for the possibility making a QoS 991 reservation (without actually making the reservation itself). 992 Without a query mechanism a user cannot take reservation costs 993 into account when choosing between different access networks 994 (or different access routers). Hence the user might not be 995 unable to refuse a more expensive service provider. To allow a 996 user to choose between different providers might be required 997 not only because of the availability of different access 998 technologies (e.g. IEEE 802.1x, Bluetooth, UTRAN) and the 999 different service quality offered but also for cost reasons. 1001 Although real-time notifications of quality of service 1002 reservation costs (cost control) to the user are outside the 1003 scope of NSIS some interaction might be required. 1005 3 Security Considerations 1007 This entire memo discusses security issues relevant for NSIS. To counter 1008 these threats security requirements have been defined and the framework 1009 relevant topics have been described. Some additional threats applicable 1010 for first peer communication in mobile environments are described in 1011 [16]. 1013 4 Acknowledgements 1015 We would like to thank (in alphabetical order) Marcus Brunner, Jorge 1016 Cuellar, Mehmet Ersue, Xiaoming Fu and Robert Hancock for their comments 1017 to this draft. Jorge and Robert gave us an extensive list of comments 1018 and provided information on additional threats. 1020 5 Authors' Addresses 1022 Hannes Tschofenig 1023 Siemens AG 1024 Otto-Hahn-Ring 6 1025 81739 Munich 1026 Germany 1027 EMail: Hannes.Tschofenig@siemens.com 1029 Dirk Kroeselberg 1030 Siemens AG 1031 Otto-Hahn-Ring 6 1032 81739 Munich 1033 Germany 1034 EMail: Dirk.Kroeselberg@siemens.com 1036 6 Bibliography 1038 [1] X. Fu, C. Kappler, and H. Tschofenig, "Analysis on RSVP regarding 1039 multicast," Internet Draft, Internet Engineering Task Force, June 2002. 1040 Work in progress. 1042 [2] H. D. Meer et al. , "Analysis of existing qos solutions," Internet 1043 Draft, Internet Engineering Task Force, July 2002. Work in progress. 1045 [3] H. Tschofenig, "Rsvp security properties," Internet Draft, Internet 1046 Engineering Task Force, 2002. Work in progress. 1048 [4] M. Thomas, "Analysis of mobile ip and rsvp interactions," Internet 1049 Draft, Internet Engineering Task Force, 2002. Work in progress. 1051 [5] J. Manner and X. Fu, "Analysis of existing quality of service 1052 signaling protocols," Internet Draft, Internet Engineering Task Force, 1053 2002. Work in progress. 1055 [6] M. Brunner, "Requirements for QoS signaling protocols," Internet 1056 Draft, Internet Engineering Task Force, July 2002. Work in progress. 1058 [7] R. Hancock, I. Freytsis, G. Karagiannis, J. Loughney, and S. V. den 1059 Bosch, "Next steps in signaling: Framework," Internet Draft, Internet 1060 Engineering Task Force, 2002. Work in progress. 1062 [8] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 1063 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session 1064 initiation protocol," RFC 3261, Internet Engineering Task Force, June 1065 2002. 1067 [9] S. Kent and R. Atkinson, "Security architecture for the internet 1068 protocol," RFC 2401, Internet Engineering Task Force, Nov. 1998. 1070 [10] L. Hamer, B. Gage, M. Broda, B. Kosinski, and H. Shieh, "Session 1071 authorization for RSVP," Internet Draft, Internet Engineering Task 1072 Force, July 2002. Work in progress. 1074 [11] L. Hamer, B. Gage, and H. Shieh, "Framework for session set-up with 1075 media authorization," Internet Draft, Internet Engineering Task Force, 1076 July 2002. Work in progress. 1078 [12] C. Partridge, "Using the flow label field in IPv6," RFC 1809, 1079 Internet Engineering Task Force, June 1995. 1081 [13] J. Rajahalme, A. Conta, B. Carpenter, and S. Deering, "IPv6 flow 1082 label specification," Internet Draft, Internet Engineering Task Force, 1083 June 2002. Work in progress. 1085 [14] A. Terzis, B. Braden, S. Vincent, and L. Zhang, "RSVP diagnostic 1086 messages," RFC 2745, Internet Engineering Task Force, Jan. 2000. 1088 [15] B. Braden and B. Lindell, "A two-level architecture for internet 1089 signaling," Internet Draft, Internet Engineering Task Force, Nov. 2001. 1090 Work in progress. 1092 [16] J. Kempf and E. Nordmark, "Threat analysis for IPv6 public multi- 1093 access links," Internet Draft, Internet Engineering Task Force, June 1094 2002. Work in progress. 1096 Table of Contents 1098 1 Introduction . . . . . . . . . . . . . . . . . . . . . . 2 1099 1.1 NSIS Security Process . . . . . . . . . . . . . . . . . . 2 1100 1.2 Relevant communication models . . . . . . . . . . . . . . 4 1101 2 Threat Scenarios . . . . . . . . . . . . . . . . . . . . 9 1102 2.1 MITM Attacks . . . . . . . . . . . . . . . . . . . . . . 9 1103 2.2 Eavesdropping and Traffic Analysis . . . . . . . . . . . 12 1104 2.3 Adversary being able to replay signaling messages . . . . 12 1105 2.4 Missing Protection of Authorization Information . . . . . 13 1106 2.5 Identity Spoofing . . . . . . . . . . . . . . . . . . . . 13 1107 2.6 Adversary being able to inject/modify messages . . . . . 15 1108 2.7 Missing Non-Repudiation . . . . . . . . . . . . . . . . . 15 1109 2.8 Malicious NSIS Entity . . . . . . . . . . . . . . . . . . 16 1110 2.9 Denial of Service Attacks . . . . . . . . . . . . . . . . 17 1111 2.10 Disclosing the network topology . . . . . . . . . . . . . 18 1112 2.11 Session/Reservation Ownership . . . . . . . . . . . . . . 18 1113 2.12 Security Parameter Exchange/Negotiation . . . . . . . . . 20 1114 2.13 Attacks against the signaling message transport 1115 mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 1116 2.14 Deployment Threats . . . . . . . . . . . . . . . . . . . 21 1117 3 Security Considerations . . . . . . . . . . . . . . . . . 22 1118 4 Acknowledgements . . . . . . . . . . . . . . . . . . . . 22 1119 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . 23 1120 6 Bibliography . . . . . . . . . . . . . . . . . . . . . . 23