1. Block Ack Security Date: 2008-03-19 Authors: May 2008 May 2008
doc.: IEEE /0537r0
May 2008
Block Ack Security
Date:
Authors:
Matthew Fischer, Broadcom
Matthew Fischer, Broadcom

2. May 2008
doc.: IEEE /0537r0
May 2008
Abstract
An introduction to some security issues with the existing BA mechanism and a proposed set of modifications to reduce and/or eliminate the security problems.
Matthew Fischer, Broadcom
Matthew Fischer, Broadcom

3. Block Ack Security problems
May 2008
Block Ack Security problems
The following security problems exist:
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)‏
Matthew Fischer, Broadcom

4. BA security solution May 2008 A solution to this security problem is:
doc.: IEEE /0537r0
May 2008
BA security solution
A solution to this security problem is:
Protect the SN value of the MAC header of the data packets by including the SN value as part of the PN value
Either include the FRAG bits in PN, or disallow fragmentation
Modify the setup of the security agreement that is negotiated between the originator and the recipient so that the originator and recipient can negotiate the use of the new PN scheme
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
Use a new protected form of the BA frame to convey BA information, disallow acceptance of unprotected BA frame, except optionally, after SIFS
Allow alternative architectural ordering of Block Ack Reordering AFTER MPDU decryption, and include a new Block Ack Replay Detection function just before the Block Ack Reordering but preserve existing ordering option as well for legacy implementation
Matthew Fischer, Broadcom
Matthew Fischer, Broadcom

5. Secure Block Ack Rules Part 1
May 2008
Secure Block Ack Rules Part 1
*1 – unencrypted BAR is not used to shift recipient LE
Encrypted BAR can shift recipient LE
Unencrypted BAR can still be used to cause a BA to be generated
*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 – PN is modified to include SN and is tracked per TID
RX Buffer reorder based on protected SN
*4 - 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
Some of these precautions can be followed by STA not using a protected SN, such steps are marked as *
Matthew Fischer, Broadcom

6. Secure Block Ack Rules Part 2
May 2008
Secure Block Ack Rules Part 2
5a - 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
Matthew Fischer, Broadcom

7. Secure Block Ack Rules Part 3
May 2008
Secure Block Ack Rules Part 3
5b - Recipients that are capable of verifying SN values before crafting a BA
extract the SN from the IV
Either examine one of the FRAG bits or use TA lookup result
may use any of partial-partial state, regular partial state or full state
WINSTART_R moves are based on protected SN values
WINSTART_B moves are based on protected SN values
*5c - Recipients that are incapable of verifying SN values at all (i.e. not participating in the new protocol)
employ ephemeral state operation
incorrect RX scoreboard information that is due to rogue MPDU SN values will not survive
WINSTART_R moves do not matter
WINSTART_B moves will be based on potentially faulty SN values, but at least relative ordering can be established by examining PN values
6 – Only the new protected MGMT frame can be used to perform BAR-style RX BUFFER pointer moves
*7 – 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
Matthew Fischer, Broadcom

8. New PN value generation – Per TID
May 2008
doc.: IEEE /0537r0
May 2008
New PN value generation – Per TID
UpperBits
MAC SN
FRAG
32 bits
12 bits
4 bits
Each stream is identified by {TA,RA,TID}
Non-QOS frames need not apply
PN is assigned per TID
The TID within the frame is protected by the Nonce
Use MAC SN and FRAG for the low order bits of the new PN value
Ensures that the PN values appear in increasing sequence at the recipient, otherwise the replay detection in the security processing section would declare a replay error.
Some values skipped if FRAG does not use all 16 values.
The new PN is treated as a single value, within each TID
I.e. When the MAC SN value reaches 0xFFF, then the next value of SN will be 0x000 again. When SN wrap occurs, the UpperBits field of the new PN is incremented by one.
If any one of the TID PN spaces uses all 2^48 PN values (minus any initial offset), then a new key must be used for this RA/TA pair
I.e. for the existing security protocol, once the PN number space has been exhausted, a new key must be used before the PN sequence can be restarted. Each TID has its own PN space, so when any is exahausted, all must start over.
SN values can continue where they left off (some loss of PN space is incurred, but it is quite small) – STA can optionally reset the SN
Each TID for a given RA/TA pair has a PN space to use that is equivalent in size to the original PN
If any one of the TID PN spaces runs through all possible 2^48 PN values which belong to that TID, then the RA/TA key must be replaced.
MGMT Type frames get their own PN space
Matthew Fischer, Broadcom
Matthew Fischer, Broadcom

