802.11i Wireless Networking Authentication Protocol

802.11i Wireless Networking Authentication Protocol

J. Mitchell

CS 259

Next few lectures

Tuesday 1/17 Brief cryptography background Key exchange protocols and properties

Today 1/19 Some project ideas Wireless security: 802.11i Choose your project partner

Next Tues 1/24 Password authentication protocols

Next Thurs 1/26 Contract-signing protocols

Thursday after that 2/2 Project presentation #1 What system? What does it do? How does it work? In 5 minutes.

Some Project Ideas VoIP

Privacy, authentication, DoS issues, Billing fraud Traffic shaping? SIP, H.323, Skype etc.

Password based authentication protocols Vulnerability to dictionary attacks?

Fair exchange protocols Voting protocols, anonymity

Digital cash Anonymous electronic voting (Bart Jacobs’ water election protocol?)

Internet infrastructure protocols SPF, other SMTP authentication mechanisms S-BGP, BGP-S Secure DNS, other DNS enhancements NTP protocol?

Access policies? HIPAA compliance? Look at last year’s projects

Changhua He

CS259 Project in 2004 Mur analysis of 802.11i 4-way handshake protocol PhD completed 2006

Publications Three papers on 802.11i (one with Mukund as

coauthor) http://theory.stanford.edu/~changhua/pubs.html

802.11i Wireless Authentication

Wireless Threats Passive Eavesdropping/Traffic Analysis

Easy, most wireless NICs have promiscuous mode

Message Injection/Active Eavesdropping Easy, some techniques to gen. any packet with common NIC

Message Deletion and Interception Possible, interfere packet reception with directional antennas

Masquerading and Malicious AP Easy, MAC address forgeable and s/w available (HostAP)

Session Hijacking Man-in-the-Middle Denial-of-Service: cost-related evaluation

Wireless Security Evolution 802.11 (Wired Equivalent Protocol)

Authentication: Open system (SSID) and Shared Key Authorization: some vendor use MAC address filtering Confidentiality/Integrity: RC4 + CRC Completely insecure

WPA: Wi-Fi Protected Access Authentication: 802.1X Confidentiality/Integrity: TKIP Reuse legacy hardware, still problematic

IEEE 802.11i (Ratified on June 24, 2004 ) Mutual authentication Data confidentiality and integrity: CCMP Key management Availability

What Went Wrong With WEP

No Key Management Long Lived keys Fix: Use 802.1X ( Standard for user, device authentication )

Crypto Issues RC4 cipher stream Key size: 40 bit keys Initialization Vector too small:24 bit Integrity Check Value based on CRC-32 Authentication messages can be forged

Authentica-tion Server (RADIUS)No Key

Authenticator UnAuth/UnAssoc802.1X BlockedNo Key

SupplicantUnAuth/UnAssoc802.1X BlockedNo Key

SupplicantAuth/Assoc802.1X BlockedNo Key

Authenticator Auth/Assoc802.1X BlockedNo Key


802.11 Association

EAP/802.1X/RADIUS Authentication

SupplicantAuth/Assoc802.1X BlockedMSK

Authenticator Auth/Assoc802.1X BlockedNo Key

Authentica-tion Server (RADIUS)MSK

MSK

SupplicantAuth/Assoc802.1X BlockedPMK

Authenticator Auth/Assoc802.1X BlockedPMK


4-Way Handshake

SupplicantAuth/Assoc802.1X UnBlockedPTK/GTK

Authenticator Auth/Assoc802.1X UnBlockedPTK/GTK


Group Key Handshake

SupplicantAuth/Assoc802.1X UnBlockedNew GTK

Authenticator Auth/Assoc802.1X UnBlockedNew GTK


802.11i Protocol

Data Communication




Outline

Wireless Threat Models IEEE 802.11i Attacks and Solutions

Attacks on Authentication: • 1. Security level rollback • 2. reflection attack

Attacks on Availability: • 3. Michael countermeasure attack• 4. RSN IE poisoning • 5. 4-Way Handshake blocking

Failure Recovery and improved 802.11i Conclusions

Security Level Rollback Attack

Probe Request

SupplicantRSNA enabledPre-RSNA enabled

AuthenticatorRSNA enabledPre-RSNA enabled

Bogus Beacon (Pre-RSNA only)

Bogus Probe Response (Pre-RSNA only)

802.11 Authentication Request802.11 Authentication Response

Bogus Association Request (Pre-RSNA only)

