January 2003

N. Cam-Winget, D. Smith, K. AmannSlide 1

doc.: IEEE 802.11-03/008r0

Submission

Proposed new AKM for Fast Roaming

Nancy Cam-Winget, Cisco Systems Inc

Doug Smith, Cisco Systems Inc

Keith Amann, Spectralink

January 2003

N. Cam-Winget, D. Smith, K. AmannSlide 2

doc.: IEEE 802.11-03/008r0

Submission

Fast Roam Goals

• TGi has provided sound framework and protocols to secure 802.11 link communications

• Next step is to evaluate Fast Roaming– Voice advocates no more than 50ms handoff latency

– Are security considerations for voice the same as data?

• Submission focuses on fast roaming for voice– Only reassociation exchange is applied

January 2003

N. Cam-Winget, D. Smith, K. AmannSlide 3

doc.: IEEE 802.11-03/008r0

Submission

Handoff Times for Voice

• Doc 02/758 states:– ITU guidance on TOTAL hand-off latency is that it

should be less than 50 ms. Cellular networks try to keep it less than 35 ms.

January 2003

N. Cam-Winget, D. Smith, K. AmannSlide 4

doc.: IEEE 802.11-03/008r0

Submission

Handoff Process DelaysSTA APs

…Probe Requests

Probe Response

Pre-authentication Exchange

Re-association Exchange

4-way & 2-way handshakes

Other APs

IAPP

Dis

cove

ryR

eau

then

tica

tio

n

New AP

January 2003

N. Cam-Winget, D. Smith, K. AmannSlide 5

doc.: IEEE 802.11-03/008r0

Submission

The Handoff Procedure : two phases

1. Discovery (active or passive scanning)• Determination to find new AP due to signal strength loss (or

inability to communicate) with current AP• Probe delays incurred when client searches for new AP

2. Reauthentication• Station reauthenticates and reassociates to new AP• Reauthentication and reassociation delays

• Implications:– Discovery phase – out of TGi’s scope– Reauthentication phase must be efficient to support wireless voice

January 2003

N. Cam-Winget, D. Smith, K. AmannSlide 6

doc.: IEEE 802.11-03/008r0

Submission

Average Roam latencies in current 802.11 systems

Phase Average measured latencies

Discovery 66ms – 440ms

Reauthentication (Open Auth, no WEP)

12ms – 40ms

January 2003

N. Cam-Winget, D. Smith, K. AmannSlide 7

doc.: IEEE 802.11-03/008r0

Submission

Cryptographic computations for RSN 4-way and 2-way exchanges

Node Message Nonce Gen Hmac-SHA11 ops

Hmac-md52

ops

STA ← AP 4-way: 1st msg 1 - -

STA → AP 4-way: 2nd msg 1 3 2

STA ← AP 4-way: 3rd msg - 3 2

STA → AP 4-way: 4th msg - - (24)

STA ← AP 2-way: 1st msg (13) (33) 2

STA → AP 2-way: 2nd msg - - 2

Total 6 msgs 2 6 8

1 Hmac-SHA1 used as PRF to compute WRAP or CCMP keys2 Hmac-MD5 requires 2 MD5 operations3 Only computed when GTK is refreshed4 MIC check doesn’t affect data flow

January 2003

N. Cam-Winget, D. Smith, K. AmannSlide 8

doc.: IEEE 802.11-03/008r0

Submission

RSN Relative Costs

Initial Assoc Reassociation

Crypto operations

2 Nonce Gen +

6 HMAC-SHA1 +

8 HMAC-MD5

2 Nonce Gen +

6 HMAC-SHA1 +

8 HMAC-MD5

Packet count (4+ EAP + 6)** packets (4 + 6)** packets

**802.11 Open Auth + (Re)Assoc = 4 pkts

January 2003

N. Cam-Winget, D. Smith, K. AmannSlide 9

doc.: IEEE 802.11-03/008r0

Submission

Potential delays• Computational delay

– Each authentication packet– Each packet requiring generation of PRF

• Media access delay : due to packets sent by other NICs between the authentication packets

Example: 1500 octet packet arrives while AP is processing an association response:

– AP at 11Mbps ≈ 1.1ms delay between each packet– AP at 6Mbps ≈ 2ms delay between each packet– AP at 2Mbps ≈ 6ms delay between each packet

For 10 message exchange, media access delay alone is 10-60ms!

The heavier the traffic, the higher the delay….

January 2003

N. Cam-Winget, D. Smith, K. AmannSlide 10

doc.: IEEE 802.11-03/008r0

Submission

Fast Roam for voice implies:

• Pre-authentication is required• Re-association 4-way handshake is too expensive• Additional 2-way handshake for GTK delivery

does not help.

GOAL:• Hand-off times MUST be efficient to support

synchronous connections, e.g. VoIP

January 2003

N. Cam-Winget, D. Smith, K. AmannSlide 11

doc.: IEEE 802.11-03/008r0

Submission

Ideally, compress roaming to:

Supplicant

