October 2004

Aboba and HarkinsSlide 1

doc.: IEEE 802.11-04/1186r0

Submission

PEKM(Post-EAP Key Management Protocol)

Bernard Aboba, Microsoft

<bernarda@microsoft.com>

Dan Harkins, Trapeze Networks

<dharkins@trpz.com>

October 2004

Aboba and HarkinsSlide 2

doc.: IEEE 802.11-04/1186r0

Submission

Principles of EAP Key Management• Parties

– EAP peer & authenticator/NAS may have one or more ports• EAP peer may have multiple interfaces• An EAP authenticator may have multiple ports

– A dialup NAS may have multiple ports/phone lines– A wireless NAS may be comprised of multiple Access Points/BSSIDs

• Key management– EAP methods export MSK, EMSK– AAA-Key derived on the EAP peer and server, transported to the NAS– Transient Session Keys (TSKs) derived from the AAA-Key– AAA-Key, TSK lifetimes determined by the authenticator, on advice from the

AAA server• Session-Timeout attribute denotes maximum lifetime while the PMK is in use (e.g.

time to reauthentication or PMK re-key)• Session-Timeout does not describe the lifetime of the PMK prior to use (e.g. pre-

authentication PMK lifetime)• No attribute available to determine the PTK/GTK lifetime (e.g. time to session re-key)

– Key lifetimes communicated by the AP to the peer via the lower layer

October 2004

Aboba and HarkinsSlide 3

doc.: IEEE 802.11-04/1186r0

Submission

PEKM Principles• Endpoints are the EAP Peer and Authenticator

– An EAP authenticator may consist of multiple Access Points– Result of the PEKM exchange is binding of PTK to station MAC and AP BSSID addresses.

• Media Independence– PEKM frames can be encapsulated over multiple lower layers:

• 802.11 data and management frames• Other IEEE 802 technologies: 802.16, 802.3, etc.

• Security– Compatible with the Housley Criteria (IETF 56)

• Algorithm negotiation• Key naming • No cascading vulnerabilities (no key sharing between authenticators)• Compatible with EAP Channel Binding

– Addresses known 802.11i issues• First message protection• Explicit Key Install/Delete operations• Defined Key Scope• Explicit Key lifetime negotiation (PMK, PTK)• Group Key Symmetry (IBSS)• Management frame protection• State machine consistency (e.g. “Link Up” same in PEKM and 802.11-2003)

October 2004

Aboba and HarkinsSlide 4

doc.: IEEE 802.11-04/1186r0

Submission

PEKM Features• Station initiated exchange

– Occurs prior to Association/Reassociation

• Low Latency– Three message exchange– First two messages off the critical path (e.g. STA can pre-key

to new AP while associated to an existing AP)

• Compatible with IETF RFCs and work-in-progress– Not dependent on proprietary backend solutions– Key distribution based on RFC 3576 (Dynamic

Authorization), RFC 3579 (RADIUS/EAP)– Key hierarchy based on EAP Key Management Framework

(draft-ietf-eap-keying)

October 2004

Aboba and HarkinsSlide 5

doc.: IEEE 802.11-04/1186r0

Submission

Discovery & EAP Overview• Discovery phase

– PEKM, “NAS-Identifier” IEs included by AP in the Beacon/Probe Response

– PEKM IE identifies the AP as PEKM-capable, indicates capabilities

– NAS-Identifier IE identifies the Authenticator• An Authenticator can be comprised of multiple BSSIDs/AP

• Key cache is shared by all ports/BSSIDs within an Authenticator

• EAP authentication/AAA– EAP peer only initiates EAP with authenticator within whom it does

not share a PMK cache entry

– NAS-Identifier attribute sent by AAA client to AAA server

– NAS-Identifier IE sent by AP to the STA

– Result: Authenticator, EAP peer, AAA server all know NAS-Identifier attribute, can verify agreement via EAP Channel Bindings

October 2004

Aboba and HarkinsSlide 6

doc.: IEEE 802.11-04/1186r0

Submission

PEKM: Parties & Identifiers

STAsAPs

Authenticator/

AAA Client

EAP

PeerEAP/AAA

Server

Access-Request/{EAP-Message, User-NameNAS-Identifier}

Access-Accept/AAA-Key

Beacon/Probe ResponseNAS-Identifier IE

EAP

PEKM

October 2004

Aboba and HarkinsSlide 7

doc.: IEEE 802.11-04/1186r0

Submission

PEKM Overview• Functionality

– PTK derivation, GTK transport (AP->STA in ESS, symmetric for IBSS)

– Key scope identification (via NAS-Identifier)– Key Lifetime negotiation (PMK, PTK)– Capabilities negotiation (not just cryptographic algorithms)– Secure Association/Re-association messages

• Messages– PEKM Pre-Key

• PEKM Message 1: “PTK-Request”, encapsulated in 802.1X EAPOL-Key• PEKM Message 2: “PTK-Response”, encapsulated in 802.1X EAPOL-Key

