doc.: IEEE /1186r0 Submission October 2004 Aboba and HarkinsSlide 1 PEKM (Post-EAP Key Management Protocol) Bernard Aboba, Microsoft Dan Harkins, Trapeze Networks

doc.: IEEE /1186r0 Submission October 2004 Aboba and HarkinsSlide 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

doc.: IEEE /1186r0 Submission October 2004 Aboba and HarkinsSlide 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: data and management frames Other IEEE 802 technologies: , 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 i 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 )

doc.: IEEE /1186r0 Submission October 2004 Aboba and HarkinsSlide 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)

doc.: IEEE /1186r0 Submission October 2004 Aboba and HarkinsSlide 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

doc.: IEEE /1186r0 Submission October 2004 Aboba and HarkinsSlide 6 PEKM: Parties & Identifiers STAs APs Authenticator/ AAA Client EAP Peer EAP/AAA Server Access-Request/ {EAP-Message, User-Name NAS-Identifier} Access-Accept/ AAA-Key Beacon/Probe Response NAS-Identifier IE EAP PEKM

doc.: IEEE /1186r0 Submission October 2004 Aboba and HarkinsSlide 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

doc.: IEEE /1186r0 Submission October 2004 Aboba and HarkinsSlide 8 PEKM Exchange Supplicant Authenticator Key (PMK), SNonce, ANonce Known Key (PMK) is Known Derive PTK, Generate 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)

doc.: IEEE /1186r0 Submission October 2004 Aboba and HarkinsSlide 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)}

doc.: IEEE /1186r0 Submission October 2004 Aboba and HarkinsSlide 10 PEKM Frame Format Next Payload | MjVer | MnVer | OpCode | Flags Message ID | Length Attributes 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

doc.: IEEE /1186r0 Submission October 2004 Aboba and HarkinsSlide 11 State 1 Unauthenticated, Unassociated State 2 Authenticated, Unassociated State 3 Authenticated, 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

doc.: IEEE /1186r0 Submission October 2004 Aboba and HarkinsSlide 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 X 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

doc.: IEEE /1186r0 Submission October 2004 Aboba and HarkinsSlide 13 PEKM Summary Clean, simple architecture –Authentication prior to Association –Full compliance with 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

doc.: IEEE /1186r0 Submission October 2004 Aboba and HarkinsSlide 14 Discussion