Presentation is loading. Please wait.

Presentation is loading. Please wait.

Doc.: IEEE 802.11-04/1572r0 Submission December 2004 Harkins and AbobaSlide 1 PEKM (Post-EAP Key Management Protocol) Dan Harkins, Trapeze Networks

Published byAubrie Emily Holland Modified over 9 years ago

Similar presentations

Presentation on theme: "Doc.: IEEE 802.11-04/1572r0 Submission December 2004 Harkins and AbobaSlide 1 PEKM (Post-EAP Key Management Protocol) Dan Harkins, Trapeze Networks"— Presentation transcript:

1 doc.: IEEE 802.11-04/1572r0 Submission December 2004 Harkins and AbobaSlide 1 PEKM (Post-EAP Key Management Protocol) Dan Harkins, Trapeze Networks dharkins@trpz.com Bernard Aboba, Microsoft bernarda@microsoft.com

2 doc.: IEEE 802.11-04/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

3 doc.: IEEE 802.11-04/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: 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

4 doc.: IEEE 802.11-04/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)

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

6 doc.: IEEE 802.11-04/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

7 doc.: IEEE 802.11-04/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

8 doc.: IEEE 802.11-04/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 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

9 doc.: IEEE 802.11-04/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

10 doc.: IEEE 802.11-04/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)

11 doc.: IEEE 802.11-04/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)}

12 doc.: IEEE 802.11-04/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

13 doc.: IEEE 802.11-04/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 802.11 Authentication frames

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

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

Download ppt "Doc.: IEEE 802.11-04/1572r0 Submission December 2004 Harkins and AbobaSlide 1 PEKM (Post-EAP Key Management Protocol) Dan Harkins, Trapeze Networks"

Similar presentations

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

Doc.: IEEE /1186r0 Submission October 2004 Aboba and HarkinsSlide 1 PEKM (Post-EAP Key Management Protocol) Bernard Aboba, Microsoft Dan Harkins,
Doc.: IEEE 802.11-00/087 Submission May, 2000 Steven Gray, NOKIA Jyri Rinnemaa, Jouni Mikkonen Nokia Slide 1.

Doc.: IEEE /087 Submission May, 2000 Steven Gray, NOKIA Jyri Rinnemaa, Jouni Mikkonen Nokia Slide 1.
IEEE 802.11i: A Retrospective Bernard Aboba Microsoft March 2004.

IEEE i: A Retrospective Bernard Aboba Microsoft March 2004.
IEEE P802 Handoff ECSG Submission July 2003 Bernard Aboba, Microsoft Detection of Network Attachment (DNA) and Handoff ECSG Bernard Aboba Microsoft July.

IEEE P802 Handoff ECSG Submission July 2003 Bernard Aboba, Microsoft Detection of Network Attachment (DNA) and Handoff ECSG Bernard Aboba Microsoft July.
Analysis of the 802.11i 4-Way Handshake Changhua He, John C Mitchell Stanford University WiSE, Oct. 1, 2004.

Analysis of the i 4-Way Handshake Changhua He, John C Mitchell Stanford University WiSE, Oct. 1, 2004.
Analysis of the 802.11i 4-Way Handshake Changhua He, John C Mitchell 2004 ACM International Workshop on Wireless Security (WiSe'04) Sang-Rok Kim Dependable.

Analysis of the i 4-Way Handshake Changhua He, John C Mitchell 2004 ACM International Workshop on Wireless Security (WiSe'04) Sang-Rok Kim Dependable.
Analysis and Improvements over DoS Attacks against IEEE 802.11i Standard Networks Security, Wireless Communications and Trusted Computing(NSWCTC), 2010.

Analysis and Improvements over DoS Attacks against IEEE i Standard Networks Security, Wireless Communications and Trusted Computing(NSWCTC), 2010.
Doc.: IEEE 802.11-00/275 Submission September 2000 David Halasz, Cisco Systems, Inc.Slide 1 IEEE 802.1X for IEEE 802.11 David Halasz, Stuart Norman, Glen.

Doc.: IEEE /275 Submission September 2000 David Halasz, Cisco Systems, Inc.Slide 1 IEEE 802.1X for IEEE David Halasz, Stuart Norman, Glen.
Doc.: Submission, Slide 1 Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Securing the 802.15.4 Network.

Doc.: Submission, Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Securing the Network.
Jesse Walker, 802.11 keying requirements1 Suggested 802.11 Keying Requirements Jesse Walker Intel Corporation

Jesse Walker, keying requirements1 Suggested Keying Requirements Jesse Walker Intel Corporation
DIMACS Nov 3 - 4, 2004 WIRELESS SECURITY AND ROAMING OVERVIEW DIMACS November 3-4, 2004 Workshop: Mobile and Wireless Security Workshop: Mobile and Wireless.

DIMACS Nov 3 - 4, 2004 WIRELESS SECURITY AND ROAMING OVERVIEW DIMACS November 3-4, 2004 Workshop: Mobile and Wireless Security Workshop: Mobile and Wireless.
An Initial Security Analysis of the IEEE 802.1x Standard Tsai Hsien Pang 2004/11/4.

An Initial Security Analysis of the IEEE 802.1x Standard Tsai Hsien Pang 2004/11/4.
Chapter 5 Secure LAN Switching.  MAC Address Flooding Causing CAM Overflow and Subsequent DOS and Traffic Analysis Attacks.

Chapter 5 Secure LAN Switching.  MAC Address Flooding Causing CAM Overflow and Subsequent DOS and Traffic Analysis Attacks.
Doc.: IEEE 802.11-11/0976r1 Submission July 2011 Hitoshi Morioka, ROOT INC.Slide 1 TGai Authentication Protocol Proposal Date: 2011-07-17 Authors: NameAffiliationsAddressPhoneemail.

Doc.: IEEE /0976r1 Submission July 2011 Hitoshi Morioka, ROOT INC.Slide 1 TGai Authentication Protocol Proposal Date: Authors: NameAffiliationsAddressPhone .
WPA2 By Winway Pang. Overview  What is WPA2?  Wi-Fi Protected Access 2  Introduced September 2004  Two Versions  Enterprise – Server Authentication.

WPA2 By Winway Pang. Overview  What is WPA2?  Wi-Fi Protected Access 2  Introduced September 2004  Two Versions  Enterprise – Server Authentication.
IEEE Wireless LAN Standard

IEEE Wireless LAN Standard
Wireless Network Security. Wireless Security Overview concerns for wireless security are similar to those found in a wired environment concerns for wireless.

Wireless Network Security. Wireless Security Overview concerns for wireless security are similar to those found in a wired environment concerns for wireless.
July 16, 2003AAA WG, IETF 571 AAA WG Meeting IETF 57 Vienna, Austria Wednesday, July 16, 2003 1300 - 1500.

July 16, 2003AAA WG, IETF 571 AAA WG Meeting IETF 57 Vienna, Austria Wednesday, July 16,
Doc.: IEEE 802.11-11/1066r2 Submission July 2011 Robert Moskowitz, VerizonSlide 1 Link Setup Flow Date: 2011-05-10 Authors: NameCompanyAddressPhoneemail.

Doc.: IEEE /1066r2 Submission July 2011 Robert Moskowitz, VerizonSlide 1 Link Setup Flow Date: Authors: NameCompanyAddressPhone .
Wireless and Email Security CSCI 5857: Encoding and Encryption.

Wireless and Security CSCI 5857: Encoding and Encryption.

Similar presentations

Ads by Google