– PEKM Management Frame Protection• Association/Reassociation

– PEKM Message 3 (“PTK Install”) embedded within Association/Reassociation• PEKM Deauthenticate

– PEKM “PMK Delete” operation embedded in Deauthenticate • PEKM Disassociate

– PEKM “PTK Delete” operation embedded in Disassociate

October 2004

Aboba and HarkinsSlide 8

doc.: IEEE 802.11-04/1186r0

Submission

PEKM Exchange

Supplicant Authenticator

Key (PMK), SNonce, ANonce Known Key (PMK) is Known

Derive PTK,Generate GTK

Install PTK and GTK

Install PTK and GTK

Message 1: EAPOL-Key(PTK-Derivation-Request)

Message 2: EAPOL-Key(PTK-Derivation-Response)

Message 3: Reassociation-Request(Install PTK & GTK, Unicast, MIC)

Message 4: Reassociation-Response(Unicast, MIC)

Derive PTK,Generate GTK (IBSS)

October 2004

Aboba and HarkinsSlide 9

doc.: IEEE 802.11-04/1186r0

Submission

Details of PEKM Messages• Message 1 (PTK-Derivation-Request):

– {peer-id, nas-identifier, sta_mac, ap_bssid, snonce, anonce, ptk_lifetime_desired, pmk_lifetime_desired, [, encrypted GTK], capabilities}, {PMKID-1, MIC(PTK-1-KCK, peer-id to capabilities)}, {PMKID-2, MIC(PTK-2-KCK, peer-id to capabilities)}

• Message 2 (PTK-Derivation-Response):– {peer-id, nas-identifier, sta_mac, ap_bssid, anonce, snonce,

Enc(PTK-X-KEK, GTK), ptk_lifetime, pmk_lifetime, capabilities}, {PMKID-X, MIC(PTK-X-KCK, peer-id to capabilities)}

where X identifies the PMKID chosen from message 1.• Message 3 (PTK-Install-Request, in Association/Reassociation-Request)

– {MIC(PTK-X-KCK, peer-id to capabilities, Reassociation-Request)}• Message 4 (PTK-Install-Request, in Association/Reassociation-Response)

– {MIC(PTK-X-KCK, peer-id to capabilities, Reassociation-Request)}

October 2004

Aboba and HarkinsSlide 10

doc.: IEEE 802.11-04/1186r0

Submission

PEKM Frame Format

Next Payload | MjVer | MnVer | OpCode | Flags

Message ID | Length

Attributes

OpCodePTK-RequestPTK-ResponsePTK-Install-RequestPTK-Install-ResponsePTK-Delete-RequestPMK-Delete-Request

AttributesSNonceANoncePeer-IdNAS-IdSTA_MACAP_BSSIDPTK_LifetimePMK_LifetimeGTKMICCapabilitiesPMKID

October 2004

Aboba and HarkinsSlide 11

doc.: IEEE 802.11-04/1186r0

Submission

State 1Unauthenticated,

Unassociated

State 2Authenticated, Unassociated

State 3Authenticated, and

Associated

EAP PMK Install

PEKM

“PTK Install”

(In Reassociate)

PEKM “PTK Delete” (In Disassociate)

PEKM “PMK Delete”

(In Deauthenticate)

PEKM

“PTK/PMK

Delete”

(In Deauthenticate)

Class 1 Frames

Class 1 & 2 Frames

Class 1, 2 & 3 Frames

State Machine

October 2004

Aboba and HarkinsSlide 12

doc.: IEEE 802.11-04/1186r0

Submission

“Make Before Break”• PEKM operations can be encapsulated within Data or Management

Frames• In order to enable PEKM-based management frame protection

(Association/Reassociation, Deauthentication, Disassociation), need to be able to derive PTKs in any State: need “make before break”

• Data Frames– Sent in State 3: STA is authenticated, associated to an AP. PEKM frames

can be sent over the DS to pre-establish PTK state. – Sent in State 1: STA is unauthenticated, unassociated. 802.1X frames

(EAP + PEKM) sent over the WM with From DS, To DS = 0.• Requirement

– Support for 802.1X Class 1 data frames in ESS• Potential alternative: In state 1, Encapsulation of EAP/PEKM within

Authentication frames

October 2004

Aboba and HarkinsSlide 13

doc.: IEEE 802.11-04/1186r0

Submission

PEKM Summary• Clean, simple architecture

– Authentication prior to Association– Full compliance with 802.11-2003 state machine

• Emphasis on correct operation– State machine consistency– Elimination of Race conditions– Endpoint naming– Explicit key install/delete operations– Compatibility with EAP Channel Binding

• Low latency– Two roundtrips: Only Reassociation Request/Response in critical path– Key lifetime negotiation, Key Scope Discovery minimize key cache

misses• Consistent with existing key establishment approaches

– Pre-authentication– RADIUS/EAP and Diameter/EAP key transport

October 2004

Aboba and HarkinsSlide 14

doc.: IEEE 802.11-04/1186r0

Submission

Discussion