July 2008 doc IEEE 802 11 080833 r

  • Slides: 13
Download presentation
July 2008 doc. : IEEE 802. 11 -08/0833 r 3 A Proposed Scaled-down Solution

July 2008 doc. : IEEE 802. 11 -08/0833 r 3 A Proposed Scaled-down Solution to AMPDU Do. S Related Comments in LB 129 Authors: Submission Date: 2008 -07 -13 1 Luke Qian etc, Cisco

July 2008 doc. : IEEE 802. 11 -08/0833 r 3 Overview A number of

July 2008 doc. : IEEE 802. 11 -08/0833 r 3 Overview A number of new types of Deny of Service (Do. S) associated with the 802. 11 n A-MPDU BA operations have been identified, commented and acknowledged since LB 115 for 802. 11 n. Resolutions for the relating comments in the recent LB 124 called for solutions less complicated and lower implementation cost than those in 802. 11 -08/0665 r 0, the jointly developed solutions. Following the thinking outlined in 802. 11 -08/0755 r 1, we present here a scaled-down version of 08/0665 r 0 which focuses on the Do. S types with the most significant damages. Also see LB 129 CID 8075, 8076. Submission 2 Luke Qian etc, Cisco

July 2008 doc. : IEEE 802. 11 -08/0833 r 3 Block Ack Security problems

July 2008 doc. : IEEE 802. 11 -08/0833 r 3 Block Ack Security problems • The following security problems exist: (802. 11 -08/0665 r 0) – – – – Submission The SN values of data packets are not protected – yet, SN values of data packets can be used to adjust the RX Buffer LE value. A single forged SN value can cause the recipient to move the LE value too far forward, thereby causing the recipient to discard frames below the new LE that should not have been discarded. Data is lost at the recipient. A single forged SN value in a data packet can also cause the recipient to place the received frames in an incorrect order, which can cause problems both when the security layer examines the sequence of PN values in the MAC SN-ordered frames and when the frames are passed to the next layer for processing. A single forged SN value in a data packet can cause RX scorecard information to be updated, and a subsequent transmission of a BA frame in response to a legitimate AMPDU can include this bogus scorecard information. A captured and replayed packet cannot be detected except by replay detection in the security layer. If the RX buffer reordering is performed before this check, then the SN in that replayed packet can cause incorrect RX Buffer LE movement. The BAR frame is not protected – yet the BAR frame SSN value is used to adjust the RX Buffer LE value. A single forged SN value can cause the recipient to move the LE value too far forward, thereby causing the recipient to discard frames below the new LE that should not have been discarded. Data is lost at the recipient. The BA frame is not protected – yet the BA frame SSN value is used to adjust the originator’s TX scorecard LE value. Forged BA frames can cause false adjustments to the LE value that result in some data packets not being transmitted to the recipient, since they now have SN values below the new LE value. Data is lost. Forged BA frames can suppress retransmission of frames that were not successfully received (even without moving LE at TX) 3 Luke Qian etc, Cisco

July 2008 doc. : IEEE 802. 11 -08/0833 r 3 Prioritizing the A-MPDU Do.

July 2008 doc. : IEEE 802. 11 -08/0833 r 3 Prioritizing the A-MPDU Do. S Attacks Sort the A-MPDU Do. S Types on their ease of launching: (base prioritization from 802. 11 -08/0755 r 1) 4) False Block ACK Request (BAR) with advanced SN. easy to launch, can be addressed, e. g. , by protecting the BAR by wrapping it in an encrypted management frame, an 11 w mechanism. 1) Forged packets with advanced Sequence Numbers (SN) easy to launch, can be addressed, e. g. , by reversing the order of BA reordering and decryption. 3) Captured and Replayed packets with advanced SN without modification. more difficult, less likely to be successful, can be addressed by, e. g. , a replay check before BA reordering, 5) False BA to prevent retransmission. less likely be successful, not unique since regular ACK can cause similar Do. S. , but can be addressed by replay check before BA reordering 2) Captured and Replayed packets with modified SN. more difficult, can be addressed by encrypting the SN, ( drop this one ? ) The following proposed solution will focus on the most significant and easy-to-launch ones: 4), 1) and 3). Submission 4 Luke Qian etc, Cisco

