Bernard Aboba bernarda@microsoft.com
Microsoft
March 2004

• 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

• 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

• 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)

STA
Beacon
Probe Requests
Probe Responses
Beacon
Pre-authentication Exchange
Re-association Request
Re-association Response
4-way handshake
APs
IAPP
New AP
• 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 preauthenticate to one or more
APs
• Reassociation Phase
– STA attempts to associate/reassociate to preferred AP ]
IEEE 802.11i security only

• 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

• 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

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

• 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

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

• 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!

State 1
Unauthenticated,
Unassociated
Class 1
Frames
PMK Delete
PTK/PMK Delete PMK Install
PTK Install
State 2
Authenticated,
Unassociated
Class 1 & 2
Frames
PTK Delete
State 3
Authenticated, and
Associated
Class 1, 2 & 3
Frames

Supplicant
Authenticator
Key (PMK) is Known
Generate SNonce
Derive PTK
Message 1: EAPOL-Key(ANonce, Unicast)
Message 2: EAPOL-Key(SNonce, Unicast, MIC)
Key (PMK) is Known
Generate ANonce
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

• 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

Supplicant
Authenticator
Key (PMK) is Known
Generate SNonce
Message 1: EAPOL-Key(SNonce, Unicast)
Message 2: EAPOL-Key(ANonce, Unicast, MIC, GTK)
Key (PMK) is Known
Generate ANonce
Derive PTK,
Generate 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