May 2004
doc.: IEEE 802.11-04/0476r2
Pre-Keying
Jesse Walker and Emily Qi
Intel Corporation
Submission
Slide 1
Jesse Walker and Emily Qi, Intel Corporation
May 2004
doc.: IEEE 802.11-04/0476r2
Agenda
•
•
•
•
•
•
•
Problem Statement
Design Goals
Pre-Keying
Usage
Open Issues
Q&A
Straw Poll
Submission
Slide 2
Jesse Walker and Emily Qi, Intel Corporation
May 2004
doc.: IEEE 802.11-04/0476r2
Problem Statement
• 802.11r seeks to optimize STA transition time from
one AP to another
– VoIP requires << 50 msec 802.11 transition times,
including 802.11 security setup
– 802.11i perceived as too expensive by many market
segments
• 802.11k messages require protection prior to STA
transitioning from one AP to another
– 802.11k measurement frames may be used before
association
– 802.11i keys not available until after association
• Protection for Reassociation frames is desirable, too
Submission
Slide 3
Jesse Walker and Emily Qi, Intel Corporation
May 2004
doc.: IEEE 802.11-04/0476r2
Design Goals
• Make 802.11i keys available before association
– “Make before break” architecture
• Reuse 802.11i framework to make keys available
– Do not redesign 802.11i infrastructure
– Minimize amount of new invention
• Use an already proven, well-reviewed scheme
Submission
Slide 4
Jesse Walker and Emily Qi, Intel Corporation
May 2004
doc.: IEEE 802.11-04/0476r2
Pre-keying Overview
• Reuse the 802.11i Pre-authentication mechanism for keying
– 802.11i 4-Way Handshake messages are encoded in 802.1X frames
– Pre-authentication mechanism can be used to forward 802.1X frames
between a STA and a new AP via an AP already associated with the STA
• Introduce two new 802.11i messages:
– Pre-Keying Request, sent from STA to targeted AP to request pre-keying
• Identifies STA MAC Address, PMKID of PMK to use
– Pre-Keying Reject, send from targeted AP to STA if request cannot be
honored
– AP may respond to Pre-Keying Request by initiating a 4-Way Handshake
over the pre-authentication channel
• Introduce PTK caching
– 4-Way Handshake via the Pre-authentication channel populates the PTKSA
cache
– Inactive PTKSAs are timed out
• Move security policy agreement from Association to 4-Way Handshake
– Add PTKSA cache timeout value to RSN IE sent AP  STA
Submission
Slide 5
Jesse Walker and Emily Qi, Intel Corporation
May 2004
doc.: IEEE 802.11-04/0476r2
Ingredients: Pre-Authentication
Channel
STA
AP 1
802.lX over 802.11
802.lX over DS
•All frames use 802.11 Pre-authentication Ethertype (0F-AC)
instead of 802.1X Ethertype (88-8E)
•All frames are 802.1X frames
AP 2
•STA  AP 2 Frames have Src Addr = STA’s MAC address,
Dest Addr = AP 2’s BSSID
•AP 2  STA have Src Addr = AP 2’s BSSID, Dest Addr =
STA’s MAC address
Submission
Slide 6
Jesse Walker and Emily Qi, Intel Corporation
May 2004
doc.: IEEE 802.11-04/0476r2
Ingredients: PMK Caching
STA
AP
STA
PMK
Cache
AP
PMK
Cache
AP’s BSSID, PMKID,
PMK
STA’s MAC Addr,
PMKID, PMK
STA2’s MAC Addr,
PMKID, PMK
AP2’s BSSID, PMKID,
PMK
If a STA and AP share a cached PMK, they needn’t reauthenticate
Submission
Slide 7
Jesse Walker and Emily Qi, Intel Corporation
May 2004
doc.: IEEE 802.11-04/0476r2
Ingredients: 4-Way Handshake
STA
AP
PMK
PMK
Pick Random ANonce
EAPOL-Key(ANonce)
Pick Random SNonce, Derive PTK = EAPOL-PRF(PMK, ANonce |
SNonce | AP MAC Addr | STA MAC Addr)
EAPOL-Key(Unicast, SNonce, MIC, STA RSN IE)
Derive PTK
EAPOL-Key(ANonce, MIC, AP RSN IE, GTK)
EAPOL-Key(MIC)
Install TK, GTK
Submission
Install TK, GTK
Slide 8
Jesse Walker and Emily Qi, Intel Corporation
May 2004
doc.: IEEE 802.11-04/0476r2
Some Observations
• 802.11i 4-Way Handshake messages are encoded
as 802.1X messages
– So could be forwarded over pre-authentication channel
by simply changing the Ethertype
– 802.11i does not define how to send 4-Way Handshake
messages over the Pre-authentication
– But it does not preclude this, either
• 802.11i implicitly ties PTK to association
– But not explicitly: still works for IBSS case
• 802.11i 4-Way Handshake is self-protecting
– Security unaffected by the message path
Submission
Slide 9
Jesse Walker and Emily Qi, Intel Corporation
May 2004
doc.: IEEE 802.11-04/0476r2
What’s Missing from 802.11i?
•
Minor change to Key Management state machines required to support prekeying
– 4-Way Handshake, Group Key Handshake messages may be encapsulated using the
Pre-authentication Ethertype
– Change state machines to track whether keying messages exchanged over normal
or over pre-authentication channel
•
STA needs a Request message to kick-start AP
– Must identify the STA and the PMK used
•
STA needs feedback if AP does not have the required PMK
– This can’t be secured so is only a hint
•
PTK rules need slight tinkering to permit pre-keying without association
– APs should not cache PTKs forever
– PTKs can’t be used across associations
•
RSN IE changes
– STA needs feedback Re: PTK timeout
– STA and AP have to negotiate security policy in 4-Way Handshake instead of
Reassociate
– Need to advertise support for pre-keying
Submission
Slide 10
Jesse Walker and Emily Qi, Intel Corporation
May 2004
doc.: IEEE 802.11-04/0476r2
Usage
• On first contact, STA uses existing 802.11i
– Discovery  Open System Authentication  Association  802.1X
authentication  4-Way Handshake  Data exchange
• After 4-Way Handshake completes STA may use pre-keying if
desired to optimize AP-to-AP transition
– Discovery  Pre-key  Reassociate  Data exchange
• If desired, STA may use pre-keyed TK to protect other
management messages prior to association
– 802.11k Protected Action Frames
• If keys are in place prior to AP-to-AP transition, then they can
be used to protect Reassociation
– Protection of Disassociation, Deauthentication becomes meaningful
Submission
Slide 11
Jesse Walker and Emily Qi, Intel Corporation
May 2004
doc.: IEEE 802.11-04/0476r2
Open Issues
• Identify modifications needed to 802.1X state machines to support prekeying?
• Prevent same PTK being used across two associations
– PTK reuse across association breaks replay protection mechanism
• What if STA transitions to the new AP before pre-keying completes?
• What if STA transitions to a different AP before pre-keying completes?
• How to handle GTK updates?
– The AP can send GTK updates over the pre-authentication channel if the STA
is not associated
– But what to do is STA moves? Security associations are stateful
• What to with pre-key request from an “already associated” STA?
• Other information that can be transferred over the pre-authentication
channel?
Submission
Slide 12
Jesse Walker and Emily Qi, Intel Corporation
May 2004
doc.: IEEE 802.11-04/0476r2
Q&A
• Where do the cached PMKs come from?
– Out of Scope. These can be provisioned by, e.g., pre-authentication,
some IETF/IRTF “standard” back-end protocol, e.g. proactive keying,
or by a proprietary key provisioning scheme, e.g., Cisco’s
• What about subnet boundary crossing?
– Out of Scope. Since it is based on the pre-authentication channel, it is a
LAN-only solution.
• Why not use some other channel?
– We know of no other candidates.
• Why reuse the 4-Way Handshake?
– We don’t want to invent a new protocol. Getting a key establishment
scheme right is hard.
Submission
Slide 13
Jesse Walker and Emily Qi, Intel Corporation
May 2004
doc.: IEEE 802.11-04/0476r2
Feedback?
Submission
Slide 14
Jesse Walker and Emily Qi, Intel Corporation