RFC 5418

Control And Provisioning of Wireless Access Points (CAPWAP) Threat Analysis for IEEE 802.11 Deployments

📅 published March 2009, from ietf

RFC 5418 💖 Control And Provisioning of Wireless Access Points (CAPWAP) Threat Analysis for IEEE 802.11 Deployments 🎀

Okay bestie, this one is from March 2009 and it's an Informational doc, so it's sharing info with the Internet community, not setting a standard 💅. The authors are S. Kelly from Aruba Networks and T. Clancy from LTS 🧚. The title block doesn't list anything it obsoletes or updates, so it doesn't replace or change any other RFC 🌸.

Status of This Memo ✨

This memo gives information to the Internet community. It does not specify an Internet standard of any kind, so no pressure, it's just vibes and info 🦋. Distribution of this memo is unlimited, so share it with everyone 💜.

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. Okay, legal stuff incoming, but it's important 🙈.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Seriously, read them 👑.

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. So basically, don't remix it outside the IETF process unless it's for RFC formatting or translation 🫶.

Abstract 🌈

Okay so, early Wireless Local Area Network (WLAN) deployments had this "fat" Access Point (AP) that acted as a stand-alone interface between the wired and wireless network segments. It was giving everything at once, but the model raised scaling, mobility, and manageability issues 😭. That's where the Control and Provisioning of Wireless Access Points (CAPWAP) protocol comes in to fix them ✨.

CAPWAP effectively splits the fat AP functionality into two network elements, and the communication channel between these components may traverse potentially hostile hops. Yes, hostile. This is why the doc exists 💀. This document analyzes the security exposure resulting from the introduction of CAPWAP and summarizes the associated security considerations for IEEE 802.11-based CAPWAP implementations and deployments. The security analysis is the whole main character energy here 🎀.

Table of Contents 🍓

   1. Introduction ....................................................4
      1.1. Rationale for Limiting Analysis Scope to IEEE 802.11 .......5
      1.2. Notations ..................................................6
   2. Abbreviations and Definitions ...................................7
   3. CAPWAP Security Goals for IEEE 802.11 Deployments ...............8
   4. Overview of IEEE 802.11 and AAA Security ........................8
      4.1. IEEE 802.11 Authentication and AAA .........................9
      4.2. IEEE 802.11 Link Security .................................11
      4.3. AAA Security ..............................................11
      4.4. Cryptographic Bindings ....................................12
   5. Structure of the Analysis ......................................13
   6. Representative CAPWAP Deployment Scenarios .....................14
      6.1. Preliminary Definitions ...................................14
           6.1.1. Split MAC ..........................................15
           6.1.2. Local MAC ..........................................15
           6.1.3. Remote MAC .........................................15
           6.1.4. Data Tunneling .....................................16
      6.2. Example Scenarios .........................................16
           6.2.1. Localized Modular Deployment .......................16
           6.2.2. Internet Hotspot or Temporary Network ..............17
           6.2.3. Distributed Deployments ............................18
                  6.2.3.1. Large Physically Contained Organization ...18
                  6.2.3.2. Campus Deployments ........................18
                  6.2.3.3. Branch Offices ............................18
                  6.2.3.4. Telecommuter or Remote Office .............19
   7. General Adversary Capabilities .................................19
      7.1. Passive versus Active Adversaries .........................20
   8. Vulnerabilities Introduced by CAPWAP ...........................22
      8.1. The Session Establishment Phase ...........................22
           8.1.1. The Discovery Phase ................................22
           8.1.2. Forming an Association (Joining) ...................23

      8.2. The Connected Phase .......................................23
   9. Adversary Goals in CAPWAP ......................................24
      9.1. Eavesdrop on AC-WTP Traffic ...............................24
      9.2. WTP Impersonation and/or Rootkit Installation .............25
      9.3. AC Impersonation and/or Rootkit Installation ..............26
      9.4. Other Goals or Sub-Goals ..................................26
   10. Countermeasures and Their Effects .............................27
      10.1. Communications Security Elements .........................27
           10.1.1. Mutual Authentication .............................27
                  10.1.1.1. Authorization ............................27
           10.1.2. Data Origin Authentication ........................29
           10.1.3. Data Integrity Verification .......................29
           10.1.4. Anti-Replay .......................................29
           10.1.5. Confidentiality ...................................29
      10.2. Putting the Elements Together ............................30
           10.2.1. Control Channel Security ..........................30
           10.2.2. Data Channel Security .............................30
   11. Countermeasures Provided by DTLS ..............................30
   12. Issues Not Addressed By DTLS ..................................31
      12.1. DoS Attacks ..............................................31
      12.2. Passive Monitoring (Sniffing) ............................32
      12.3. Traffic Analysis .........................................32
      12.4. Active MitM Interference .................................32
      12.5. Other Active Attacks .....................................32
   13. Security Considerations .......................................32
   14. Acknowledgements ..............................................32
   15. References ....................................................33
      15.1. Normative References .....................................33
      15.2. Informative References ...................................33

1. Introduction ✨

Wireless Local Area Network (WLAN) deployments are getting more and more common 📶. The tech is maturing, and wireless interface chips are now standard in laptops and all kinds of hand-held computing devices 📱. In the simplest deployments, WLAN access is entirely provided by a wireless Access Point (AP), which bridges the client system (station or "STA") and the Distribution System (DS) or wired network 🦋.

     +------+
     |client|         +--------+     |
     |(STA) |         | Access |     |    +------+
     +------+ ) ) ) ) | Point  |-----|   /optional\    +-------+
    /      /          +--------+     |--(    L3    )---|  AAA  |
   +------+                          |   \ cloud  /    +-------+
                                     |    +------+

               Figure 1: IEEE 802.11 Deployment Using RSN

In this architecture, the AP is the gatekeeper 🔑, deciding how clients get onto the network. Typically, the client must somehow authenticate before it gets access, and in enterprise deployments this is frequently done using [8021X]. When IEEE 802.11 is involved, this mode is called a Robust Security Network (RSN) [80211I] 🛡️. Here, the client is called the "supplicant", the AP is the "authenticator", and either the AP or an external Authentication, Authorization, and Accounting (AAA) server takes on the role of "authentication server", depending on which authentication mechanism is used 💅.

From the network administrator's point of view, the wired LAN the AP is attached to is usually considered more trusted than the wireless LAN 🏠. That's either because there's some physical boundary around the wired segment (aka the building walls), or because it's secured somehow (perhaps cryptographically) 🔐. The AAA server may live in that same physical administrative domain, or it may be remote 🌍. Common AAA protocols are RADIUS [RFC3579] and Diameter [RFC4072] 🧚.

