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

1
CAPWAP Threat Analysisdraft-kelly-capwap-threat-a
nalysis-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 (dont introduce a weak
  link)

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

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

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

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

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

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

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.

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
• 00 version is available, 01 is coming soon
• Questions?