Suggested 802.11 Keying
Requirements
Jesse Walker
Intel Corporation
jesse.walker@intel.com
Jesse Walker, 802.11 keying requirements
1
Goal and agenda
• Goal:
– Help establish requirements for future
development
• Agenda
– Review of 802.11 Authentication and Keying
today
– Analysis
– Requirements
Jesse Walker, 802.11 keying requirements
2
802.11i Review
Authentication
and Keying Today
802.11i review
Station
Authentication
Server
Access
Point
Security capabilities
discovery
802.1X authentication
802.1X key management
RADIUS-based key
distribution
Data protection
Jesse Walker, 802.11 keying requirements
3
802.11i Review
Authentication
and Keying Today
802.11i review: 802.1X authentication
Wireless
Station
Authentication
Server
Access
Point
EAP Method (e.g., EAP-TLS)
EAP
802.1X (EAPOL)
EAP Transport (e.g. RADIUS)
802.11
TCP/UDP/IP
Jesse Walker, 802.11 keying requirements
4
802.11i Review
Authentication
and Keying Today
802.11i review: EAP authentication
STA
AP
AS
802.1X
(EAP-Request Identity)
802.1X
(EAP-Response Identity)
EAP Transport
(EAP-Response Identity)
EAP type specific
mutual authentication
Derive Pairwise Master Key (PMK)
Derive Pairwise Master Key (PMK)
EAP Transport
(EAP-Success, PMK)
802.1X (EAP-Success)
802.1X
RADIUS
Jesse Walker, 802.11 keying requirements
5
Problem
Analysis
Statement
Problem 1: Who is the other guy?
• STA never learns it is communicating with the AP
the AS is communicating with under EAP
– AP never advertises its authenticated identity to STA
– BSSID is the only identifier the AP exposes to the STA
• AP never learns it is communicating with the STA
the AS is communicating in under EAP
– STA never advertises its authenticated identity to AP
– STA MAC address is the only identifier the STA exposes
to the STA
• Although AP can peak inside the EAP-Response/Identity
• And the STA could use its MAC address to identify itself
• The gap is closed by faith
Jesse Walker, 802.11 keying requirements
6
Problem
Analysis
Statement
Problem 2: Inconsistent contract
• 802.11i goes to great trouble to prevent PMK
reuse across different APs
– Compromise of one AP must not compromise STA’s
traffic at another AP
– Only mechanism STA has to detect conformance is the
AP’s BSSID
• Modern switched APs present a dilemma
– PMK is kept at switch, so does not cross crypto
boundaries if reused at different APs belonging to same
switch
– But the STA has no way to distinguish this (correct)
usage from abuse at classical APs
• The PMK is not used consistently by
infrastructure and this is visible to the STA
Jesse Walker, 802.11 keying requirements
7
Problem
Analysis
Statement
Problem 3: Expiry time
• AAA protocols deliver the PMK
expiry time to the AP, but not the STA
• EAP doesn’t deliver PMK expiry time
to the AP, either
• PMK expiry a surprise to the STA, or
else
• STAs need more predictable PMK
usage to make caching work
Jesse Walker, 802.11 keying requirements
8
Problem
Analysis
Statement
Problem 4: Performance v. security
• Only mechanisms 802.11i defines to
populate PMK at AP are authentication
after association and pre-authentication
• Authentication after association too slow
for real-time applications
• Pre-authentication enables new DoS
attack
– A single STA can flood pre-authentication
requests to every AP
– In a sufficiently large network, a small number
of STAs can allocate all PMK caches at all APs
Jesse Walker, 802.11 keying requirements
9
802.11i
Analysis
Deployment Requirements
802.11i Keying abstractly
Goal: Establish session key K between STA and AP
Technique: Use on-line trusted 3rd party AS as an intermediary
Explicit Assumptions:
• STA and AS can mutually authenticate and derive a session key PMK
• AP and AS share a key encryption key KB1 and a data authentication
key KB2
• AS delivers a fresh PMK to the AP
AP
STA
EAP
Authentication +
Session Key PMK
derivation
A,{PMK}KB1,
MICKB2
AS
Jesse Walker, 802.11 keying requirements
10
802.11i
Analysis
Deployment Requirements
What can we do without?
• No mutual authentication enables MITM attack between STA, AS
• No end-to-end data authentication key enables MITM attack
between AP, AS
• No end-to-end key encryption key enables PMK theft
• PMK freshness still a matter of faith to the AP
AP
STA
STA,{PMK}KB1,
MIC KB2
EAP Authentication + AP/AS/STA
Session Key PMK
derivation
STA,{PMK}
KB1,
MICKB2
AS
Jesse Walker, 802.11 keying requirements
11
802.11i
Analysis
Deployment Requirements
802.11i Authentication concretely
Goal: Establish a session key PMK between STA and AP
Technique: Use an on-line trusted third party AS as an intermediary
Explicit Assumptions:
• STA and AS can mutually authenticate and derive a session key PMK
• AP and AS share a key encryption key KB1 and a data authentication
key KB2
• Note path via AP allows replay attacks against AP
STA
EAP Authentication +
Session Key PMK
derivation
AS
AP
STA,{PMK}KB1,
MICKB2
Jesse Walker, 802.11 keying requirements
12
802.11i Authentication
Requirements
Requirements
Design Hueristics
• Some prudent engineering practices for
cryptographic protocols (Abadi and
Needham, 1995)
– Use explicit communication: Every message
should say what it means
– Specify the semantics: The conditions for a
message to be acted upon should be spelled
out
– Name entities: If the identity of a principal is
essential to the meaning of the message,
include the name explicitly
– Make trust assumptions explicit: The protocol
designer should know which trust
assumptions and dependencies are necessary
Jesse Walker, 802.11 keying requirements
13
802.11i Authentication
Requirements
Requirements
802.11 keying requirements
• New Peer-NAS-Server key binding protocol
– Make keying explicit by client request instead of implicit
• Complement EAP but independent of EAP
– Allow the STA to request AAA-Key by name
– Piggyback keying messages with EAP messages
– Allow client to rekey the AP PMK cache without
reauthentication
• Use the existing AAA-Key
• Bind authenticated identities of STA and AP to the
AAA-Key
• Binding must provide freshness guarantee
– Allow the AP to determine response freshness
• Allow specification or negotiation of PMK expiry
time
Jesse Walker, 802.11 keying requirements
14
802.11i Authentication
Requirements
Requirements
Rationale
•
Explicit Peer-NAS-Server key binding protocol
– Address open problems before they are exploited
•
Complement EAP but independent of EAP
– Key binding is a 3-party problem, while EAP is a 2-party problem
– Piggy-backing messages with EAP allows client to request key during
EAP authentication
– Protocol independent of EAP allows client to rekey AP PMK cache
without reauthenticating
•
Use the existing AAA-Key
– Keying draft consensus has been hard enough
•
Bind authenticated identities of STA and AP to the AAA-Key
– This is all the AS knows
– The AS is the only party that both the STA and AP trust, so it must do
the binding
•
Binding must provide freshness guarantee
– AP needs to know message delivering PMK is fresh
•
Allow specification or negotiation of PMK expiry time
– Make PMK cache usage consistent to the STA
Jesse Walker, 802.11 keying requirements
15
Requirements
Example protocol
Peer
NAS
Server
Peer generates random number RP
RP || AAA-Key-ID
NAS generates random number RN
RP || AAA-Key-ID || RN
Server computes  = AAA-Key-ID || IdP || IdNAS || T ||
MAC(TEKP, RP || AAA-Key-ID || IdP || IdNAS || T)
Server encrypts W = E(KEK, AAA-Key)
Server computes  =  || W || AAA-Key-ID || IdP || IdNAS || T
|| MAC(KAK, RN ||  || W || AAA-Key-ID || IdP || IdNAS || T)
 || 