Client

Authenticator

AP

Reassociate Request: negotiate CKM, authenticate rekey

Reassociate Response: validate rekey, random challenge, deliver group key

Client and AP can now protect 802.1X and 802.11 packets

Reassociate Confirm: random challenge response, MIC

January 2003

N. Cam-Winget, D. Smith, K. AmannSlide 12

doc.: IEEE 802.11-03/008r0

Submission

Handoff Procedure using a Roam Server

Roam Server

1st AP New AP

Establish Security Block Send Security Block

Re-association

Assumptions:• Roam Server can be adapted to document 02/758• Roam Server is trusted, can be the Authentication Server• AP is trusted and has trust relationship with Roam Server

January 2003

N. Cam-Winget, D. Smith, K. AmannSlide 13

doc.: IEEE 802.11-03/008r0

Submission

Roam Server is Central Key Manager (CKM)

Central Key Management (CKM) Protocol:• Uses PMK from successful EAP Authentication to derive

1. rekey request key (RRK) – used to authenticate rekey element in reassociation request

2. Rekey base key (RBK) – used to mutually derive pairwise transient keys (PTK) to protect 802.1X and 802.11 packets.

• RRK and RBK derived on association• RRK serves as authorization key• RBK serves as Base Key used to derive PTKs• Roam Server may only distribute PTKs or with proactive

key distribution can forward <RRK,RBK> to APs

January 2003

N. Cam-Winget, D. Smith, K. AmannSlide 14

doc.: IEEE 802.11-03/008r0

Submission

New Key HierarchyPMK implicitly derived as

a result of a successful EAP authentication

RRK128 bits

RBK256 bits

Generate RRK and BRK: PRF-384(PMK, “Fast-Roam Generate Base Key”, MACAPi | MACSTA | NonceSTA | NonceRS)

802.1X Encrypt Key

(16bytes)

802.1X MIC Key

(16 bytes)

802.11 Encrypt Key

(16 bytes)

MIC Keys (TKIP only)

Tx Key Rx Key 8 bytes 8 bytes

PTKRSC = PRF-XXX(RBK, RSC|BSSID)

January 2003

N. Cam-Winget, D. Smith, K. AmannSlide 15

doc.: IEEE 802.11-03/008r0

Submission

New Key Hierarchy facilitates reassoc

• RRK used to authenticate new Reassociation Request element

Element ID

Length Rekey Sequence Counter

MIC

1octet 1octet 4octets 8octets

MIC = HMAC-MD5(RRK, MACSTA | BSSID | RSNESTA | RSC )

January 2003

N. Cam-Winget, D. Smith, K. AmannSlide 16

doc.: IEEE 802.11-03/008r0

Submission

Reassociation Response includes GTK

MICRRK = HMAC-MD5(RRK, RSC | MACSTA)

PTKRSC = <KCK, KEK, TK> = PRF-XXX(RBKBSSID, RSC | BSSID )

MICPTK = HMAC-MD5(TKRSC, RSNEAP | RSC | KeyIDunicast | KeyIDmulticast | Multicast Key length | E(PTKRSC, GTK) )

Elem ID Len RSC Random Challenge

KeyID unicast

KeyID multi-cast

Multi-cast key length

MICRRK MICPTK E(GTK)

1octet 1octet 4octets 16 octects 1octet 1octet 2octets 8 octets 8octets N octets

January 2003

N. Cam-Winget, D. Smith, K. AmannSlide 17

doc.: IEEE 802.11-03/008r0

Submission

Re-association Confirm

• New 3rd message should be management :– 3rd message includes random challenge response

– 3rd message confirms liveness of PTK

– 3rd message defeats MIM attack

January 2003

N. Cam-Winget, D. Smith, K. AmannSlide 18

doc.: IEEE 802.11-03/008r0

Submission

Same Assoc and 802.1X Auth as default RSN

Association Req + RSN IE (802.1X, CKM)**

Association Response (success)

EAP type specific mutual authentication

Derive Pairwise Master Key (PMK)

RADIUS ACCEPT (with PMK)

802.1X/EAP-SUCCESS

Derive Pairwise Master Key (PMK)

**New AKM → Central Key Management (CKM) is negotiated

Open Authentication Request

Open Authentication Response

January 2003

N. Cam-Winget, D. Smith, K. AmannSlide 19

doc.: IEEE 802.11-03/008r0

Submission

Initial 4-way handshake with Roam Server

EAPoL-Key(Unicast, ANonce)

PMKPMK

Derive ANonceDerive SNonce

EAPoL-Key(Unicast, SNonce, MIC, RSNESTA)

EAPoL-Key(Install PTK1, Unicast, MIC, RSNEAP)

Derive RRK, RBK, PTK1

Derive RRK, RBK, PTK1

EAPoL-Key(Unicast, MIC)

Install Keys Install Keys

Deliver PTK1

RSAP

STA

Group key handshake used for PTK liveness confirm

January 2003

N. Cam-Winget, D. Smith, K. AmannSlide 20

