Month 1998 doc IEEE 802 11 01636 r

Month 1998 doc. : IEEE 802. 11 -01/636 r 1 A Simple Rekeying Proposal Dmitri Varsanofiev Resonext Communications San Jose, CA dmitri@varsanofiev. com Submission 1 John Doe, His Company

November 2001 doc. : IEEE 802. 11 -01/636 r 1 Rekeying Proposal • Goals – Eliminate the synchronization exchange at the MAC level – Handle the per-link keys and multicast keys in a uniform manner Submission 2 Dmitri Varsanofiev

November 2001 doc. : IEEE 802. 11 -01/636 r 1 Rekeying Proposal: Idea • Temporary key is derived based on a master key and a nonce • Rekeying is synchronized using the nonce broadcasted in the clear in each beacon • To avoid the packet loss during rekeying, two keys are used. Rekeying moments for the two keys are different. Stations avoid using the key that is about to be changed • All stations are rekeyed simultaneously • Two nonces are transmitted with the corresponding key IDs: the current one and the next one as well as the number of beacon intervals before a key change. Submission 3 Dmitri Varsanofiev

November 2001 doc. : IEEE 802. 11 -01/636 r 1 Rekeying Proposal: Assumptions • Master key setup is done using means outside of the scope of this proposal (Upper Layer Authentication) • Rekeying is infrequent (once per so many minutes) • Rekeying is done using a temporary key which is a function of a master key and a nonce. • Nonce and key derivation for temporary key are outside of the scope of this proposal. For example, the formula for base_shared_key in the 01/508 can be used Submission 4 Dmitri Varsanofiev

November 2001 doc. : IEEE 802. 11 -01/636 r 1 Beacon Information Element • Patterned after the Rekey Information Element in 01/508 • Includes – – – – Submission Current Nonce Current Key ID Next Nonce Next Key ID Key Sequence Number Cipher Suite Rekey Count MIC 5 Dmitri Varsanofiev

November 2001 doc. : IEEE 802. 11 -01/636 r 1 Rekeying Proposal: Drawbacks • The rekeying is based on the station that was the first to exhaust the IVs. AP has to derive keys for all associated stations each time – more calculations needed than in the case of individual rekeying of each station. • Two key IDs are needed (can be relaxed) Submission 6 Dmitri Varsanofiev

November 2001 doc. : IEEE 802. 11 -01/636 r 1 Rekeying Proposal • Inspired by Young / O’Hara’s proposal 01/540 • Not a stand-alone proposal – Uses re-key information element similar to 01/508 • Possible modifications – Use just one key ID. May require re-encryption of few packets during the key switch time, if they would fall into a different beacon interval than planned. Alternatively, packets encrypted both with the old and new key can be always transmitted during the predetermined “overlap” period. – Transmit nonces only along with DTIM information – Broadcast two nonces at a time; one for each direction Submission 7 Dmitri Varsanofiev