doc.:IEEE 802.11-10/0313r1
March 12, 2010
Rekeying Protocol Fix
Date: 2010-03-12
Authors:
Name
Company
Address
Phone
email
Robert Stacey
Intel
2111 NE 25th Ave,
Hillsboro, OR 97124
+1-503-724-0893
[email protected]
Adrian Stephens
Intel
[email protected]
Jesse Walker
Intel
[email protected]
Herbert Lionidas
Intel
[email protected]
Emily Qi
Intel
[email protected]
Submission
Slide 1
Robert Stacey (Intel)
March 12, 2010
doc.:IEEE 802.11-10/0313r1
Problem Statement (1)
• Key installation
after M4 is not
precisely defined
• Differences in install
timing between
Authenticator and
Supplicant can
result in packet loss
Submission
Robert Stacey (Intel)
doc.:IEEE 802.11-10/0313r1
March 12, 2010
Problem Statement (2)
Supplicant
Authenticator
Message 4
Apply new key to Tx,
Install new key for Rx
User Data
Decryption fails:
Rx using old key
Decryption fails:
Rx using new key
High packet loss causes
TCP to slow start
•
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
–
–
•
Apply new key to Tx,
Install new key for Rx
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
Submission
Robert Stacey (Intel)
doc.:IEEE 802.11-10/0313r1
March 12, 2010
Implementation issues
RSNA Key
Management
RSNA Key
Management
data
mux
demux
Key
management
control
Key
management
control
Priority
Queues
encrypt
•
data
Queue &
Reorder
buffers
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
Submission
Robert Stacey (Intel)
doc.:IEEE 802.11-10/0313r1
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
Submission
Robert Stacey (Intel)
doc.:IEEE 802.11-10/0313r1
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
Submission
Robert Stacey (Intel)
doc.:IEEE 802.11-10/0313r1
March 12, 2010
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
Submission
Robert Stacey (Intel)
March 12, 2010
doc.:IEEE 802.11-10/0313r1
Protocol Changes (1)
Install New Key
for Rx
Start using
New Key for Tx
Submission
• Authenticator installs new
key for Rx before sending
M3
• Supplicant installs new
key for Rx after receiving
Install New Key
for Rx
M3 but before sending M4
• Supplicant starts using
Start using
new key for Tx after
New Key for Tx
sending M4
• Authenticator starts using
new key for Tx after
receiving M4
Robert Stacey (Intel)
doc.:IEEE 802.11-10/0313r1
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
Submission
Robert Stacey (Intel)
March 12, 2010
doc.:IEEE 802.11-10/0313r1
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
Submission
Robert Stacey (Intel)
doc.:IEEE 802.11-10/0313r1
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
Submission
Robert Stacey (Intel)