CAPWAP Threat Analysis 66 th IETF, Montreal 10 July 2006 Scott KellyCharles Clancy

10 July th 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 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)

10 July th IETF - CAPWAP3 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

10 July th IETF - CAPWAP4 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)

10 July th IETF - CAPWAP5 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

10 July th IETF - CAPWAP6 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

10 July th IETF - CAPWAP7 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

10 July th IETF - CAPWAP8 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) mgmt frame attacks (on the wire) Application data exposure Information leakage (topology, applications, etc)

10 July th IETF - CAPWAP9 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 user traffic –Modify 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

10 July th IETF - CAPWAP10 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

10 July th IETF - CAPWAP11 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

10 July th IETF - CAPWAP12 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.

10 July th 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 Draft is in progress, hope to have 00 out within a few weeks