1. Fast Roaming Observations
January 2002
Fast Roaming Observations
Jesse Walker, Intel Corporation
Nancy Cam-Winget, Atheros Communications
Walker/Cam-Winget; Intel/Atheros

2. Background TGf IAPP “Fast Hand-off” to effect fast roaming
January 2002
Background
TGf IAPP “Fast Hand-off” to effect fast roaming
TGf intended to address several important needs:
Update 802 bridges after a roam
Delete obsolete state off roaming STA’s old AP
Move QoS data from old AP to new AP
Also being (ab?) used by TGi to pass keying material from old AP to new AP on STA roam
Claims:
Simpler, more secure protocols are possible
TGf is being needlessly complicated by considerations relevant only to TGi
If it tries, TGi can find a better fast roaming solution that does not distort TGf
Even if it doesn’t try, most of the work still falls to TGi, and TGi needs to undertake this work
Walker/Cam-Winget; Intel/Atheros

3. IAPP Fast Hand-off of TGi Keys
January 2002
IAPP Fast Hand-off of TGi Keys
Old AP
IAPP Send SecBlock
IAPP Move
STA
IAPP Send SecBlock Ack
IAPP Move Ack AS
New AP
Reassociate Request
Query
Query Response
Reassociate Response
Query transaction supplies IPsec security association material  only needed once if New AP caches SAs; requires AS to maintain registry of IPsec SAs
SendBlock transaction copies keying material from old AP to new AP
Move transaction deletes keying material off old AP
Walker/Cam-Winget; Intel/Atheros

4. Some Problems (1) Sharing keying material among n APs
January 2002
Some Problems (1)
Sharing keying material among n APs
increases chance of key compromise
Exposure of 1 AP compromises STA on all subsequent roams
All STAs that roamed through the compromised AP have to be considered compromised
How does the STA and new AP establish its fresh EAPOL Key?
Keys live forever
Walker/Cam-Winget; Intel/Atheros

5. Some Problems (2) Authentication issues
January 2002
Some Problems (2)
Authentication issues
Does client authentication really work?
Does New AP have to remember every <nonce, key> pair ever seen to guarantee liveness? The answer depends critically dependent on (a) the Security Block exchange being properly protected from replay and forgery, and (b) the old AP never being compromised
Who should be authenticated to whom?
For protocol to be secure, each party (Old AP, new AP, STA) must be authenticated to the other two? It looks so.
Walker/Cam-Winget; Intel/Atheros

6. January 2002
Some Problems (3)
How does protocol distinguish the reassociations types:
Legacy reassociation
IAPP “Fast Handoff” reassociation
Reassociation to the same AP
Walker/Cam-Winget; Intel/Atheros

7. A Different Architecture (1)
January 2002
A Different Architecture (1)
Assume: Each AP shares a secret KAP with the AS (Needed for 802.1X support anyway)
Key Hierarchy:
Master Key KSTA  secure communication between AS, STA
Association Key  secure EAPOL key messages
Temporal Key  derive keys to secure data between AP, STA
Three processing elements:
STA
AP (802.1X Authenticator)
Hand-off server (802.1X Authentication server)
One new protocol:
Key Sharing Protocol:
Protocol goal: to push a fresh key out from AS to new AP and STA
Walker/Cam-Winget; Intel/Atheros

8. A Different Architecture (2)
January 2002
A Different Architecture (2)
Steps on Association:
Associate
Run full EAP authentication (AS  STA)
Derive Master Key
Run key sharing protocol (AS  AP  STA)
Use Master Key to distribute Association Key to STA
Use AP  AS key to deliver Association Key to AP
Steps on Reassociation
Run key sharing protocol (AS  AP  STA) embedded in reassociation
Use Master Key to distribute new Association Key to STA
Use AP  AS key to deliver new Association Key to new AP
Steps on Disassociation or IAPP Delete:
Must carry the new Authenticator Element
Old AP securely deletes Association and Temporal Keys if Authenticator Element checks
STA retains only Master Key
Walker/Cam-Winget; Intel/Atheros

9. Key Sharing Protocol STA AS AP
January 2002
Key Sharing Protocol
STA AP AS
AP-ID, STA-ID, NonceAP
EKAP(NonceAP, AP-ID, K, EKSTA(K, STA-ID))
EKSTA(K, STA-ID)
K = f(K), Association Key = g(K)
EK (NonceSTA)
EK (NonceSTA+1)
This is just the Needham-Shroeder protocol
Walker/Cam-Winget; Intel/Atheros

10. Example Reassociation Instantiation
January 2002
Example Reassociation Instantiation
STA AP AS
Reassociate Request (STA-ID)
AP-ID, STA-ID, NonceAP
EKAP(NonceAP, AP-ID, K, EKSTA(K, STA-ID))
Reassociate Response = EKSTA(K, STA-ID)
EAPOL Key = EK (NonceSTA)
EAPOL Key = EK (NonceSTA+1), EAssocKey(Nonce)
K = f(K), AssocKey = g(K)
Walker/Cam-Winget; Intel/Atheros

11. Comparison with IAPP “Fast Hand-off” (1)
January 2002
Comparison with IAPP “Fast Hand-off” (1)
Reduces # of catastrophic failure points from n to 1
STA + new AP have fresh, independent Association Key on every association v. Association Key derived from same keying material on every reassociation for IAPP
Protocol is live by construction v. not evident for IAPP “Fast Hand-off”
Explicit reauthentication v. don’t know if authentication works for IAPP fast hand-off
Explicit key verification v. implicit key verification for IAPP
Walker/Cam-Winget; Intel/Atheros

12. Comparison with IAPP “Fast Hand-off” (2)
January 2002
Comparison with IAPP “Fast Hand-off” (2)
IPsec not required v. IPsec required for IAPP Fast Hand-off
New AP could forward STA’s authenticator to Old AP in an appropriate request after Key Sharing Protocol completes, causing the Old STA to delete obsolete state
AS IPsec SA management suspicious
If AS IPsec SA management not used, decreases number of AP keys from n(n+1)/2 to n
On the other hand, if the AS supported its part of Key Sharing Protocol, this could be used between old AP and new AP to secure data exchange between them
Walker/Cam-Winget; Intel/Atheros

13. January 2002
Summary
IAPP has its proper functions, but TGi is distorting its architecture by moving keys between APs
More important, using IAPP for key transfer introduces a number of security problems
Simpler, more secure, more scalable architectures are feasible
TGf should not compromise its architecture to accommodate TGi
However, it must if TGi does not abandon this usage
If it doesn’t abandon this, TGi is still responsible for
Define Send Security Block and Move contents
Define how it wants these contents secured
Walker/Cam-Winget; Intel/Atheros

14. January 2002
Feedback?
Walker/Cam-Winget; Intel/Atheros