CAPWAP Threat Analysis

1. CAPWAP Threat Analysis 66th IETF, Montreal 10 July 2006 Scott Kelly Charles Clancy

2. A little review… • In previous CAPWAP episodes we saw that… • There are many interdependent security protocols running between the station and the network • CAPWAP potentially creates exposure by breaking the original fat AP model into two pieces and connecting them with a channel which may traverse hostile hops • Want to do all we reasonably can to ensure that this architectural change does not degrade existing WLAN security (don’t introduce a weak link) 66th IETF - CAPWAP

3. Fast-forwarding to the present… • CAPWAP is still gestating • Yet current protocol draft is already over 150 pages… • The protocol will grow/change as we gain deployment experience • Some changes will likely impact security • How will we know when this occurs? • Those designing new features should take security considerations/assumptions into account • Security assumptions/requirements should be made explicit • Recommendation: • Working group should undertake and document a comprehensive CAPWAP threat analysis (Informational) • Clancy and Kelly are currently working on a draft • We’d like to see this accepted as a work item 66th IETF - CAPWAP

4. Why a new document? • The current document is defining a base protocol • There will be extensions, probably other documents • Threat analysis, security requirements span these • Should not have to rev base protocol document each time new extension highlights new threats • CAPWAP threat analysis is complex • There are numerous deployment models • Each has unique threat scenarios • Likely to be many (50+ ?) pages • Following is a brief document outline (to give a general feel for the level of detail in 00 draft) 66th IETF - CAPWAP

5. Document Outline • Introduction • A little background on original fat AP model • CAPWAP splits this AP function in two • WTP implements WLAN edge functions with respect to user • AC implements edge functions with respect to LAN, AAA • Variable splits of MAC functions between WTP/AC • Splitting in itself introduces nothing new in terms of security if the same assumptions hold as for fat AP model • But in most cases they don’t • Ideally, CAPWAP should introduce no new vulnerabilities which are not intrinsic to WLANs (i.e. present in fat AP scenarios) • Practically, this is not achievable, but we must strive to minimize new exposures introduced by the act of splitting the AP function 66th IETF - CAPWAP

6. Document Outline (2) • Example Deployment Scenarios • Localized modular deployment • Single building or physically contained area • Some physical security for LAN • WLAN is extension of LAN • Sometimes it’s an overlay (separate wiring) • Sometimes WTPs are commingled with the existing LAN elements • Internet Hotspot or temporary network • Local-MAC model • AC in the cloud • Primary CAPWAP function is WTP control and transport for AAA subscriber management • Split-MAC • airport, hotel, conference • wired LAN between AC/WTP may be within single domain of control • data traffic may be tunneled 66th IETF - CAPWAP

7. Document Outline (3) • Example Deployment Scenarios (continued) • Distributed deployment • Headquarters with multiple discrete LAN segments • Campus (multiple buildings) • Remote offices (branch or telecommuters) • Local-MAC (data bridged locally) • Split-MAC (data tunneled back to AC) • WTP network may be within same domain of control as AC (branch office) or not (telecommuter) • General Adversary Capabilities • Passive adversaries (sniffers) • Can observe and record (eavesdrop), but not interact with the traffic • Active adversaries • Pass-by • can sniff, inject, replay, reflect (with duplication), cause redirection • Inline (MiM) • Can observe, inject, delete, replay, reflect, redirect, modify packets 66th IETF - CAPWAP

8. Document Outline (4) • Vulnerabilities resulting from splitting AP function • New exposures during session establishment • Discovery • Information leakage • DoS potential (by injecting/modifying requests/responses) • Redirection potential • Secure association (DTLS handshake) • Various DoS opportunities • Information leakage (identity, capabilities) • New exposures while connected • Cryptographic DoS on CAPWAP protocol endpoint(s) • 802.11 mgmt frame attacks (on the wire) • Application data exposure • Information leakage (topology, applications, etc) 66th IETF - CAPWAP

9. Document Outline (5) • General adversary goals (and sub-goals) in CAPWAP • Eavesdrop on AC-WTP traffic • WTP spoofing • AC spoofing • Control which AC associates with which WTP • Cause (CAPWAP) de-association of WTP/AC • Cause (802.11) de-association of authorized user • Facilitate (802.11) association of unauthorized user (by impersonating AC) • Inject 802.11 user traffic • Modify 802.11 user traffic • Remotely take control of WTP • Modify WTP configuration, firmware • Remotely take control of AC • Buffer overflow • Protocol DoS attacks • Inject MiM requests/replies which terminate AC-WTP connection • Delete session establishment requests/replies • Repeatedly initiate sessions, leaving them dangling 66th IETF - CAPWAP

10. Document Outline (6) • Countermeasures • Preventative Measures • Strong control channel security • Prevents impersonation/spoofing for configuration/mgmt/monitoring • Strong data channel security • Prevents eavesdropping • Prevents disassociation of authorized users (DoS) • Mutual authentication • Prevents AC/WTP impersonation/spoofing • Prevents MiM attacks • Can be used to limit DoS attacks • Data origin authentication • Prevents injection, impersonation, spoofing, (dis)association of authorized users • Data integrity verification • Prevents reflection, modification • Anti-replay protection • Prevents recording and subsequent replay of valid session • Confidentiality • Prevents eavesdropping 66th IETF - CAPWAP

11. Document Outline (7) • Countermeasures, cont. • Detection and Response • Some things cannot be entirely prevented (but can be detected) • Attacks on authentication mechanisms • Credential guessing • Attempt to use expired certificate • Attempt to use invalid certificate • MiM on initial handshake packets to collect data for PSK attack • DoS attacks • A MiM can always prevent packets from going through • Session initialization • DTLS handshake interference • Session exhaustion (on AC) • Session runtime • Injection of bogus packets (requiring crypto operations) • Deletion of packets • Implementation Recommendations 66th IETF - CAPWAP

12. Document Outline (8) • There are some threats we cannot prevent or detect • Passive monitoring • Traffic analysis (actually, there are ways to prevent this, but not to detect it) • Active MiM traffic interference • Packet deletion, re-ordering • Other active attacks • ARP poisoning • DNS poisoning • Offline dictionary attacks on pre-shared keys • Probably want to provide practical advice for when these are possible, and what can be done to mitigate them. 66th IETF - CAPWAP

13. Summarizing • CAPWAP threat analysis is a complex endeavor • It’s important to document our assumptions, so that extensions and modifications don’t wind up breaking our security mechanisms • This should be a work item for group • Draft is in progress, hope to have 00 out within a few weeks 66th IETF - CAPWAP