idnits 2.17.1 draft-tschofenig-nsis-threats-00.txt: -(180): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(221): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(225): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(246): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(264): 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: ---------------------------------------------------------------------------- ** Missing revision: the document name given in the document, 'draft-tschofenig-nsis-threats-', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-tschofenig-nsis-threats-', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-tschofenig-nsis-threats-', but the file name used is 'draft-tschofenig-nsis-threats-00' == There are 8 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (May 2002) is 8010 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) == Outdated reference: A later version (-09) exists of draft-ietf-nsis-req-02 ** Downref: Normative reference to an Informational draft: draft-ietf-nsis-req (ref. '1') Summary: 6 errors (**), 1 flaw (~~), 5 warnings (==), 1 comment (--). 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-tschofenig-nsis-threats- Siemens 5 00.txt 6 Expires: August 2002 May 2002 8 NSIS Threats 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance 14 with all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 As the work in the NSIS working has begun to describe requirements 34 and the framework people started thinking about possible security 35 implication. This document should provide a starting point for the 36 discussion at the NSIS interim meeting and at the NSIS working group 37 mailing list regarding the security issues that have to be 38 addressed. It does not describe threats for a particular published 39 protocol. This memo is furthermore meant to create awareness for the 40 security within the group. The threat scenarios in this document are 41 matched against the security requirements described in [1]. 43 1 Introduction 45 It is often argued that QoS signaling protocols are similar to other 46 signaling protocols and one might re-use their security mechanisms 47 for avoiding reengineering overhead. This is true up to some point: 48 A QoS signaling protocol might borrow many security mechanisms from 49 other protocols but different trust assumptions, and different 50 protocol processing may demand different solutions or adaptations. 51 This document tries to show security issues that need to be 52 addressed by a QoS signaling protocol that claims to be secure. 53 Although the base protocol might be sure, some extensions may cause 54 problems when used in a particular environment. We think that it is 55 necessary to investigate the kontext in which a QoS protocol is 56 integrated and in which sequence protocols are executed (when 57 combined together with other protocols). A particular focus of QoS 58 signaling protocols should be given to the interaction with 59 accounting and charging solutions: Without an appropriate 60 integration of QoS and accounting protocols there is no good 61 incentive for network operators to deploy them. 63 Independent of the threat scenarios described in Section 3 we 64 indentify the following structural pieces, which require different 65 security protection because of different trust relationships. The 66 sub-parts are:_access network part, intra and inter-domain part, and 67 the issues related to the end-to-end communication. These parts are 68 briefly described. The threat scenarios in Section 3 can be assigned 69 to the individual parts. 71 a) Access Network 73 This section addresses threats that arise when the QoS Inititiator 74 (QI) is attached to access network and transmits and receives QoS 75 signaling messages. There might not exist a pre-established trust 76 relationship between a user and the access network, as in many 77 mobility scenarios it is usually assumed. 79 Threat scenarios dealing with initial QoS security association 80 setup, replay attacks, lack of confidentiality, denial of service, 81 integrity violation, identity spoofing and fraud are applicable. 82 From a security point of view this part of the network causes the 83 most problems. 85 b) Intra-Domain 87 After receiving and verifying a QoS request at the access network 88 the signaling messages traverse the network within the same 89 administrative domain. Since the request has already been 90 authenticated and authorized threats are different compared to those 91 described in the previous section. To differentiate the user-to- 92 access network interface with the intra-domain communication (i.e. 93 communication within the core-network) we assume that no user hosts 94 are attached to the core-network. (That is: the interface between 95 any host and the first router is part of the access network). We 96 furthermore assume that nodes within one administrative domain have 97 a stronger trust relationship between each other. 99 c) Inter-Domain 101 The security considerations at the border between different 102 administrative domains largely depends on how accounting is done. If 103 one domain transmits forged QoS reservations (for example stating a 104 higher QoS reservation than a aggregated number of user did) to next 105 domain then it is likely that the originating network domain has 106 also has to pay for the reservation. Hence in this case, there is no 107 real benefit for the first network domain to forge a QoS 108 reservation. But if the user is directly charged by intermediate 109 domains too then this kind of attack may be reasonable. Security 110 protection of messages transmitted between different administrative 111 domains is still necessary to tackle attacks like spoofing, 112 integrity violation, denial of service etc. The lower number of 113 networks and higher trust relationship (compared in the access 114 network case) cause fewer problems for a key management. 116 d) End-to-End 118 In our opinion end-to-end security for QoS signaling messages is 119 rarely required if we assume that end-to-end issues like charging 120 and the selection which user has to pay for a reservation is already 121 securely negotiated by preceding upper layer protocols (for example 122 SIP). Information carried within a QoS signaling protocol for the 123 purpose of charging is therefore assumed opaque to the QoS protocol 124 itself and appropriately protected as part of the AAA interaction. 125 For accounting data, the QoS signaling protocol is therefore only 126 used as a transport mechanism. Note however that this assumption 127 strongly depends on the chosen solution of a protocol interaction 128 with AAA, QoS and application layer protocol. It is however possible 129 to select a charging solution that requires end-to-end protection of 130 information delivered within the QoS signaling protocol. The 131 following example requires some sort of end-to-end protection: Alice 132 wants Bob to pay for the QoS reservation. (reverse charging) Bob 133 wants to be assured that the QoS signaling message he receives are 134 transmitted by Alice because he is only willing to pay for 135 particular users and not for everyone. Hence Bob requires Alice to 136 authenticated the request. 138 2 Terminology 140 Some threat scenarios in this document use the entity user instead 141 of the QoS Initiator (as introduced by [1]). This is mainly due to 142 the fact that security protocols allow a differentiation between 143 entities being hosts or users. Since the QoS Initiator as used in 144 [1] also allows to act on behalf of various entities including a 145 network it is reasonable to distinguish between these identities. 147 We use the term access network for a network to which a mobile node 148 is attached. Other terms often used in this context are foreign or 149 visited network. The missing direct trust relationship between the 150 mobile node and the visited networks is characteristic for such an 151 interface and complicates authentication and key agreement. Usually 152 AAA protocols (like Radius or Diameter) are used for such a purpose. 153 These protocols exploit the infrastructure and trust relationships 154 between the access network and the home network of the user. 156 The term security association is used to describe established 157 security-relevant data structure between two entities. This data 158 structure consists of keys, algorithms including their parameters, 159 values used for replay protection etc. Using this information two 160 nodes are able to protect QoS signaling messages. 162 3 Threat Scenarios 164 This section provides threat scenarios that are applicable to the 165 quality of service signaling protocols. 167 Additionally, it might also be possible that the QoS initiator acts 168 on behalf of an other user and must therefore interact with this 169 node to be able to trigger the reservation setup. This issue however 170 requires further investigation based on specific protocol proposals. 172 3.1 Man-in-the-Middle Attacks 174 This Section describes man-in-the-middle attacks of the following 175 type: During the process of establishing a security association an 176 adversary fools the QI with respect to the entity to which it has to 177 authenticate. The man-in-the-middle adversary is able to modify 178 signaling messages transmitted to the real network requesting 179 different QoS parameters. The QI wrongly believes that it talks to 180 the �real� network whereas it is actually attached to an adversary. 181 Note that a solution for protecting QoS signaling messages does not 182 necessarily need to establish a security association. In general it 183 is however advisable to create one because of performance reasons. 185 For this attack to be successful, pre-conditions have to hold which 186 are described with the two scenarios below: 188 a) No authentication 190 The first case considers the case that no authentication between the 191 QI and other entity (access network, other networks, a single node) 192 takes places: Without authentication the QI is unable to detect an 193 adversary. 195 b) Unilateral authentication 197 In case of only unilateral authentication (that is, a missing 198 authentication of the access network to the QI) the QI is not able 199 to discover the man-in-the-middle adversary. In the 200 telecommunication world this type of attack is known as the false 201 base-station attacks (if the unilateral authentication is executed 202 between a user and the access network). 204 The two threats described above are a general problem of network 205 access without appropriate authentication, not only for QoS. Still 206 these issues need to be correctly addressed in a proposed protocol 207 since the impacts may reach beyond the local network. 209 3.2 Missing real-time notifications of QoS reservation costs (cost 210 control) 212 An other type of attack uses the fact that a user is not able to 213 authorize a particular network service provider (i.e. because of a 214 large number of providers). A large number of service providers with 215 complex roaming agreements create a non-transparent cost-structure. 216 Using AAA protocols in a subscription-based scenario (i.e. user is 217 registered with his home service provider) the user does not learn 218 the identity of the network using a regular message exchange. The 219 user is only authenticated to the home network (and possibly vice 220 versa). The identity of the access network is possibly not revealed. 221 Furthermore one service provider �steals� users from an other close- 222 by service provider and because of a missing cost-notification the 223 user is unable to refuse the more expensive service provider 224 although he could route his traffic possible via both providers. The 225 user is not able to select the �cheapest� access router (in terms of 226 QoS costs). 228 Although real-time notifications of quality of service reservation 229 costs (cost control) to the user are outside the scope of a quality 230 of service protocol itself there are still interactions with AAA and 231 other protocols. 233 3.3 Eavesdropping and Traffic Analysis 235 This Section covers two threats: The first one is related to privacy 236 concerns whereas the second addresses problems caused by weak 237 authentication mechanisms and the increased risk of eavesdropping on 238 the wireless link in absence of appropriate confidentiality 239 protection. 241 The first threat case covers adversaries that are unable to actively 242 participate in the QoS signaling (passive adversary) but eavesdrop 243 messages. The collected signaling packets may serve for the purpose 244 of traffic analysis or to later mount replay attacks as described in 245 the next Section. By eavesdropping an adversary might violate a 246 user�s privacy preference. Especially QoS signaling messages provide 247 information that may be interesting for an adversary since the 248 messages include user and/or application identities, policy 249 information, information about the desired QoS reservation, etc. The 250 information gathered by an adversary can be to learn usage patterns 251 of users requesting resources and track QoS reservations. 253 The second threat case addresses weak authentication mechanisms 254 whereby information transmitted within the QoS signaling protocol 255 may leak passwords and may allow offline dictionary attacks. This 256 threat is not specific to QoS signaling protocols by may also be 257 applicable and countermeasures must be taken. 259 3.4 Adversary being able to replay signaling messages 261 This threat scenario covers the case where an adversary eavesdrops 262 and collects signaling messages and replays them at a latter point 263 in time (or at a different place, or uses parts of them at a 264 different place or in a different way � e.g. cut and paste attacks). 265 The adversary may use this technique in absence of appropriately 266 protected messages to mount denial of service attacks. Furthermore 267 also theft of service is possible. 269 A more difficult attack that may cause problems even in case of 270 replay protection requires the adversary to crash a QoS aware node 271 (router, broker, etc.) to lose synchronization and to be able to 272 replay old QoS signaling messages. 274 3.5 Identity Spoofing 276 An adversary with the capability to spoof the identity may mount the 277 following attacks: 279 Eve, acting as an adversary, claims to be the registered user Alice 280 by spoofing the identity of Alice. Thereby Eve causes the network to 281 charge Alice for the consumed network resources. Using unprotected 282 messages Eve may experience no particular problems in succeeding. 284 In case that the signaling request is properly protected the 285 situation becomes more difficult. This threat tries to address 286 possible problems with network based QoS traffic classification 287 based on some identifiers (IP address, ports, other header 288 information etc.). The situation does not change when the data 289 traffic is marked by the transmitting host (i.e. using DSCP). 291 After the network receives a properly protected reservation request, 292 transmitted by the legitimate user Alice, traffic filters are 293 installed at edge devices. These traffic filters allow data traffic 294 originated from a given address to be assigned to a particular QoS 295 class. The adversary Eve now spoofs the IP address of the Alice (or 296 whatever identifier is used in the flow classification). 297 Additionally Alice�s host may be crashed by the adversary as a 298 result of a denial of service attack or lost connectivity for a 299 variety of other reasons. In any case Eve is now able to receive and 300 transmit data (for example RTP data traffic), that receives 301 preferential QoS treatment, using Alice�s IP address (or whatever 302 identifier is used in the flow classification) until the next 303 signaling message appears and forces Eve to respond with a protected 304 signaling message. Again this issue is not only applicable to QoS 305 traffic but the existence of QoS reservation causes more 306 difficulties since this type of traffic is more expensive. 308 3.6 Adversary being able to inject/modify messages 310 The next type of threat is caused by an integrity violation: An 311 adversary modifies signaling messages (e.g. by acting as a man-in- 312 the-middle) to achieve an unexpected network behavior with the bogus 313 request. Possible actions are reordering, delaying, dropping, 314 injecting and modifying. 316 Using a different identity the adversary may forward a modified a 317 QoS signaling message requesting a large amount of resources (using 318 a different identity). If granted it causes other user's resource- 319 request not to be successful and a different user to pay for the 320 reservation. This attack is only useful in absence of user 321 authentication or if the adversary is able to spoof someone�s 322 identity since the attack is useless if the adversary itself is 323 charged for the huge resource reservation. 325 3.7 Missing Non-Repudiation Property 327 Repudiation in this context refers to a problem where one party 328 later denies to have made a reservation. This issue comes in two 329 flavors: 331 From a service provider point-of-view the following threat may be 332 worth an investigation because a user may deny to have issued 333 reservation requests for which he was charged. A service provider 334 may then like to prove that a particular user issued the reservation 335 request. 337 The same threat can be interpreted from the users point-of-view. A 338 service provider claims to have received a number of reservation 339 requests. The user in question thinks that he never issued those 340 requests and wants to have a proof for correct service usage for a 341 given set of QoS parameters. 343 3.8 Malicious Edge-Router 345 Network elements within a domain (intra-domain) experience a 346 different trust relationship with regard to the security protection 347 of signaling messages compared to edge routers. Assuming that edge 348 routers have the responsibility to perform cryptographic processing 349 (authentication, integrity and replay protection, authorization and 350 accounting). If however an adversary manages to take over an edge 351 router then the security of the entire network is affected. An 352 adversary can then launch a number of attacks including denial of 353 service, integrity violation, replay attacks etc. Note that this 354 problem is not only restricted to the QoS protocols. In such a case 355 even the chain-of-trust principle does not prevent the network from 356 being vulnerable: If we assume that the adversary, with access to 357 the edge router, is able to access the keys used to secure messages 358 to other nodes. 360 Thus the edge router is a critical component that requires strong 361 security protection. This does not necessarily imply that all 362 routers within the core network do not need to cryptographically 363 verify signaling messages and that these routers cannot have any 364 security effect if they act maliciously. If the (hop-by-hop) chain- 365 of-trust principle is deployed then the security of the path (in 366 this case within the network of a single administrative domain) is 367 as strong as the weakest link. In our case the edge router is the 368 most critical component of this network that may also act as a 369 security gateway/firewall for incoming/outgoing traffic. For 370 outgoing traffic this device has to act according to the security 371 policy of the local domain to apply the appropriate security 372 protection. 374 3.9 Denial of Service in a two phase reservation 376 This threat tries to address potential denial of service attacks 377 when the reservation setup is split into two phases i.e. path and 378 reservation. For this example we assume that the node transmitting 379 the path message is not charged for this message and is able to 380 issue a high number of reservation request (possibly in a 381 distributed fashion). The reservations are however never intended to 382 be successful because of various reasons: for example the 383 destination node cannot be reached or is not responding node or 384 rejects the reservation. An adversary can benefit from the fact that 385 resources are already consumed along the path for various processing 386 tasks including path pinning. 388 3.10 Denial of Service with a bogus reservation request 390 With a resource reservation request received at a network element 391 (for example by the first QoS aware router) processing is required 392 for authentication and authorization (processing by other nodes 393 including policy server, LDAP server, etc. is also possible 394 depending on the network architecture). The verification of the 395 provided credentials requires computations and resources to be 396 allocated memory for state maintenance, setting timers, additional 397 messages transmitted to other nodes, cryptographic computations). If 398 an adversary is able to transmit a large number of reservation 399 request (flooding) with bogus credentials and assuming that the 400 verification is expensive in terms of resource consumption then the 401 verifying node may not be able to process further reservation 402 messages by legitimate user. 404 3.11 Disclosing the networking structure 406 In some architectures a network provider does not want to reveal its 407 internal network structure to the outside world. An adversary might 408 be able to use NSIS messages for network mapping (e.g. discovering 409 which nodes existed, which used NSIS, what version etc.). This 410 requirement might conflict with a protocol solution that provides a 411 mean to automatically discover NSIS aware nodes and their identity 412 (the identity required for security protection). 414 3.12 Modification of subsequent reservation request 416 An adversary might be able to modify an existing reservation which 417 had already been established within the network as a result of a 418 previous QoS signaling message. This means that a QoS signaling 419 messages that modifies established state must be subject to security 420 protection comparable to the original signaling message setting up 421 the reservation. Furthermore it might be necessary to provide 422 (possibly cryptographic) information to assure a correct binding to 423 a specific state/session. 425 3.13 Faked Error/Response messages 427 An adversary may be able to use false error/response messages as 428 part of a denial of service attack. This could be either at the 429 reservation level or at the protocol level. 431 4 Security Considerations 433 This entire memo discusses security issues. 435 5 References 437 [1] Brunner, M., "Requirements for QoS Signaling Protocols", draft- 438 ietf-nsis-req-02.txt, Work In Progress, May 2002. 440 6 Acknowledgments 442 I would like to thank (in alphabetical order) Marcus Brunner, Jorge 443 Cuellar, Xiaoming Fu and Robert Hancock for their comments to this 444 draft. Jorge and Robert gave me an extensive list of comments for 445 this memo and provided more information on additional threats that 446 should be added. 448 7 Author's Addresses 450 Hannes Tschofenig 451 Siemens AG 452 Otto-Hahn-Ring 6 453 81739 Munchen 454 Germany 455 Email: Hannes.Tschofenig@mchp.siemens.de