The CAPWAP protocol [RFC5415] changes this architecture by splitting the AP into two pieces: the Wireless Termination Point (WTP) and the Access Controller (AC), with a communications link created between the two new components 🎀. In this model, the WTP handles the WLAN edge functions facing the user (wireless transmit/receive), while the AC handles the wired-side edge functions 🌸. For a complete description of CAPWAP architecture, see [RFC4118] 📚.

  +------+    +==========================+
  |client|    |           +---+          |   |    +------+
  |(STA) |    | +-----+  /  L3 \  +----+ |   |   /optional\   +-----+
  +------+ ) )|)| WTP |-( cloud )-| AC |-|---|--(    L3    )--| AAA |
 /      /     | +-----+  \     /  +----+ |   |   \ cloud  /   +-----+
+------+      |           +---+          |   |    +------+
              +==========================+
                 AP equivalence boundary

            Figure 2: WLAN Deployment utilizing CAPWAP

For our purposes, it's super useful to think of the entire CAPWAP system as one big "AP equivalent", and the figure above shows that idea 👑. With that model in mind, our ideal is to make sure CAPWAP doesn't introduce any vulnerabilities that weren't already there in the original fat AP scenario 🫶. As we'll see, that isn't entirely possible, but from a security perspective we should still aim for that equivalence as closely as we can 😭🔥.

1.1. Rationale for Limiting Analysis Scope to IEEE 802.11

CAPWAP grew out of protocols built specifically for managing IEEE 802.11 wireless LANs, but it could be useful for managing other kinds of network device deployments, wireless or not. So you might think one security analysis would cover everything, apart from minor per-binding differences. 💅 But a few other scenarios have come up as likely CAPWAP candidates, like Radio Frequency Identification (RFID) sensors, and that makes it way less of a simple yes-or-no decision. 🤔

Here's the contrast. IEEE 802.11 users usually authenticate to a back-end AAA server, and that exchange produces the cryptographic keys the STA and WTP use to encrypt and authenticate over-air traffic. So the threat environment usually looks like this:

  • The user is not immediately trusted, and therefore must authenticate.
  • The WTP is not immediately trusted, and therefore must indirectly authenticate to the user via the AAA server.
  • The AAA server is not necessarily trusted, and therefore must authenticate.
  • The medium is not trusted, and therefore communications must be secured.

RFID tags, on the other hand, usually don't have the same authentication, confidentiality, and integrity needs as the WLAN players, and they generally aren't well suited to environments with the same threats. 🏷️ Put the WLAN security requirements together with the Medium Access Control (MAC)-splitting behavior that defines the IEEE 802.11 binding for CAPWAP, and you get security concerns for WLAN that just don't exist for an RFID-based version of CAPWAP. It's giving "different problems, different fixes" 💀

Now, there are definitely similarities and overlapping security considerations for every CAPWAP deployment. Authenticating the AC for WTP device management operations is probably always important, for example. 🔐 Still, the RFID threats are different enough to need their own separate security analysis. Since RFID tags commonly deployed today have no over-air authentication, integrity, or confidentiality mechanisms, the need for similar protections between the WTP and AC for RFID tag data isn't clearly indicated. In other words, the threats are different. 🌸

We don't have a full view of all the ways CAPWAP might be adapted later, though it looks like it could be the basis for a generalized scalable provisioning protocol. ✨ Since our view is limited for now, it makes sense to admit that our current perspective is colored by the IEEE 802.11 roots of the protocol, and to make that explicit in our analysis. If newly added bindings turn out to be substantially similar to IEEE 802.11, their binding documents can simply reference this document in their security considerations and call out any substantive differences. 🎀 Still, based on our limited visibility right now, it does look like per-binding threat analyses will be required. 🦋

1.2. Notations

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 📖✨

2. Abbreviations and Definitions 🎀

  • AAA - Authentication Authorization and Accounting
  • AC - Access Controller
  • AES-CCMP - Advanced Encryption Standard - Counter-mode CBC MAC Protocol
  • AP - (wireless) Access Point
  • CAPWAP - Control And Provisioning of Wireless Access Points
  • Cert - X509v3 Certificate
  • DIAMETER - proposed successor to RADIUS protocol (see below)
  • DoS - Denial of Service (attack)
  • DTLS - Datagram Transport Layer Security
  • EAP - Extensible Authentication Protocol
  • MitM - Man in the Middle
  • PMK - Pairwise Master Key
  • PSK - Pre-Shared Key
  • RADIUS - Remote Authentication Dial-In User Service
  • STA - (wireless) STAtion
  • TK - Transient Key
  • TKIP - Temporal Key Integrity Protocol
  • WEP - Wired Equivalent Privacy
  • WLAN - Wireless Local Area Network
  • WTP - Wireless Termination Point

3. CAPWAP Security Goals for IEEE 802.11 Deployments 🎯

When CAPWAP is used with IEEE 802.11, it should avoid introducing any system security degradation compared to the fat AP scenario. 🛡️ But by splitting the AP functions between the WTP and AC, CAPWAP moves potentially sensitive protocol interactions that used to happen inside the AP onto the Layer 3 (L3) network between the AC and WTP. 😳 So the security of this new system depends on the security of that network in between, plus the details of the split. It's a whole chain, bestie. 🔗

Since CAPWAP doesn't directly interact with over-air or AAA protocols, those are mostly out of scope here. 🙈 We don't analyze the basic AAA or IEEE 802.11 security protocols directly, because CAPWAP doesn't modify them in any way and they don't directly interact with CAPWAP. Still, by splitting AP functionality, CAPWAP may expose security elements of those protocols that wouldn't otherwise be exposed. In those cases, CAPWAP should explicitly avoid degrading the security of these protocols in any way compared to the fat AP scenario. 🔍

4. Overview of IEEE 802.11 and AAA Security 🧚

This document isn't directly about IEEE 802.11 or AAA security, but CAPWAP introduces some subtle interactions, and there's related terminology we need to cover to talk about them. 💜 The figure below shows some of the complicated relationships between the protocols and where CAPWAP fits in:

                         +-----+  RADIUS/Diameter
                         | AAA |<==============\\
                         +-----+               ||
                            |                  ||
                +-----------+------------+     ||
                |                        |     ||
             +-----+                  +----+   ||
             | AC  |                  | AC |<==//
             +-----+                  +----+
          +---|  |---+             +---|  |---+
          |          |             |          |
          |          |             |  CAPWAP  |
       +-----+    +-----+       +-----+    +-----+
       | WTP |    | WTP |       | WTP |    | WTP |
       +-----+    +-----+       +-----+    +-----+
       ^                       ^^^
      ^^                      ^^^  802.11i,
      ^^                      ^^  802.1X, WPA,
  +-----+              +-----+     WEP
  | STA |              | STA |
  +-----+              +-----+
 /     /              /     /