9. AAD construction AAD construction is unchanged
May 2008
doc.: IEEE /0537r0
May 2008
AAD construction
AAD construction is unchanged
But PN construction is modified
SN value is used in the PN construction
This protects the SN
Matthew Fischer, Broadcom
Matthew Fischer, Broadcom

10. Management frame change
May 2008
doc.: IEEE /0537r0
May 2008
Management frame change
Modified PN will not be recognized by legacy STA
Existing devices will not function properly if the modified PN value is used
Therefore, it is necessary to negotiate the use of the new protocol through a modified management exchange
New bits added to the Extended Capabilities information element
To signal capability
To signal requirements
Matthew Fischer, Broadcom
Matthew Fischer, Broadcom

11. Extended Capabilities Element changes
May 2008
Extended Capabilities Element changes
HT Info
Exch Sp
On-Demand
Beacon
Ext Chnl
Switching
WAVE
Indication
Resv
EBAC
UNBAI
USBAI
EBRC
UBRI
PSNC
PSNR
Resv
ANA B0 B1 B2 B3 B4 B5 B6 B7 B8 B9
B10
B11
B12
B14
B15
EBAC – Encrypted BA Capable
UNBAI – Unencrypted Non-SIFS BA Ignored
USBAI – Unencrypted SIFS BA Ignored
EBRC – Encrypted BAR Capable
UBRI – Unencrypted BAR Ignored
PSNC – Protected SN Capable
PSNR – Protected SN Required
Matthew Fischer, Broadcom

12. Encrypted BAR frame New Action frame Encrypted according to TGw
May 2008
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
Matthew Fischer, Broadcom

13. Encrypted BA frame New Action frame Encrypted according to TGw
May 2008
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
Matthew Fischer, Broadcom

14. Specification change for order of operations
May 2008
Specification change for order of operations
Allow alternative ordering of Block Ack Reordering AFTER A new Block Ack Replay Detection function, but preserve existing ordering option as well for legacy implementations.
Add a BlockAck Replay
Detection function here
Move MPDU Decryption and
Integrity Function to here
Matthew Fischer, Broadcom

15. Add Replay Detection within Block Ack Reordering block
May 2008
Add Replay Detection within Block Ack Reordering block
Add new parameter WinPN_B at recipient, per TID, WinPN_B and WinStart_B operations are as follows:
Initialize WinPN_B = SSN from ADDBA
WinPN_B = next higher value of PN that has SN portion that matches ADDBA-SSN from current WinPN_B value
If RX DATA packet fails decryption
Discard
If RX PN < WinPN_B
If RX PN = WinPN_B + 1
WinPN_B = highest PN in RX Buffer in sequence starting with WinPN_B+1
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 0xF
“Next in sequence” determination skips these holes
Move WinStart_B to equal the SN portion of adjusted WinPN_B
Accept the packet
If RX PN > WinPN_B + WinSize_B * 16
WinPN_B = WinStart_B = PN – WinSize_B *
If WinPN_B + 1 < RX PN <= WinPN_B + WinSize_B * 16
No change to WinStart_B or WinPN_B
If secure BAR passes decryption
WinStart_B = WinPN_B = SSN from secure BAR
Note that WinSize_B is expressed in terms of MSDUs, but PN values track fragments, hence the factor of 16
Matthew Fischer, Broadcom

16. May 2008
References
Matthew Fischer, Broadcom