CAPWAP Threat Analysis

CAPWAP Threat Analysis

66th IETF, Montreal

10 July 2006

Scott Kelly Charles Clancy

10 July 2006 66th IETF - CAPWAP 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)


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


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)


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


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


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


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)


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


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


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


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.


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

CAPWAP Threat Analysis

Documents

Transcript of CAPWAP Threat Analysis