IEEE 802.11i: A Retrospective

1. IEEE 802.11i: A Retrospective Bernard Aboba bernarda@microsoft.com Microsoft March 2004

2. Outline • What was/was not accomplished • Threat Model • Performance Model • Discovery • EAP methods • State Machine • Authenticated Key Management

3. What Was Accomplished… • Cooperation by multiple standards bodies: IEEE 802, IETF, 3GPP, 3GPP2, GSMA, etc. • New ciphersuites defined: TKIP, AES CCMP • Flexible key management scheme adopted (based on EAP) • Integration with existing network access authentication, authorization and accounting mechanisms (RADIUS & Diameter) • Widespread vendor support

4. What Is Missing… • Denial of service vulnerabilities partially addressed • No mandatory-to-implement authentication or key management scheme • Vulnerabilities found in proposed authentication and key management schemes • Widespread interoperability, deployment problems reported • Improvements in roaming latency needed • Proprietary enhancements often needed to fill in the holes

5. Threat Model • IEEE 802.11i does not include an explicit threat model • Result: endless discussions of which threats were worth addressing, no way to know when the specification was done. • TKIP rejected in many mission critical applications due to DoS vulnerabilities • How to do better • Discuss the threat model early on • Identify the usage scenarios, draw simple pictures • Distinguish between DoS attacks • Attacks from afar worse than attacks requiring proximity • Leveraged attacks more serious than unleveraged ones • References • RFC 3748 (EAP) threat model • EAP Key Management Framework (work in progress)

6. Beacon Beacon Pre-authentication Exchange 802.11 Phases - ESS • Discovery Phase • STA scans for APs • Passive (Beacon) • Active (Probe Request/Response) • 80-90% of roaming time spent in discovery • Reauthentication phase • Authentication occurs prior to association • If already associated to another AP, STA can pre-authenticate to one or more APs • Reassociation Phase • STA attempts to associate/reassociate to preferred AP APs STA Probe Requests … IAPP Probe Responses Discovery New AP Re-association Request Reauthentication/Reassociatation Re-association Response ] IEEE 802.11i security only 4-way handshake

7. Performance Model • IEEE 802.11i decided that a backward compatible cipher (TKIP) was needed, but: • Performance criteria not thought through • Lead to adoption of low quality MIC (MICHAEL), adoption of countermeasures • All the transition issues not considered • “Virtual AP” support typically required in some form to allow co-existence • Result: • Countermeasures unacceptable in many mission critical applications • Reasonable performance, higher quality (proprietary) MIC widely adopted instead • Alternative shipped even by the MICHAEL proponents! • Many deployments blocked pending release of transition functionality • How to do better • Think through the required performance and hardware implications explicitly • Think through the transition/deployment model • Remember that hardware price/performance continually improves, standards take longer than expected • Remember that while retrofits are technically possible, vendors may implement only on new equipment

8. Discovery • IEEE 802.11i does not secure management or control frames: • Beacon/Probe Request/Response frames • Association/Reassociation/Disassociation/Deauthentication • Control frames face severe time constraints (ACK) • Result: DoS vulnerabilities • Power mgmt. attacks on the TIM, Rate attacks, attacks on measurement frames, vendor specific attributes, etc. • Result: Fixes required after the fact • Beacon IEs can now (optionally) be included in 4-way handshake • IEEE 802.11k now looking to secure measurement frames • How to do better • Think through the discovery threats beforehand • Think through the performance model • Some frame types may not be protectable, depending on the required performance

9. Discovery Questions • What does the discovery exchange look like? • Which frames are unicast, which are multicast? • When can discovery frames be sent? • Before authentication? After authentication? • Is the information in discovery frames integrity protected? If yes, then: • Is the whole frame protected? Or just individual Information Elements? • Is information protected when sent? • With group or unicast keys? • Or is the information protected after the fact? • With group/unicast keys? • How big can discovery frames get? • Who will use them, and for what? • Is fragmentation possible?

10. EAP Methods • Flaws • No mandatory to implement EAP method in IEEE 802.11i • Authentication server needed in simplest deployments • “Fix”: PSK mode • Inability to use standard EAP key naming schemes • Vulnerability to dictionary attack • EAP method requirements defined late in the process • Results • Explosion in proprietary EAP methods lacking adequate review • Flaws found in many proposals • Interoperability problems widespread • PSK mode implementations often crackable • Method rewrites required to meet the method requirements • Deployments using unacceptable methods less secure than WEP! • How to do better • Define a mandatory to implement method • Define EAP method requirements early on • Leverage IETF standardization process • References • Draft-walker-ieee802-req-00.txt

11. 802.11-1999 State Machine State 1Unauthenticated, Unassociated Class 1 Frames DeAuthentication Notification Deauthentication notification Successful Authentication State 2Authenticated, Unassociated Class 1 & 2 Frames Successful Association or Reassociation Disassociation Notification State 3Authenticated, and Associated Class 1, 2 & 3 Frames

12. State Machine Issues • Flaws • Association/Reassociation/Disassociation/ Deauthenticate messages not protected. • Can’t base a security protocol on a state machine governed by insecure frames, so… • Functionality duplicated in the IEEE 802.11i authenticated key management (AKM) protocol • Results • Denial of service attacks at a distance • Confusion between standards (IEEE 802.11F vs. 802.11i) • Excessive complexity • How to do better • Think through the basic state machine early on • Keep it simple!

13. How This Probably Should Have Worked State 1Unauthenticated, Unassociated Class 1 Frames PMK Delete PTK/PMK Delete PMK Install State 2Authenticated, Unassociated Class 1 & 2 Frames PTK Install PTK Delete State 3Authenticated, and Associated Class 1, 2 & 3 Frames

14. IEEE 802.11i Authenticated Key Mgmt Supplicant Authenticator Key (PMK) is Known Generate SNonce Key (PMK) is Known Generate ANonce Message 1: EAPOL-Key(ANonce, Unicast) Derive PTK Message 2: EAPOL-Key(SNonce, Unicast, MIC) Derive PTK If needed, generate GTK Message 3: EAPOL-Key(Install PTK, Unicast, MIC, GTK) Message 4: EAPOL-Key(Unicast, MIC) Install PTK and GTK Install PTK

15. AKM Issues • Flaws • Too many exchanges • Handshake is 6-way when Association/Reassociation exchange included (for PMK negotiation) • 4-way handshake initiated by authenticator, not supplicant • GTK transport is uni-directional • How to do better • Remember that keys needed to be deleted as well as installed • Remember that state needs to be synchronized on both sides • Draw simple box and arrow diagrams before diving into details • References • EAP Key Management Framework

16. How STA-Initiated AKM Might Work Supplicant Authenticator Key (PMK) is Known Generate SNonce Key (PMK) is Known Generate ANonce Message 1: EAPOL-Key(SNonce, Unicast) Derive PTK, Generate GTK Message 2: EAPOL-Key(ANonce, Unicast, MIC, GTK) Derive PTK, Generate GTK Message 3: EAPOL-Key(Install PTK & GTK, Unicast, MIC, GTK) Message 4: EAPOL-Key(Unicast, MIC) Install PTK and GTK Install PTK and GTK

17. Feedback?