1. Jesse Walker, 802.11 keying requirements1 Suggested 802.11 Keying Requirements Jesse Walker Intel Corporation jesse.walker@intel.com

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

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

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

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

6. Jesse Walker, 802.11 keying requirements6 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 Problem Statement Analysis

7. Jesse Walker, 802.11 keying requirements7 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 Problem Statement Analysis

8. Jesse Walker, 802.11 keying requirements8 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 Problem Statement Analysis

9. Jesse Walker, 802.11 keying requirements9 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 Problem Statement Analysis

10. Jesse Walker, 802.11 keying requirements10 802.11i Keying abstractly STA AP AS 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 EAP Authentication + Session Key PMK derivation A,{PMK} KB1, MIC KB2 802.11i Deployment Requirements Analysis

11. Jesse Walker, 802.11 keying requirements11 EAP Authentication + Session Key PMK derivation What can we do without? STA AP AS 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 STA,{PMK} KB1, MIC KB2 AP/AS/STA STA,{PMK} KB1, MIC KB2 802.11i Deployment Requirements Analysis

12. Jesse Walker, 802.11 keying requirements12 802.11i Authentication concretely STA AP AS 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 STA,{PMK} KB1, MIC KB2 EAP Authentication + Session Key PMK derivation 802.11i Deployment Requirements Analysis

13. Jesse Walker, 802.11 keying requirements13 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 802.11i Authentication Requirements Requirements

14. Jesse Walker, 802.11 keying requirements14 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 802.11i Authentication Requirements Requirements

15. Jesse Walker, 802.11 keying requirements15 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 802.11i Authentication Requirements Requirements

16. Jesse Walker, 802.11 keying requirements16 Example protocol PeerNASServer Requirements Peer generates random number R P R P || AAA-Key-ID NAS generates random number R N R P || AAA-Key-ID || R N Server computes  = AAA-Key-ID || Id P || Id NAS || T || MAC(TEK P, R P || AAA-Key-ID || Id P || Id NAS || T) Server computes  =  || W || AAA-Key-ID || Id P || Id NAS || T || MAC(KAK, R N ||  || W || AAA-Key-ID || Id P || Id NAS || T) Server encrypts W = E(KEK, AAA-Key)  ||  

17. Jesse Walker, 802.11 keying requirements17 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 802.11i Authentication Requirements Requirements

18. Jesse Walker, 802.11 keying requirements18 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 802.11i Authentication Requirements Requirements

19. Jesse Walker, 802.11 keying requirements19 Call to Action Key distribution enjoys a “troubled history” –Bellare and Rogaway, “Provably secure session key distribution: the three party case,” Proc 27 th 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

20. Jesse Walker, 802.11 keying requirements20 Feedback?