1 / 15

PEKM (Post-EAP Key Management Protocol)

PEKM (Post-EAP Key Management Protocol). Dan Harkins, Trapeze Networks dharkins@trpz.com Bernard Aboba, Microsoft bernarda@microsoft.com. Principles of EAP Key Management. Parties EAP peer & authenticator/NAS may have one or more ports EAP peer may have multiple interfaces

cleo
Download Presentation

PEKM (Post-EAP Key Management Protocol)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  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: • 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 • 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) 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 • 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 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 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. 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 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”, 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 Harkins and Aboba

  9. PEKM Exchange Supplicant Authenticator Key (PMK), SNonce, ANonce Known Key (PMK) is Known Derive PTK, Generate GTK (IBSS) Message 1: EAPOL-Key(PEKM-Init-Request) Derive PTK, Generate GTK Message 2: EAPOL-Key(PEKM-Init-Response) Message 3: Association/Reassociation-Request(PEKM-Confirm-Request) Message 4: Association/Reassociation-Response(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, 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)} Harkins and Aboba

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

  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 802.11 Authentication frames Harkins and Aboba

  14. PEKM Summary • Clean, simple architecture • Authentication prior to Association • Compatible with 802.11-2003 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 Harkins and Aboba

  15. Discussion? Harkins and Aboba

More Related