+-----+              +-----+

           Figure 3: CAPWAP Protocol Hierarchy

CAPWAP sits between the 802.ll link security mechanism and the authentication server communication, so for some context, here's a quick and very brief overview of IEEE 802.11 and AAA security. ⚡ Heads up: we only cover the stuff that matters for our discussion, so this is definitely not exhaustive. For more detailed coverage of IEEE 802.11-related security topics, see e.g., [80211SEC]. 📚

4.1. IEEE 802.11 Authentication and AAA 🔑

IEEE 802.11 supports several authentication methods before network access is granted. 🚪 In the simplest case, open authentication is used, and that's basically the same as no authentication at all. 🙃 But if IEEE 802.11 link security is going to be provided, some sort of authentication is required to bootstrap the trust relationship that the key establishment process is built on. 🫶

That authentication can be done with a shared secret. In those cases, the authentication may be implicitly tied to the link security mechanism (for example, when Wired Equivalent Privacy (WEP) is used with open authentication), or it may be explicit, like when Wi-fi Protected Access is used with a Pre-Shared Key (WPA-PSK). 🌈

In other cases, authentication needs an explicit cryptographic exchange, and that operation bootstraps link security. In most of these cases, IEEE 802.1X is used together with the Extensible Authentication Protocol [RFC3748] to authenticate the client, or both the client and the authentication server. 🧠 This exchange produces cryptographic keying material for use with IEEE 802.11 security mechanisms. 🔐

The resulting trust relationships are complex, as you can see in this (simplified) figure: 👀

      /--------------------------------------------\
      |                       TK (6)               | EAP Credentials,
      V                  /--------------\          | PMK (3)
   +------+              |  PSK/Cert(1) |          |
   |client|              V              |          V
   |(STA) |         +--------+     |    v     |  +-----+
   +------+ ) ) ) ) |  WTP   |-----|  +----+  |--| AAA |
  /      /          +--------+     |--| AC |--|  +-----+
 +------+              ^           |  +----+  |      ^
   ^  ^                |               ^  ^ (2,4)    |
   |  |    PTK (7)     |               |  \----------/
   |  \----------------/               |   Radius PSK,
   \-----------------------------------/       PMK
           4-Way Handshake (w/PMK) (5)

                Figure 4: Trust Relationships

Here's what each of the relationships means: 💁‍♀️

  1. WTP and AC establish secure link
  2. AC establishes secure link with AAA server
  3. STA and AAA server conduct EAP, produce PMK
  4. AAA server pushes PMK to AC
  5. AC and STA conduct 4-way handshake (producing TK, among other keys)
  6. AC pushes TK to WTP (if decentralized encryption is used)
  7. WTP/STA use TK for IEEE 802.11 link security

okay so the current CAPWAP binding for IEEE 802.11 mostly supports IEEE 802.11i security on the wireless link 💖 BUT, since 802.11i doesn't ban WEP, CAPWAP doesn't either. ngl that's a lot of leniency 💀 Still, using WEP with CAPWAP is NOT RECOMMENDED 🙅‍♀️

If you do use WEP with CAPWAP, the whole CAPWAP system inherits every WEP problem that any wireless network has. 40-bit keys can get brute-forced, and statistical attacks can crack session keys of any length once enough packets have been collected [WEPSEC]. As of late 2008, those attacks are trivial and take literally seconds 😭 not me WEP being this cooked 🗑️

The newer link security mechanisms in IEEE 802.11i, like TKIP and AES-CCMP, seriously level up wireless security 🔥 It is strongly RECOMMENDED that CAPWAP only be used with these newer techniques 👑

Here's the one slightly sus thing CAPWAP adds when it's used with IEEE 802.11i: the KeyRSC counter. With decentralized encryption, the WTP keeps this value, but the AC needs it to do the 4-way handshake 🤝 The value used in the handshake sets the counter on the client. In CAPWAP, this value starts at zero, which opens a tiny window for replay attacks on broadcast traffic. That window is between the initial authentication and the moment the client gets its first valid broadcast packet from the WTP. This small window of attack has been documented in [RFC5416]. ✨

4.3. AAA Security 🛡️

CAPWAP doesn't have much say in how AAA security gets set up, because it isn't directly bound to AAA the way IEEE 802.11 is 🥺 So the most CAPWAP can do is give guidance on how to lock down the AAA parts of a CAPWAP-enabled wireless network 🎀

AAA is the umbrella term for using either RADIUS [RFC3579] or Diameter [RFC4072] to carry EAP traffic between the authenticator and the AAA server. Here the authenticator is the AC, so the AAA protocol is what secures the link between the AC and the AAA server 🫶 Using non-unique or low-entropy long-term credentials to secure the AC-AAA link can seriously wreck the security of the whole CAPWAP deployment 💀 So that's NOT RECOMMENDED, obviously. Each AC should have a mutually authenticated link that gives robust data confidentiality and integrity 🔒 The AAA protocols and keys used SHOULD be consistent with the guidance in [RFC4962]. 📖

Since CAPWAP doesn't directly interact with AAA, it doesn't change the overall security of an AAA network 🙌 Honestly, fewer devices talking to the AAA server means less exposure and less risk of attack, so that's a W 🌸

4.4. Cryptographic Bindings 🔗

okay bestie, the big problem with both the EAP and AAA models is that they're inherently two-party models 💅 In CAPWAP deployments, a whole bunch of security associations come into play when an IEEE 802.11 WLAN client session gets set up. They include:

  • WTP-AC (CAPWAP Authentication)
  • AC-AAA (AAA Authentication)
  • STA-AAA (EAP Method Execution)
  • STA-AC (AAA pushes keys to AC)
  • STA-WTP (AC pushes keys to WTP)

Each of these is a pairwise trust relationship, and none of them come from a multi-party key agreement protocol like Kerberos 🧩 So just because an STA trusts a AAA server, which trusts an AC, which trusts a WTP, does NOT mean the STA should trust the WTP 🙃 Like, the WTP could be compromised and use its credentials to keep a trust relationship with an AC, while telling an STA false stuff about the network 😭 main character villain arc, no cap 💀

Protecting against stuff like this is really hard, especially while keeping trust relationships scalable with the other entities in the network 🥲 Since multiple protocols are involved, multi-party keying to derive end-to-end trust relationships is infeasible 🚫

And since CAPWAP is just a collection of pairwise trust relationships, if we want to claim CAPWAP is secure, we have to believe those trust relationships are transitive 🧠 The hierarchical structure does help cut down on the domino effect 🎲, but any compromised device in the hierarchy can affect every device below it 🫠

5. Structure of the Analysis 🗺️

