PEKM (Post-EAP Key Management Protocol)

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

2. Principles of EAP • Two 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 as PMK • Transient Session Keys (TSKs) derived from the PMK/AAA-Key • AAA-Key, TSK lifetimes determined by the authenticator, on advice from the AAA server • PMK/AAA-Key deleted by AAA server after transmission • Session-Timeout attribute denotes maximum session time prior to reauthentication/AAA-Key rekey • Maximum AAA-Key lifetime on the authenticator while in use • Missing attributes • Lifetime of the PMK/AAA-Key prior to use (pre-authentication lifetime) • Lifetime of the PTK/GTK Harkins and Aboba

3. Principles of PEKM • Endpoints are the EAP peer and authenticator • PEKM is a two-party protocol (AAA server not involved) • An EAP authenticator may include multiple Access Points (BSSIDs) • Flexible binding • Result of the PEKM exchange is binding of the PTK to specific STA MAC and AP BSSID addresses • Binding can be to MAC addresses other than those in the source and destination fields of the PEKM frames • Integrated security/capabilities negotiation • Cryptographic algorithm negotiation • Extensible capabilities negotiation via TLVs enables simultaneous secure confirmation of all required capabilities (QoS, rates, etc.) • 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. • PEKM implementation can be reused on devices implementing multiple media for lower footprint • No need to completely reinvent the wheel for 802.11, 802.16, 802.3, etc. • Security • Compatible with the Housley Criteria (IETF 56) • Key naming • No cascading vulnerabilities (no key sharing between Authenticators) • Compatible with EAP Channel Binding Harkins and Aboba

4. PEKM Features • Station initiated exchange of 4 messages • First two messages: PTK derivation + capabilities negotiation • Third and fourth messages: PTK/GTK installation + capability confirmation • Compatible with IETF RFCs and work-in-progress • Not dependent on proprietary backend solutions, no change to backend necessary • No additional parties required • Compatible with existing AAA specifications • RADIUS: RFC 3576 (Dynamic Authorization), RFC 3579 (RADIUS/EAP), RFC 2548 • Diameter: RFC 3588, Diameter EAP • Key hierarchy based on EAP Key Management Framework (draft-ietf-eap-keying) Harkins and Aboba

5. 802.11i Issues Addressed by PEKM • Latency: 6-way exchange (4-way handshake + Assoc/Reassoc) • PEKM: first two messages are derivation/pre-key, only last two messages (Association/Reassociation) in the critical path • First message attacks • PEKM: First message protection– message verified before state created • Undefined key scope • PEKM: Key scope advertised in Beacon/Probe Response, confirmed in PEKM negotiation, explicit binding step • Lack of PMK/PTK lifetime negotiation • PEKM: Explicit Key lifetime negotiation (PMK, PTK) • Bi-directional exchanges required in IBSS • PEKM: support for symmetric Group Key exchange in IBSS • Denial of service attacks via forged management frames • PEKM: State machine consistency (e.g. “Link Up” same in PEKM and 802.11-2003) • PEKM: explicit and authenticated key install/delete operations encapsulated in management frames Harkins and Aboba

6. Discovery & EAP Overview • Discovery phase • PEKM IE identifies the AP as PEKM-capable, indicates capabilities • NAS-Identifier IE included in the Beacon/Probe Response identifies the authenticator/key scope • 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 (802.1x supplicant) only initiates EAP with an authenticator with whom it does not share a PMK cache entry • NAS-Identifier IE identical to NAS-Identifier attribute in AAA Request • Enables verification via EAP channel binding Harkins and Aboba

7. PEKM: Parties & Identifiers & Handshakes APs Beacon/Probe Response PEKM IE with NAS-Id PTK Access-Request/ {EAP-Message, User-Name NAS-Identifier} PMK EAP 4way HS PEKM Access-Accept/ AAA-Key EAP/AAA Server EAP Peer PTK Beacon/Probe Response PEKM IE with NAS-Id Authenticator/ AAA Client Harkins and Aboba

8. 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 • Cryptographic algorithms • 802.11 capabilities • Other capability IEs (QoS, etc.) • Secure Association/Reassociation/Disassociate/Deauthenticate messages • Messages • PEKM Pre-Key • PEKM Message 1: “PEKM-Init-Request”, 802.11 authentication or 802.1X EAPOL Key • PEKM Message 2: “PEKM-Init-Response”, 802.11 authentication or 802.1X EAPOL Key • PEKM Management Frame Protection • Association/Reassociation • PEKM Message 3 (“PEKM-Confirm-Request”) embedded within Association/Reassociation Request • PEKM Message 4 (“PEKM-Confirm-Response”) embedded within Association/Reassociation Response • Deauthenticate • “PEKM-Control” operation embedded in Deauthenticate • Disassociate • “PEKM-Control” operation embedded in Disassociate Harkins and Aboba

