CAPWAP Threat Analysis draft-kelly-capwap-threat-analysis-00

1. CAPWAP Threat Analysisdraft-kelly-capwap-threat-analysis-00 67th IETF, San Diego 6 November 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 introduces new 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) 67th IETF - CAPWAP

3. Fast-forwarding to the present… • CAPWAP is still gestating • Just split original draft into base + 802.11 binding • The protocol will grow/change as we gain deployment experience • We may somehow extend/modify the 802.11 binding (e.g. for 11n) • there will likely be other bindings defined • Some changes may impact security model • How will we know when this occurs? • Those designing new features should take existing security considerations/assumptions into account • It might be us adding new features… or it might be someone new • They will need to know what we were thinking about • Security assumptions/requirements should be made explicit • Recommendation: • Working group should undertake and document a comprehensive CAPWAP threat analysis based on current base protocol and 802.11 binding (Informational) • There is currently a 00 draft • We’d like to see this accepted as a work item 67th IETF - CAPWAP

4. Why a new document? • Why not just include this as security considerations? • Hmmm… in which document? • The current documents define a base protocol and 802.11 binding • Threat analysis, security requirements span these two • There will be extensions, probably new bindings, and these may bring new security requirements of their own • CAPWAP threat analysis is complex • There are numerous deployment models • Each has unique threat scenarios • Some considerations specific to base protocol deployment, some specific to 802.11 binding, some relate to both • Clearest approach: discuss this all in one place 67th IETF - CAPWAP

5. Document Overview • Introduction • A little background on original fat AP mode • Provides important context • CAPWAP splits this fat AP functionality 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 often, they don’t • Fat AP model typically assumes wired LAN is “safe” • CAPWAP may run across “unsafe” hop(s) • 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 67th IETF - CAPWAP

6. Document Overview (2) • Discussion of CAPWAP security goals • Gist: try not to add any exposure not present in original fat AP model • Overview of 802.11 and AAA security • Need to give background, context to understand how CAPWAP interacts with WLAN security landscape • There are complex trust relationships, trust chaining • CAPWAP is smack dab in the middle of all this • Structure of the analysis • What are we protecting? • What are the risks? • Attacker capabilities • Vulnerabilities/potential points of attack • Attacker goals • Mitigation strategies • Trade-off analysis 67th IETF - CAPWAP

7. Document Overview (3) • Example Deployment Scenarios • Current draft spends a few pages discussing how CAPWAP may be deployed • Helps to illustrate use cases that were considered for security analysis • Sets context for later changes: if new proposal introduces new use case, good chance additional security analysis is required • Not a litmus test, but certainly helps 67th IETF - CAPWAP

8. Document Overview (4) • 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 • Vulnerabilities resulting from splitting AP function • New exposures during session establishment • Discovery • Information leakage • DoS potential (by injecting/modifying requests/responses) • Redirection potential • CAPWAP Session Establishment • Various DoS opportunities • Information leakage (identity, capabilities) • New exposures while connected • DoS on CAPWAP protocol endpoint(s) • 802.11 mgmt frame attacks (on the wire) • Application data exposure • Information leakage (topology, applications, etc) 67th IETF - CAPWAP

9. Document Overview (5) • General adversary goals in CAPWAP • Eavesdrop on AC-WTP traffic • WTP impersonation • AC impersonation • Sub-goals (which may be building blocks for other attacks) • 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 (e.g. by impersonating AC) • Inject/Modify 802.11 user traffic • Remotely take control of WTP • Modify WTP configuration, firmware • Remotely take control of AC • And indirectly control WTP(s) and 802.11 user traffic as a result • Protocol DoS attacks • Inject MiM requests/replies which terminate AC-WTP connection • Delete session establishment requests/replies • Repeatedly initiate sessions, leaving them dangling 67th IETF - CAPWAP

10. Document Overview (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 67th IETF - CAPWAP

11. Document Overview (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 67th IETF - CAPWAP

12. Document Overview (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. 67th 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 • 00 version is available, 01 is coming soon • Questions? 67th IETF - CAPWAP