1. Rekeying Protocol Fix Date: 2010-03-12 Authors: Month Year
doc.: IEEE yy/xxxxr0
Rekeying Protocol Fix
Date:
Authors:
John Doe, Some Company

2. Problem Statement (1)
Key installation after M4 is not precisely defined
Differences in install timing between Authenticator and Supplicant can result in packet loss

3. Problem Statement (2)
Difference in key install times between supplicant and authenticator can result in packet loss
One side transmits using new key while other side is still decrypting using old key
One side transmits using old key while other side is decrypting using new key
High packet loss causes
Video streaming disruption
TCP slow start
Use of new PN sequence may be detected as replay attack
Erodes the security value of statistics on potential attacks
May result in disassociation

4. Implementation issues
RSNA Key
Management
RSNA Key
Management
data
data
mux
demux
Key management control
Key management control
Queue & Reorder buffers
Priority
Queues
encrypt
decrypt
Key management messages and control incur variable implementation delay from
Queuing delays
Key management/encryption engine control path architecture
E.g. messaging passing vs direct write
OS scheduling latencies
Inline control is possible on transmit side, but doesn’t help on receive side

5. Protocol issues
The specification is not clear on exactly when key installation occurs after Message 4 is sent or received
Message 4 may be aggregated with other data frames in the same A-MPDU
Does key switch-over occur mid A-MPDU?
Message 4 may be retransmitted
Does transmitter install after transmitting Message 4 or after message 4 is acknowledged?
Block Ack may be in use; Message 4 may only be acknowledged after additional data messages have been sent

6. Proposed Solution Use different Key ID with each new key installation
Need to increase Key ID space for unicast traffic
Currently:
Key ID = 0 used for unicast traffic
Key ID = 1, 2, 3 used for broadcast/multicast traffic
Change to:
Key ID = 0, 1 to be used for unicast
Key ID = 0, 1, 2, 3 to be used for broadcast/multicast
At recipient distinguish key space based on receive address in packet:
Unicast address  Key ID indexes pairwise key
Broadcast/multicast address  Key ID indexes group key
Ensure that Tx key use at sender occurs after Rx key install at recipient
Previously installed key remains valid during transition
Capability exchange required to ensure that both ends support the new mechanism

7. Rekeying procedure using 2 keys
Rekeying period (several hours)
4whs
4whs
4whs
4whs
4whs
time
PTKSA lifetime
PTKSA (Key ID = 0)
PTKSA (Key ID = 0)
PTKSA (Key ID = 1)
PTKSA (Key ID = 1)
Transition to new key
PTKSA = Pairwise Transient Key Security Association
Keys remain in place (for receive processing) for 2 handshake periods
PTKSA lifetime is 2 handshake periods
New key installation replaces old key with same Key ID
Having two active keys permits a smooth, timing relaxed transition from one PTKSA to the next

8. Protocol Changes (1)
Authenticator installs new key for Rx before sending M3
Supplicant installs new key for Rx after receiving M3 but before sending M4
Supplicant starts using new key for Tx after sending M4
Authenticator starts using new key for Tx after receiving M4
Install New Key for Rx
Install New Key for Rx
Start using
New Key for Tx
Start using
New Key for Tx

9. Protocol Changes (2) Protocol (Authenticator) Protocol (Supplicant)
Calculate key on receiving Message 2
Install new key for Rx
Ensure installation prior to transmitting Message 3
Transmit Message 3
Receive Message 4
Install new key for Tx (send MPDUs using new key)
Timing is relaxed; use of new key for tx occurs any time after message 4 arrives at receive antenna, allowing for software processing delays
Protocol (Supplicant)
Calculate new key on receiving Message 3
Ensure installation prior to transmitting Message 4
Transmit Message 4
Timing is relaxed; some data MPDUs may still be sent using old key after Message 4 is transmitted

10. Summary of Specification Changes
Permit Key IDs 0 and 1 to be used for unicast traffic
Add Extended Key ID for Unicast capability bit in RSNE
Add Key ID KDE to pairwise 4-way handshake
Associates generated key with a Key ID
Separate installation of key for Rx from installation of key for Tx
Modify description of 4-way handshake to define when installation occurs
Modify MLME-SETKEYS primitive to independently install key for Rx and Tx

11. Conclusion
Proposed solution eliminates race condition in rekeying procedure
Precisely defines (with reference to message exchange) points at which new key installation occurs
Maintains relaxed timing for flexibility in implementation
No real-time coupling of when messages appear on-air and when key installation occurs
Allows key exchange messages to be treated as data messages by lower layers