okay so, to run a thorough threat analysis, there are some basic questions we have to answer 💖

  • Exactly what are we trying to protect?
  • What are the risks?
    • What are the capabilities of would-be attackers?
    • What might be goals of would-be attackers?
    • What are the vulnerabilities or conditions they might attempt to exploit?
    • For various attackers, what is the likelihood of attempting to exploit a given vulnerability given the cost of the exploit versus the value of attack?
  • What potential mitigation strategies are available to us?
  • What kinds of trade-offs do these mitigation strategies offer, and do they introduce any new risks?

This is a super simplified overview of what we need to get through below, but it should give you a feel for how the discussion flows ✨

First up, we describe some representative CAPWAP deployment scenarios 🏠 This helps frame what comes next, so we actually understand what we're protecting 🎀 After that, we describe a threat model in terms of adversary capabilities, the vulnerabilities that come from the CAPWAP functionality split, and a representative sampling of adversary goals 😈 We don't spend a ton of time guessing about specific attackers here, since this is a very general analysis and a WLAN can be deployed in tons of different situations 🌈

Once the general threat model is in place, we describe the countermeasures that make sense, and how they're implemented through different means in the CAPWAP protocol ⚙️ Finally, we talk about the issues that aren't (or can't be) completely addressed, and we give recommendations for reducing the exposure that's left over 🫶

6. Representative CAPWAP Deployment Scenarios 🏢

In this section, we walk through some representative CAPWAP deployment scenarios, especially the ones that were considered when designing the current CAPWAP protocol security 🦋 To keep things clear, we first give some preliminary definitions, along with descriptions of common deployment configurations that cover multiple scenarios 📚 After that, there's a sampling of individual deployment scenarios 💜

6.1. Preliminary Definitions 📝

The IEEE 802.11 standard describes several frame types, and differences in WLAN architectures decide where these frame types start and/or end (that is, at the WTP or the AC) 🧩 There are three basic IEEE 802.11 frame types currently defined:

  • Control: These are for managing the transmission medium (i.e., the airwaves). Examples include RTS, CTS, ACK, PS-POLL, CF-POLL, CF-END, and CF-ACK.
  • Management: These are for managing access to the logical network, as opposed to the physical medium. Example functions include association/disassociation, reassociation, deauthentication, Beacons, and Probes.
  • Data: Transit data (network packets).

There are also a bunch of other services the WLAN infrastructure provides, including these:

  • Packet distribution
  • Synchronization
  • Retransmissions
  • Transmission Rate Adaptation
  • Privacy/Confidentiality/Integrity (e.g., IEEE 802.11i)

The way these (and other) services get split between the AC and the WTP is collectively called "MAC-splitting" characteristics 🍓 We briefly go over the different forms of MAC-splitting below. For more detail, check out [RFC5415] and [RFC5416]. 🔍

6.1.1. Split MAC 🪓

Split MAC scenarios are all about the fact that some IEEE 802.11 MAC messages get processed by the WTP, while others get processed by the AC 💫 For example, a Split MAC setup might divide IEEE 802.11 frame processing like this:

WTP

  • Beacons
  • Probes
  • RTS, CTS, ACK, PS-POLL, CF-POLL,CF-END, CF-ACK

AC

  • Association/Reassociation/Disassociation
  • Authentication/Deauthentication
  • Key Management
  • IEEE 802.11 Link Security (WEP, TKIP, IEEE 802.11i)

The Split MAC model isn't locked to any one deployment scenario, as we'll see below, and vendors get a lot of freedom in choosing how to distribute the IEEE 802.11 functionality 🧁

6.1.2. Local MAC 🏡

Local MAC scenarios are all about the fact that most IEEE 802.11 MAC messages get processed by the WTP 🙌 Some IEEE 802.11 MAC frames do have to be forwarded to the AC (for example, IEEE 802.11 Association Request frames), but overall the WTP handles the MAC interactions. Data frames can also be forwarded to the AC, but they're usually bridged locally 🌷

6.1.3. Remote MAC 🛰️

Remote MAC scenarios are all about the fact that every IEEE 802.11 MAC message gets forwarded to the AC 😶 The WTP doesn't process any of them locally. This model supports super lightweight WTPs that basically need to be nothing more than smart antennas 📡 Remote MAC scenarios aren't covered by the current IEEE 802.11 protocol binding for CAPWAP, but the description is included here for completeness 🫡

6.1.4. Data Tunneling 🚇

No matter which approach to MAC splitting you use, there's still the question of where user data packets get translated between wired and wireless frame formats, meaning where the bridging function happens 🌉 In some cases, user data frames get tunneled back to the AC, and in others, the WTP bridges them locally. You'd expect Remote MAC implementations to always tunnel data packets back to the AC, but for Local and Split MAC modes the decision isn't so clear 🤷‍♀️ Also, it's important to know that there are no rules or standards in place that rigidly define these terms and how they're handled 🙈 Data tunneling gets a further look for each scenario below. 🎀

6.2. Example Scenarios 🌟

In this section, we describe a number of example deployment scenarios. This isn't meant to be an exhaustive list 💅 It's really meant to give a general sense of how WLANs are or may be deployed right now 🌍 This will be important context when we get into adversaries and threats in the sections that follow 🫶

6.2.1. Localized Modular Deployment ✨

okay so this one is about a WLAN that lives inside a single domain of control, usually one building or some other physically contained spot 🏢. bestie, this is giving small to medium-sized org energy 💅. In general the LAN gets some physical security (like, it's inside a building where access is somehow limited), but ngl the real level of physical security is often way less than everyone assumes 🙈.

In these deployments the WLAN is usually an extension of a wired LAN 🎀. But how it hooks up to the wired LAN can vary. For example, the link between the WTPs and ACs can have its own wiring, and its only connection to the LAN is through the AC's Distribution System (DS) port(s). When that happens, the WLAN often gets its own distinct addressing partition(s) so routing is easier, and the AC often acts as a forwarding element 🦋.

Other times the WTPs are mingled with the existing LAN elements 🌸. They might share address space, or they might be logically isolated from the other wired stuff (e.g., by Virtual LAN). In those cases, traffic going to and from the WLAN can be mixed in with traffic going to and from the LAN 👀.

Localized deployments like these could pick any one of the MAC-splitting scenarios, depending on the size of the deployment, mobility requirements, and other considerations ✨. In lots of cases, any one of the different MAC-splitting approaches would be good enough 👑. That means user data may get bridged by either the WTP or the AC 🧚.

6.2.2. Internet Hotspot or Temporary Network ☕

The Internet hotspot scenario is a more general deployment model you'd find at cafes, hotels, or airports ✈️. It's also super similar to temporary WLANs, the ones made for conferences, conventions, and stuff like that 🎪. Some common vibes of these networks:

  • Primary function is to provide Internet access
  • Authentication may be very weak
  • There frequently is no IEEE 802.11 link security

Sometimes the Local MAC model gets used 💅. In that case the AC may be "in the clouds" (out on the Internet somewhere), and user data traffic will typically be locally bridged instead of tunneled back to the AC 🌈. Some IEEE 802.11 management traffic may still get tunneled back to the AC, but honestly the authentication is often just knowing the Service Set Identifier (SSID) and maybe a shared key for use with WEP or WPA-PSK 🙃.

Other times a Split MAC model is used 🫶. This is more common in airport and hotel scenarios, where users may have an account that needs verifying with some back-end infrastructure before they get access 💼. In these cases IEEE 802.11 management frames get tunneled back to the AC (e.g., user authentication), and stronger IEEE 802.11 link security may be provided (e.g., RSN). But user data is still typically locally bridged, because the main goal is still just Internet access 🌐.

A third variation tunnels user data through a local AC so centralized policy can be applied 🔐. For example, in a hotel or airport there's no reason to allow direct access between WLAN users (who typically sit in a private address space) 🙅. Allowing that access could invite all kinds of malicious behavior 💀. So tunneling all user data back to the (local) AC gives you a security choke point where policy can be applied to the traffic 🛡️.

6.2.3. Distributed Deployments 🗺️

The distributed deployment model is a more complex WLAN topology with network segments that are usually spatially separated, although not always 🌍. Those segments might be connected in a physically secure manner, or (if they're widely separated) they might be connected across potentially hostile hops 😤. Below we go through several subgroups of this model 💖.

6.2.3.1. Large Physically Contained Organization 🏬

One distributed example is a single large organization that's physically contained, typically inside one big building 🏢. The network might have logically distinct segments (e.g., per-department or per-floor), and in some cases there might be firewalls between segments for access control 🧱. In these deployments the AC is typically in a centralized datacenter, but there might also be a hierarchy of ACs, with a master in the datacenter and subordinate ACs spread out among the network segments 🌳. These deployments typically assume some level of physical security for the network infrastructure 🔒.

6.2.3.2. Campus Deployments 🎓

Some large organizations have networks that span multiple buildings 🏫. The interconnections between those buildings might be wired (e.g., underground cables), or they might be wireless (e.g., a point-to-point Metropolitan Area Network (MAN) link) 📡. The interconnections may be secured, but sometimes they aren't 😬. The organization may be providing outdoor wireless access to users, in which case some WTPs will typically be located outdoors, and those may or may not be inside physically secure space 🌤️. For example, college campuses frequently provide outdoor wireless access, and the WTPs may simply be mounted on a light post 💡.

For these deployments, ACs may be centrally located in a datacenter, or they may be distributed 🧩. User data traffic may be locally bridged, but more frequently it gets tunneled back to the AC, since that makes mobility and centralized policy enforcement easier 🦋.

6.2.3.3. Branch Offices 🏪

A really common setup is an enterprise with a headquarters and one or more branch offices, with the branches connected to the central HQ 🏙️. Sometimes the site-to-site connection is a private WAN link, and other times it runs across the Internet 🌐. For connections crossing potentially hostile hops (e.g., the Internet), some sort of Virtual Private Network (VPN) is typically used as a protective measure 🔐.

In some simple branch office setups, there are only WTPs at the remote site, and a controller at the central site manages them 🎛️. In other cases, a branch site may have its own subordinate controller, with the master controller still living at the central site 👑. In the first case, local bridging is often the best choice for user data, because of latency and link capacity issues 🐢. In the second case, traffic may be locally bridged by the WTPs, or it may be forwarded to the local subordinate controller for centralized policy enforcement ⚖️. The choice depends on many factors, including local topology and security policy 💅.

6.2.3.4. Telecommuter or Remote Office 🏡

It's getting more and more common to send WTPs home with employees as a telecommuting solution 🏠. There aren't yet any standards or hard rules for how these work, but a pretty typical config is Split MAC with all user data tunneled back to the controller in the organization's datacenter, so the WTP is basically providing wireless VPN services 🔑. These devices may in some cases provide their own channel security (e.g., IPsec), but other approaches are possible too 🤷‍♀️. For example, there may be a stand-alone VPN gateway between the WTP and the Internet, which forwards all organization-bound traffic to the VPN gateway 🚪.

Travelers are also increasingly plugging a WTP into a hotel broadband connection 🧳. In many cases these WTPs are stand-alone fat APs, but in some they're configured to create a secure connection to a centralized controller back at headquarters, basically forming a VPN connection 🌸. In these scenarios a Split MAC approach is typical, but split-tunneling may also be supported (i.e., only data traffic destined for the headquarters is tunneled back to the controller, while Internet-bound traffic is locally bridged) 🦋.

7. General Adversary Capabilities 😈

This section is all about the general capabilities we might expect an adversary to have in various CAPWAP scenarios 👀. Obviously it's possible to limit what an adversary can do through deployment restrictions (e.g., providing strict physical security for the AC-WTP link) 🔐. But those restrictions just aren't always feasible 😩. For example, it's not possible to provide strict physical security for various aspects of the telecommuter scenario 🏡. So we have to consider what capabilities an adversary might have in the worst case, and plan accordingly 💜.

7.1. Passive versus Active Adversaries 🕵️

Okay so one way to sort adversaries is by how much they can actually do to AC/WTP communications 👀. A passive adversary is basically a lurker: they can observe and maybe record traffic, but they can't touch it. They can "see" the traffic zooming by, but they can't interfere in any way and they can't inject traffic of their own 🦋. Still, a passive adversary doesn't necessarily see everything. They might miss chunks of a conversation, like when some packets take a different path, or when the network is so busy that the adversary can't keep up and ends up dropping packets 💀.

An active adversary is a whole different energy 🔥. They can interact with the traffic in real-time. There are two modes an active adversary might run in:

Pass-by (or sniffer)

  • Can observe/record traffic
  • Can inject packets
  • Can replay packets
  • Can reflect packets (i.e., send duplicate packets to a different destination, including the to the packet source)
  • Can cause redirection (e.g., via Address Resolution Protocol (ARP)/DNS poisoning)

Inline (Man-in-the-Middle, or MitM)

  • Can observe/record traffic
  • Can inject packets
  • Can replay packets
  • Can reflect packets (with or without duplication)
  • Can delete packets
  • Can modify packets
  • Can delay packets

A passive adversary could be sitting anywhere along the path between the AC and WTP, and its whole thing is that it only listens 👂✨:

     +------+
     |client|         +--------+     |
     |(STA) |         |   WTP  |     |     +------+
     +------+ ) ) ) ) |        |-----|    /        \    +------+
    /      /          +--------+     |-x-( optional )---|  AC  |
   +------+                          | |  \ cloud  /    +------+
                                     | |   +------+
                                       |
                                       |  +-----------+
                                       +--|  pass-by  |
                                          |  listener |
                                          +-----------+

                  Figure 5: Passive Attacker