July 2008 doc. : IEEE 802. 11 -08/0833 r 3 A Scaled-down Solution •

July 2008 doc. : IEEE 802. 11 -08/0833 r 3 A Scaled-down Solution • A scaled-down solution addressing the most significant few of the problems is: – Include capability for A-MPDU protection for backward compatibility – Use a new protected form of the BAR frame to convey BAR information, and allow this protected BAR frame to cause RX Buffer LE movement while forbidding unprotected BAR frames from making RX Buffer LE changes – Allow alternative architectural ordering of Block Ack Reordering AFTER MPDU decryption, just before the Block Ack Reordering but preserve existing ordering option as well for legacy implementation – Include Block ACK Replay detection during Block Ack Reordering function Submission 5 Luke Qian etc, Cisco

July 2008 doc. : IEEE 802. 11 -08/0833 r 3 Secure Block Ack Rules

July 2008 doc. : IEEE 802. 11 -08/0833 r 3 Secure Block Ack Rules Part 1 • 1 – unencrypted BAR is not used to shift recipient RX BUFFER LE – Encrypted BAR can shift recipient RX BUFFER LE • STA with hybrid support for secure PN but no support for encrypted BAR can still use unencrypted BAR to shift recipient LE • 2 – unsolicited unencrypted BA is not used to shift originator LE – SIFS-response unencrypted BA may be used to shift originator LE – Encrypted BA may be used to shift originator LE at any time • 3 - recipient sends BA using partial state – BA of SSN is based on immediately preceding MPDU(s) – SIFS separation requires JAM for attacker to succeed – BA SSN mismatch to AMPDU SNs can be used to detect weak attack Submission 6 Luke Qian etc, Cisco

July 2008 doc. : IEEE 802. 11 -08/0833 r 3 Secure Block Ack Rules

July 2008 doc. : IEEE 802. 11 -08/0833 r 3 Secure Block Ack Rules Part 2 • 4 a - Recipients that are incapable of verifying SN values before crafting a BA (i. e. within SIFS) – employ “ephemeral” state operation • I. e. WINSTART_R and scorecard information is deleted after BA transmission • Incorrect RX scoreboard information that is due to rogue MPDU SN values will not survive • This is less stateful than partial state operation – Shall not send an encrypted BA after SIFS • Because encrypted information is based on potentially rogue SN info – WINSTART_R moves do not matter • E. g. those generated by rogue BAR or rogue MPDU SN – WINSTART_B moves are based on protected SN values • Implies reversal of reordering and decryption steps Submission 7 Luke Qian etc, Cisco

July 2008 doc. : IEEE 802. 11 -08/0833 r 3 Secure Block Ack Rules

July 2008 doc. : IEEE 802. 11 -08/0833 r 3 Secure Block Ack Rules Part 3 • 4 b - Recipients that are capable of verifying SN values before crafting a BA – WINSTART_R moves are based SN values – WINSTART_B moves are based SN values • 5 – Only the new protected MGMT frame can be used to perform BAR-style RX BUFFER pointer moves • 6 – use only AMPDU, even if wishing to send a single MPDU – i. e. do not use non-AMPDU for single frame transmission, since it will elicit ACK which can be jammed Submission 8 Luke Qian etc, Cisco

July 2008 doc. : IEEE 802. 11 -08/0833 r 3 Capability Negotiation: RSN Element

