CAPWAP Threat Analysis Clancy Kelly CAPWAP Threat

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

CAPWAP Threat Analysis Clancy & Kelly Document Status • Adopted as a working group document • Published as -00 • Changes – Filled in AAA security section – Added discussion of channel binding IETF 68 CAPWAP Working Group

CAPWAP Threat Analysis Clancy & Kelly 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 11 i/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 IETF 68 CAPWAP Working Group

CAPWAP Threat Analysis Clancy & Kelly Recent Changes • New discussion on channel bindings STA bootstrapped trust relationship WTP long-term trust relationship AC long-term trust relationship AAA long-term trust relationship • Just because STA trust AAA who trusts AC who trusts WTP, why should STA trust WTP? • Is trust transitive? • Nature of identity IETF 68 CAPWAP Working Group

CAPWAP Threat Analysis Clancy & Kelly 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? IETF 68 CAPWAP Working Group

CAPWAP Threat Analysis Clancy & Kelly 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 11 i 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 IETF 68 CAPWAP Working Group

CAPWAP Threat Analysis Clancy & Kelly 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. 1 X / EAP authentication Channel binding phase — MIC(ID(WP), ID(AC), ID(AAA) ** STA verifies chbind info ** 802. 11 i 4 -way handshake CAPWAP Add-Mobile IETF 68 CAPWAP Working Group

CAPWAP Threat Analysis Clancy & Kelly 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 IETF 68 CAPWAP Working Group

CAPWAP Threat Analysis Clancy & Kelly Conclusion • New WG document • Some changes since last version, including chbind discussion • Would like WG input! • Another revision, and then perhaps WGLC IETF 68 CAPWAP Working Group