An active adversary can either attach the same way the passive one does (in which case it's in pass-by mode), or it can be lodged directly in the path between the AC and WTP (inline mode) 😈:

     +------+
     |client|       +--------+   |
     |(STA) |       |   WTP  |   | +------+    +------+
     +------+ ) ) ) |        |---| |active|   /        \    +------+
    /      /        +--------+   |-| MitM |--( optional )---|  AC  |
   +------+                      | +------+   \ cloud  /    +------+
                                 |             +------+

            Figure 6: Active Man-in-the-Middle Attacker

So if it's not inline, it can only observe and create traffic. If it is inline, it can do whatever it wants with the traffic it sees 💅.

It's important to get that becoming a MitM doesn't necessarily mean physically inserting yourself into the transmission path 🙈. The adversary can also just cause traffic to get diverted to the MitM system, e.g., via ARP or DNS poisoning. So launching a MitM attack isn't as hard as it might first sound 😭.

8. Vulnerabilities Introduced by CAPWAP 🚨

Okay this section is where we talk about the vulnerabilities that show up when you split the AP function across potentially hostile hops 🫣. We mostly focus on network-based vulnerabilities. We don't really get into how an adversary might physically compromise the WTP or AC, but we do think about what those compromises could do to CAPWAP, and the operational changes it brings compared to stand-alone AP deployments 🧐.