802.11 Association ResponsePre-RSNA Connections

Beacon + AA RSN IE

Probe Response + AA RSN IE

Association Request + SPA RSN IE

Solutions Security Level Rollback Attack

Similar to general version rollback attack Destroy security since WEP is insecure Not vulnerability of 802.11i standard, but an

implementation problem

Solutions Allow only RSNA connections: secure, but too strict for

common networks, where Transient Security Network is more convenient

Deploy both, but• Supplicant manually choose to deny or accept• Authenticator limit pre-RSNA connections to only insensitive

data

Reflection AttackAdversaryImpersonatesCommunicatingPeers

{A2, Nonce2, RSN IE, sn, msg2, MIC}{A1, Nonce1, RSN IE, GTK, sn+1, msg3, MIC}

{A1, sn+1, msg4, MIC}

Legitimate DevicesAuthenticator andSupplicant

Bogus Authentication Peers Authenticated

{A1, Nonce1, sn, msg1}{A2, Nonce1, sn, msg1}

{A1, Nonce2, RSN IE, sn, msg2, MIC}

{A2, Nonce1, RSN IE, GTK, sn+1, msg3, MIC}

{SPA, sn+1, msg4, MIC}

Reflection Solutions

Possible in ad hoc networks Violates mutual authentication Solutions:

Restrict each entity to single role• Access point is not wireless station

Allow one entity to have two roles• But require different pairwise master keys (PMK)

802.11i Availability Not an original design objective Physical Layer DoS attacks

Inevitable but detectable, not our focus

Network and upper Layer DoS attack Depend on protocols, not our focus

Link Layer attack Flooding attack: Lots of traffic and power req’d Some Known DoS attacks in 802.11 networks DoS attack on Michael algorithm in TKIP RSN IE Poisoning/Spoofing 4-Way Handshake Blocking Failure Recovery

Known DoS attacks and Solutions

DoS attacks on plain 802.11 networks Forge unprotected management frames, like

Deauthentication/Disassociation frame Exploit virtual carrier sense mechanism by forging

unprotected control frames, like RTS/CTS etc. 802.11i still has these problems, solutions could be

• Authenticate management frames• Validate virtual carrier sense in control frames

DoS attacks on EAP messages Forge EAPOL-Start, EAPOL-Success, EAPOL-Logoff,

EAPOL-Failure 802.11i can eliminate these by simply ignoring them ! Send more than 255 association request to exhaust the

EAP identifier space (8 bits) Adopt separate EAP identifier counter for each

association

Michael Countermeasure TKIP Michael algorithm and countermeasures

Message Integrity Code (MIC), provide 20-bit security one successful forgery / 2 min., need countermeasures Cease communication for 60 sec. if two Michael MIC failures

detected in one minute, re-key & deauthentication Limit to one successful forgery / 6 month Check order: FCS < ICV < TSC < MIC Update TSC unless MIC is validated

MAC IV/KeyID

TKIP MPDU Format

Ext. IV Data/MSDU MIC ICV FCS

EncryptedContains TSC

Michael DoS and Solutions DoS attack through MIC failures

Intercept a packet with valid TSC (possible) Modify packet and corresponding values of FCS, ICV

(easy) Send modified packet twice in one minute (easy) MIC always invalid, TSC always valid

Solutions When MIC failure, cease communication only, no re-

keying and deauthentication Update TSC before MIC is validated What happens if modify TSC to extremely large number?

• Change TSC also change encryption key, wrong decryption• Some confidence on TKIP key schedule algorithm

Mitigation but not elimination

RSN IE Poisoning

(2) Probe Request(3) Probe Response + AA RSN IE

(18) {AA, ANonce, AA RSN IE, GTK, sn+1, msg3, MIC}

RSN IE confirmation failed, Disassociation

Disassociate the Supplicant

(1) Beacon + AA RSN IEBogus Beacon + Modified RSN IE

Bogus Probe Response + Modified RSN IE

Legitimate Message Exchanges

SupplicantUnauthenticatedUnassociated802.1X Blocked

Authenticator UnauthenticatedUnassociated802.1X Blocked

RSN IE Poisoning: Solutions Easy to launch the attack Legitimate participants unaware of it

Continue message exchanges, waste resources Adversary have more time to repeat the attack

Solutions Authenticate management frames

• Difficult to authenticate Beacon and Probe Response frame

Confirm RSN IE as soon as possible (EAP-TLS)• Necessary modifications on the standard

