1. CAPWAP Threat Analysis draft-kelly-capwap-threat-analysis-00 67 th IETF, San Diego 6 November 2006 Scott KellyCharles Clancy

2. 6 November 200667th IETF - CAPWAP2 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)

3. 6 November 200667th IETF - CAPWAP3 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

4. 6 November 200667th IETF - CAPWAP4 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

5. 6 November 200667th IETF - CAPWAP5 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

6. 6 November 200667th IETF - CAPWAP6 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

7. 6 November 200667th IETF - CAPWAP7 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

8. 6 November 200667th IETF - CAPWAP8 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)

9. 6 November 200667th IETF - CAPWAP9 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

10. 6 November 200667th IETF - CAPWAP10 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

11. 6 November 200667th IETF - CAPWAP11 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

12. 6 November 200667th IETF - CAPWAP12 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.

13. 6 November 200667th IETF - CAPWAP13 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?