Functionally, we care about two general "states of being" for AC-WTP communications: the session establishment phase or state, and the "connected" (or session established) state. We'll break each of these down below. Also, heads up: we first describe the vulnerabilities assuming the CAPWAP communications have no security of any kind. We'll evaluate the protocol with the security mechanisms currently planned for CAPWAP later 🔐.

8.1. The Session Establishment Phase 🤝

The session establishment phase has two subphases: discovery, and association or joining. We treat each of these individually in the following sections.

8.1.1. The Discovery Phase 🔍

Discovery is basically an information exchange between the AC and WTP, and there are a few spots where things can go wrong:

Information Leakage: During Discovery, information about the WTP and AC hardware and software gets exchanged, along with info about the AC's current operational state. That could give an adversary some seriously valuable insights 👀.

DoS Potential: During Discovery, there are several chances for Denial of Service (DoS), beyond the ones an inline adversary already has. For example, an adversary might respond to a WTP faster than a valid AC does, which could make the WTP try to join a non-existent AC, or one that's currently at maximum load 😩.

Redirection Potential: There are multiple ways an adversary might redirect a WTP during Discovery. For example, the adversary might pretend to be a valid AC and entice the WTP to connect to it. Or the adversary might instead cause the WTP to associate with an AC of the adversary's choosing, by posing as a DNS or DHCP server, injecting a spoofed Discovery Response, or by modifying valid AC responses 🎭.

Misdirection: An adversary might mislead either the WTP or the AC by modifying the Discovery Request or Response in flight. That way, the AC and/or WTP end up with a false view of the other's capabilities, which could change how they interact (e.g., they might not use important features that earlier versions don't support) 🙃.

8.1.2. Forming an Association (Joining) 💞

The association phase kicks off once the WTP has figured out which AC it wants to join. A few exposure points show up during this phase:

Information Leakage: During association, the adversary could glean useful info about hardware, software, current configuration, etc., which could then get used in all sorts of ways 🕵️‍♀️.

DoS Potential: During formation of a WTP-AC association, there are several chances for Denial of Service (DoS), beyond the ones an inline adversary already has. For example, the adversary could flood the AC with connection setup requests. Or it could respond to the WTP with invalid connection setup responses, causing a connection reset. An adversary with MitM capability could also delete critical session establishment packets 💀.

Misdirection: An adversary might mislead either the WTP or AC by modifying the association request(s) or response(s) in flight. That leaves the AC and/or WTP with an inaccurate view of the other's capabilities, which might change the way they interact 🌀.

Some of these exposures are extremely difficult to prevent. BUT there are things we can do to mitigate the effects, as we'll see below 🛡️✨.

8.2. The Connected Phase 🔗

Once the WTP and AC have set up an association, the adversary's attention shifts to the network connection. If we assume a passive adversary, the main concern for established connections is eavesdropping. If we assume an active adversary, there are several other potential exposure points:

Connection Hijacking: An adversary may assume the identity of one end of the connection and take over the conversation. There are lots of ways the true owner of that identity could get knocked offline, including DoS or MitM attacks 😱.

Eavesdropping: An adversary may glean useful info from knowing the contents of CAPWAP control and/or data traffic 👂.

Modification of User Data: An adversary with MitM capabilities could modify, delete, or insert user data frames 🥲.

Modification of Control/Monitoring Messages: An adversary with MitM capability could modify control traffic like statistics, status information, etc., to create a false impression at the recipient 🫠.

Modification/Control of Configuration: An adversary with MitM capability could modify configuration messages to create unexpected conditions at the recipient. Likewise, if a WTP gets redirected during Discovery (or joining) and connects to an adversary instead of an authorized AC, the adversary may exert complete control over the WTPs configuration, including potentially loading tainted WTP firmware. Yikes 🙀🔥.

9. Adversary Goals in CAPWAP 🎯

This section gives an sampling of potential adversary goals. It isn't exhaustive, and it makes no judgment about the relative likelihood or value of each goal. It's more about giving you some idea of what's possible. Remember that clever attacks often come from seemingly innocent flaws or vulnerabilities being combined in some non-intuitive way 🧩. So we don't rule out a goal that, taken alone, might not seem to make sense from an adversarial perspective 🤷‍♀️.

9.1. Eavesdrop on AC-WTP Traffic 👀

There are lots of reasons an adversary might want to eavesdrop on AC-WTP traffic. For example, it enables reconnaissance, answering questions like:

  • Where are the ACs?
  • Where are the WTPs?
  • Who owns them?
  • Who manufactured them?
  • What version of firmware do they run?
  • What cryptographic capabilities do they have?

Snooping on tunneled data traffic could also reveal a ton about the network, including answers to questions like:

  • Who's using the WLAN?
  • When, and for how long?
  • What addresses are they using?
  • What protocols are they using?
  • What over-the-air security are they using?
  • Who/What are they talking to?

Plus, access to tunneled user data could let the attacker see confidential info being exchanged by applications (e.g., financial transactions) 💸. An eavesdropper may pick up valuable info that either sets up another, maybe more sophisticated attack, or that has its own intrinsic value 🧠.