doc.: IEEE 802.11-03/008r0

Submission

Ideally, compress roaming to:

Supplicant

Client

Authenticator

AP

Reassociate Request: negotiate CKM, authenticate rekey

Reassociate Response: validate rekey, random challenge, deliver group key

Client determines new AP for roam, increments RSCGenerates new PTKi, requests CKMGenerate CKM rekey authentication element

AP validates CKM rekey authentication elementGenerates new PTKi, finalizes Client switch to APGenerate CKM rekey response authentication elementDeliver group keys to Client

Client and AP can now protect 802.1X and 802.11 packets

Reassociate Confirm: random challenge response, MIC

January 2003

N. Cam-Winget, D. Smith, K. AmannSlide 21

doc.: IEEE 802.11-03/008r0

Submission

Using Roam ServerRS

APSTA

Reassoc Req: negotiate CKM, authenticate rekey

Reassoc Resp: validate rekey, random challenge, deliver group key

AP requests for STA’s RBK(For proactive key distribution, no request is needed)

Deliver STA’s RBK

Reassoc Confirm: random challenge response

January 2003

N. Cam-Winget, D. Smith, K. AmannSlide 22

doc.: IEEE 802.11-03/008r0

Submission

Reassociation triggers rekey with new AP

• Rekey obviates need to reauthenticate with AS• Rekey obviates need for client to pre-authenticate• Rekey is embedded in reassociate exchange to

reduce number of packet exchanges• Reassociation messages include new authenticated

element to validate rekey request

January 2003

N. Cam-Winget, D. Smith, K. AmannSlide 23

doc.: IEEE 802.11-03/008r0

Submission

Cryptographic computations for CKM Reassociation

Node Message Nonce Gen Hmac-Sha11 ops

Hmac-md52 ops

STA → AP Reassoc Request - (34) 1

AP → RS PTK request - - 3

RS → AP PTK response - (34) 3

STA ← AP Reassoc Response (1)3+1 - 2

STA → AP Reassoc Confirm - - 2

Total 3 air pkts + 2 DS pkts 1 - 11

1 Hmac-SHA1 used as PRF to compute CCMP keys2 Hmac-MD5 requires 2 MD5 operations3 Only computed when GTK is refreshed4 Can be precomputed before reassociation commit

January 2003

N. Cam-Winget, D. Smith, K. AmannSlide 24

doc.: IEEE 802.11-03/008r0

Submission

Relative Costs

RSN CKM

Crypto Ops for Assoc

2 Nonce Gen +

6 HMAC-SHA1 +

8 HMAC-MD5

2 Nonce Gen +

12 HMAC-SHA1 +

8 HMAC-MD5

Crypto Ops for Reassociation

2 Nonce Gen +

6 HMAC-SHA1 +

8 HMAC-MD5

1 Nonce Gen +

0 HMAC-SHA1 +

11 HMAC-MD5

Assoc pkts (4 + EAP + 6) pkts (4 + EAP + 6) pkts

Reassoc pkts (4 + 6)** pkts 3 pkts over air + 2pkts on DS

**Presumes Pre-authentication

January 2003

N. Cam-Winget, D. Smith, K. AmannSlide 25

doc.: IEEE 802.11-03/008r0

Submission

Proposal optimizes Fast roaming by

• Reduction in packet exchanges • Reduction in cryptographic computations• No propagation of MK or PMK is required• Roam Server can be adapted to use proactive key

distribution and forward <RRK,RBK,RSC> in context

January 2003

N. Cam-Winget, D. Smith, K. AmannSlide 26

doc.: IEEE 802.11-03/008r0

Submission

TGi must address Fast Roaming

• Roaming must be seamless for all clients• Must account for small clients (e.g. wireless

phones)

January 2003

N. Cam-Winget, D. Smith, K. AmannSlide 27

doc.: IEEE 802.11-03/008r0

Submission

Feedback?

January 2003

N. Cam-Winget, D. Smith, K. AmannSlide 28

doc.: IEEE 802.11-03/008r0

Submission

Roam Server generates AP specific <RRK, RBK>

Roam Server

1st AP New AP

<RRKAP1, RBKAP1>

Re-association

<RRKAP1, RBKAP1>

<RRKAP1, RBKAP1> = PRF-384(PMK, “Fast-Roam Generate Base Key”, MACAP1 | MACSTA | NonceSTA | NonceRS)

January 2003

N. Cam-Winget, D. Smith, K. AmannSlide 29

doc.: IEEE 802.11-03/008r0

Submission

Initial 4-way handshake in distributed model….

EAPoL-Key( Unicast, ANonce)

PMKPMK

Derive ANonceDerive SNonce

EAPoL-Key(Unicast, SNonce, MIC, RSNESTA)

EAPoL-Key( Install PTK1, Unicast, MIC, RSNEAP)

Derive RRK, RBK, PTK1

Derive RRK, RBK, PTK1

EAPoL-Key(Unicast, MIC)

Install Keys Install Keys