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

December 2004 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

Principles of PEKM Endpoints are the EAP peer and authenticator December 2004 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

PEKM Features Station initiated exchange of 4 messages December 2004 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

802.11i Issues Addressed by PEKM December 2004 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

Discovery & EAP Overview December 2004 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

PEKM: Parties & Identifiers & Handshakes December 2004 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

PEKM Overview Functionality Messages December 2004 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

PEKM Exchange Authenticator Supplicant December 2004 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

PEKM Scenarios Straight through PTK Pre-Key December 2004 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

Details of PEKM Messages December 2004 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

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

December 2004 “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

PEKM Summary Clean, simple architecture Emphasis on correct operation December 2004 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

December 2004 Discussion? Harkins and Aboba