CAPWAP Threat Analysis

1
CAPWAP Threat Analysis

• draft-ietf-capwap-threat-analysis-00
• IETF 68, CAPWAP Working Group
• Charles Clancy Scott Kelly

2
Document Status

• Adopted as a working group document
• Published as -00
• Changes
• Filled in AAA security section
• Added discussion of channel binding

3
Quick Recap

• Document not designed to replace security
  considerations text
• Security considerations focuses more on low-level
  protocol details, things CAPWAP-specific
• Threat analysis looks more at the big picture
• Goal of the document
• Provide a little history on 11i/AAA security, and
  how CAPWAP fits into the mix
• Document the many different use cases, and
  describe how such deployment scenarios affect the
  system security

4
Recent Changes

• New discussion on channel bindings
• Just because STA trust AAA who trusts AC who
  trusts WTP, why should STA trust WTP?
• Is trust transitive?
• Nature of identity

AAA
AC
WTP
STA
long-term trust relationship
long-term trust relationship
bootstrapped trust relationship
long-term trust relationship
5
Example Attack

• Lying NAS problem AP has one identity in its
  security association to the AAA server, but
  provides another identity to the STA in 802.11
  beacon messages
• CAPWAP only compounds the problem
• Problem is that the STA only trusts the AAA
  server, and not anything else
• Is this an actual problem? What does knowing all
  these identities buy us?

6
Fix the problem?

• Solution 1 3-party key agreement protocols
• Involve all parties in a cross-protocol key
  agreement
• In CAPWAP, would need 4-party protocol
• Infeasible, as CAPWAP cant change 11i or AAA
• Solution 2 Channel Bindings
• After keys are all generated, AAA server encrypts
  everyones identities and sends it to the STA
• Could be implemented by CAPWAP-specific
  extensions to an EAP method, need AAA messages to
  carry CAPWAP WTP/AC info

7
Ideally, how would this work?
AAA
WTP
STA
AC
AAA authentication
CAPWAP authentication
802.11 beacons ID(WTP), ID(AC), ID(AAA)
AAA(CAPWAP config, ID(WTP), ID(AC))
802.1X / EAP authentication Channel binding phase
MIC(ID(WP), ID(AC), ID(AAA)
STA verifies chbind info
802.11i 4-way handshake
CAPWAP Add-Mobile
8
Implementation?

• Implementing channel bindings would require an
  additional RFC describing
• Universal WTP / AC identities
• RADIUS and Diameter transport for identities
• CAPWAP-specific CHBIND blobs for EAP methods to
  securely transport
• Threat Analysis draft simply documents the
  problem
• Not a problem if you deployment believes in the
  transitivity of trust

9
Conclusion

• New WG document
• Some changes since last version, including chbind
  discussion
• Would like WG input!
• Another revision, and then perhaps WGLC