July 2008 doc. : IEEE 802. 11 -08/0833 r 3 Capability Negotiation: RSN Element changes Pre-Auth No Pairwise B 0 B 1 PTKSA Replay GTKSA Replay Reserved Counter B 2 B 3 B 4 B 5 B 6 B 8 Peer. Key Enabled B 9 Reserved B 10 B 11 PBAC B 12 Resv B 13 B 15 Modified RSN Capabilities subfield of the RSN Element • PBAC – Protected BAR/BA Capable – Indicates capability to perform modified replay rules and decryption ordering – Indicates capability to perform encryption/decryption of BAR/BA Mgmt Action frames • If both STA advertise PBAC=1, then PBAC SHALL be used – If at least one STA of a pair advertises PBAC=0, then PBA SHALL NOT be used – STA that supports PBAC must also indicate TGw (e. g. dot 11 RSNAProtected. Management. Frames. Enabled) – SIFS-BA is allowed Submission 9 Luke Qian etc, Cisco

July 2008 doc. : IEEE 802. 11 -08/0833 r 3 Encrypted BAR frame •

July 2008 doc. : IEEE 802. 11 -08/0833 r 3 Encrypted BAR frame • New Action frame – Category = Block Ack – Action = BAR – Body = BAR Control, BAR Information (see TGn draft) • Multi-TID version allowed • Uncompressed? • Encrypted according to TGw Submission 10 Luke Qian etc, Cisco

July 2008 doc. : IEEE 802. 11 -08/0833 r 3 Encrypted BA frame •

July 2008 doc. : IEEE 802. 11 -08/0833 r 3 Encrypted BA frame • New Action frame – Category = Block Ack – Action = BA – Body = BAR Control, BAR Information (see TGn draft) • Multi-TID version allowed • Uncompressed? • Optionally includes recipient RX Buffer LE value – To allow originator to synch its TX Buffer with RX Buffer • Encrypted according to TGw Submission 11 Luke Qian etc, Cisco

July 2008 doc. : IEEE 802. 11 -08/0833 r 3 Specification change for order

July 2008 doc. : IEEE 802. 11 -08/0833 r 3 Specification change for order of operations • Allow alternative ordering of Block Ack Reordering AFTER A new Block Ack Replay Detection function that includes a preceding MPDU decryption step, but preserve existing ordering option as well for legacy implementations. Submission Add a Block. Ack Replay Detection function here Move MPDU Decryption and Integrity Function to here 12 Luke Qian etc, Cisco

July 2008 doc. : IEEE 802. 11 -08/0833 r 3 Add Replay Detection within

July 2008 doc. : IEEE 802. 11 -08/0833 r 3 Add Replay Detection within Block Ack Reordering block • Add new parameter Win. PN_B at recipient, per TID, Win. PN_B and Win. Start_B operations are as follows: – Initialize Win. PN_B = SSN from ADDBA • Win. PN_B = next higher value of PN that has SN portion that matches ADDBA-SSN from current Win. PN_B value – If RX DATA packet fails decryption – If RX PN < Win. PN_B • • – Discard If RX PN = Win. PN_B + 1 • Win. PN_B = highest PN in RX Buffer in sequence starting with Win. PN_B+1 – – • Move Win. Start_B to equal the SN portion of adjusted Win. PN_B – – Win. PN_B = Win. Start_B = PN – Win. Size_B * 16 + 1 – No change to Win. Start_B or Win. PN_B – – Submission Accept the packet if there is not currently a packet with this PN stored in the RX BUFFER Declare a replay if the packet if there already is a packet with this PN stored in the RX BUFFER and discard the packet If secure BAR passes decryption • – Accept the packet If Win. PN_B + 1 < RX PN <= Win. PN_B + Win. Size_B * 16 • – Accept the packet If RX PN > Win. PN_B + Win. Size_B * 16 • – Note that “false holes” may exist in the sequence when the protected MORE FRAGS bit appears in MPDUs which have a FRAG bit value of less than 0 x. F “Next in sequence” determination skips these holes Win. Start_B = Win. PN_B = SSN from secure BAR Note that Win. Size_B is expressed in terms of MSDUs, but PN values track fragments, hence the factor of 16 13 Luke Qian etc, Cisco