idnits 2.17.1 draft-ietf-capwap-threat-analysis-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1520. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1531. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1538. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1544. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 419: '... is NOT RECOMMENDED....' RFC 2119 keyword, line 431: '... It is strongly RECOMMENDED that CAPW...' RFC 2119 keyword, line 458: '...sequently is NOT RECOMMENDED. Each AC...' RFC 2119 keyword, line 461: '... SHOULD be consistent with the guidance in [RFC4962]....' RFC 2119 keyword, line 1419: '...y considerations MUST be described in ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 10, 2008) is 5705 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4017' is defined on line 1472, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-capwap-protocol-binding-ieee80211-07 == Outdated reference: A later version (-15) exists of draft-ietf-capwap-protocol-specification-11 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Kelly 3 Internet-Draft Aruba Networks 4 Intended status: Informational T. Clancy 5 Expires: March 14, 2009 LTS 6 September 10, 2008 8 CAPWAP Threat Analysis for IEEE 802.11 Deployments 9 draft-ietf-capwap-threat-analysis-04 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on March 14, 2009. 36 Abstract 38 Early Wireless Local Area Network (WLAN) deployments feature a "fat" 39 Access Point (AP) which serves as a stand-alone interface between the 40 wired and wireless network segments. However, this model raises 41 scaling, mobility, and manageability issues, and the Control and 42 Provisioning for Wireless Access Points (CAPWAP) protocol is meant to 43 address these issues. CAPWAP effectively splits the fat AP 44 functionality into two network elements, and the communication 45 channel between these components may traverse potentially hostile 46 hops. This document analyzes the security exposure resulting from 47 the introduction of CAPWAP, and summarizes the associated security 48 considerations for IEEE 802.11-based CAPWAP implementations and 49 deployments. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 1.1. Rationale for Limiting Analysis Scope to IEEE 802.11 . . . 5 55 2. Abbreviations and Definitions . . . . . . . . . . . . . . . . 6 56 3. CAPWAP Security Goals for IEEE 802.11 Deployments . . . . . . 7 57 4. Overview of IEEE 802.11 and AAA Security . . . . . . . . . . . 8 58 4.1. IEEE 802.11 Authentication and AAA . . . . . . . . . . . . 9 59 4.2. IEEE 802.11 Link Security . . . . . . . . . . . . . . . . 10 60 4.3. AAA Security . . . . . . . . . . . . . . . . . . . . . . . 11 61 4.4. Cryptographic Bindings . . . . . . . . . . . . . . . . . . 11 62 5. Structure of the Analysis . . . . . . . . . . . . . . . . . . 12 63 6. Representative CAPWAP Deployment Scenarios . . . . . . . . . . 13 64 6.1. Preliminary Definitions . . . . . . . . . . . . . . . . . 13 65 6.1.1. Split MAC . . . . . . . . . . . . . . . . . . . . . . 14 66 6.1.2. Local MAC . . . . . . . . . . . . . . . . . . . . . . 14 67 6.1.3. Remote MAC . . . . . . . . . . . . . . . . . . . . . . 15 68 6.1.4. Data Tunneling . . . . . . . . . . . . . . . . . . . . 15 69 6.2. Example Scenarios . . . . . . . . . . . . . . . . . . . . 15 70 6.2.1. Localized Modular Deployment . . . . . . . . . . . . . 15 71 6.2.2. Internet Hotspot or Temporary Network . . . . . . . . 16 72 6.2.3. Distributed Deployments . . . . . . . . . . . . . . . 17 73 7. General Adversary Capabilities . . . . . . . . . . . . . . . . 18 74 7.1. Passive vs Active Adversaries . . . . . . . . . . . . . . 19 75 8. Vulnerabilities Introduced by CAPWAP . . . . . . . . . . . . . 21 76 8.1. The Session Establishment Phase . . . . . . . . . . . . . 21 77 8.1.1. The Discovery Phase . . . . . . . . . . . . . . . . . 21 78 8.1.2. Forming an Association (Joining) . . . . . . . . . . . 22 79 8.2. The Connected Phase . . . . . . . . . . . . . . . . . . . 22 80 9. Adversary Goals in CAPWAP . . . . . . . . . . . . . . . . . . 23 81 9.1. Eavesdrop on AC-WTP Traffic . . . . . . . . . . . . . . . 23 82 9.2. WTP Impersonation and/or Rootkit Installation . . . . . . 24 83 9.3. AC Impersonation and/or Rootkit Installation . . . . . . . 25 84 9.4. Other Goals or Sub-Goals . . . . . . . . . . . . . . . . . 25 85 10. Countermeasures and Their Effects . . . . . . . . . . . . . . 26 86 10.1. Communications Security Elements . . . . . . . . . . . . . 26 87 10.1.1. Mutual Authentication . . . . . . . . . . . . . . . . 26 88 10.1.2. Data Origin Authentication . . . . . . . . . . . . . . 28 89 10.1.3. Data Integrity Verification . . . . . . . . . . . . . 28 90 10.1.4. Anti-replay . . . . . . . . . . . . . . . . . . . . . 28 91 10.1.5. Confidentiality . . . . . . . . . . . . . . . . . . . 28 92 10.2. Putting the Elements Together . . . . . . . . . . . . . . 29 93 10.2.1. Control Channel Security . . . . . . . . . . . . . . . 29 94 10.2.2. Data Channel Security . . . . . . . . . . . . . . . . 29 95 11. Countermeasures Provided By DTLS . . . . . . . . . . . . . . . 29 96 12. Issues Not Addressed By DTLS . . . . . . . . . . . . . . . . . 30 97 12.1. DoS Attacks . . . . . . . . . . . . . . . . . . . . . . . 30 98 12.2. Passive Monitoring (Sniffing) . . . . . . . . . . . . . . 31 99 12.3. Traffic Analysis . . . . . . . . . . . . . . . . . . . . . 31 100 12.4. Active MitM Interference . . . . . . . . . . . . . . . . . 31 101 12.5. Other Active Attacks . . . . . . . . . . . . . . . . . . . 31 102 13. Security Considerations . . . . . . . . . . . . . . . . . . . 31 103 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 104 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 105 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 106 16.1. Normative References . . . . . . . . . . . . . . . . . . . 32 107 16.2. Informative References . . . . . . . . . . . . . . . . . . 32 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 109 Intellectual Property and Copyright Statements . . . . . . . . . . 34 111 1. Introduction 113 Wireless Local Area Network (WLAN) deployments are increasingly 114 common as the technology matures and wireless interface chips become 115 standard equipment in laptops and various hand-held computing 116 devices. In the simplest deployments, WLAN access is entirely 117 provided by a wireless Access Point (AP), which bridges the client 118 system (station or "STA") and the Distribution System (DS) or wired 119 network. 121 +------+ 122 |client| +--------+ | 123 |(STA) | | Access | | +------+ 124 +------+ ) ) ) ) | Point |-----| /optional\ +-------+ 125 / / +--------+ |--( L3 )---| AAA | 126 +------+ | \ cloud / +-------+ 127 | +------+ 129 Figure 1: IEEE 802.11 deployment using RSN 131 In this architecture the AP serves as a gatekeeper, facilitating 132 client access to the network. Typically, the client must somehow 133 authenticate prior to being granted access, and in enterprise 134 deployments this is frequently accomplished using [8021X]. When 135 using IEEE 802.11, this mode is called a Robust Security Network 136 (RSN) [80211I]. Here, the client is called the "supplicant", the AP 137 is the "authenticator", and either the AP or an external 138 Authentication, Authorization, and Accounting (AAA) server fulfill 139 the role of "authentication server", depending on the authentication 140 mechanism used. 142 From the perspective of the network administrator, the wired LAN to 143 which the AP is attached is typically considered to be more trusted 144 than the wireless LAN, either because there is some physical boundary 145 around the wired segment (i.e. the building walls), or because it is 146 otherwise secured somehow (perhaps cryptographically). The AAA 147 server may reside within this same physical administrative domain, or 148 it may be remote. Common AAA protocols are RADIUS [RFC3579] and 149 Diameter [RFC4072]. 151 The CAPWAP [I-D.ietf-capwap-protocol-specification] protocol modifies 152 this architecture by splitting the AP into two pieces, the Wireless 153 Termination Point (WTP), and the Access Controller (AC), and creating 154 a communications link between the two new components. In this model, 155 the WTP implements the WLAN edge functions with respect to the user 156 (wireless transmit/receive), while the AC implements the wired-side 157 edge functions. For a complete description of CAPWAP architecture, 158 see [RFC4118]. 160 +------+ +==========================+ 161 |client| | +---+ | | +------+ 162 |(STA) | | +-----+ / L3 \ +----+ | | /optional\ +-----+ 163 +------+ ) )|)| WTP |-( cloud )-| AC |-|---|--( L3 )--| AAA | 164 / / | +-----+ \ / +----+ | | \ cloud / +-----+ 165 +------+ | +---+ | | +------+ 166 +==========================+ 167 AP equivalence boundary 169 Figure 2: WLAN Deployment utilizing CAPWAP 171 For our purposes, it is useful to think of the entire CAPWAP system 172 as a sort of "AP equivalent", and the figure above illustrates this 173 concept. With this model in mind, our ideal is to ensure that CAPWAP 174 introduces no vulnerabilities which aren't present in the original 175 fat AP scenario. As we will see, this is not entirely possible, but 176 from a security perspective we should nonetheless strive to achieve 177 this equivalence as nearly as we can. 179 1.1. Rationale for Limiting Analysis Scope to IEEE 802.11 181 Although CAPWAP derives from protocols which were designed explicitly 182 for management of IEEE 802.11 wireless LANs, it may also turn out to 183 be useful for managing other types of network device deployments, 184 wireless and otherwise. This might lead one to conclude that a 185 single security analysis, except for minor per-binding variations, 186 might be sufficient. However, based on a limited number of 187 additional related scenarios that have been described as likely 188 candidates for CAPWAP thus far, e.g., use with Radio Frequency 189 Identification (RFID) sensors, this does not seem to be a simple, 190 binary decision. 192 Contrasting RFID and IEEE 802.11 deployment scenarios, IEEE 802.11 193 users typically authenticate to some a back-end AAA server, and as a 194 result of that exchange, derive cryptographic keys which are used by 195 the STA and WTP to encrypt and authenticate over-air communications. 196 That is, the threat environment is such that the following typically 197 holds: 199 o the user is not immediately trusted, and therefore must 200 authenticate 202 o the WTP is not immediately trusted, and therefore must indirectly 203 authenticate to the user via the AAA server 205 o the AAA server is not necessarily trusted, and therefore must 206 authenticate 208 o the medium is not trusted, and therefore communications must be 209 secured 211 RFID tags, on the other hand, typically do not have the same 212 authentication, confidentiality, and integrity requirements as the 213 principals in a WLAN deployment, and are not, generally speaking, 214 well suited to environments in which similar threats exist. As a 215 result of the combination of WLAN security requirements and the MAC- 216 splitting behavior which epitomizes the IEEE 802.11 binding for 217 CAPWAP, there are definite security-related considerations in the 218 WLAN case which simply do not exist for an RFID-based adaptation of 219 CAPWAP. 221 Now, there certainly are similarities and overlapping security 222 considerations which will apply to any CAPWAP deployment scenario. 223 For example, authentication of the AC for purposes of WTP device 224 management operations is probably always important. Even so, the 225 threats to RFID are different enough to suggest the need for a 226 separate security analysis in that case. For example, since RFID 227 tags commonly deployed today implement no over-air authentication, 228 integrity, or confidentiality mechanisms, the need for similar 229 mechanisms between the WTP and AC for RFID tag data communications is 230 not clearly indicated - that is, the threats are different. 232 We have limited visibility into the varied ways in which CAPWAP might 233 be adapted in the future, although we may observe that it seems to 234 provide the basis for a generalized scalable provisioning protocol. 235 Given our currently limited view of the technologies for which it 236 might be used, it seems prudent to recognize that our current view is 237 colored by the IEEE 802.11 roots of the protocol, and make that 238 recognition explicit in our analysis. If newly added bindings turn 239 out to be substantially similar to IEEE 802.11, then the associated 240 binding documents can simply reference this document in their 241 security considerations, while calling out any substantive 242 differences. However, it does appear, based on our current limited 243 visibility, that per-binding threat analyses will be required. 245 2. Abbreviations and Definitions 247 o AAA - Authentication Authorization and Accounting 249 o AC - Access Controller 251 o AES-CCMP - Advanced Encryption Standard - Counter-mode Cbc MAC 252 Protocol 254 o AP - (wireless) Access Point 256 o CAPWAP - Control And Provisioning of Wireless Access Points 258 o Cert - X509v3 Certificate 260 o DIAMETER - proposed successor to RADIUS protocol (see below) 262 o DoS - Denial of Service (attack) 264 o DTLS - Datagram Transport Layer Security 266 o EAP - Extensible Authentication Protocol 268 o MitM - Man in the Middle 270 o PMK - Pairwise Master Key 272 o PSK - PreShared Key 274 o RADIUS - Remote Authentication Dial-In User Service 276 o STA - (wireless) STAtion 278 o TK - Transient Key 280 o TKIP - Temporal Key Integrity Protocol 282 o WEP - Wired Equivalent Privacy 284 o WLAN - Wireless Local Area Network 286 o WTP - Wireless Termination Point 288 3. CAPWAP Security Goals for IEEE 802.11 Deployments 290 When deployed for use with IEEE 802.11, CAPWAP should avoid 291 introducing any system security degradation as compared to the fat AP 292 scenario. However, by splitting the AP functions between the WTP and 293 AC, CAPWAP places potentially sensitive protocol interactions that 294 were previously internal to the AP onto the L3 network between the AC 295 and WTP. Therefore, the security properties of this new system are 296 dependent on the security properties of the intervening network, as 297 well as on the details of the split. 299 Since CAPWAP does not directly interact with over-air or AAA 300 protocols, these are mostly out of scope for this analysis. That is, 301 we do not analyze the basic AAA or IEEE 802.11 security protocols 302 directly here, as CAPWAP does not modify these protocols in any way, 303 nor do they directly interact with CAPWAP. However, by splitting AP 304 functionality, CAPWAP may expose security elements of these protocols 305 that would not otherwise be exposed. In such cases, CAPWAP should 306 explicitly avoid degrading the security of these protocols in any way 307 when compared to the fat AP scenario. 309 4. Overview of IEEE 802.11 and AAA Security 311 While this document is not directly concerned with IEEE 802.11 or AAA 312 security, there are some subtle interactions introduced by CAPWAP, 313 and there will be related terminology we must touch on in discussing 314 these. The following figure illustrates some of the complex 315 relationships between the various protocols, and illustrates where 316 CAPWAP sits: 318 +-----+ RADIUS/Diameter 319 | AAA |<==============\\ 320 +-----+ || 321 | || 322 +-----------+------------+ || 323 | | || 324 +-----+ +----+ || 325 | AC | | AC |<==// 326 +-----+ +----+ 327 +---| |---+ +---| |---+ 328 | | | | 329 | | | CAPWAP | 330 +-----+ +-----+ +-----+ +-----+ 331 | WTP | | WTP | | WTP | | WTP | 332 +-----+ +-----+ +-----+ +-----+ 333 ^ ^^^ 334 ^^ ^^^ 802.11i, 335 ^^ ^^ 802.1X, WPA, 336 +-----+ +-----+ WEP 337 | STA | | STA | 338 +-----+ +-----+ 339 / / / / 340 +-----+ +-----+ 342 Figure 3: CAPWAP Protocol Hierarchy 344 CAPWAP is being inserted between the 802.ll link security mechanism 345 and the authentication server communication, so to provide supporting 346 context, we give a very brief overview of IEEE 802.11 and AAA 347 security below. It is very important to note that we only cover 348 those topics which are relevant to our discussion, so what follows is 349 not by any means exhaustive. For more detailed coverage of IEEE 350 802.11-related security, topics see e.g. [80211SEC] 352 4.1. IEEE 802.11 Authentication and AAA 354 IEEE 802.11 provides for multiple methods of authentication prior to 355 granting access to the network. In the simplest case, open 356 authentication is used, and this is equivalent to no authentication. 357 However, if IEEE 802.11 link security is to be provided, then some 358 sort of authentication is required in order to bootstrap the trust 359 relationship which underlies the associated key establishment 360 process. 362 This authentication can be implemented through use of a shared 363 secret. In such cases the authentication may be implicitly tied to 364 the link security mechanism, (e.g. when Wired Equivalent Privacy 365 (WEP) is used with open authentication), or it may be explicit, e.g. 366 when Wi-fi Protected Access is used with a Pre-Shared Key (WPA-PSK). 368 In other cases, authentication requires an explicit cryptographic 369 exchange, and this operation bootstraps link security. In most such 370 cases, IEEE 802.1X is used in conjunction with the Extensible 371 Authentication Protocol [RFC3748] to authenticate either the client 372 or both the client and the authentication server. This exchange 373 produces cryptographic keying material for use with IEEE 802.11 374 security mechanisms. 376 The resulting trust relationships are complex, as can be seen from 377 the following (simplified) figure: 379 /--------------------------------------------\ 380 | TK (6) | EAP Credentials, 381 V /--------------\ | PMK (3) 382 +------+ | PSK/Cert(1) | | 383 |client| V | V 384 |(STA) | +--------+ | v | +-----+ 385 +------+ ) ) ) ) | WTP |-----| +----+ |--| AAA | 386 / / +--------+ |--| AC |--| +-----+ 387 +------+ ^ | +----+ | ^ 388 ^ ^ | ^ ^ (2,4) | 389 | | PTK (7) | | \----------/ 390 | \----------------/ | Radius PSK, 391 \-----------------------------------/ PMK 392 4-Way Handshake (w/PMK) (5) 394 Figure 4: Trust Relationships 396 The following describes each of the relationships: 398 1. WTP and AC establish secure link 400 2. AC establishes secure link with AAA server 402 3. STA and AAA server conduct EAP, produce PMK 404 4. AAA server pushes PMK to AC 406 5. AC and STA conduct 4-way handshake (producing TK, among other 407 keys) 409 6. AC pushes TK to WTP (if decentralized encryption is used) 411 7. WTP/STA use TK for IEEE 802.11 link security 413 4.2. IEEE 802.11 Link Security 415 The current CAPWAP binding for IEEE 802.11 primarily supports the use 416 of IEEE 802.11i [80211I] security on the wireless link. However, 417 since IEEE 802.11i does not prohibit the use of WEP for link 418 security, neither does CAPWAP. Nonetheless, use of WEP with CAPWAP 419 is NOT RECOMMENDED. 421 If WEP is used with CAPWAP, the CAPWAP system will inherit all the 422 security problems associated with the use of WEP in any wireless 423 network. In particular, 40-bit keys can be subject to brute-force 424 attacks, and statistical attacks can be used to crack session keys of 425 any length after enough packets have been collected [WEPSEC]. As of 426 late 2008, such attacks are trivial, and take mere seconds to 427 accomplish. 429 Newer link security mechanisms described in IEEE 802.11i, including 430 TKIP and AES-CCMP, significantly improve the security of wireless 431 networks. It is strongly RECOMMENDED that CAPWAP only be used with 432 these newer techniques. 434 The only slight insecurity introduced by CAPWAP when using it with 435 IEEE 802.11i is the handling of the KeyRSC counter. When performing 436 decentralized encryption, this value is maintained by the WTP, but 437 needed by the AC to perform the four-way handshake. The value used 438 during the handshake initializes the counter on the client. In 439 CAPWAP, this value is initialized to zero, allowing the possibility 440 for replay attacks of broadcast traffic in the window between initial 441 authentication and the client receiving the first valid broadcast 442 packet from the WTP. This slight window of attack has been 443 documented in the CAPWAP bindings document. 445 4.3. AAA Security 447 CAPWAP has very little control over how AAA security is deployed, as 448 it's not directly bound to AAA as it is to IEEE 802.11. As a result, 449 CAPWAP can only provide guidance on how to best secure the AAA 450 portions of a CAPWAP-enabled wireless network. 452 The AAA protocol is a term that refers to use of either RADIUS 453 [RFC3579] or Diameter [RFC4072] to transport EAP communications 454 between the authenticator and the AAA server. Here the authenticator 455 is the AC, thus the AAA protocol secures the link between the AC and 456 AAA server. Use of non-unique or low-entropy long-term credentials 457 to secure the AC-AAA link can severely impact the overall security of 458 a CAPWAP deployment, and consequently is NOT RECOMMENDED. Each AC 459 should have a mutually-authenticated link that provides robust data 460 confidentiality and integrity. The AAA protocols and keys used 461 SHOULD be consistent with the guidance in [RFC4962]. 463 Since CAPWAP does not directly interact with AAA, it does not affect 464 the overall security of a AAA network. In fact, by decreasing the 465 number of devices that communicate with the AAA server, we can 466 actually decrease its exposure and risk of attack. 468 4.4. Cryptographic Bindings 470 One key shortcoming of both the EAP and AAA models is that they are 471 inherently two-party models. In CAPWAP deployments, we rely on a 472 variety of security associations when an IEEE 802.11 WLAN client 473 session is established. These include: 475 o WTP-AC (CAPWAP Authentication) 477 o AC-AAA (AAA Authentication) 479 o STA-AAA (EAP Method Execution) 481 o STA-AC (AAA pushes keys to AC) 483 o STA-WTP (AC pushes keys to WTP) 485 Each of these security associations involve a pairwise trust 486 relationship, and none result from a multi-party key agreement 487 protocol such as Kerberos. In particular, just because a STA trusts 488 a AAA server who trusts an AC who trusts a WTP doesn't necessarily 489 mean that the STA should trust the WTP. The WTP may be compromised 490 and using his credentials to maintain a trust relationship with an 491 AC, while advertising false information about the network to a STA. 493 Protection against attacks like these can be very difficult, while 494 maintaining scalable trust relationships with other entities in the 495 network. Since multiple protocols are being used, multi-party keying 496 to derive end-to-end trust relationships is infeasible. 498 Since CAPWAP is a collection of pairwise trust relationships, in 499 order to claim CAPWAP is secure, we must believe in the transitivity 500 of these trust relationships. Its hierarchal nature mitigates the 501 domino effect, but any compromised device in the hierarchy can affect 502 those below it in the hierarchy. 504 5. Structure of the Analysis 506 In order to conduct a comprehensive threat analysis, there are some 507 basic questions we must answer: 509 o Exactly what are we trying to protect? 511 o What are the risks? 513 * What are the capabilities of would-be attackers? 515 * What might be goals of would-be attackers? 517 * What are the vulnerabilities or conditions they might attempt 518 to exploit? 520 * For various attackers, what is the likelihood of attempting to 521 exploit a given vulnerability given the cost of the the exloit 522 vs. the value of attack? 524 o What potential mitigation strategies are available to us? 526 o What kinds of trade-offs do these mitigation strategies offer, and 527 do they introduce any new risks? 529 This is a very simplistic overview of what we must accomplish below, 530 but it should give some insight into the manner in which the 531 discussion proceeds. 533 As a preliminary, we describe some representative CAPWAP deployment 534 scenarios. This helps to frame subsequent discussion, so that we 535 better understand what we are trying to protect. Following this, we 536 describe a threat model in terms of adversary capabilities, 537 vulnerabilities introduced by the CAPWAP functionality split, and a 538 representative sampling of adversary goals. Note that we do not 539 spend a lot of time speculating about specific attackers here, as 540 this is a very general analysis, and there are many different 541 circumstances under which a WLAN might be deployed. 543 Following the development of the general threat model, we describe 544 appropriate countermeasures, and discuss how these are implemented 545 through various means within the CAPWAP protocol. Finally, we 546 discuss those issues which are not (or cannot be) completely 547 addressed, and we give recommendations for mitigating the resulting 548 exposure. 550 6. Representative CAPWAP Deployment Scenarios 552 In this section, we describe some representative CAPWAP deployment 553 scenarios, and in particular, those scenarios which have been taken 554 into consideration for the current CAPWAP protocol security design. 555 For clarity, we first provide some preliminary definitions, along 556 with descriptions of common deployment configurations which span 557 multiple scenarios. Following this is a sampling of individual 558 deployment scenarios. 560 6.1. Preliminary Definitions 562 The IEEE 802.11 standard describes several frame types, and 563 variations in WLAN architectures dictate where these frame types 564 originate and/or terminate (i.e. at the WTP or AC). There are three 565 basic IEEE 802.11 frame types currently defined: 567 o Control: These are for managing the transmission medium (i.e. the 568 airwaves). Examples include RTS, CTS, ACK, PS-POLL, CF-POLL, CF- 569 END, and CF-ACK 571 o Management: These are for managing access to the logical network, 572 as opposed to the physical medium. Example functions include 573 association/disassociation, reassociation, deauthentication, 574 beacons, and probes 576 o Data: Transit data (network packets) 578 There are a number of other services provided by the WLAN 579 infrastructure, including these: 581 o Packet distribution 583 o Synchronization 585 o Retransmissions 586 o Transmission Rate Adaptation 588 o Privacy/Confidentiality/Integrity (e.g. IEEE 802.11i) 590 The manner in which these (and other) services are divided among the 591 AC and WTP is collectively referred to in terms of "MAC-splitting" 592 characteristics. We briefly describe various forms of MAC-splitting 593 below. For further detail, see 594 [I-D.ietf-capwap-protocol-specification] and 595 [I-D.ietf-capwap-protocol-binding-ieee80211] 597 6.1.1. Split MAC 599 Split-MAC scenarios are characterized by the fact that some IEEE 600 802.11 MAC messages are processed by the WTP, while some are 601 processed by the AC. For example, a split MAC implementation might 602 divide IEEE 802.11 frame processing as follows: 604 WTP 606 * Beacons 608 * Probes 610 * RTS, CTS, ACK, PS-POLL, CF-POLL,CF-END, CF-ACK 612 AC 614 * Association/Reassociation/Disassociation 616 * Authentication/Deauthentication 618 * Key Management 620 * IEEE 802.11 Link Security (WEP, TKIP, IEEE 802.11i) 622 The split MAC model is not confined to any one particular deployment 623 scenario, as we'll see below, and vendors have considerable leeway in 624 choosing how to distribute the IEEE 802.11 functionality. 626 6.1.2. Local MAC 628 Local-MAC scenarios are characterized by the fact that most IEEE 629 802.11 MAC messages are processed by the WTP. Some IEE 802.11 MAC 630 frames must be forwarded to the AC (i.e. IEEE 802.11 Association 631 Request frames), but in general, the WTP manages the MAC 632 interactions. Data frames may also be forwarded to the AC, but are 633 generally bridged locally. 635 6.1.3. Remote MAC 637 Remote MAC scenarios are characterized by the fact that all IEEE 638 802.11 MAC messages are forwarded to the AC. The WTP does not 639 process any of these locally. This model supports very light-weight 640 WTPs which need be little more than smart antennas. While Remote MAC 641 scenarios are not addressed by the current IEEE 802.11 protocol 642 binding for CAPWAP, the description is included here for 643 completeness. 645 6.1.4. Data Tunneling 647 Regardless of the approach to MAC splitting, there is also the matter 648 of where user data packets are translated between wired and wireless 649 frame formats, i.e. where the bridging function occurs. In some 650 cases, user data frames are tunneled back to the AC, and in others, 651 they are locally bridged by the WTP. While one might expect remote 652 MAC implementations to always tunnel data packets back to the AC, for 653 local and split MAC modes the decision is not so clear. Also, it's 654 important to note that there are no rules or standards in place which 655 rigidly define these terms and associated handling. Data tunneling 656 is further discussed for each scenario below. 658 6.2. Example Scenarios 660 In this section we describe a number of example deployment scenarios. 661 This is not meant to be an exhaustive enumeration; rather, it is 662 intended to give a general sense of how WLANs currently are or may be 663 deployed. This will provide important context when we discuss 664 adversaries and threats in subsequent sections below. 666 6.2.1. Localized Modular Deployment 668 The localized modular model describes a WLAN which is deployed within 669 a single domain of control, typically within either a single building 670 or some otherwise physically contained area. This would be typical 671 of a small to medium-sized organization. In general, the LAN enjoys 672 some sort of physical security (e.g. it's within the confines of a 673 building for which access is somehow limited), although the actual 674 level of physical security is often far less than is assumed. 676 In such deployments, the WLAN is typically an extension of a wired 677 LAN. However, its interface to the wired LAN can vary. For example, 678 the interconnection between the WTPs and ACs can have its own wiring, 679 and its only connection to the LAN is via the AC's Distribution 680 System (DS) port(s). In such cases, the WLAN frequently occupies its 681 own distinct addressing partition(s) in order to facilitate routing, 682 and the AC often acts as a forwarding element. 684 In other cases, the WTPs may be mingled with the existing LAN 685 elements, perhaps sharing address space, or perhaps somehow logically 686 isolated from other wired elements (e.g. by Virtual LAN). Under 687 these circumstances, it is possible that traffic destined to/from the 688 WLAN is mixed with traffic to/from the LAN. 690 Localized deployments such as these could potentially choose any one 691 of the MAC-splitting scenarios, depending on the size of the 692 deployment, mobility requirements, and other considerations. In many 693 cases, any one of the various MAC-splitting approaches would be 694 sufficient. This implies that user data may be bridged by either the 695 WTP or the AC. 697 6.2.2. Internet Hotspot or Temporary Network 699 The Internet hotspot scenario is representative of a more general 700 deployment model one might find at cafes, hotels, or airports. It is 701 also quite similar to temporary WLANs which are created for 702 conferences, conventions, and the like. Some common characteristics 703 of these networks include the following: 705 o Primary function is to provide Internet access 707 o Authentication may be very weak 709 o There frequently is no IEEE 802.11 link security 711 Sometimes, the local-MAC model is used. In such cases the AC may be 712 "in the cloud" (out on the Internet somewhere), and user data traffic 713 will typically be locally bridged, rather than tunneled back to the 714 AC. Some IEEE 802.11 management traffic may be tunneled back to the 715 AC, but frequently the authentication consists in simply knowing the 716 SSID and perhaps a shared key for use with WEP or WPA-PSK. 718 In other cases, a split-MAC model may be used. This is more common 719 in airport and hotel scenarios, where users may have an account which 720 requires verification with some back-end infrastructure prior to 721 access. In these cases, IEEE 802.11 management frames are tunneled 722 back to the AC (e.g. user authentication), and stronger IEEE 802.11 723 link security may be provided (e.g. RSN), but user data is still 724 typically locally bridged, as the primary goal is to provide Internet 725 access. 727 A third variation on this scenario entails tunneling user data 728 through a local AC in order to apply centralized policy. For 729 example, in a hotel or airport scenarios, there is no reason to 730 provide direct access between WLAN users (who typically are within a 731 private address space), and in fact, allowing such access might 732 invite various sorts of malicious behavior. In such cases, tunneling 733 all user data back to the (local) AC provides a security choke point 734 at which policy may be applied to the traffic. 736 6.2.3. Distributed Deployments 738 The distributed deployment model describes a more complex WLAN 739 topology which features network segments that are typically somehow 740 spatially separated, although not necessarily so. These segments 741 might be connected in a physically secure manner, or (if they are 742 widely separated) they might be connected across potentially hostile 743 hops. Below we discuss several subgroups of this model. 745 6.2.3.1. Large Physically-Contained Organization 747 One distributed deployment example involves a single large 748 organization which is physically contained, typically within one 749 large building. The network might feature logically distinct (e.g. 750 per-department or per-floor) network segments, and in some cases, 751 there might be firewalls between the segments for access control. In 752 such deployments, the AC is typically in a centralized datacenter, 753 but there might also be a hierarchy of ACs, with a master in the 754 datacenter, and subordinate ACs distributed among the network 755 segments. Such deployments typically assume some level of physical 756 security for the network infrastructure. 758 6.2.3.2. Campus Deployments 760 Some large organizations have networks which span multiple buildings. 761 The interconnections between these buildings might be wired (e.g. 762 underground cables), or might be wireless (e.g. a point to point MAN 763 link). The interconnections may be secured, but sometimes they are 764 not. The organization may be providing outdoor wireless access to 765 users, in which case some WTPs will typically be located outdoors, 766 and these may or may not be within physically secure space. For 767 example, college campuses frequently provide outdoor wireless access, 768 and the associated WTPs may simply be mounted on a light post. 770 For such deployments, ACs may be centrally located in a datacenter, 771 or they may be distributed. User data traffic may be locally 772 bridged, but more frequently it is tunneled back to AC, as this 773 facilitates mobility and centralized policy enforcement. 775 6.2.3.3. Branch Offices 777 A common deployment model entails an enterprise consisting of a 778 headquarters and one or more branch offices, with the branches 779 connected to the central HQ. In some cases, the site-to-site 780 connection is via a private WAN link, and in others it is across the 781 Internet. For connections crossing potentially hostile hops (e.g. 782 the Internet), some sort of Virtual Private Network (VPN) is 783 typically employed as a protective measure. 785 In some simple branch office scenarios, there are only WTPs at the 786 remote site, and these are managed by a controller residing at the 787 central site. In other cases, a branch site may have its own 788 subordinate controller, with the master controller again residing at 789 the central site. In the first case, local bridging is often the 790 best choice for user data, due to latency and link capacity issues. 791 In the second case, traffic may be locally bridged by the WTPs, or it 792 may be forwarded to the local subordinate controller for centralized 793 policy enforcement. The choice depends on many factors, including 794 local topology and security policy. 796 6.2.3.4. Telecommuter or Remote Office 798 It is becoming increasingly common to send WTPs home with employees 799 for use as a telecommuting solution. While there are not yet any 800 standards or hard rules for how these work, a fairly typical 801 configuration provides split MAC with all user data tunneled back to 802 the controller in the organization's datacenter so that the WTP is 803 essentially providing wireless VPN services. These devices may in 804 some cases provide their own channel security (e.g. IPsec), but 805 alternative approaches are possible. For example, there may be a 806 stand-alone VPN gateway between the WTP and the Internet which 807 forwards all organization-bound traffic to the VPN gateway. 809 Similarly, it is becoming increasingly common for travelers to plug a 810 WTP into a hotel broadband connection. While in many cases, these 811 WTPs are stand-alone fat APs, in some cases they are configured to 812 create a secure connection to a centralized controller back at 813 headquarters, essentially forming a VPN connection. In such 814 scenarios, a split-MAC approach is typical, but split-tunneling may 815 also be supported (i.e. only data traffic destined for the 816 headquarters is tunneled back to the controller, with Internet-bound 817 traffic locally bridged). 819 7. General Adversary Capabilities 821 This section describes general capabilities we might expect an 822 adversary to have in various CAPWAP scenarios. Obviously, it is 823 possible to limit what an adversary can do through various deployment 824 restrictions (e.g. provide strict physical security for the AC-WTP 825 link), but such restrictions are simply not always feasible. For 826 example, it is not possible to provide strict physical security for 827 various aspects of the telecommuter scenario. Thus, we must consider 828 what capabilities an adversary might have in the worst case, and plan 829 accordingly. 831 7.1. Passive vs Active Adversaries 833 One way to classify adversaries is in terms of their ability to 834 interact with AC/WTP communications. For example, a passive 835 adversary is one who can observe and perhaps record traffic, but 836 cannot interact with it. They can "see" the traffic as it goes by, 837 but they cannot interfere in any way, and they cannot inject traffic 838 of their own. Note that such an adversary does not necessarily see 839 all traffic - they may miss portions of a communication e.g. because 840 some packets traverse a different path, or because the network is so 841 busy that the adversary can't keep up (and drops packets as a 842 result). 844 An active adversary, on the other hand, can directly interact with 845 the traffic in real-time. There are two modes in which an active 846 adversary might operate: 848 Pass-by (or sniffer) 850 * Can observe/record traffic 852 * Can inject packets 854 * Can replay packets 856 * Can reflect packets (i.e. send duplicate packets to a different 857 destination, including the to the packet source) 859 * Can cause redirection (e.g. via ARP/DNS poisoning) 861 Inline (Man in the Middle, or MitM) 863 * Can observe/record traffic 865 * Can inject packets 867 * Can replay packets 869 * Can reflect packets (with or without duplication) 871 * Can delete packets 873 * Can modify packets 874 * Can delay packets 876 A passive adversary could be located anywhere along the path between 877 the AC and WTP, and is characterized by the fact that it only 878 listens: 880 +------+ 881 |client| +--------+ | 882 |(STA) | | WTP | | +------+ 883 +------+ ) ) ) ) | |-----| / \ +------+ 884 / / +--------+ |-x-( optional )---| AC | 885 +------+ | | \ cloud / +------+ 886 | | +------+ 887 | 888 | +-----------+ 889 +--| pass-by | 890 | listener | 891 +-----------+ 893 Figure 5: Passive Attacker 895 An active adversary may attach in the same manner as the passive 896 adversary (in which case it is in pass-by mode), or it may be lodged 897 directly in the path between the AC and WTP (inline mode): 899 +------+ 900 |client| +--------+ | 901 |(STA) | | WTP | | +------+ +------+ 902 +------+ ) ) ) | |---| |active| / \ +------+ 903 / / +--------+ |-| MitM |--( optional )---| AC | 904 +------+ | +------+ \ cloud / +------+ 905 | +------+ 907 Figure 6: Active Man in the Middle Attacker 909 If it is not inline, it can only observe and create traffic; if it is 910 inline, it can do whatever it wishes with the traffic it sees. 912 It is important to recognize that becoming a MitM does not 913 necessarily require physical insertion directly into the transmission 914 path. Alternatively, the adversary can cause traffic to be diverted 915 to the MitM system, e.g. via ARP or DNS poisoning. Hence, launching 916 a MitM attack is not so difficult as it might first appear. 918 8. Vulnerabilities Introduced by CAPWAP 920 In this section we discuss vulnerabilities which arise as a result of 921 splitting the AP function across potentially hostile hops. We 922 primarily consider network-based vulnerabilities, and while in 923 particular we do not address how an adversary might affect a physical 924 compromise of the WTP or AC, we do consider the potential effects of 925 such compromises with respect to CAPWAP and the operational changes 926 it introduces when compared to stand-alone AP deployments. 928 Functionally, we are interested in two general "states of being" with 929 respect to AC-WTP communications: the session establishment phase or 930 state, and the "connected" (or session established) state. We 931 discuss each of these further below. Also, it is important to note 932 that we first describe vulnerabilities assuming that the CAPWAP 933 communications lack security of any kind. Later, we will evaluate 934 the protocol given the security mechanisms currently planned for 935 CAPWAP. 937 8.1. The Session Establishment Phase 939 The session establishment phase consists of two subordinate phases: 940 discovery, and association or joining. These are treated 941 individually in the following sections. 943 8.1.1. The Discovery Phase 945 Discovery consists of an information exchange between the AC and WTP. 946 There are several potential areas of exposure: 948 Information Leakage: During discovery, information about the WTP and 949 AC hardware and software are exchanged, as well as information 950 about the AC's current operational state. This could provide an 951 adversary with valuable insights. 953 DoS Potential: During Discovery, there are several opportunities for 954 Denial of Service (DoS), beyond those inherently available to an 955 inline adversary. For example, an adversary might respond to a 956 WTP more quickly than a valid AC, causing the WTP to attempt to 957 join with a non-existent AC, or one which is currently at maximum 958 load. 960 Redirection Potential: There are multiple ways in which an adversary 961 might redirect a WTP during discovery. For example, the adversary 962 might pretend to be a valid AC, and entice the WTP to connect to 963 it. Or, the adversary might instead cause the WTP to associate 964 with the AC of the adversary's choosing, by posing as a DNS or 965 DHCP server, injecting a spoofed discovery response, or by 966 modifying valid AC responses. 968 Misdirection: An adversary might mislead either the WTP or AC by 969 modifying the discovery request or response in flight. In this 970 way, the AC and/or WTP will have a false view of the other's 971 capabilities, and this might cause a change in the way they 972 interact (e.g. they might not use important features not supported 973 by earlier versions). 975 8.1.2. Forming an Association (Joining) 977 The association phase begins once the WTP has determined with which 978 AC it wishes to join. There are several potential areas of exposure 979 during this phase: 981 Information Leakage: During association, the adversary could glean 982 useful information about hardware, software, current 983 configuration, etc. that could be used in various ways. 985 DoS Potential: During formation of a WTP-AC association, there are 986 several opportunities for Denial of Service (DoS), beyond those 987 inherently available to an inline adversary. For example, the 988 adversary could flood the AC with connection setup requests. Or, 989 it could respond to the WTP with invalid connection setup 990 responses, causing a connection reset. An adversary with MitM 991 capability could delete critical session establishment packets. 993 Misdirection: An adversary might mislead either the WTP or AC by 994 modifying the association request(s) or response(s) in flight. In 995 this way, the AC and/or WTP will have an inaccurate view of the 996 other's capabilities, and this might cause a change in the way 997 they interact. 999 Some of these types of exposure are extremely difficult to prevent. 1000 However, there are things we can do to mitigate the effects, as we 1001 will see below. 1003 8.2. The Connected Phase 1005 Once the WTP and AC have established an association, the adversary's 1006 attention will turn to the network connection. If we assume a 1007 passive adversary, the primary concern for established connections is 1008 eavesdropping. If we assume an active adversary, there are several 1009 other potential areas of exposure: 1011 Connection Hijacking: An adversary may assume the identity of one 1012 end of the connection and take over the conversation. There are 1013 numerous ways in which the true owner of the identity may be taken 1014 off-line, including DoS or MitM attacks. 1016 Eavesdropping: An adversary may glean useful information from 1017 knowledge of the contents of CAPWAP control and/or data traffic. 1019 Modification of User Data: An adversary with MitM capabilities could 1020 modify, delete, or insert user data frames. 1022 Modification of Control/Monitoring Messages: An adversary with MitM 1023 capability could modify control traffic such as statistics, status 1024 information, etc. to create a false impression at the recipient. 1026 Modification/Control of Configuration An adversary with MitM 1027 capability could modify configuration messages to create 1028 unexpected conditions at the recipient. Likewise, if a WTP is 1029 redirected during discovery (or joining) and connects to an 1030 adversary rather than an authorized AC, the adversary may exert 1031 complete control over the WTPs configuration, including 1032 potentially loading tainted WTP firmware. 1034 9. Adversary Goals in CAPWAP 1036 This section gives an sampling of potential adversary goals. It is 1037 not exhaustive, and makes no judgement as to the relative likelihood 1038 or value of each individual goal. Rather, it is meant to give some 1039 idea of what is possible. It is important to remember that clever 1040 attacks often result when seemingly innocuous flaws or 1041 vulnerabilities are combined in some non-intuitive way. Hence, we 1042 don't rule out some goal that, taken alone, might not seem to make 1043 sense from an adversarial perspective. 1045 9.1. Eavesdrop on AC-WTP Traffic 1047 There are numerous reasons why an adversary might want to eavesdrop 1048 on AC-WTP traffic. For example, it allows for reconnaissance, 1049 providing answers to the following questions: 1051 o Where are the ACs? 1053 o Where are the WTPs? 1055 o Who owns them? 1056 o Who manufactured them? 1058 o What version of firmware do they run? 1060 o What cryptographic capabilities do they have? 1062 Similarly, snooping on tunneled data traffic might potentially reveal 1063 a great deal about the network, including answers to the following: 1065 o Who's using the WLAN? 1067 o When, and for how long? 1069 o What addresses are they using? 1071 o What protocols are they using? 1073 o What over-the-air security are they using? 1075 o Who/what are they talking to? 1077 Additionally, access to tunneled user data could allow the attacker 1078 to see confidential information being exchanged by applications (e.g. 1079 financial transactions). An eavesdropper may gain access to valuable 1080 information that either provides the basis for another perhaps more 1081 sophisticated attack, or which has its own intrinsic value. 1083 9.2. WTP Impersonation and/or Rootkit Installation 1085 An adversary might want to impersonate or control an authorized WTP 1086 for many reasons, some of which we might realistically imagine today, 1087 and perhaps others about which we have no clue at this point. 1088 Examples we might reasonably imagine include the following: 1090 o to facilitate MitM attacks against WLAN users 1092 o to leak/inject or otherwise compromise WLAN data 1094 o to give an inaccurate view of the state of the WLAN 1096 o to gain access to a trusted channel to an AC, through which 1097 various protocol attacks might be launched (e.g. hijack client 1098 sessions from other WTPs) 1100 o to facilitate denial of service attacks against WLAN users or the 1101 network 1103 9.3. AC Impersonation and/or Rootkit Installation 1105 For reasons similar to the WTP impersonation discussed above, an 1106 adversary might want to impersonate an authorized AC for many 1107 reasons. Examples we might reasonably imagine include the following: 1109 o to facilitate DoS attack against WLAN 1111 o to facilitate MitM attacks against WLAN users 1113 o to intercept user mobility context from another AC (possibly 1114 including security-sensitive information such as cryptographic 1115 keys) 1117 o to facilitate selective control of one or more WTPs 1119 * modify WTP configuration 1121 * load tainted firmware onto WTP 1123 o to assist in controlling which AC associates with which WTP 1125 o to facilitate IEEE 802.11 association of unauthorized WLAN user(s) 1127 o to exploit inter-AC trust in order facilitate attacks on other ACs 1129 In general, AC impersonation opens the door to a large measure of 1130 control over the WLAN, and could be used as the foundation to many 1131 other attacks. 1133 9.4. Other Goals or Sub-Goals 1135 There are many less concrete goals an adversary might have which, 1136 taken alone, might not seem to have any purpose, but when combined 1137 with other goals/attacks, might have very definite and undesirable 1138 consquences. Here are some examples: 1140 o cause CAPWAP de-association of WTP/AC 1142 o cause IEEE 802.11 de-association of authorized user 1144 o inject/modify/delete tunneled IEEE 802.11 user traffic 1146 * to interact with a specific application 1148 * to launch various attacks on WLAN user systems 1149 * to launch protocol fuzzing or other attacks on the AC which 1150 bridges between IEEE 802.11 and 802.3 frame formats 1152 o control DNS responses 1154 o control DHCP/BOOTP responses 1156 Anticipating all of the things an adversary might want to do is a 1157 daunting task. Part of the difficulty stems from the fact that we 1158 are analyzing CAPWAP in a very general sense, rather than in a 1159 specific deployment scenario with specific assets and very specific 1160 adversary goals. However, we have no choice but to take this 1161 approach if we are to provide reasonably good security across the 1162 board. 1164 10. Countermeasures and Their Effects 1166 In the previous sections we described numerous vulnerabilities which 1167 result from splitting the AP function in two, and also discussed a 1168 number of adversary goals which could be realized by exploiting one 1169 or more of those vulnerabilities. In this section, we describe 1170 countermeasures we can apply to mitigate the risks that come with the 1171 introduction of CAPWAP into WLAN deployment scenarios. 1173 10.1. Communications Security Elements 1175 10.1.1. Mutual Authentication 1177 Mutual authentication consists in each side proving its identity to 1178 the other. There are numerous authentication protocols which 1179 accomplish this, typically using either a shared secret (e.g. a 1180 preshared key) or by relying on a trusted third party (e.g. with 1181 digital credentials such as X.509 certificates). 1183 Strong mutual authentication accomplishes the following: 1185 o helps prevent AC/WTP impersonation 1187 o helps prevent MitM attacks 1189 o can be used to limit DoS attacks 1191 10.1.1.1. Authorization 1193 While authentication consists in proving the identity of an entity, 1194 authorization consists in determing whether that entity should have 1195 access to some resource. The current IEEE 802.11i CAPWAP protocol 1196 binding takes a rather simplistic approach to authorization, 1197 depending on the authentication method chosen. If preshared keys are 1198 used, authorization is broad and coarse: if the device knows the 1199 preshared key, the device is "trusted", meaning the that it is 1200 believed to be what it claims to be ( AC vs. WTP), and it is granted 1201 all privilege/access associated with that device class. 1203 When using preshared keys, some granularity may be achieved by 1204 creating classes, each with their own preshared key, but this still 1205 has drawbacks. For example, while possession of the key may suffice 1206 to identify the device as a member of a given group or class, it 1207 cannot be used to prove a device is either a WTP or an AC. This 1208 means the key can be abused, and those possessing the key can claim 1209 to be either type of device. 1211 When X.509v3 certificates are used for authentication, much more 1212 granular authorization policies are possible. Nonetheless, the 1213 current IEEE 802.11i protocol binding remains simplistic in its 1214 approach (though this may be addressed in future revisions). As 1215 currently defined, the X.509v3 certificates facilitate the following 1216 authorization checks: 1218 o CommonName (CN): the CN contains the MAC address of the device; if 1219 the relying party (AC or WTP) has a method for determining 1220 "acceptability" of a given MAC address, this helps prevent AC/WTP 1221 impersonation, MitM attacks, and may help in limiting DoS attacks 1223 o Extended Key Usage (EKU) key purpose ID bits: CAPWAP uses specific 1224 key purpose ID bits (see [I-D.ietf-capwap-protocol-specification] 1225 for more information) to explicitly differentiate between an AC 1226 and a WTP. If use of these bits is strictly enforced, this 1227 segregates devices into AC vs. WTP classes, and assists in 1228 preventing AC/WTP impersonation, MitM attacks, and may also help 1229 in limiting DoS attacks. However, if the id-kp- 1230 anyExtendedKeyUsage keyPurposeID is supported, this mechanism may 1231 be on a par with preshared keys, as a rogue device has the ability 1232 to claim it is either a WTP or AC, unless CN-based access controls 1233 are employed in tandem. 1235 It should be noted that certificate-based authorization and zero 1236 configuration are not fully compatible. Even if the WTPs and the ACs 1237 are shipped with manufacturer-provided certificates, the WTPs need a 1238 way to identify the correct AC is in this deployment (as opposed to 1239 other ACs from the same vendor, purchased and controlled by an 1240 adversary), and the AC needs to know which WTPs are part of this 1241 deployment (as opposed to WTPs purchased and controlled by an 1242 adversary). 1244 The threat analysis in this document assumes that WTPs can identify 1245 the correct AC, and the AC can identify the correct WTPs. Analysis 1246 of situations where either of these do not hold is beyond the scope 1247 of this document. 1249 10.1.2. Data Origin Authentication 1251 Data origin authentication typically depends on first authenticating 1252 the party at the other end of the channel, and then binding the 1253 identity derived from that authentication process to the data origin 1254 authentication process. Data origin authentication primarily 1255 prevents an attacker from injecting data into the communication 1256 channel and pretending it was originated by a valid endpoint. This 1257 mitigates risk by preventing the following: 1259 o packet injection 1261 o connection hijacking 1263 o modification of control and/or user data 1265 o impersonation 1267 10.1.3. Data Integrity Verification 1269 Data integrity verification provides assurance that data has not been 1270 altered in transit, and is another link in the trust chain beginning 1271 from mutual authentication, extending to data origin authentication, 1272 and ending with integrity verification. This prevents the adversary 1273 from undetectably modifying otherwise valid data while in transit. 1274 It effectively prevents reflection and modification, and in some 1275 cases may help to prevent re-ordering. 1277 10.1.4. Anti-replay 1279 Anti-replay is somewhat self-explanatory: it prevents replay of valid 1280 packets at a later time, or to a different recipient. It may also 1281 prevent limited re-ordering of packets. It is typically accomplished 1282 by assigning monotonically increasing sequence numbers to packets. 1284 10.1.5. Confidentiality 1286 Data confidentiality prevents eavesdropping by protecting data as it 1287 passes over the network. This is typically accomplished using 1288 encryption. 1290 10.2. Putting the Elements Together 1292 Above we described various security elements and their properties. 1293 Below, we discuss combinations of these elements in terms of CAPWAP. 1295 10.2.1. Control Channel Security 1297 The CAPWAP control channel is used for forming an association between 1298 a WTP and AC, and subsequently it allows the AC to provision and 1299 monitor the WTP. This channel is critical for the control, 1300 management, and monitoring of the WLAN, and thus requires all of the 1301 security elements described above. With these elements in place, we 1302 can effectively create a secure channel which mitigates almost all of 1303 the vulnerabilities described above. 1305 10.2.2. Data Channel Security 1307 The CAPWAP data channel contains some IEEE 802.11 management traffic 1308 including association/disassociation, reassociation, and 1309 deauthentication. It also may contain potentially sensitive user 1310 data. If we assume that threats to this channel exist (i.e. it 1311 traverses potentially hostile hops), then providing strong mutual 1312 authentication coupled with data origin/integrity verification would 1313 prevent an adversary from injecting and/or modifying transit data, or 1314 impersonating a valid AC or WTP. Adding confidentiality would 1315 prevent eavesdropping. 1317 11. Countermeasures Provided By DTLS 1319 Datagram TLS (DTLS) is the currently proposed security solution for 1320 CAPWAP. DTLS supports the following security functionality: 1322 o Mutual Authentication (preshared secrets or X.509 Certificates) 1324 o Mutual Authorization (preshared secrets or X.509 Certificates) 1326 o Data Origin Authentication 1328 o Data Integrity Verification 1330 o Antireplay 1332 o Confidentiality (supports strong cryptographic algorithms) 1334 Using DTLS for both the control and data channels mitigates nearly 1335 all risks resulting from splitting the AP function in two. 1337 12. Issues Not Addressed By DTLS 1339 Unfortunately, DTLS does not solve all of our CAPWAP security 1340 concerns. There are some things it just cannot prevent. These are 1341 enumerated below. 1343 12.1. DoS Attacks 1345 Even with the security provided by DTLS, CAPWAP is still susceptible 1346 to various types of DoS attack: 1348 o Session Initialization: an adversary could initiate thousands of 1349 DTLS handshakes simultaneously in order to exhaust memory 1350 resources on the AC; DTLS provides a mitigation tool via the 1351 HelloVerifyRequest, which ensures that the initiator can receive 1352 packets at the claimed source address prior to allocating 1353 resources. However, this would not thwart a botnet-style attack. 1355 o Cryptographic DoS: an adversary could flood either the AC or WTP 1356 with properly formed DTLS records containing garbage, causing the 1357 recipient to waste compute cycles decrypting and authenticating 1358 the traffic 1360 o Session interference: a MitM could either drop important session 1361 establishment packets, or inject bogus connection resets during 1362 session establishment phase. It could also interfere with other 1363 traffic in an established session. 1365 These attacks can be mitigated through various mechanisms, but not 1366 entirely avoided. For example, session initialization can be rate- 1367 limited, and in case of resource exhaustion, some number of 1368 incompletely initialized sessions could be discarded. Also, such 1369 events should be strictly audited. 1371 Likewise, cryptographic DoS attacks are detectable if appropriate 1372 auditing and monitoring controls are implemented. When detected, 1373 these events should (at minimum) trigger an alert. Additional 1374 mitigation might be realized by randomly discarding packets. 1376 Session interference is probably the most difficult of DoS attacks. 1377 It is very difficult to detect in real-time, although it may be 1378 detected if exceeding a lost packet threshold triggers an alert. 1379 However, this depends on the MitM not being in a position to delete 1380 the alert before it reaches its appropriate destination. 1382 12.2. Passive Monitoring (Sniffing) 1384 CAPWAP protocol security cannot prevent (or detect) passive 1385 monitoring. The best we can do is provide a confidentiality 1386 mechanism. 1388 12.3. Traffic Analysis 1390 DTLS provides no defense for traffic analysis. If this is a concern, 1391 there are traffic generation and padding techniques designed to 1392 mitigate this threat, but none of these are currently specified for 1393 CAPWAP. 1395 12.4. Active MitM Interference 1397 This was discussed in more limited scope in the section above on DoS 1398 attacks. An active MitM can delete or re-order packets in a manner 1399 which is very difficult to detect, and there is little the CAPWAP 1400 protocol can do in such cases. If packet loss is reported upon 1401 exceeding some threshold, then perhaps detection might be possible, 1402 but this is not guaranteed. 1404 12.5. Other Active Attacks 1406 In addition to the issues raised above, there are other active 1407 attacks that can be mounted if the adversary has access to the wired 1408 medium. For example, the adversary may be able to impersonate a DNS 1409 or DHCP server, or to poison either a DNS or ARP cache. Such attacks 1410 are beyond the scope of CAPWAP, and point to an underlying LAN 1411 security problem. 1413 13. Security Considerations 1415 This document outlines a threat analysis for CAPWAP, and as such, no 1416 additional CAPWAP-related security considerations are described here. 1417 However, in some cases additional management channels (e.g., SNMP) 1418 may be introduced into CAPWAP deployments. Whenever this occurs, 1419 related security considerations MUST be described in detail in those 1420 documents. 1422 14. IANA Considerations 1424 This document introduces no IANA considerations. 1426 15. Acknowledgements 1428 The authors gratefully acknowledge the reviews and helpful comments 1429 of Dan Romascanu, Joe Salowey, Sam Hartman, Mahalingham Mani, and 1430 Pasi Eronen. 1432 16. References 1434 16.1. Normative References 1436 [80211I] "IEEE Std 802.11i: WLAN Specification for Enhanced 1437 Security", April 2004. 1439 [80211SEC] 1440 Edney, J. and W. Arbaugh, "Real 802.11 Security - Wi-Fi 1441 protected Access and 802.11i", 2004, . 1445 [8021X] "IEEE Std 802.1X-2004: Port-based Network Access Control", 1446 December 2004. 1448 [I-D.ietf-capwap-protocol-binding-ieee80211] 1449 Calhoun, P., "CAPWAP Protocol Binding for IEEE 802.11", 1450 draft-ietf-capwap-protocol-binding-ieee80211-07 (work in 1451 progress), July 2008. 1453 [I-D.ietf-capwap-protocol-specification] 1454 Calhoun, P., "CAPWAP Protocol Specification", 1455 draft-ietf-capwap-protocol-specification-11 (work in 1456 progress), July 2008. 1458 [RFC4118] Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy 1459 for Control and Provisioning of Wireless Access Points 1460 (CAPWAP)", RFC 4118, June 2005. 1462 16.2. Informative References 1464 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 1465 Dial In User Service) Support For Extensible 1466 Authentication Protocol (EAP)", RFC 3579, September 2003. 1468 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1469 Levkowetz, "Extensible Authentication Protocol (EAP)", 1470 RFC 3748, June 2004. 1472 [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible 1473 Authentication Protocol (EAP) Method Requirements for 1474 Wireless LANs", RFC 4017, March 2005. 1476 [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 1477 Authentication Protocol (EAP) Application", RFC 4072, 1478 August 2005. 1480 [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, 1481 Authorization, and Accounting (AAA) Key Management", 1482 BCP 132, RFC 4962, July 2007. 1484 [WEPSEC] Petroni, N. and W. Arbaugh, "The Dangers of Mitigating 1485 Security Design Flaws: A Wireless Case Study", 1486 January 2003. 1488 Authors' Addresses 1490 Scott G. Kelly 1491 Aruba Networks 1492 1322 Crossman Ave 1493 Sunnyvale, CA 94089 1494 US 1496 Email: scott@hyperthought.com 1498 T. Charles Clancy 1499 DoD Laboratory for Telecommunications Sciences 1500 8080 Greenmead Drive 1501 College Park, MD 20740 1502 US 1504 Email: clancy@LTSnet.net 1506 Full Copyright Statement 1508 Copyright (C) The IETF Trust (2008). 1510 This document is subject to the rights, licenses and restrictions 1511 contained in BCP 78, and except as set forth therein, the authors 1512 retain all their rights. 1514 This document and the information contained herein are provided on an 1515 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1516 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1517 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1518 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1519 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1520 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1522 Intellectual Property 1524 The IETF takes no position regarding the validity or scope of any 1525 Intellectual Property Rights or other rights that might be claimed to 1526 pertain to the implementation or use of the technology described in 1527 this document or the extent to which any license under such rights 1528 might or might not be available; nor does it represent that it has 1529 made any independent effort to identify any such rights. Information 1530 on the procedures with respect to rights in RFC documents can be 1531 found in BCP 78 and BCP 79. 1533 Copies of IPR disclosures made to the IETF Secretariat and any 1534 assurances of licenses to be made available, or the result of an 1535 attempt made to obtain a general license or permission for the use of 1536 such proprietary rights by implementers or users of this 1537 specification can be obtained from the IETF on-line IPR repository at 1538 http://www.ietf.org/ipr. 1540 The IETF invites any interested party to bring to its attention any 1541 copyrights, patents or patent applications, or other proprietary 1542 rights that may cover technology that may be required to implement 1543 this standard. Please address the information to the IETF at 1544 ietf-ipr@ietf.org.