PEKM (Post-EAP Key Management Protocol)

1. PEKM(Post-EAP Key Management Protocol) Bernard Aboba, Microsoft <bernarda@microsoft.com> Dan Harkins, Trapeze Networks <dharkins@trpz.com> Aboba and Harkins

2. 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 Aboba and Harkins

3. 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) Aboba and Harkins

4. 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) Aboba and Harkins

5. 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 Aboba and Harkins

6. STAs PEKM: Parties & Identifiers Beacon/Probe Response NAS-Identifier IE APs Access-Request/ {EAP-Message, User-Name NAS-Identifier} EAP EAP Peer PEKM Access-Accept/ AAA-Key EAP/AAA Server Authenticator/ AAA Client Aboba and Harkins

7. 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 Aboba and Harkins

8. PEKM Exchange Supplicant Authenticator Key (PMK), SNonce, ANonce Known Key (PMK) is Known Derive PTK, Generate GTK (IBSS) Message 1: EAPOL-Key(PTK-Derivation-Request) Derive PTK, Generate GTK Message 2: EAPOL-Key(PTK-Derivation-Response) Message 3: Reassociation-Request(Install PTK & GTK, Unicast, MIC) Message 4: Reassociation-Response(Unicast, MIC) Install PTK and GTK Install PTK and GTK Aboba and Harkins

9. 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)} Aboba and Harkins

10. PEKM Frame Format OpCode PTK-Request PTK-Response PTK-Install-Request PTK-Install-Response PTK-Delete-Request PMK-Delete-Request Attributes SNonce ANonce Peer-Id NAS-Id STA_MAC AP_BSSID PTK_Lifetime PMK_Lifetime GTK MIC Capabilities PMKID Aboba and Harkins

11. State Machine State 1Unauthenticated, Unassociated Class 1 Frames PEKM “PMK Delete” (In Deauthenticate) PEKM “PTK/PMK Delete” (In Deauthenticate) EAP PMK Install State 2Authenticated, Unassociated Class 1 & 2 Frames PEKM “PTK Install” (In Reassociate) PEKM “PTK Delete” (In Disassociate) State 3Authenticated, and Associated Class 1, 2 & 3 Frames Aboba and Harkins

12. “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 Aboba and Harkins

13. 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 Aboba and Harkins

14. Discussion Aboba and Harkins