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

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

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

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

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?

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

Ideally, how would this work? STA WTP AC AAA 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

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

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