idnits 2.17.1 draft-ietf-nsis-threats-00.txt: -(742): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 9 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 59 lines 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 191 has weird spacing: '...vations to ne...' -- 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 (October 2002) is 7864 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Downref: Normative reference to an Informational RFC: RFC 1809 (ref. '6') -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NSIS Working Group 3 Internet Draft Hannes Tschofenig 4 Document: draft-ietf-nsis-threats-00.txt Siemens AG 5 Expires: April 2003 October 2002 7 NSIS Threats 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance 13 with all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 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 23 material 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 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 NSIS Threats October 2002 32 Abstract 34 This threats document provides a starting point to security 35 discussions at the NSIS working group. It therefore tries to help the 36 NSIS interested reader to understand various security considerations 37 in the NSIS Requirements, Framework and Protocol proposals. This 38 document does not describe vulnerabilities of specific NSIS related 39 protocols. 41 1 Introduction 43 Section 1.1 tries to introduce the reader into the overall process of 44 addressing the security of work done in the NSIS working group. 45 Section 1.2 gives a big picture about the different network parts 46 which are traversed by a signaling protocol. Each part is 47 characterized by a different set of requirements and different trust 48 relationships. The threats described in Section 2 can be assigned to 49 the individual parts. 51 Note that this document tries to use the terminology introduced and 52 used in the NSIS Framework document [5]. Some of the terms which 53 demand additional clarifications are briefly explained introduced in 54 Section 1.3 56 1.1 NSIS Security Process 58 Whenever a new protocol has to be developed or existing protocols 59 have to be modified potential security threats should be evaluated. 60 The process of securing protocols in separated into individual steps. 61 To address security in the NSIS working group a number of documents 62 have been produced: 64 +----------------------------------------------+ 65 | NSIS Analysis Activities | 66 | (e.g. RSVP Security Properties) | 67 +----------------------------------------------+ 68 +----------------------------------------------+ 69 | NSIS Threats | 70 | | 71 +----------------------------------------------+ 72 +----------------------------------------------+ 73 | NSIS Requirements | 74 | | 75 +----------------------------------------------+ 76 +----------------------------------------------+ 77 | NSIS Framework Activities | 78 | | 79 +----------------------------------------------+ 80 +----------------------------------------------+ 81 | Published | 82 | NSIS Protocol Proposals | 83 +----------------------------------------------+ 84 Figure 1: NSIS Security related Documents 85 NSIS Threats October 2002 87 In order to reach a satisfactory security protection for a NSIS 88 protocol a number of steps are necessary. The relevant information is 89 distributed over a number of documents as depicted in Figure 1. The 90 purpose of each of these documents is briefly described below to give 91 the reader a more insights into the development process. 93 The primary goal of the NSIS analysis activity is the investigation 94 of existing approaches in the area of quality of service signaling 95 protocols. Several of the published approaches contain directly 96 security relevant descriptions whereas other requirements can be 97 derived from different protocol behavior or different scenarios in 98 which such a protocol is used. Document [8] points to the reduced 99 complexity if RSVP is used without multicast support. This 100 modification also comes with some simplifications for security 101 handling. In [10] security issues raised by some example 102 configurations are given. In [9] the security properties of RSVP are 103 described. There are, however, a number of other analysis documents 104 available but they do not directly address security issues. 106 Threats relevant for NSIS are discussed in this document. 108 To address threats described in this document requirements were 109 specified in the NSIS Requirements document [1]. In addition to the 110 requirements the document describes some basic scenarios where a QoS 111 signaling protocol might be deployed. 113 Signaling information to a number of devices located in different 114 parts in the network with different trust assumptions and possible 115 interactions with a large number of other protocols require some 116 framework thoughts. A few proposals were submitted and a few authors 117 cooperatively produced a NSIS framework document [5], which also 118 address security issues. 120 Finally there are documents describing concrete protocol proposals. 121 These proposals either rely on existing security mechanisms or 122 develop their own if the existing mechanisms cannot be solve all 123 security threats or if they are inappropriate for other reasons. In 124 practice a protocol proposal might use existing security mechanisms 125 but is likely to require some additional protection mechanisms or to 126 combine them in a specific manner. 128 Note that the process of developing the above-mentioned documents is 129 not linear. Instead various iterations are required to reach a 130 satisfactory final status. 132 This document tries to identify the basic threats that need to be 133 addressed by the NSIS signaling protocol design. Although the base 134 protocol might be secure, some extensions may cause problems when 135 used in a particular environment. Furthermore it is necessary to 136 investigate the context in which a signaling protocol is used and the 137 architecture where it is integrated. As an example of such an 138 interaction accounting and charging is often mentioned in 139 relationship with QoS signaling protocols. Without an appropriate 140 integration of the two there is no good incentive for network 141 NSIS Threats October 2002 143 operators to deploy QoS signaling protocols. This interaction is 144 subject of a framework and some aspects are discussed in [5]. 146 1.2 Involved Network Parts 148 Independent of the threat scenarios described in Section 2 end-to-end 149 signaling messages traverse different network parts, which demand 150 different security mechanisms caused by the difference in trust 151 relationships. The sub-parts are: access network part, intra and 152 inter-domain part, and finally end-to-end communication. These parts 153 are briefly described in this section and the threat scenarios of 154 Section 2 can be assigned to the individual parts. 156 a) Access Network (or First-Peer) Communication 158 The term access network is fuzzy but in this context we refer to the 159 communication between an end host and the first NSIS aware entity in 160 the network to which this host is attached. Therefore threats are 161 addressed where an NSIS Initiator (NI) transmits and receives 162 signaling messages to some entity in the access network. In many 163 mobility environments it is difficult to assume the existence of a 164 pre-established trust relationship between a user and the access 165 network. 167 Threat scenarios dealing with initial security association setup, 168 replay attacks, lack of confidentiality, denial of service, integrity 169 violation, identity spoofing and fraud are applicable. From a 170 security point of view this part of the network causes the largest 171 number of problems. 173 b) Intra-Domain Communication 175 After receiving a NSIS signaling message and verifying the request 176 somewhere in the access network the signaling message traverses the 177 network within the same administrative domain. Since the request has 178 already been authenticated and authorized threats are different 179 compared to those described in the previous section. To differentiate 180 the end-node-to-access network interface with the intra-domain 181 communication we assume that no user hosts are logically attached to 182 the core-network. (That is: the interface between any host and the 183 first router is part of the access network). We furthermore assume 184 that nodes within one administrative domain have a stronger trust 185 relationship between each other. 187 c) Inter-Domain Communication 189 The threat assumptions between the borders of different 190 administrative domains largely depends on how accounting is done. If 191 one domain transmits forged QoS reservations to next domain then it 192 is likely that the originating network domain has also has to pay for 193 the reservation. Hence in this case, there is no real benefit for the 194 first network domain to forge a QoS reservation. But if an end-node 195 is directly charged by intermediate domains then this kind of attack 196 may be reasonable. Security protection of messages transmitted 197 NSIS Threats October 2002 199 between different administrative domains is still necessary to tackle 200 attacks like spoofing, integrity violation, denial of service etc. 201 The lower number of networks and higher trust relationship (compared 202 in the access network case), the fewer problems for key management 203 arise. 205 d) End-to-End Communication 207 In our opinion end-to-end security for NSIS signaling messages (in 208 addition to hop-by-hop security) is rarely required if we assume that 209 end-to-end issues like charging and the selection which user has to 210 pay for a reservation is already securely negotiated by preceding 211 upper layer protocols (for example SIP). Information carried within a 212 NSIS signaling protocol for the purpose of charging is therefore 213 assumed opaque to the NSIS protocol itself and appropriately 214 protected as part of the AAA interaction. Note however that this 215 assumption strongly depends on the chosen solution of a protocol 216 interaction with AAA, QoS and application layer protocol. It is 217 however possible to select a charging solution that requires end-to- 218 end protection of information delivered within the QoS signaling 219 protocol. 221 The following example requires some sort of end-to-end protection: 222 Alice wants Bob to pay for the QoS reservation (reverse charging). 223 Bob wants to be assured that the QoS signaling message he receives 224 was transmitted by Alice because he is only willing to pay for 225 particular users and not for everyone. Hence Bob requires Alice to 226 protect the reservation request. 228 Regarding end-to-end security one additional issue needs to be 229 clarified. Whenever a signaling protocol travels end-to-end and a 230 node along the path acts on behalf of the other endpoint then further 231 investigation is required how to solve this issues. 233 1.3 Clarification 235 Some threat scenarios in this document use the term user instead of 236 NSIS Initiator. This is mainly due to the fact that security 237 protocols allow a differentiation between entities being hosts and 238 users (based on the identities used). Since the NSIS Initiator as 239 used in [5] also allows to act on behalf of various entities 240 including a network it is reasonable to distinguish between these 241 identities. 243 The term access network is used for networks to which a mobile node 244 is attached. Other terms often used in this context are foreign or 245 visited network. The missing direct trust relationship between the 246 mobile node and the access network complicates authentication and key 247 agreement. Usually AAA protocols (like Radius or Diameter) are used 248 to provide the initial authentication and key establishment. These 249 protocols take advantage of the AAA infrastructure (AAAL, AAAH, 250 Broker, etc.) and trust relationships between the access network and 251 the users home network. This trust relationship is usually based on 252 some sort of business contract. The trust relationship between the 253 NSIS Threats October 2002 255 two networks is considered to be symmetric (network A trusts network 256 B and vice versa) whereas the dynamically established trust 257 relationship between the mobile node and the access network is often 258 asymmetric. In today's network a mobile node has to trust the access 259 network with regard to collection and processing of accounting data. 260 The access network usually does not trust attached end-hosts. 262 The term security association is used to describe established 263 security-relevant data structure between two entities. This data 264 structure consists of keys, algorithms including their parameters, 265 values used for replay protection etc. Using this information two (or 266 more) nodes are able to protect signaling messages. 268 2 Threat Scenarios 270 This section provides threat scenarios that are applicable to 271 signaling protocols. 273 2.1 Lack of Authentication and Man-in-the-Middle Attacks 275 This section describes man-in-the-middle attacks of the following 276 type: During the process of establishing a security association an 277 adversary fools the signaling message initiator with respect to the 278 entity to which it has to authenticate. The man-in-the-middle 279 adversary is able to modify signaling messages to mount DoS attacks. 280 The signaling message initiator wrongly believes that it talks to the 281 �real� network whereas it is actually attached to an adversary. 282 For this attack to be successful, pre-conditions have to hold which 283 are described with the following two cases: 284 a) Missing Authentication 286 The first case addresses missing authentication between the 287 neighboring peers: Without authentication a NI, NR or NF is unable to 288 detect an adversary. However in some cases protection available might 289 be difficult to accomplish in a practical environment either because 290 the other peer of the communication is unknown or because of 291 misbelieved trust relationships in parts of the network. If one of 292 the communication endpoints is unknown then for some security 293 protocols it is not possible or difficult to select the appropriate 294 security association. Sometimes network administrators refuse to 295 consider security protection of intra-domain signaling messages. Such 296 a configuration would then allow an adversary at a compromised node 297 to cause security problems. Even if there was no intention that this 298 compromised node actively participates in the signaling message 299 exchange its interference cannot be prevented. 301 b) Unilateral Authentication 303 In case of only unilateral authentication the NI is not able to 304 discover the man-in-the-middle adversary. Although authentication of 305 signaling message should take place between each peer participating 306 in the protocol operation special focus is given to the communication 307 in the end host and the access network. 309 NSIS Threats October 2002 311 The two threats described above are a general problem of network 312 access without appropriate authentication, not only for an NSIS 313 signaling protocol. Obviously there is a strong need to correctly 314 address them in a future NSIS protocol. The signaling protocols 315 addressed by NSIS are different to other protocols where only two 316 entities are involved. The impacts of a security breach likely reach 317 beyond the directly involved entities (or even beyond a local 318 network). 320 Finally it should be noted that the signaling protocol should be 321 considered as a peer-to-peer protocol where the roles of initiator 322 and responder can be reversed at any time. This leads to the 323 conclusion that unilateral authentication is not very useful for such 324 a protocol. However there might be a need to have some form of 325 asymmetry in the authentication process whereby one entity uses a 326 different authentication mechanism than the other one. As an example 327 the combination of symmetric and asymmetric cryptography should be 328 mentioned. 330 2.2 Missing Authorization 332 Authentication as described in Section 2.1 is a very important step 333 for providing the foundation for authorization and accounting. Unlike 334 some other protocols where authorization can be verified without huge 335 difficulties NSIS protocols might experience some difficulties. First 336 there is the question what authorization means in the context of NSIS 337 signaling and particularly for quality of service and middlebox 338 communication. The possible range is broad and could range from pure 339 monetary policies to traditional role-based access control policies. 340 Second there is a question where this authorization data can be 341 retrieved. Especially in a mobile environment this might be more 342 complicated to securely exchange this information between different 343 network domains. Finally there is an issue of representing 344 authorization information if it has to be shared between a number of 345 network domains. 347 Currently the above-mentioned issues have not been appropriately 348 addressed and might cause obstacles for deployment. 349 In a discovery phase an additional issue of authorization was raised. 350 Whenever a node wants to discover the next NSIS aware node then 351 authentication might not be sufficient. In many cases the IP address 352 or FQDN of a particular router in an unknown network does not add too 353 much trust. An end host for example might want some assurance that 354 this node belongs to a network with which some sort of business 355 relationship (directly or indirectly) is available. 357 2.3 Missing Cost Control 359 This type of threat addresses a deployment problem of QoS signaling 360 in a real-world environment. It is not a particular attack. A large 361 number of service providers with complex roaming agreements create a 362 non-transparent cost-structure. Using AAA protocols in a 363 subscription-based scenario. In a traditional subscription-based 364 NSIS Threats October 2002 366 scenario users are registered with their home networks and use this 367 trust relationship to dynamically establish other security 368 associations. In these scenarios users do not learn the identity of 369 the access network as part of a regular message exchange. The user is 370 therefore only authenticated to the home network (and hopefully vice 371 versa). The identity of the access network is possibly not revealed. 372 When issuing a reservation request to an entity in the access network 373 the end-user does not know the cost of such a reservation. 374 Furthermore due to mobility and route changes along the path the 375 costs for an end-to-end QoS reservation might not be transparent or 376 unacceptable. 378 Today there is no protocol available which allows users to 379 communicate cost limits, to request costs for network resources or to 380 learn the currently accumulated costs for a particular reservation. 382 Especially in mobility environments where many networks might be 383 contacted in a short period of time cost control is even more 384 complicated. 386 Some proposals which try to merge mobility protocols with QoS 387 signaling probe the access network (towards the cross-over router or 388 the MAP) for the possibility making a QoS reservation (without 389 actually making the reservation itself). Without a query mechanism a 390 user cannot take reservation costs into account when choosing between 391 different access networks. Hence the user might not be unable to 392 refuse the more expensive service provider. To allow a user to choose 393 different providers might be required not only because of the 394 availability of different access technologies (either using a WLAN 395 card to access the local network or to use UMTS/UTRAN based 396 technology) and the different service quality offered but also for 397 cost reasons. 399 Although real-time notifications of quality of service reservation 400 costs (cost control) to the user are outside the scope of a quality 401 of service signaling protocol itself some interactions might be 402 required. Note that payment issues should be discussed independently 403 of cost-control since other mechanisms are required to negotiate 404 which involved party actually has to pay the costs (and how). 406 2.4 Eavesdropping and Traffic Analysis 408 This section covers two threats: The first is related to privacy 409 concerns whereas the second addresses problems caused by weak 410 authentication mechanisms and the increased risk of eavesdropping on 411 the wireless link in absence of appropriate confidentiality 412 protection. 414 The first threat case covers adversaries which are able to eavesdrop 415 signaling messages but are unable to actively participate in the QoS 416 signaling (i.e. passive adversary). The collected signaling packets 417 may serve for the purpose of traffic analysis or to later mount 418 replay attacks as described in the next section. By eavesdropping an 419 adversary might violate a user's privacy preference. Especially QoS 420 NSIS Threats October 2002 422 signaling messages provide information that may be interesting for an 423 adversary since the messages reveal user and/or application 424 identities, policy information, information about the desired QoS 425 reservation, etc. The information gathered by an adversary can be 426 used to learn communication patterns of users requesting resources 427 (QoS, firewall, NAT, etc.). 429 An adversary might be able to use the signaling protocol to discover 430 the topology of a network (e.g. using record route). Additionally it 431 might be possible to obtain diagnostic information usually used for 432 network monitoring and administration. Other options might allow an 433 adversary to route signaling messages specifically along a particular 434 route similar to source routing. 436 The second threat case addresses weak authentication mechanisms 437 whereby information transmitted within the QoS signaling protocol may 438 leak passwords and may allow offline dictionary attacks. This threat 439 is not specific to QoS signaling protocols but may also be applicable 440 and countermeasures must be taken. 442 2.5 Adversary being able to replay signaling messages 444 This threat scenario covers the case where an adversary eavesdrops 445 and collects signaling messages and replays them at a latter point in 446 time (or at a different place, or uses parts of them at a different 447 place or in a different way � e.g. cut and paste attacks). Without 448 proper replay protection an adversary might be able to mount denial 449 and/or theft of service attacks. 451 A more difficult attack that may cause problems even in case of 452 replay protection requires the adversary to crash a NSIS aware node 453 to loose state information (sequence numbers, security associations, 454 etc.) and to be able to replay old signaling messages. 456 Additionally it should be mentioned that the interaction between 457 different protocols based on authorization tokens requires some care. 458 Using such an authorization token it is possible to link state 459 information between different protocols. Returning an authorization 460 token to the end host might allow an adversary to steal resources 461 without proper protection of the token delivery or without proper 462 verification of the hopefully protected content of the token. The 463 functionality and structure of such an authorization token for RSVP 464 is described in [3] and in [4]. 466 2.6 Identity Spoofing 468 The following paragraph gives an example of an adversary using 469 identity spoofing: 471 Eve, acting as an adversary, claims to be the registered user Alice 472 by spoofing the identity of Alice. Thereby Eve causes the network to 473 charge Alice for the consumed network resources. Using unprotected 474 signaling messages Eve may experience no particular problems in 475 succeeding. This attack can be classified as theft of service. 477 NSIS Threats October 2002 479 If a signaling message is properly protected the adversary is unlike 480 to succeed. 482 A non-traditional identity spoofing attack exploits flow 483 classification (required for QoS and Midcom specific signaling 484 protocols). Some identifiers such as IP addresses, transport protocol 485 identifiers, port numbers, flow labels [6, 7] and others are 486 communicated in these protocols and represent an attractive target 487 for an adversary. Modification of these flow identifiers cause 488 quality of service reservations or policy rules at middleboxes to be 489 either ineffective or beneficial for adversaries. 491 Additional concerns might occur if end hosts perform traffic marking 492 (for example by using a DSCP). Whenever an ingress router uses only 493 marked incoming data traffic for admission control procedures then 494 various attacks are possible. These problems are known in the 495 DiffServ community for a long time and documented in various DiffServ 496 related documents. The IPSec protection of DiffServ Code Points is 497 described in Section 6.2 of [11]. Related security issues (for 498 example denial of service attacks) are described in Section 6.1 of 499 the same document. 501 The following paragraph describes a possible threat caused by 502 identity spoofing of transmitted data traffic. The spoofed identity 503 is thereby the source IP addresses. Assume that accounting records 504 are collected based on the source IP address and not on a SPI due to 505 IPSec protection. After the network receives a properly protected 506 reservation request, transmitted by the legitimate user Alice, 507 Traffic Selectors are installed at the corresponding devices (for 508 example edge router). These Traffic Selectors are used for flow 509 identification and allow to match data traffic originated from a 510 given source address to be assigned to a particular QoS reservation. 511 The adversary Eve now spoofs the IP address of the Alice. 512 Additionally Alice�s host may be subject of a DoS attack by and by 513 the adversary. If both nodes are located at the same link and use the 514 same IP address then obviously a duplicate IP address will be 515 detected. Assuming that only Eve is present at the link then she is 516 able to receive and transmit data (for example RTP data traffic), 517 which receives preferential QoS treatment based on the previous 518 reservation. Depending on the installed Traffic Selector granularity 519 Eve might have more possibilities to exploit the QoS reservation or a 520 pin-holed firewall. Assuming the soft state paradigm, where 521 periodical refresh messages are required, the absence of Alice will 522 not be detected until the next signaling message appears and forces 523 Eve to respond with a protected signaling message. Again this issue 524 is not only applicable to QoS traffic but the existence of QoS 525 reservation causes more difficulties since this type of traffic is 526 more expensive. The same procedure is also applicable to a Middlebox 527 communication protocol. 529 2.7 Adversary being able to inject/modify messages 530 NSIS Threats October 2002 532 The next type of threat addresses an integrity violations: An 533 adversary modifies signaling messages (e.g. by acting as a man-in- 534 the-middle) to cause an unexpected network behavior with a bogus 535 signaling message. Possible actions are reordering, delaying, 536 dropping, injecting and modifying. 538 An adversary may inject a signaling message requesting a large amount 539 of resources (using a different user identity). If granted it causes 540 other user's resource-request not to be successful and a different 541 initiator (for example a user) to pay for the QoS reservation. This 542 attack is only successful in absence of signaling message protection. 544 2.8 Missing Non-Repudiation 546 Repudiation in this context refers to a problem where one party later 547 denies to have made a reservation. This issue comes in two flavors: 549 From a service provider point-of-view the following threat may be 550 worth an investigation. A user may deny to have issued reservation 551 request for which it was charged. A service provider may then like to 552 prove that a particular user issued reservation requests. 554 The same threat can be interpreted from the users point-of-view. A 555 service provider claims to have received a number of reservation 556 requests. The user in question thinks that he never issued those 557 requests and wants to have a proof for correct service usage for a 558 given set of QoS parameters. 560 In today's telecommunication networks non-repudiation is not 561 provided. The user has to trust the network operator to correctly 562 meter the traffic, collect and merge accounting data and that no 563 unforeseen problems occur. If a signaling protocol is used to 564 establish QoS reservations with a higher volume (for example service 565 level agreements) then it might impact protocol design. 567 2.9 Malicious NSIS Entity 569 Network elements within a domain (intra-domain) experience a 570 different trust relationship with regard to the security protection 571 of signaling messages compared to edge routers. We assume that edge 572 routers have the responsibility to perform cryptographic processing 573 (authentication, integrity verification, replay protection, 574 authorization, etc.). Depending on the protocol functionality every 575 NSIS aware router should be able to issue signaling messages. If 576 however an adversary manages to take over an edge router then the 577 security of the entire network is affected. An adversary is then able 578 to launch a number of attacks including denial of service, integrity 579 violation, replay attacks etc. Note that this problem is not only 580 restricted to QoS signaling protocols. In case of policy rule 581 installation a rogue firewall can cause harm to other firewalls by 582 modifying the policy rules accordingly. 584 The chain-of-trust principle applied in the peer-to-peer security 585 protection cannot provide proper protection. An adversary with full 586 NSIS Threats October 2002 588 access to the edge router is then also able to retrieve security 589 associations to secure signaling messages. Note that even non-peer- 590 to-peer security protection might not be able to fully prevent this 591 problem. 593 Thus the edge router is a critical component that requires strong 594 security protection. Strong security policy applied at edge routers 595 does not imply that intra-domain routers do not need to 596 cryptographically verify signaling messages. If the chain-of-trust 597 principle is deployed then the security protection of the path (in 598 this case within the network of a single administrative domain) is as 599 strong as the weakest link. In our case the edge router is the most 600 critical component of this network that may also act as a security 601 gateway/firewall for incoming/outgoing traffic. For outgoing traffic 602 this device has to act according to the security policy of the local 603 domain to apply the appropriate security protection. 605 2.10 Denial of Service in a two phase reservation 607 This threat tries to address potential denial of service attacks when 608 the reservation setup is split into two phases path discovery/path 609 pinning and reservation (as for example used in a receiver-initiated 610 reservation). For this example we assume that the node transmitting 611 the path message is not charged for the path message itself and is 612 able to issue a high number of reservation request (possibly in a 613 distributed fashion). Charging is activated only after successful 614 verification of the reservation request. The reservations are however 615 never intended to be successful because of various reasons: the 616 destination node cannot be reached; it is not responding or simply 617 rejects the reservation. An adversary can benefit from the fact that 618 resources are already consumed along the path for various processing 619 tasks including path pinning. 621 2.11 Denial of Service with a bogus signaling request 623 With a resource reservation request received at a network element 624 (for example by the first NSIS aware router) processing is required 625 for authentication and authorization. Processing by other nodes 626 including policy servers, LDAP servers, etc. is also possible 627 depending on the network infrastructure. Verification requires 628 cryptographic computations, state maintenance, setting timers, 629 transmitting messages and other processing actions. If an adversary 630 is able to transmit a large number of reservation request with bogus 631 credentials (and assuming that the verification is expensive in terms 632 of resource consumption) then the verifying node may not be able to 633 process further reservation messages by legitimate users. This 634 assumes that verification is expensive (especially cryptographic 635 computations). 637 2.12 DoS Attack at the Discovery Phase 639 Signaling information to a large number of entities along a data path 640 requires some sort of discovery. This discovery process is vulnerable 641 to a number of attacks since it is difficult to secure. An adversary 642 NSIS Threats October 2002 644 can use the discovery mechanisms to convince an entity to signal 645 information to another entity which is not along the data path or to 646 cause the discovery process to fail. In the first case the signaling 647 protocol could be correctly continued with the problem that policy 648 rules are installed at incorrect firewalls or QoS resource 649 reservations take place at the wrong entities. For an end host this 650 means that the protocol failed for unknown reasons. 652 2.13 Disclosing the networking structure 654 In some architectures there is a desire not to reveal the internal 655 network structure (or other related information) to the outside 656 world. An adversary might be able to use NSIS messages for network 657 mapping (e.g. discovering which nodes exist, which use NSIS, what 658 version, what resources are allocated, capabilities of nodes along a 659 paths etc.). A requirement of not disclosing a network structure 660 might conflict with another requirement to provide means for 661 automatically discovering NSIS aware nodes and to provide diagnostic 662 facilities. 664 2.14 Modification of Session State Information 666 An adversary might be able to modify an existing reservation which 667 has already been established within the network as a result of a 668 previous signaling message exchange. 669 Hence it might be necessary to provide assurance for a secure binding 670 between an owner of the established session state and the session 671 state information distributed at various entities along the data 672 path. The state information created at nodes along the path created 673 by signaling messages is the uniquely identified Session ID as 674 described in [5]. Whenever a signaling message has to refer to 675 existing state information (for a refresh, modify or delete 676 operation) then the existing session identifier is used. Hence there 677 is a requirement that it must not be possible for someone to use an 678 existing session identifier to modify state information of someone 679 else. An adversary might have learned a session identifier by 680 eavesdropping the signaling messages. Especially in a roaming 681 scenario where a mobile node retransmits signaling messages from a 682 different point of attachment it must be assured that the routers 683 along the path are able to verify whether the entity transmitting the 684 signaling messages is allowed to modify the established state. 686 To make processing even more difficult it must be mentioned that not 687 only the initial signaling message originator is allowed to signal 688 information during the lifetime of an established session. As part of 689 the protocol any node along the path (and the path might change over 690 time) could be involved in the signaling message exchange and it 691 might be necessary to provide mobility support or to trigger a local 692 repair procedure. Hence if only the initial signaling message 693 originator is allowed to trigger signaling message exchange some 694 protocol behavior will not be possible. 696 In case that this threat is not addressed an adversary can launch 697 denial of service, theft of service, and various other attacks. 699 NSIS Threats October 2002 701 2.15 Faked Error/Response messages 703 An adversary may be able to use false error/response messages as part 704 of a denial of service attack. This could be either at the message 705 signaling protocol level, at the level of each client layer protocol 706 (QoS, Midcom, etc.) or at the transport level protocol. An adversary 707 might cause unexpected protocol behavior or produce denial of service 708 attacks. Especially the discovery protocol shows vulnerabilities with 709 regard to this threat. In case that no separate discovery protocol is 710 used by addressing signaling messages to end hosts only (with a 711 Router Alert Option to intercept message as NSIS aware nodes) then an 712 error message might be used to indicate a path change. Such a design 713 is a combination of a discovery protocol together with a signaling 714 message exchange protocol. 716 3 Security Considerations 718 This entire memo discusses security issues in the context of NSIS. 719 Some additional threats are applicable for a framework where an NSIS 720 protocol is used. Some other relevant threats especially for end 721 hosts to access network communication described in [2]. 723 4 Open Issues 725 A future version of this draft will experience a minor restructuring 726 to add deployment threats, to separation between attacks during 727 security association setup and attacks which aim to attack the 728 signaling messages itself, middlebox communication specific threats 729 and a discussion of threats applicable to the transport level vs. the 730 application level (according to a 2-level-architecture). 732 5 References 734 [1] Brunner, M., "Requirements for QoS Signaling Protocols", 735 , (work in progress), August, 2002. 737 [2] Kempf, J., Nordmark, E.: �Threat Analysis for IPv6 Public 738 Multi-Access Links�, , 739 (work in progress), December, 2002. 741 [3] Hamer, L-N., Gage, B., Broda, M., Kosinski, B., Shieh, H.: 742 �Session Authorization for RSVP�, , (work in progress), October, 2002. 745 [4] Hamer, L-N., Gage, B., Shieh, H.: �Framework for session set-up 746 with media authorization�, , 747 (work in progress), June, 2002. 749 [5] Freytsis, I., Hancock, R., Karagiannis, G., Loughney, J., Van 750 den Bosch, S.: �Next Steps in Signaling: A Framework Proposal�, 751 , (work in progress), October, 2002. 753 NSIS Threats October 2002 755 [6] Partridge, C.: "Using the Flow Label Field in IPv6", RFC 756 1809, June, 1995. 758 [7] Rajahalme, J., Conta, A., Carpenter, B., Deering, S.: "IPv6 759 Flow Label Specification", , (work 760 in progress), September, 2002. 762 [8] Fu, S., Kappler, C., Tschofenig, H.: "Analysis on RSVP 763 Regarding Multicast", , 764 (work in progress), October, 2002. 766 [9] Tschofenig, H.: "RSVP Security Properties", , (work in progress), October, 2002. 769 [10] de Meer, H., Feher, G., Blefari-Melazzi, N., Tschofenig, H., 770 Karagiannis, G., Partain, D., Rexhepi, V., Westberg, L.: "Analysis of 771 Existing QoS Solutions", , (work 772 in progress), October, 2002. 774 [11] Terzis, A., Braden, B., Vincent, S., Zhang, L.: "RSVP 775 Diagnostic Messages", RFC 2745, January, 2000. 777 6 Acknowledgments 779 I would like to thank (in alphabetical order) Marcus Brunner, Jorge 780 Cuellar, Mehmet Ersue, Xiaoming Fu and Robert Hancock for their 781 comments to this draft. Jorge and Robert gave me an extensive list of 782 comments and provided information on additional threats. 784 7 Author's Addresses 786 Hannes Tschofenig 787 Siemens AG 788 Otto-Hahn-Ring 6 789 81739 Munich 790 Germany 791 Email: Hannes.Tschofenig@siemens.com