pekm post eap key management protocol
Skip this Video
Download Presentation
PEKM (Post-EAP Key Management Protocol)

Loading in 2 Seconds...

play fullscreen
1 / 14

PEKM (Post-EAP Key Management Protocol) - PowerPoint PPT Presentation

  • Uploaded on

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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' PEKM (Post-EAP Key Management Protocol)' - chiara

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
pekm post eap key management protocol

PEKM(Post-EAP Key Management Protocol)

Bernard Aboba, Microsoft


Dan Harkins, Trapeze Networks


Aboba and Harkins

principles of eap key management
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
      • Session-Timeout attribute denotes maximum lifetime while the PMK is in use (e.g. time to reauthentication or PMK re-key)
      • Session-Timeout does not describe the lifetime of the PMK prior to use (e.g. pre-authentication PMK lifetime)
      • No attribute available to determine the PTK/GTK lifetime (e.g. time to session re-key)
    • Key lifetimes communicated by the AP to the peer via the lower layer

Aboba and Harkins

pekm principles
PEKM Principles
  • Endpoints are the EAP Peer and Authenticator
    • An EAP authenticator may consist of multiple Access Points
    • Result of the PEKM exchange is binding of PTK to station MAC and AP BSSID addresses.
  • 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.
  • Security
    • Compatible with the Housley Criteria (IETF 56)
      • Algorithm negotiation
      • Key naming
      • No cascading vulnerabilities (no key sharing between authenticators)
      • Compatible with EAP Channel Binding
    • Addresses known 802.11i issues
      • First message protection
      • Explicit Key Install/Delete operations
      • Defined Key Scope
      • Explicit Key lifetime negotiation (PMK, PTK)
      • Group Key Symmetry (IBSS)
      • Management frame protection
      • State machine consistency (e.g. “Link Up” same in PEKM and 802.11-2003)

Aboba and Harkins

pekm features
PEKM Features
  • Station initiated exchange
    • Occurs prior to Association/Reassociation
  • Low Latency
    • Three message exchange
    • First two messages off the critical path (e.g. STA can pre-key to new AP while associated to an existing AP)
  • Compatible with IETF RFCs and work-in-progress
    • Not dependent on proprietary backend solutions
    • Key distribution based on RFC 3576 (Dynamic Authorization), RFC 3579 (RADIUS/EAP)
    • Key hierarchy based on EAP Key Management Framework (draft-ietf-eap-keying)

Aboba and Harkins

discovery eap overview
Discovery & EAP Overview
  • Discovery phase
    • PEKM, “NAS-Identifier” IEs included by AP in the Beacon/Probe Response
    • PEKM IE identifies the AP as PEKM-capable, indicates capabilities
    • NAS-Identifier IE identifies the Authenticator
      • 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 authenticator within whom it does not share a PMK cache entry
    • NAS-Identifier attribute sent by AAA client to AAA server
    • NAS-Identifier IE sent by AP to the STA
    • Result: Authenticator, EAP peer, AAA server all know NAS-Identifier attribute, can verify agreement via EAP Channel Bindings

Aboba and Harkins

pekm parties identifiers


PEKM: Parties & Identifiers

Beacon/Probe Response

NAS-Identifier IE



{EAP-Message, User-Name











AAA Client

Aboba and Harkins

pekm overview
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 (not just cryptographic algorithms)
    • Secure Association/Re-association messages
  • Messages
    • PEKM Pre-Key
      • PEKM Message 1: “PTK-Request”, encapsulated in 802.1X EAPOL-Key
      • PEKM Message 2: “PTK-Response”, encapsulated in 802.1X EAPOL-Key
    • PEKM Management Frame Protection
      • Association/Reassociation
        • PEKM Message 3 (“PTK Install”) embedded within Association/Reassociation
      • PEKM Deauthenticate
        • PEKM “PMK Delete” operation embedded in Deauthenticate
      • PEKM Disassociate
        • PEKM “PTK Delete” operation embedded in Disassociate

Aboba and Harkins

pekm exchange
PEKM Exchange



Key (PMK), SNonce,

ANonce Known

Key (PMK) is Known

Derive PTK,

Generate GTK (IBSS)

Message 1: EAPOL-Key(PTK-Derivation-Request)

Derive PTK,

Generate GTK

Message 2: EAPOL-Key(PTK-Derivation-Response)

Message 3: Reassociation-Request(Install PTK & GTK, Unicast, MIC)

Message 4: Reassociation-Response(Unicast, MIC)

Install PTK and GTK

Install PTK and GTK

Aboba and Harkins

details of pekm messages
Details of PEKM Messages
  • Message 1 (PTK-Derivation-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)}
  • Message 2 (PTK-Derivation-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.
  • Message 3 (PTK-Install-Request, in Association/Reassociation-Request)
    • {MIC(PTK-X-KCK, peer-id to capabilities, Reassociation-Request)}
  • Message 4 (PTK-Install-Request, in Association/Reassociation-Response)
    • {MIC(PTK-X-KCK, peer-id to capabilities, Reassociation-Request)}

Aboba and Harkins

pekm frame format
PEKM Frame Format





















Aboba and Harkins


State Machine

State 1Unauthenticated, Unassociated

Class 1 Frames

PEKM “PMK Delete”

(In Deauthenticate)




(In Deauthenticate)

EAP PMK Install

State 2Authenticated, Unassociated

Class 1 & 2 Frames


“PTK Install”

(In Reassociate)

PEKM “PTK Delete” (In Disassociate)

State 3Authenticated, and Associated

Class 1, 2 & 3 Frames

Aboba and Harkins

make before break
“Make Before Break”
  • PEKM operations can be encapsulated within Data or Management Frames
  • In order to enable PEKM-based management frame protection (Association/Reassociation, Deauthentication, Disassociation), need to be able to derive PTKs in any State: need “make before break”
  • Data Frames
    • Sent in State 3: STA is authenticated, associated to an AP. PEKM frames can be sent over the DS to pre-establish PTK state.
    • Sent in State 1: STA is unauthenticated, unassociated. 802.1X frames (EAP + PEKM) sent over the WM with From DS, To DS = 0.
  • Requirement
    • Support for 802.1X Class 1 data frames in ESS
  • Potential alternative: In state 1, Encapsulation of EAP/PEKM within Authentication frames

Aboba and Harkins

pekm summary
PEKM Summary
  • Clean, simple architecture
    • Authentication prior to Association
    • Full compliance with 802.11-2003 state machine
  • 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
    • Two roundtrips: Only Reassociation Request/Response in critical path
    • 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

Aboba and Harkins



Aboba and Harkins