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

doc.: IEEE /1572r0 Submission December 2004 Harkins and AbobaSlide 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 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 AAA-Key prior to use (pre-authentication lifetime) –Lifetime of the PTK/GTK –Key lifetimes communicated by the AP to the peer via the lower layer

doc.: IEEE /1572r0 Submission December 2004 Harkins and AbobaSlide 3 PEKM Principles 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: data and management frames Other IEEE 802 technologies: , 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.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

doc.: IEEE /1572r0 Submission December 2004 Harkins and AbobaSlide 4 PEKM Features Station initiated exchange –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 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)

doc.: IEEE /1572r0 Submission December 2004 Harkins and AbobaSlide i 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 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 ) –PEKM: explicit key install/delete operations encapsulated in management frames

doc.: IEEE /1572r0 Submission December 2004 Harkins and AbobaSlide 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 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

doc.: IEEE /1572r0 Submission December 2004 Harkins and AbobaSlide 7 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 /1572r0 Submission December 2004 Harkins and AbobaSlide 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 capabilities Other capability IEs (QoS, etc.) –Secure Association/Reassociation/Disassociate/Deauthenticate messages Messages –PEKM Pre-Key PEKM Message 1: “PEKM-Init-Request”, encapsulated in 802.1X EAPOL-Key PEKM Message 2: “PEKM-Init-Response”, encapsulated in 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

doc.: IEEE /1572r0 Submission December 2004 Harkins and AbobaSlide 9 PEKM Exchange Supplicant Key (PMK), SNonce, ANonce Known Key (PMK) is Known Derive PTK, Generate GTK Install PTK and GTK Message 1: EAPOL-Key(PEKM-Init-Request) Message 2: EAPOL-Key(PEKM-Init-Response) Message 3: Association/Reassociation-Request(PEKM-Confirm-Request) Message 4: Association/Reassociation-Response(PEKM-Confirm-Response) Derive PTK, Generate GTK (IBSS) Authenticator

doc.: IEEE /1572r0 Submission December 2004 Harkins and AbobaSlide 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)

doc.: IEEE /1572r0 Submission December 2004 Harkins and AbobaSlide 11 Details of PEKM Messages PEKM-Init-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)} PEKM-Init-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. PEKM-Confirm-Request, within Association/Reassociation-Request –{MIC(PTK-X-KCK, peer-id to capabilities, Reassociation-Request)} PEKM-Confirm-Response, within in Association/Reassociation- Response –{MIC(PTK-X-KCK, peer-id to capabilities, Reassociation-Response)}

doc.: IEEE /1572r0 Submission December 2004 Harkins and AbobaSlide 12 State 1 Unauthenticated, Unassociated State 2 Authenticated, Unassociated State 3 Authenticated, and Associated EAP Authentication & PMK Derivation PEKM-Confirm (in Association/Reassociation) PEKM-Control “PTK Delete” (In Disassociate) PEKM-Control “PMK Delete” (In Deauthenticate) PEKM-Control “PTK/PMK Delete” (In Deauthenticate) Class 1 Frames Class 1 & 2 Frames Class 1, 2 & 3 Frames State Machine

doc.: IEEE /1572r0 Submission December 2004 Harkins and AbobaSlide 13 “Make Before Break” PEKM operations can be 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. –State 1: STA is unauthenticated, unassociated 802.1X frames (EAP + PEKM) sent over the WM with From DS, To DS = 0 in IBSS EAP 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 EAP/PEKM within Authentication frames

doc.: IEEE /1572r0 Submission December 2004 Harkins and AbobaSlide 14 PEKM Summary Clean, simple architecture –Authentication prior to Association –Compatible with state machine –Applicable to other IEEE 802 media: code footprint reduction 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 Security benefits –Management frame protection (Association/Reassociation, Disassociate, Deauthenticate) –DoS vulnerability reduction: first message attack

doc.: IEEE /1572r0 Submission December 2004 Harkins and AbobaSlide 15 Discussion?