802.11i Wireless Networking Authentication Protocol

1
802.11i Wireless Networking Authentication
Protocol
CS 259

• J. Mitchell

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

3
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 years projects

4
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

5
802.11i Wireless Authentication
6
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

7
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

8
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 small24 bit
• Integrity Check Value based on CRC-32
• Authentication messages can be forged

9
802.11i Protocol
10
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

11
Security Level Rollback Attack
Authenticator RSNA enabled Pre-RSNA enabled
Supplicant RSNA enabled Pre-RSNA enabled
Bogus Beacon (Pre-RSNA only)
Beacon AA RSN IE
Probe Request
Bogus Probe Response (Pre-RSNA only)
Probe Response AA RSN IE
802.11 Authentication Request
802.11 Authentication Response
Bogus Association Request (Pre-RSNA only)
Association Request SPA RSN IE
802.11 Association Response
Pre-RSNA Connections
12
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

13
Reflection Attack
Adversary Impersonates Communicating Peers
Legitimate Devices Authenticator and Supplicant
A1, Nonce1, sn, msg1
A2, Nonce1, sn, msg1
A1, Nonce2, RSN IE, sn, msg2, MIC
A2, Nonce2, RSN IE, sn, msg2, MIC
A1, Nonce1, RSN IE, GTK, sn1, msg3, MIC
A2, Nonce1, RSN IE, GTK, sn1, msg3, MIC
A1, sn1, msg4, MIC
SPA, sn1, msg4, MIC
Bogus Authentication
Peers Authenticated
14
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)

15
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 reqd
• 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

16
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

17
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 lt ICV lt TSC lt MIC
• Update TSC unless MIC is validated

18
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

19
RSN IE Poisoning
Supplicant Unauthenticated Unassociated 802.1X
Blocked
Authenticator Unauthenticated Unassociated 802.1X
Blocked
(1) Beacon AA RSN IE
(2) Probe Request
(3) Probe Response AA RSN IE
Legitimate Message Exchanges
(18) AA, ANonce, AA RSN IE, GTK, sn1, msg3, MIC
20
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

21
The 4-Way Handshake
MSK
22
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
• PTKPRFPMK, AASPAANonceSNonce
• Analysis
• Based on the existing specifications of the 4-way
  handshake
• Murj verification using rationale reconstruction

23
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

24
Simplified 4-Way Handshake
Supplicant Auth/Assoc 802.1X Blocked PMK
Authenticator Auth/Assoc 802.1X Blocked PMK
PTK Derived
PTK Derived Random GTK
AA, ANonce, AA RSN IE, GTK, sn1,
msg3, MIC
SPA, sn1, msg4, MIC
PTK and GTK 802.1X Unblocked
PTK and GTK 802.1X Unblocked
25
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

26
Forged Message 1 Attack
Supplicant Auth/Assoc 802.1X Blocked PMK
Authenticator Auth/Assoc 802.1X Blocked PMK
PTK Derived
PTK Derived Random GTK
AA, ANonce, AA RSN IE, GTK, sn1,
msg3, MIC
SPA, sn1, msg4, MIC
PTK and GTK 802.1X Unblocked
PTK and GTK 802.1X Unblocked
27
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

28
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
29
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
30
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
• PTKPRFPMK, AASPAANonceSNonce
• More computations in the supplicant

Performance Degradation
31
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

32
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 adversarys 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 gtgt protocol execution time

33
Complex Control Flows
Simple Flow
Complex Flow
34
Improved 802.11i Architecture
35
Vulnerability Summary
ATTACKS SOLUTIONS
security 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.
36
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