9. PEKM Exchange Supplicant Authenticator Key (PMK), SNonce, ANonce Known Key (PMK) is Known Derive PTK, Generate GTK (IBSS) Message 1: 802.11 authenticate (PEKM-Init) Request Derive PTK, Generate GTK Message 2: 802.11 authenticate (PEKM-Init) Response Message 3: Association/Reassociation (PEKM-Confirm) Request Message 4: Association/Reassociation (PEKM-Confirm) Response Install PTK and GTK Install PTK and GTK Harkins and Aboba

10. PEKM Scenarios • Straight through • PEKM-Init exchanged followed by PEKM-Confirm • PTK Pre-Key • PEKM-Init exchange used to confirm initial capabilities, establish a cached PTK • Negotiated PMK, PTK lifetimes need to be acceptable to the AP • Can run multiple pre-key exchanges with the same authenticator, establish PTKs with multiple BSSIDs • Reassociation and key install exchange completed later (PEKM-Confirm exchange) • Capabilities exchange needed here too, to confirm continued availability where capabilities can change (e.g. QoS) Harkins and Aboba

11. Details of PEKM Messages • PEKM-Init-Request: • {peer-id, nas-identifier, sta_mac, ap_bssid, snonce, ptk_lifetime_desired, pmk_lifetime_desired, [, encrypted GTK], capabilities}, {PMKID-1, anonce-1, MIC(PTK-1-KCK, peer-id to capabilities)} [,{PMKID-2, anonce-2, MIC(PTK-2-KCK, peer-id to capabilities)}] • PEKM-Init-Response • {peer-id, nas-identifier, sta_mac, ap_bssid, snonce,Enc(PTK-X-KEK, GTK), ptk_lifetime, pmk_lifetime, capabilities}, {PMKID-X, anonce-X, MIC(PTK-X-KCK, peer-id to capabilities)}where X identifies the PMKID chosen from message 1. • PEKM-Confirm-Request, within Association/Reassociation-Request • {MIC(PTK-X-KCK, peer-id to capabilities, Reassociation-Request)} • PEKM-Confirm-Response, within Association/Reassociation-Response • {MIC(PTK-X-KCK, peer-id to capabilities, Reassociation-Response)} Harkins and Aboba

12. State Machine State 1Unauthenticated, Unassociated Class 1 Frames PEKM-Control “PTK/PMK Delete” (In Deauthenticate) PEKM-Control “PTK delete” (In Deauthenticate) PEKM-Init (in authenticate) State 2Authenticated, Unassociated Class 1 & 2 Frames PEKM-Confirm (in Association/Reassociation) PEKM-Control “PTK Deinstall” (In Disassociate) State 3Authenticated, and Associated Class 1, 2 & 3 Frames Harkins and Aboba

13. “Make Before Break” • PEKM operations are encapsulated within Data or Management Frames • Data Frames • State 3: STA is authenticated, associated. • PEKM-Init-Request/Response frames sent within 802.1X EAPOL-Key messages • Pre-Key: PTK-Confirm-Request/Response frames can be sent over the DS to pre-establish PTK state. Useful in verifying capabilities without going off channel. • State 1: STA is unauthenticated, unassociated • PEKM frames sent over the WM with From DS, To DS = 0 in IBSS • PEKM frames sent over the WM encapsulated in Authentication frames (ESS) • Management Frames • Association/Reassociation, Disassociate, Deauthenticate • To enable encapsulation of PEKM frames in *all* management frames, need to be able to derive PTKs in any state • Transport for PEKM PTK-Request/Response frames needed in State 1 • Possibilities • Support for Class 1 data frames in ESS (802.1X) • Encapsulation of PEKM within 802.11 Authentication frames Harkins and Aboba

14. PEKM Summary • Clean, simple architecture • Authentication prior to Association • Compatible with 802.11-2003 state machine • No dependency on new work being done elsewhere • 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 • Pre-key support (one roundtrip) enables establishment of PTK prior to association • Only Assoc/Reassociation exchange in the critical path, single round-trip • 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 • No new key hierarchies necessary • Security benefits • Management frame protection (Association/Reassociation, Disassociate, Deauthenticate) • DoS vulnerability reduction: first message attack Harkins and Aboba

15. Discussion? Harkins and Aboba