1 / 9

CAPWAP Threat Analysis

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.

zita
Download Presentation

CAPWAP Threat Analysis

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 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 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 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

  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

More Related