CAPWAP%20Threat%20Analysis

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 (dont introduce a weak
  link)

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
• Wed like to see this accepted as a work item

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)

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 dont
• 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
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 its 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

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

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)

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

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

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

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.

13
Summarizing

• CAPWAP threat analysis is a complex endeavor
• Its important to document our assumptions, so
  that extensions and modifications dont 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