1 / 17

IEEE 802.11i: A Retrospective

IEEE 802.11i: A Retrospective. Bernard Aboba bernarda@microsoft.com Microsoft March 2004. Outline. What was/was not accomplished Threat Model Performance Model Discovery EAP methods State Machine Authenticated Key Management. What Was Accomplished….

ajaxe
Download Presentation

IEEE 802.11i: A Retrospective

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

More Related