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
STA
bootstrapped
trust relationship
WTP
long-term
trust relationship AC
long-term
trust relationship
AAA
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 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 can’t change 11i or AAA
Solution 2: Channel Bindings
After keys are all generated, AAA server encrypts everyone’s 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?
STA
WTP AC
AAA
AAA authentication
CAPWAP
authentication
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