Doc.: IEEE 802.11-04/0707r0 Submission July 2003 N. Cam-Winget, et alSlide 1 Establishing PTK...

July 2003

N. Cam-Winget, et alSlide 1

doc.: IEEE 802.11-04/0707r0

Submission

Establishing PTK liveness during re-association

Nancy Cam-Winget, Cisco Systems Inc

Emily H. Qi and Jesse Walker, Intel Corporation

July 2003


doc.: IEEE 802.11-04/0707r0

Submission

Where we are so far…

• Existing Standard & Proposals:– Pre-authentication + 4-Way Handshake at Reassociation (802.11i)– Pre-keying (04/476)– Tentative association (04/606)

• Existing Proposal Problems– Pre-authentication + 4-Way Handshake at Reassociation is not fast

• Otherwise 802.11r would not exist– Pre-keying and Tentative association incomplete

• 802.11i replay protection tied to key freshness and peer liveness• So far, both have failed to explain how they will obtain these• Reservation introduces a novel DoS attack against network resources• Proposals must explain how to protect against these novel DoS

attacks, because PAR says 802.11r can’t make security worse

July 2003


doc.: IEEE 802.11-04/0707r0

Submission

4-Way Handshake Observations

• 4-Way Handshake overloads ANonce, SNonce to perform two functions:– They must be different on each 4-Way Handshake to

provide key separation (“fresh” keys)– They must be unpredictable to prove liveness, so are

specified as random

• Making nonces serve both functions serializes PTK derivation with 4-Way Handshake execution– Infeasible for STA to pre-compute PTK, because

ANonce must be unpredictable

July 2003


doc.: IEEE 802.11-04/0707r0

Submission

Proposal

• Pre-compute PTK on the STA prior to Re-Association• Establish security associations liveness and GTK at reassociation time

– Not after, as 802.11i does today– Not before, as pre-keying and tentative association propose

• Apply updates to the 802.11i 4-Way Handshake to allow it to meet requirements:– Eliminate 4-Way Handshake Msg 1 by making ANonce predictable for

AP-to-AP transition– Embed 4-Way Handshake Msg 2 in Reassociation Request– Embed 4-Way Handshake Msg 3 in Reassociation Response– Add AP-Challenge to 4-Way Handshake Msgs 3 and 4, to prove STA

liveness to AP– Don’t change the 802.11i key hierarchy

July 2003


doc.: IEEE 802.11-04/0707r0

Submission

Optimized Re-Association with 4-way

Supplicant

Client

Authenticator

AP