Jesse Walker, 802.11 keying requirements
16
802.11i Authentication
Requirements
Requirements
How would 802.11 use this?
• 802.11 must advertise the AP’s identity to the STA
– Or the binding is not meaningful to the STA
– e.g., insert hash of AP’s authenticated identity into Beacons,
Probe Responses, and/or Reassociation Response msgs
• Must advertise STA’s identity to the AP
– Or the binding is not meaningful to the AP
– e.g., insert hash of STA’s identity into Reassociation Requests
• AP, STA both verify bound identity matches advertised
identity
• 802.11i key derivation modified to include bound identities
in the PTK derivation
• AP cache timeout rules somehow conveyed to the STA
Jesse Walker, 802.11 keying requirements
17
802.11i Authentication
Requirements
Requirements
Does this solve anything?
• These changes identify AP to STA and vice versa
– Both parties trust AS to attest to the identity of the other
– Both parties advertise their authenticated identities
– Problem 1 solved
• Key usage identified by device’s crypto boundary,
not by MAC addresses
– Changes impose a consistent “contract” between AP
and STA
– Problem 2 solved
• Both STA and AP learn the PMK expiry time
– Enables 802.11 to solve Problem 3
• STA can efficiently fill the AP’s PMK cache
without reauthentication and before AP-to-AP
transition
– Problem 4 solved
Jesse Walker, 802.11 keying requirements
18
Call to Action
• Key distribution enjoys a “troubled history”
– Bellare and Rogaway, “Provably secure session key
distribution: the three party case,” Proc 27th Symp on
Theory of Computing, 1995
• Existing design has vulnerabilities that can be
exploited
• There is no reason to believe we can avoid
consequences of these vulnerabilities any better
than prior protocols solving the 3-party problems
– Wide-Mouth Frog, Denning-Sacco, Woo-Lam, LuSundareshan, etc.
• Work to solve the problem
Jesse Walker, 802.11 keying requirements
19
Feedback?
Jesse Walker, 802.11 keying requirements
20