1 / 11

Rekeying Protocol Fix

Rekeying Protocol Fix. Date: 2010-03-12. Authors:. 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).

arussell
Télécharger la présentation

Rekeying Protocol Fix

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Rekeying Protocol Fix Date: 2010-03-12 Authors:

  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 • 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 data mux demux Key management control Key management control Queue & Reorder buffers Priority Queues encrypt decrypt

  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) 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 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

  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) • 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. 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

More Related