Reassociate Request( 802.1X 4-way Message #2)

Reassociate Response( 802.1X 4-way Message #3)

Client determines new AP for roam, increments ANONCEGenerates new PTKi, Generate 802.1X Optimized 4-way Message #2

AP validates ANONCEGenerates new PTK validate 802.1X 4-way Message #2Generate 802.1X Optimized 4-way Message #3

Client and AP can now protect 802.1X and 802.11 packets

802.1X 4-way Message #4

Client validates Message #3 (process flows same as TGi)

July 2003


doc.: IEEE 802.11-04/0707r0

Submission

Optimized 4-way Handshake

• Use of 4-way Handshake as on associations defined in 802.11i:– SNonce and ANonce remain unpredictable and random

• On Roam use Optimized 4-way Handshake:– ANonce becomes an incrementing counter in reassociations, used as replay

protector against rekeys triggered either by IV exhaustion or roams– 4-way Message #1 is not used in the optimized 4-way handshake– Reassociation Request includes optimized Message # 2– Message #2 conveys ANonce and PMKID STA used to generate the PTK– AP validates ANonce from STA to ensure it is not a replay– Reassociation Response includes optimized Message # 3– Optimized Message #4 flows as defined in 802.11i– Uses PMK cacheing and established PMKID to kickstart optimized 4-way

handshake

• ANonce is bound to STA, BSSID and PMKID• Proposal enables 802.11i 4-way and Optimized 4-way handshakes to co-exist

July 2003


doc.: IEEE 802.11-04/0707r0

Submission

Two new KDE’s

• ANonce in Message 2 is conveyed as KDE• AP-Challenge to ensure STA liveness proof to AP

July 2003


doc.: IEEE 802.11-04/0707r0

Submission

4-way Handshake Optimized Message 2

Key Descriptor Type (1 octet)

Key Information (2 octets) Key Length (2 octets)

Key Replay Counter (8 octets)

SNonce (32 octets)

Key MIC (16 octets)

Key Data Length (2 octets) RSN IE, PMKID, ANonce

July 2003


doc.: IEEE 802.11-04/0707r0

Submission





ANonce (32 octets)

Key MIC (16 octets)

Key Data Length (2 octets) RSN IE, GTK, AP-Challenge

July 2003


doc.: IEEE 802.11-04/0707r0

Submission





Key MIC (16 octets)

Key Data Length (2 octets) AP-Challenge

July 2003


doc.: IEEE 802.11-04/0707r0

Submission

Inserting 802.1X in 802.11

• 802.1X EAPOL Key Frame (Message 2 and 3) are embedded into Reassociation Request and Response in new IE

Element ID Length Data

TBD 802.1X packet length

802.1X EAPOL Key frame

July 2003


doc.: IEEE 802.11-04/0707r0

Submission

Optimizations enable

• Reuse of TGi • Compression of exchanges reduce latencies • Enables the STA to precompute PTK prior to

association (to minimize time spent during association)

• Enables the STA to plumb PTK prior to reassociation….fixes race conditions in 4-way handshake

July 2003


doc.: IEEE 802.11-04/0707r0

Submission

Questions?

July 2003


doc.: IEEE 802.11-04/0707r0

Submission

Backup slides

July 2003


doc.: IEEE 802.11-04/0707r0

Submission

EAPOL Message Field Message 1 Message 2 Message 3 Message 4

Key Information Version V1 or v2 V1 or v2 V1 or v2 V1 or v2

Key Type 1 1 1 1

Install 0 0 1 0

Key ACK 1 0 1 0

Key MIC 0 1 1 1

Secure 0 0 1 1

Error 0 0 0 0

Request 0 0 0 0

ENC Key Data

0 0 1 0

Key Length Cipher spec 0 Cipher spec 0

Key Replay Counter n n n+1 n+1

Key Nonce ANonce SNonce ANonce 0

Key IV 0 0 0 if v2

Random v1

0

Key RSC 0 0 GTK’s PN 0

Key MIC 0 MIC MIC 0

Key Data Length 22 Len-2 Len-3 0

Key Data PMKID RSNIESTA RSNIEAP, GTK 0

802.11i 4-way Handshake Message values

July 2003


doc.: IEEE 802.11-04/0707r0

Submission

EAPOL Message Field Message 1 Message 2 Message 3 Message 4

Key Information

Version Not Used on Reassociation

V1 or v2 V1 or v2 V1 or v2

Key Type 1 1 1

Install 1 1 0

Key ACK 0 1 0

Key MIC 1 1 1

Secure 0 1 1

Error 0 0 0

Request 0 0 0

ENC Key Data 0 1 0

Key Length 0 Cipher spec 0

Key Replay Counter n n+1 n+1

Key Nonce SNonce ANonce 0

Key IV 0 0 if v2

Random v1

0

Key RSC 0 GTK’s PN 0

Key MIC MIC MIC 0

Key Data Length 62 RSNIEAP+ GTK len 0

Key Data RSNIESTA, PMKID, ANonce

RSNIEAP, GTK,

AP-Challenge

AP-Challenge

Optimized 802.11i 4-way Handshake Message values

July 2003


doc.: IEEE 802.11-04/0707r0

Submission

EAPOL Key Frame Format




Key Nonce (32 octets)

Key IV (16 octets)

Key RSC (8 octets)

Reserved (8 octets)

Key MIC (16 octets)

Key Data Length (2 octets) Key Data (n octets)

Doc.: IEEE 802.11-04/0707r0 Submission July 2003 N. Cam-Winget, et alSlide 1 Establishing PTK...

Documents

Transcript of Doc.: IEEE 802.11-04/0707r0 Submission July 2003 N. Cam-Winget, et alSlide 1 Establishing PTK...