90 likes | 236 Views
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.
E N D
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 AAA 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
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