Relax the condition of RSN IE confirmation• Ignore insignificant bits, only confirm authentication suite• If authentication suite modified, probably error at the

beginning of associations




The 4-Way Handshake

802.11 Association

EAP/802.1X/RADIUS Authentication

Group Key Handshake

Data Communication

MSK {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}




Problem Statement

Assumption PMK is shared between the Supplicant and the

Authenticator

Handshake Goals 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 Mur verification using “rationale reconstruction”

Modeling the 4-Way Handshake

Authenticators/Supplicants: Each authenticator maintains one association with each

supplicant, and vice versa Each association has a uniquely shared PMK Multiple sequential legitimate handshakes in one

association

Intruder 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

AA, ANonce, AA RSN IE, GTK, sn+1, msg3, MIC SPA, sn+1, msg4, MIC

PTK Derived

PTK DerivedRandom GTK

PTK and GTK802.1X Unblocked

PTK and GTK 802.1X Unblocked



AA, ANonce, sn, msg1

SPA, SNonce, SPA RSN IE, sn, msg2, MIC

Protocol Clarifications

Sequence number, AA, SPA Essentially redundant

Message flag Necessary to be included and protected Otherwise could ambiguously use Msg 2 as 3, or vice

versa

Exclusive supplicant and authenticator Otherwise reflection attacks

Fresh nonces Globally unique and unpredictable Otherwise pre-computation attacks and replay attacks

Forged Message 1 Attack

AA, ANonce, AA RSN IE, GTK, sn+1, msg3, MIC SPA, sn+1, msg4, MIC

PTK Derived

PTK DerivedRandom GTK

PTK and GTK802.1X Unblocked

PTK and GTK 802.1X Unblocked




SPA, SNonce, SPA RSN IE, sn, msg2, MIC



Need for “half-open” handshakes

TPTK/PTK solution Proposed in the documentation Does not work for all cases

Keep state for each Message 1 received Memory/CPU exhaustion Similar to TCP SYN flooding attack

Interleaving handshakes may be required Authenticator can reject unexpected messages Supplicant must accept Msg 1 in all stages Parallel incomplete handshakes are required

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, recallPTK=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

Failure Recovery Important for large protocols like 802.11i

Not affect protocol correctness, but efficiency Not eliminate DoS vulnerabilities, but make DoS more

difficult

802.11i adopts a simple scheme Whenever failure, restart from the beginning, inefficient !

Tradeoffs Defensive DoS attack vs Captured DoS attack Assumptions on adversary’s capability and network

scenario

A better failure recovery for 802.11i If failure before 802.1X finishes, restart everything Otherwise restart components from nearest point channel scanning time >> protocol execution time

Complex Control Flows

Simple Flow Complex Flow

Improved 802.11i ArchitectureStage 1: Network and Security Capability Discovery

Stage 2: 802.1X Authentication (mutual authentication, shared secret, cipher suite)

Stage 3: Secure Association (management frames protected)

Stage 4: 4-Way Handshake(PMK confirmation, PTK derivation, and GTK distribution)

Stage 5: Group Key Handshake

Stage 6: Secure Data Communications

Michael MIC Failure or Other Security Failures

Group Key Handshake Timout

4-Way Handshake Timout

Association Failure

802.1X Failure

Vulnerability Summary

ATTACKS SOLUTIONSsecurity rollback supplicant manually choose security;

authenticator restrict pre-RSNA to only insensitive data.

reflection attack each participant plays the role of either authenti-cator or supplicant; if both, use different PMKs.

attack on Michael countermeasures

cease connections for a specific time instead of re-key and deauthentication; update TSC before MIC and after FCS, ICV are validated.

RSN IE poisoning Authenticate Beacon and Probe Response frame; Confirm RSN IE in an earlier stage; Relax the condition of RSN IE confirmation.

4-way handshake blocking

adopt random-drop queue, not so effective; authenticate Message 1, packet format modified; re-use supplicant nonce, eliminate memory DoS.

Conclusions 802.11i provides

Satisfactory data confidentiality & integrity with CCMP Satisfactory mutual authentication & key management

Some implementation mistakes Security Level Rollback Attack in TSN Reflection Attack on the 4-Way Handshake

Availability is a problem Simple policies can make 802.11i robust to some known

DoS Possible attack on Michael Countermeasures in TKIP RSN IE Poisoning/Spoofing 4-Way Handshake Blocking Inefficient failure recovery scheme

Improved 802.11i

Documents

802.11i Wireless Networking Authentication Protocol