9.2. WTP Impersonation and/or Rootkit Installation 😈

An adversary might want to impersonate or control an authorized WTP for lots of reasons, some of which we can realistically imagine today, and maybe others we have no clue about yet 🌚. Examples we can reasonably imagine include:

  • to facilitate MitM attacks against WLAN users
  • to leak/inject or otherwise compromise WLAN data
  • to give an inaccurate view of the state of the WLAN
  • to gain access to a trusted channel to an AC, through which various protocol attacks might be launched (e.g., hijack client sessions from other WTPs)
  • to facilitate Denial-of-Service attacks against WLAN users or the network

9.3. AC Impersonation and/or Rootkit Installation

Okay, same energy as the WTP impersonation drama 👀 An adversary could also want to pretend to be an authorized AC, and honestly the reasons are kind of iconic. Here are some we can totally imagine 💅

  • to facilitate DoS attacks against WLANs
  • to facilitate MitM attacks against WLAN users
  • to intercept user mobility context from another AC (possibly including security-sensitive information such as cryptographic keys)
  • to facilitate selective control of one or more WTPs
    • modify WTP configuration
    • load tainted firmware onto WTP
  • to assist in controlling which AC associates with which WTP
  • to facilitate IEEE 802.11 association of unauthorized WLAN user(s)
  • to exploit inter-AC trust in order facilitate attacks on other ACs

Ngl, AC impersonation is giving total control of the WLAN 😭 Once someone has that, it can be the foundation for a whole bunch of other attacks 🧨

9.4. Other Goals or Sub-Goals

There are a bunch of low-key goals an adversary might have that, on their own, seem pointless 🙃 But stack them with other goals or attacks and suddenly they have very real, very not-cute consequences. Some examples:

  • cause CAPWAP de-association of WTP/AC
  • cause IEEE 802.11 de-association of authorized user
  • inject/modify/delete tunneled IEEE 802.11 user traffic
    • to interact with a specific application
    • to launch various attacks on WLAN user systems
    • to launch protocol fuzzing or other attacks on the AC that bridges between IEEE 802.11 and 802.3 frame formats
  • control DNS responses
  • control DHCP/BOOTP responses

Trying to predict everything an adversary might want to do is a lot 😩 Part of the struggle is that we're looking at CAPWAP in a very general way, not in one specific deployment with specific assets and very specific adversary goals. Still, we don't really have a choice if we want reasonably good security across the board 🫶

10. Countermeasures and Their Effects ✨

Okay, glow-up time 🌸 In the last sections we went through a bunch of vulnerabilities that come from splitting the AP function in two, plus a bunch of adversary goals that could be pulled off by abusing one or more of them. Now we get to the good part: the countermeasures we can use to reduce the risks that come with bringing CAPWAP into WLAN deployments 💖

10.1. Communications Security Elements

10.1.1. Mutual Authentication

Mutual authentication is basically both sides proving who they are to each other 🪪 There are plenty of authentication protocols that pull this off. They usually use either a shared secret (for example, a pre-shared key) or a trusted third party (for example, digital credentials like X.509 certificates).

Strong mutual authentication does all of this for us:

  • helps prevent AC/WTP impersonation
  • helps prevent MitM attacks
  • can be used to limit DoS attacks.

10.1.1.1. Authorization

Authentication is about proving who an entity is, but authorization is about deciding whether that entity should get access to some resource 🔑 Honest tea: the current IEEE 802.11i CAPWAP protocol binding is pretty simplistic about this, and it depends on which authentication method you pick. If pre-shared keys are used, authorization is broad and coarse 🙈 If the device knows the pre-shared key, the device is "trusted", meaning that it is believed to be what it claims to be ( AC versus WTP), and it gets all the privilege/access tied to that device class.

When using pre-shared keys, you can get a little more granularity by making classes that each have their own pre-shared key. Still, this has drawbacks 😬 Knowing the key might be enough to show a device belongs to a given group or class, but it can't prove the device is actually a WTP or an AC. That means the key can be abused, and anyone holding it can claim to be either type of device 💀

When X.509v3 certificates are used for authentication, much more granular authorization policies are possible ✨ Still, the current IEEE 802.11i protocol binding stays pretty simplistic here (though this may get addressed in future revisions). As currently defined, the X.509v3 certificates make the following authorization checks possible:

  • CommonName (CN): the CN contains the MAC address of the device; if the relying party (AC or WTP) has a method for determining "acceptability" of a given MAC address, this helps prevent AC/WTP impersonation, MitM attacks, and may help in limiting DoS attacks
  • Extended Key Usage (EKU) key purpose ID bits: CAPWAP uses specific key purpose ID bits (see [RFC5415] for more information) to explicitly differentiate between an AC and a WTP. If use of these bits is strictly enforced, this segregates devices into AC versus WTP classes, and assists in preventing AC/WTP impersonation, MitM attacks, and may also help in limiting DoS attacks. However, if the id-kp-anyExtendedKeyUsage keyPurposeID is supported, this mechanism may be on a par with pre-shared keys, as a rogue device has the ability to claim it is either a WTP or AC, unless CN-based access controls are employed in tandem.

Also, certificate-based authorization and zero configuration are not fully compatible 🙅‍♀️ Even if the WTPs and the ACs ship with manufacturer-provided certificates, the WTPs need a way to identify the correct AC for this deployment (as opposed to other ACs from the same vendor, purchased and controlled by an adversary). The AC also needs to know which WTPs are part of this deployment (as opposed to WTPs purchased and controlled by an adversary). Main character problems, fr 😤

The threat analysis in this document assumes that WTPs can identify the correct AC, and that the AC can identify the correct WTPs 🫶 Analysis of situations where either of these doesn't hold is beyond the scope of this document.

10.1.2. Data Origin Authentication

Data origin authentication usually starts by authenticating the party on the other end of the channel, and then tying the identity from that process to the data origin authentication itself 🔗 Its main job is stopping an attacker from injecting data into the channel and pretending a valid endpoint sent it 🚫 This mitigates risk by preventing:

  • packet injection
  • connection hijacking
  • modification of control and/or user data
  • impersonation

10.1.3. Data Integrity Verification

Data integrity verification gives you assurance that data hasn't been changed in transit 🧵 It's another link in the trust chain: it starts with mutual authentication, extends to data origin authentication, and ends with integrity verification. This stops the adversary from quietly modifying otherwise valid data on the way. It effectively prevents reflection and modification, and in some cases it may help prevent re-ordering 🔄

10.1.4. Anti-Replay

Anti-replay is pretty self-explanatory 😌 It stops valid packets from being replayed later, or being sent to a different recipient. It may also prevent limited re-ordering of packets. It's typically done by assigning monotonically increasing sequence numbers to packets 🔢

