Transcript 802.1X Authentication

Analysis of the 802.11i
4-Way Handshake
Changhua He, John C Mitchell
Stanford University
WiSE, Oct. 1, 2004
Outline

IEEE 802.11i



Murφ Verification




Murφ Modeling
Clarifications of the protocol
Forged Message 1 attack
DoS attack & countermeasures



RSNA (Robust Security Network Association)
4-Way Handshake (our focus !)
DoS attack in practical implementation
3 possible countermeasures
Conclusion & Future work
IEEE 802.11i Standard
Ratified on June 24, 2004
 Components





RSNA and Pre-RSNA algorithms
WEP, TKIP included for backward compatibility
CCMP as a long-term solution with hardware upgrade
RSNA Establishment Procedures






Network and Security Capability Discovery
802.11 Open System Authentication and Association
EAP/802.1X/RADIUS Authentication
4-Way Handshake
Group Key Handshake
Secure Data Communications
RSNA Conversations
Supplicant
UnAuth/UnAssoc
Auth/Assoc
802.1X UnBlocked
Blocked
No Key
MSK
PMK
New
PTK/GTK
GTK
Authenticator
UnAuth/UnAssoc
Auth/Assoc
802.1X UnBlocked
Blocked
No Key
PMK
New
PTK/GTK
GTK
Authentication Server
(RADIUS)
MSK
No
Key
802.11 Association
EAP/802.1X/RADIUS Authentication
MSK
4-Way Handshake
Group Key Handshake
Data Communication
The 4-Way Handshake
Supplicant
Auth/Assoc
802.1X UnBlocked
Blocked
PMK
PTK/GTK
Authenticator
Auth/Assoc
802.1X UnBlocked
Blocked
PMK
PTK/GTK
Authentication Server
(RADIUS)
No Key
802.11 Association
EAP/802.1X/RADIUS Authentication
{AA, ANonce, sn, msg1, PMKID}
{SPA, SNonce, SPA RSN IE, sn, msg2, MIC}
{AA, ANonce, AA RSN IE, GTK, sn+1, msg3, MIC}
{SPA, sn+1, msg4, MIC}
Group Key Handshake
Data Communication
MSK
Problem Statement

Assumption



Handshake Goals



PMK is shared between the Supplicant and the Authenticator
The AS “move” the key materials to the Authenticator
Confirm the possession of PMK
Derive a fresh session key for data transmission
PTK=PRF{PMK, AA||SPA||ANonce||SNonce}
Analysis


Based on the existing specifications of the 4-way handshake
Murj verification using “rationale reconstruction”
Finite-State Verification

...

...

Correctness
condition violated

Murφ rules for protocol
participants and the intruder
define a nondeterministic state
transition graph
Murφ will exhaustively
enumerate all graph nodes
Murφ will verify whether
specified security conditions
hold in every reachable node
If not, the path to the violating
node will describe the attack
Running Murφ
Informal
Protocol
Description
Formal
Protocol
Intruder
Model
Murj code
Murj code,
similar for
all protocols
RFC, IEEE Std.
Find error
Specify security
conditions and run Murj
Analysis
Tool
Modeling the 4-Way Handshake

Authenticators/Supplicants:




Intruder






Each authenticator maintain one association with each
supplicant, and vice versa
Each association has a uniquely shared PMK
Multiple sequential legitimate handshakes in one association
Impersonate both supplicant and authenticator
Eavesdrop, intercept and replay messages
Compose messages with known nonce and MIC
Forge fresh Message 1
Predict and replay nonces for pre-computation of MIC
Rationale reconstruction

Turn on/off fields: nonce, sequence, msg, address
Simplified 4-Way Handshake
Supplicant
Auth/Assoc
802.1X Blocked
PMK
Authenticator
Auth/Assoc
802.1X Blocked
PMK
AA, ANonce, sn, msg1
PTK Derived
SPA, SNonce, SPA RSN IE, sn, msg2, MIC
PTK Derived
Random GTK
AA, ANonce, AA RSN IE, GTK, sn+1, msg3, MIC
SPA, sn+1, msg4, MIC
PTK and GTK
802.1X Unblocked
PTK and GTK
802.1X Unblocked
Protocol Clarifications

Sequence number, AA, SPA


Message flag



Nessary to be included and protected
otherwise could ambiguously use Msg 2 as 3, or vice versa
Exclusive supplicant and authenticator


Essentially redundant
Otherwise reflection attacks
Fresh nonces


globally unique and unpredictable
Otherwise pre-computation attacks and replay attacks
Forged Message 1 Attack
Supplicant
Auth/Assoc
802.1X Blocked
PMK
Authenticator
Auth/Assoc
802.1X Blocked
PMK
AA, ANonce, sn, msg1
PTK Derived
SPA, SNonce, SPA RSN IE, sn, msg2, MIC
AA, ANonce, sn, msg1
PTK Derived
Random GTK
AA, ANonce, AA RSN IE, GTK, sn+1, msg3, MIC
SPA, sn+1, msg4, MIC
AA, ANonce, sn, msg1
PTK and GTK
802.1X Unblocked
PTK and GTK
802.1X Unblocked
DoS attack

TPTK/PTK solution



Keep states for every incoming Message 1



Proposed in the documentation
not work for all cases
DoS attack: Memory/CPU exhaustion
Like a TCP SYN flooding attack
Interleaving handshakes



Authenticator could only accept expected messages
Supplicant could not do so, must accept Msg 1 in all stages
Parallel handshake instances exist
Countermeasures (1)
Random-Drop
Queue:
Randomly drop a
stored entry to
adopt the state
for the incoming
Message 1 if the
queue is filled.
Not so effective
Countermeasures (2)

Authenticate Message 1




To reuse the algorithms/hardware, set nonces to special
values, e.g., 0, and derive PTK.
Calculate MIC for Msg 1 using the derived PTK
Good solution if PMK is fresh
If PSK and cached PMK, replay attacks !




Add a monotonically increasing global sequence counter
Use local time in authenticator side
Sufficient space in Message 1 ( 8-octet sequence field )
No worry about time synchronization
Modifications on packet format
Countermeasures (3)

Re-Use Nonce




Supplicant re-use SNonce until one 4-way handshake
completes successfully
Derive correct PTK from Message 3
Authenticator may (or may not) re-use ANonce
Solve the problem, but


Attacker might gather more infomation about PMK by
playing with Message 1, recall
PTK=PRF{PMK, AA||SPA||ANonce||SNonce}
More computations in the supplicant
Performance Degradation
Our Proposal

Combined solution




Supplicant re-use SNonce
Store one entry of ANonce and PTK for the first Message 1
If nonce in Message 3 matches the entry, use PTK directly;
otherwise derive PTK again and use it.
Advantages



Eliminate the memory DoS attack
Ensure performance in “friendly” scenarios
Only minor modifications on the algorithm in the Supplicant
• No modifications on the packet format

Adopted by TGi

Documentation will be updated once a chance
Conclusion & Future Work

Conclusions





Simplified protocol and several clarifications
Parallel instances exist => Forged Message 1 attack
Keep all states => Denial-of-Service attack
3 countermeasures and the effectiveness
Proposed solution
• Supplicant re-use SNonce to eliminate the vulnerability
• Supplicant may store one entry of PTK for performance
• no modifications on the packet format, adopted by TGi

Future Work

A full study of the 802.11i correctness