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

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

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

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

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

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

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

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

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

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

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