1 / 20

Suggested 802.11 Keying Requirements

Suggested 802.11 Keying Requirements. Jesse Walker Intel Corporation jesse.walker@intel.com. Goal and agenda. Goal: Help establish requirements for future development Agenda Review of 802.11 Authentication and Keying today Analysis Requirements. 802.11i Review.

calabrese
Download Presentation

Suggested 802.11 Keying Requirements

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. Suggested 802.11 Keying Requirements Jesse Walker Intel Corporation jesse.walker@intel.com Jesse Walker, 802.11 keying requirements

  2. Goal and agenda • Goal: • Help establish requirements for future development • Agenda • Review of 802.11 Authentication and Keying today • Analysis • Requirements Jesse Walker, 802.11 keying requirements

  3. 802.11i Review Authentication and Keying Today Authentication Server Station Access Point 802.1X authentication Security capabilities discovery RADIUS-based key distribution 802.1X key management Data protection 802.11i review Jesse Walker, 802.11 keying requirements

  4. 802.11i Review Authentication and Keying Today Authentication Server Wireless Station Access Point EAP Method (e.g., EAP-TLS) EAP EAP Transport (e.g. RADIUS) TCP/UDP/IP 802.11i review: 802.1X authentication 802.1X (EAPOL) 802.11 Jesse Walker, 802.11 keying requirements

  5. 802.11i Review Authentication and Keying Today AS 802.1X (EAP-Request Identity) 802.1X (EAP-Response Identity) EAP Transport (EAP-Response Identity) EAP type specific mutual authentication Derive Pairwise Master Key (PMK) Derive Pairwise Master Key (PMK) EAP Transport (EAP-Success, PMK) 802.1X (EAP-Success) 802.11i review: EAP authentication STA AP 802.1X RADIUS Jesse Walker, 802.11 keying requirements

  6. Problem Statement Analysis Problem 1: Who is the other guy? • STA never learns it is communicating with the AP the AS is communicating with under EAP • AP never advertises its authenticated identity to STA • BSSID is the only identifier the AP exposes to the STA • AP never learns it is communicating with the STA the AS is communicating in under EAP • STA never advertises its authenticated identity to AP • STA MAC address is the only identifier the STA exposes to the STA • Although AP can peak inside the EAP-Response/Identity • And the STA could use its MAC address to identify itself • The gap is closed by faith Jesse Walker, 802.11 keying requirements

  7. Problem Statement Analysis Problem 2: Inconsistent contract • 802.11i goes to great trouble to prevent PMK reuse across different APs • Compromise of one AP must not compromise STA’s traffic at another AP • Only mechanism STA has to detect conformance is the AP’s BSSID • Modern switched APs present a dilemma • PMK is kept at switch, so does not cross crypto boundaries if reused at different APs belonging to same switch • But the STA has no way to distinguish this (correct) usage from abuse at classical APs • The PMK is not used consistently by infrastructure and this is visible to the STA Jesse Walker, 802.11 keying requirements

  8. Problem Statement Analysis Problem 3: Expiry time • AAA protocols deliver the PMK expiry time to the AP, but not the STA • EAP doesn’t deliver PMK expiry time to the AP, either • PMK expiry a surprise to the STA, or else • STAs need more predictable PMK usage to make caching work Jesse Walker, 802.11 keying requirements

  9. Problem Statement Analysis Problem 4: Performance v. security • Only mechanisms 802.11i defines to populate PMK at AP are authentication after association and pre-authentication • Authentication after association too slow for real-time applications • Pre-authentication enables new DoS attack • A single STA can flood pre-authentication requests to every AP • In a sufficiently large network, a small number of STAs can allocate all PMK caches at all APs Jesse Walker, 802.11 keying requirements

  10. 802.11i Deployment Requirements Analysis EAP Authentication + Session Key PMK derivation A,{PMK}KB1, MICKB2 802.11i Keying abstractly • Goal: Establish session key K between STA and AP • Technique: Use on-line trusted 3rd party AS as an intermediary • Explicit Assumptions: • STA and AS can mutually authenticate and derive a session key PMK • AP and AS share a key encryption key KB1 and a data authentication key KB2 • AS delivers a fresh PMK to the AP AP STA AS Jesse Walker, 802.11 keying requirements

  11. 802.11i Deployment Requirements Analysis STA,{PMK}KB1, MICKB2 EAP Authentication + Session Key PMK derivation STA,{PMK}KB1, MICKB2 What can we do without? • No mutual authentication enables MITM attack between STA, AS • No end-to-end data authentication key enables MITM attack between AP, AS • No end-to-end key encryption key enables PMK theft • PMK freshness still a matter of faith to the AP AP STA AP/AS/STA AS Jesse Walker, 802.11 keying requirements

  12. 802.11i Deployment Requirements Analysis EAP Authentication + Session Key PMK derivation STA,{PMK}KB1, MICKB2 802.11i Authentication concretely • Goal: Establish a session key PMK between STA and AP • Technique: Use an on-line trusted third party AS as an intermediary • Explicit Assumptions: • STA and AS can mutually authenticate and derive a session key PMK • AP and AS share a key encryption key KB1 and a data authentication key KB2 • Note path via AP allows replay attacks against AP AP STA AS Jesse Walker, 802.11 keying requirements

  13. 802.11i Authentication Requirements Requirements Design Hueristics • Some prudent engineering practices for cryptographic protocols (Abadi and Needham, 1995) • Use explicit communication: Every message should say what it means • Specify the semantics: The conditions for a message to be acted upon should be spelled out • Name entities: If the identity of a principal is essential to the meaning of the message, include the name explicitly • Make trust assumptions explicit: The protocol designer should know which trust assumptions and dependencies are necessary Jesse Walker, 802.11 keying requirements

  14. 802.11i Authentication Requirements Requirements 802.11 keying requirements • New Peer-NAS-Server key binding protocol • Make keying explicit by client request instead of implicit • Complement EAP but independent of EAP • Allow the STA to request AAA-Key by name • Piggyback keying messages with EAP messages • Allow client to rekey the AP PMK cache without reauthentication • Use the existing AAA-Key • Bind authenticated identities of STA and AP to the AAA-Key • Binding must provide freshness guarantee • Allow the AP to determine response freshness • Allow specification or negotiation of PMK expiry time Jesse Walker, 802.11 keying requirements

  15. 802.11i Authentication Requirements Requirements Rationale • Explicit Peer-NAS-Server key binding protocol • Address open problems before they are exploited • Complement EAP but independent of EAP • Key binding is a 3-party problem, while EAP is a 2-party problem • Piggy-backing messages with EAP allows client to request key during EAP authentication • Protocol independent of EAP allows client to rekey AP PMK cache without reauthenticating • Use the existing AAA-Key • Keying draft consensus has been hard enough • Bind authenticated identities of STA and AP to the AAA-Key • This is all the AS knows • The AS is the only party that both the STA and AP trust, so it must do the binding • Binding must provide freshness guarantee • AP needs to know message delivering PMK is fresh • Allow specification or negotiation of PMK expiry time • Make PMK cache usage consistent to the STA Jesse Walker, 802.11 keying requirements

  16. Requirements RP || AAA-Key-ID RP || AAA-Key-ID || RN  ||   Example protocol Peer NAS Server Peer generates random number RP NAS generates random number RN Server computes  = AAA-Key-ID || IdP || IdNAS || T || MAC(TEKP, RP || AAA-Key-ID || IdP || IdNAS || T) Server encrypts W = E(KEK, AAA-Key) Server computes  =  || W || AAA-Key-ID || IdP || IdNAS || T || MAC(KAK, RN ||  || W || AAA-Key-ID || IdP || IdNAS || T) Jesse Walker, 802.11 keying requirements

  17. 802.11i Authentication Requirements Requirements How would 802.11 use this? • 802.11 must advertise the AP’s identity to the STA • Or the binding is not meaningful to the STA • e.g., insert hash of AP’s authenticated identity into Beacons, Probe Responses, and/or Reassociation Response msgs • Must advertise STA’s identity to the AP • Or the binding is not meaningful to the AP • e.g., insert hash of STA’s identity into Reassociation Requests • AP, STA both verify bound identity matches advertised identity • 802.11i key derivation modified to include bound identities in the PTK derivation • AP cache timeout rules somehow conveyed to the STA Jesse Walker, 802.11 keying requirements

  18. 802.11i Authentication Requirements Requirements Does this solve anything? • These changes identify AP to STA and vice versa • Both parties trust AS to attest to the identity of the other • Both parties advertise their authenticated identities • Problem 1 solved • Key usage identified by device’s crypto boundary, not by MAC addresses • Changes impose a consistent “contract” between AP and STA • Problem 2 solved • Both STA and AP learn the PMK expiry time • Enables 802.11 to solve Problem 3 • STA can efficiently fill the AP’s PMK cache without reauthentication and before AP-to-AP transition • Problem 4 solved Jesse Walker, 802.11 keying requirements

  19. Call to Action • Key distribution enjoys a “troubled history” • Bellare and Rogaway, “Provably secure session key distribution: the three party case,” Proc 27th Symp on Theory of Computing, 1995 • Existing design has vulnerabilities that can be exploited • There is no reason to believe we can avoid consequences of these vulnerabilities any better than prior protocols solving the 3-party problems • Wide-Mouth Frog, Denning-Sacco, Woo-Lam, Lu-Sundareshan, etc. • Work to solve the problem Jesse Walker, 802.11 keying requirements

  20. Feedback? Jesse Walker, 802.11 keying requirements

More Related