PEKM (Post-EAP Key Management Protocol)

Please download to get full document.

View again

of 15
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Information Report



Views: 54 | Pages: 15

Extension: PDF | Download: 0

PEKM (Post-EAP Key Management Protocol). Dan Harkins, Trapeze Networks Bernard Aboba, Microsoft Principles of EAP Key Management. Parties EAP peer & authenticator/NAS may have one or more ports EAP peer may have multiple interfaces
PEKM(Post-EAP Key Management Protocol)Dan Harkins, Trapeze Networksdharkins@trpz.comBernard Aboba, Microsoftbernarda@microsoft.comHarkins and AbobaPrinciples 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 AbobaPEKM 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 AbobaPEKM 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 Aboba802.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 AbobaDiscovery & 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 AbobaSTAsPEKM: Parties & IdentifiersBeacon/Probe ResponseNAS-Identifier IEAPsAccess-Request/{EAP-Message, User-NameNAS-Identifier}EAPEAP PeerPEKMAccess-Accept/AAA-KeyEAP/AAA ServerAuthenticator/AAA ClientHarkins and AbobaPEKM 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 AbobaPEKM ExchangeSupplicantAuthenticatorKey (PMK), SNonce, ANonce KnownKey (PMK) is KnownDerive PTK,Generate GTK (IBSS)Message 1: EAPOL-Key(PEKM-Init-Request)Derive PTK,Generate GTKMessage 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 GTKInstall PTK and GTKHarkins and AbobaPEKM 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 AbobaDetails 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 AbobaState MachineState 1Unauthenticated, UnassociatedClass 1 FramesPEKM-Control “PMK Delete”(In Deauthenticate)EAP Authentication & PMK DerivationPEKM-Control “PTK/PMK Delete”(In Deauthenticate)State 2Authenticated, UnassociatedClass 1 & 2 FramesPEKM-Confirm(in Association/Reassociation)PEKM-Control “PTK Delete”(In Disassociate)State 3Authenticated, and AssociatedClass 1, 2 & 3 FramesHarkins and Aboba“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 AbobaPEKM 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 AbobaDiscussion?Harkins and Aboba
    We Need Your Support
    Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

    Thanks to everyone for your continued support.

    No, Thanks

    We need your sign to support Project to invent "SMART AND CONTROLLABLE REFLECTIVE BALLOONS" to cover the Sun and Save Our Earth.

    More details...

    Sign Now!

    We are very appreciated for your Prompt Action!