Pekm post eap key management protocol
This presentation is the property of its rightful owner.
Sponsored Links
1 / 14

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


  • 65 Views
  • Uploaded on
  • Presentation posted in: General

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

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.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

<[email protected]>

Dan Harkins, Trapeze Networks

<[email protected]>

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

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

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

Supplicant

Authenticator

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

OpCode

PTK-Request

PTK-Response

PTK-Install-Request

PTK-Install-Response

PTK-Delete-Request

PMK-Delete-Request

Attributes

SNonce

ANonce

Peer-Id

NAS-Id

STA_MAC

AP_BSSID

PTK_Lifetime

PMK_Lifetime

GTK

MIC

Capabilities

PMKID

Aboba and Harkins


Pekm post eap key management protocol

State Machine

State 1Unauthenticated, Unassociated

Class 1 Frames

PEKM “PMK Delete”

(In Deauthenticate)

PEKM

“PTK/PMK

Delete”

(In Deauthenticate)

EAP PMK Install

State 2Authenticated, Unassociated

Class 1 & 2 Frames

PEKM

“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


Pekm post eap key management protocol

Discussion

Aboba and Harkins


  • Login