10.1.5. Confidentiality

Data confidentiality stops eavesdropping by protecting data while it crosses the network 🤫 This is typically accomplished using encryption 🔐

10.2. Putting the Elements Together

Okay so we've covered all the individual security elements and what they do ✨ Now it's time to see how they pair up for CAPWAP 💅

10.2.1. Control Channel Security

The CAPWAP control channel is what forms the association between a WTP and an AC, and after that it lets the AC provision and monitor the WTP 🎛️ This channel is critical for controlling, managing, and monitoring the WLAN, so it needs all of the security elements described above 👑 With all of those in place, we can create a secure channel that mitigates almost all of the vulnerabilities we talked about earlier 🦋

10.2.2. Data Channel Security

The CAPWAP data channel carries some IEEE 802.11 management traffic, including association/disassociation, reassociation, and deauthentication. It may also carry potentially sensitive user data 👀 If we assume threats to this channel exist (in other words, it crosses potentially hostile hops), then strong mutual authentication combined with data origin/integrity verification would stop an adversary from injecting and/or modifying transit data, or from impersonating a valid AC or WTP 🛡️ Adding confidentiality would stop eavesdropping too 🎀

11. Countermeasures Provided by DTLS 🌈

Datagram TLS (DTLS) is the currently proposed security solution for CAPWAP 💜 DTLS supports the following security functionality:

  • Mutual Authentication (pre-shared secrets or X.509 Certificates)
  • Mutual Authorization (pre-shared secrets or X.509 Certificates)
  • Data Origin Authentication
  • Data Integrity Verification
  • Anti-replay
  • Confidentiality (supports strong cryptographic algorithms)

Using DTLS for both the control and data channels mitigates nearly all risks that come from splitting the AP function in two 🥹

12. Issues Not Addressed By DTLS ⭐

Unfortunately, DTLS doesn't solve every single CAPWAP security concern 😭 There are some things it just can't prevent. Those are listed below 👇

12.1. DoS Attacks 💥

okay bestie, even with DTLS locking things down, CAPWAP is still open to a few kinds of DoS attack 😭

  • Session Initialization: an adversary could start thousands of DTLS handshakes at the same time to drain the AC's memory 💀. DTLS has a fix for this, the HelloVerifyRequest, which makes sure the initiator can actually receive packets at the claimed source address before any resources get allocated 🛡️. Sadly, that doesn't stop a botnet-style attack 🤖.
  • Cryptographic DoS: an adversary could flood either the AC or the WTP with properly formed DTLS records full of garbage, so the recipient burns compute cycles trying to decrypt and authenticate traffic that was never legit 🥲.
  • Session interference: a MitM could drop important session establishment packets, inject bogus connection resets during the session establishment phase, or mess with other traffic inside an established session 👀.

these attacks can be mitigated in different ways, but they can't be fully avoided ✨. For example, session initialization can be rate-limited, and when resources are running out, some number of incompletely initialized sessions could be discarded 🧹. Also, such events should be strictly audited 📋.

cryptographic DoS attacks are detectable if appropriate auditing and monitoring controls are in place 🔍. When detected, these events should (at minimum) trigger an alert 🚨. Additional mitigation might be realized by randomly discarding packets 🎲.

session interference is probably the hardest DoS attack of all 😩. It's very difficult to detect in real time, although it may be detected if exceeding a lost packet threshold triggers an alert. The catch is that this only works if the MitM isn't in a position to delete the alert before it reaches its proper destination 🙃.

12.2. Passive Monitoring (Sniffing) 👂

CAPWAP protocol security cannot prevent (or detect) passive monitoring 🫣. The best we can do is provide a confidentiality mechanism 🔐.

12.3. Traffic Analysis 📊

DTLS gives no defense against traffic analysis 🙈. If this is a concern, there are traffic generation and padding techniques designed to mitigate this threat, but none of them are currently specified for CAPWAP 🧩.

12.4. Active MitM Interference 🕵️

We already touched on this in a more limited way in the DoS section above 🔁. An active MitM can delete or re-order packets in a way that's very difficult to detect, and there's little the CAPWAP protocol can do about it in those cases 😤. If packet loss is reported upon exceeding some threshold, then detection might be possible, but that's not guaranteed 🤞.

12.5. Other Active Attacks 🦹

On top of everything above, there are other active attacks that can be mounted if the adversary has access to the wired medium 🔌. For example, the adversary may be able to impersonate a DNS or DHCP server, or to poison either a DNS or ARP cache 🫠. These attacks are beyond the scope of CAPWAP, and they point to an underlying LAN security problem 🏠.

13. Security Considerations 🔐

okay this section is serious, so listen up 🫶. This document outlines a threat analysis for CAPWAP in the context of IEEE 802.11 deployments, so no additional CAPWAP-related security considerations are described here 📝. However, in some cases additional management channels (e.g., Simple Network Management Protocol (SNMP)) may be introduced into CAPWAP deployments. Whenever this happens, related security considerations MUST be described in detail in those documents ⚠️.

14. Acknowledgements 🙏

The authors gave a huge shoutout to the reviews and helpful comments from Dan Romascanu, Joe Salowey, Sam Hartman, Mahalingham Mani, and Pasi Eronen 💜✨.

15. References 📚

15.1. Normative References

  • [80211I] "IEEE Std 802.11i: WLAN Specification for Enhanced Security", April 2004.
  • [80211SEC] Edney, J. and W. Arbaugh, "Real 802.11 Security - Wi-Fi protected Access and 802.11i", 2004.
  • [8021X] "IEEE Std 802.1X-2004: Port-based Network Access Control", December 2004.
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC4118] Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy for Control and Provisioning of Wireless Access Points (CAPWAP)", RFC 4118, June 2005.
  • [RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, Ed., "Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification", RFC 5415, March 2009.
  • [RFC5416] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, Ed., "Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Binding for IEEE 802.11", RFC 5416, March 2009.

15.2. Informative References

  • [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003.
  • [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
  • [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005.
  • [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, Authorization, and Accounting (AAA) Key Management", BCP 132, RFC 4962, July 2007.
  • [WEPSEC] Petroni, N. and W. Arbaugh, "The Dangers of Mitigating Security Design Flaws: A Wireless Case Study", January 2003.

Authors' Addresses 🖊️

Scott G. Kelly Aruba Networks 1322 Crossman Ave Sunnyvale, CA 94089 US

EMail: scott@hyperthought.com

T. Charles Clancy DoD Laboratory for Telecommunications Sciences 8080 Greenmead Drive College Park, MD 20740 US

EMail: clancy@LTSnet.net 💅

📦 where this page comes from