1. doc.:IEEE 802.11-10/0313r1 Submission Robert Stacey (Intel) March 12, 2010 Slide 1 Rekeying Protocol Fix Authors: Date: 2010-03-12

2. doc.:IEEE 802.11-10/0313r1 Submission Robert Stacey (Intel) March 12, 2010 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. doc.:IEEE 802.11-10/0313r1 Submission Robert Stacey (Intel) March 12, 2010 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. doc.:IEEE 802.11-10/0313r1 Submission Robert Stacey (Intel) March 12, 2010 Implementation issues 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 RSNA Key Management mux data Priority Queues RSNA Key Management demux data Queue & Reorder buffers encryptdecrypt Key management control

5. doc.:IEEE 802.11-10/0313r1 Submission Robert Stacey (Intel) March 12, 2010 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. doc.:IEEE 802.11-10/0313r1 Submission Robert Stacey (Intel) March 12, 2010 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. doc.:IEEE 802.11-10/0313r1 Submission Robert Stacey (Intel) March 12, 2010 PTKSA (Key ID = 0) Rekeying procedure using 2 keys 4whs PTKSA (Key ID = 0) PTKSA lifetime Rekeying period (several hours) time PTKSA (Key ID = 1) Transition to new key PTKSA (Key ID = 1) 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. doc.:IEEE 802.11-10/0313r1 Submission Robert Stacey (Intel) March 12, 2010 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 Start using New Key for Tx Start using New Key for Tx

9. doc.:IEEE 802.11-10/0313r1 Submission Robert Stacey (Intel) March 12, 2010 Protocol Changes (2) Protocol (Authenticator) –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 –Install new key for Rx Ensure installation prior to transmitting Message 4 –Transmit Message 4 –Install new key for Tx (send MPDUs using new key) Timing is relaxed; some data MPDUs may still be sent using old key after Message 4 is transmitted

10. doc.:IEEE 802.11-10/0313r1 Submission Robert Stacey (Intel) March 12, 2010 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. doc.:IEEE 802.11-10/0313r1 Submission Robert Stacey (Intel) March 12, 2010 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