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

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


  • 72 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)

Bernard Aboba, Microsoft

<[email protected]>

Dan Harkins, Trapeze Networks

<[email protected]>

Aboba and Harkins


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

  • 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

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


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

  • 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

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

  • 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

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


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”

  • 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

  • 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


Discussion

Aboba and Harkins


  • Login