1. PEKM (Post-EAP Key Management Protocol)
December 2004
PEKM (Post-EAP Key Management Protocol)
Dan Harkins, Trapeze Networks
Bernard Aboba, Microsoft
Harkins and Aboba

2. December 2004
Principles of EAP
Two 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 as PMK
Transient Session Keys (TSKs) derived from the PMK/AAA-Key
AAA-Key, TSK lifetimes determined by the authenticator, on advice from the AAA server
PMK/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 PMK/AAA-Key prior to use (pre-authentication lifetime)
Lifetime of the PTK/GTK
Harkins and Aboba

3. Principles of PEKM Endpoints are the EAP peer and authenticator
December 2004
Principles of PEKM
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:
data and management frames
Other IEEE 802 technologies: , 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.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 Aboba

4. PEKM Features Station initiated exchange of 4 messages
December 2004
PEKM Features
Station initiated exchange of 4 messages
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 change to backend necessary
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 Aboba

5. 802.11i Issues Addressed by PEKM
December 2004
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– message verified before state created
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 )
PEKM: explicit and authenticated key install/delete operations encapsulated in management frames
Harkins and Aboba

6. Discovery & EAP Overview
December 2004
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 (802.1x supplicant) 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 Aboba

7. PEKM: Parties & Identifiers & Handshakes
December 2004
PEKM: Parties & Identifiers & Handshakes
APs
Beacon/Probe Response
PEKM IE with NAS-Id
PTK
Access-Request/
{EAP-Message, User-Name
NAS-Identifier}
PMK
EAP
4way HS
PEKM
Access-Accept/
AAA-Key
EAP/AAA Server
EAP Peer
PTK
Beacon/Probe Response
PEKM IE with NAS-Id
Authenticator/ AAA Client
Harkins and Aboba

8. PEKM Overview Functionality Messages
December 2004
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
capabilities
Other capability IEs (QoS, etc.)
Secure Association/Reassociation/Disassociate/Deauthenticate messages
Messages
PEKM Pre-Key
PEKM Message 1: “PEKM-Init-Request”, authentication or 802.1X EAPOL Key
PEKM Message 2: “PEKM-Init-Response”, authentication or 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 Aboba

9. PEKM Exchange Authenticator Supplicant December 2004
Key (PMK), SNonce,
ANonce Known
Key (PMK) is Known
Derive PTK,
Generate GTK (IBSS)
Message 1: authenticate (PEKM-Init) Request
Derive PTK,
Generate GTK
Message 2: authenticate (PEKM-Init) Response
Message 3: Association/Reassociation (PEKM-Confirm) Request
Message 4: Association/Reassociation (PEKM-Confirm) Response
Install PTK and GTK
Install PTK and GTK
Harkins and Aboba

10. PEKM Scenarios Straight through PTK Pre-Key
December 2004
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)
Harkins and Aboba

11. Details of PEKM Messages
December 2004
Details of PEKM Messages
PEKM-Init-Request:
{peer-id, nas-identifier, sta_mac, ap_bssid, snonce, ptk_lifetime_desired, pmk_lifetime_desired, [, encrypted GTK], capabilities}, {PMKID-1, anonce-1, MIC(PTK-1-KCK, peer-id to capabilities)} [,{PMKID-2, anonce-2, MIC(PTK-2-KCK, peer-id to capabilities)}]
PEKM-Init-Response
{peer-id, nas-identifier, sta_mac, ap_bssid, snonce, Enc(PTK-X-KEK, GTK), ptk_lifetime, pmk_lifetime, capabilities}, {PMKID-X, anonce-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 Association/Reassociation-Response
{MIC(PTK-X-KCK, peer-id to capabilities, Reassociation-Response)}
Harkins and Aboba

12. State Machine Class 1 Frames Class 1 & 2 Frames Class 1, 2 & 3 Frames
December 2004
State Machine
State 1 Unauthenticated, Unassociated
Class 1 Frames
PEKM-Control
“PTK/PMK Delete”
(In Deauthenticate)
PEKM-Control “PTK delete”
(In Deauthenticate)
PEKM-Init
(in authenticate)
State 2 Authenticated, Unassociated
Class 1 & 2 Frames
PEKM-Confirm
(in Association/Reassociation)
PEKM-Control “PTK Deinstall”
(In Disassociate)
State 3 Authenticated, and Associated
Class 1, 2 & 3 Frames
Harkins and Aboba

13. December 2004
“Make Before Break”
PEKM operations are 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. Useful in verifying capabilities without going off channel.
State 1: STA is unauthenticated, unassociated
PEKM frames sent over the WM with From DS, To DS = 0 in IBSS
PEKM 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 PEKM within Authentication frames
Harkins and Aboba

14. PEKM Summary Clean, simple architecture Emphasis on correct operation
December 2004
PEKM Summary
Clean, simple architecture
Authentication prior to Association
Compatible with state machine
No dependency on new work being done elsewhere
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
No new key hierarchies necessary
Security benefits
Management frame protection (Association/Reassociation, Disassociate, Deauthenticate)
DoS vulnerability reduction: first message attack
Harkins and Aboba

15. December 2004
Discussion?
Harkins and Aboba