IEEE i: A Retrospective Bernard Aboba Microsoft March 2004

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

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

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

Threat Model IEEE i 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)

Phases - ESS STA … Probe Requests Probe Responses Pre-authentication Exchange Re-association Response 4-way handshake IAPP Discovery Reauthentication/ Reassociatation New AP Beacon APs 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 Re-association Request ] IEEE i security only

Performance Model IEEE i 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

Discovery IEEE i 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 k 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

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?

EAP Methods Flaws –No mandatory to implement EAP method in IEEE i –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

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

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

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

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

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

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

Feedback?