Why Is the 4-Way Handshake So Important?

When a wireless client connects to a protected Wi-Fi network, authentication alone is not enough. The client and the access point must also establish fresh encryption keys before normal data traffic can be securely exchanged.

This is the purpose of the IEEE 802.11 4-Way Handshake.

The handshake allows the client and access point to:

• Confirm that the client and Access Point (AP) possess the same Pairwise Master Key, or PMK
• Derive a fresh Pairwise Transient Key, or PTK
• Install encryption keys for unicast traffic
• Securely distribute the Group Temporal Key, or GTK
• Protect the exchange against message modification and replay attacks

What Has Already Happened Before the Handshake?

Before the 4-Way Handshake starts, the client has normally completed:

1. 802.11 discovery and association
2. Authentication through either 802.1X/EAP in an enterprise network or a pre-shared key mechanism in a personal network
3. Establishment or derivation of a PMK

At this point, both the client and the authenticator have access to the same PMK, but the temporary keys used to protect the wireless session have not yet been established.

The PMK is therefore the starting point for the 4-Way Handshake, not its final result.

Where Does the PMK Come From?

The origin of the PMK depends on the wireless security mode.

WPA2-Enterprise with 802.1X

In an enterprise deployment, the client, also called the supplicant or EAP peer, authenticates with an EAP server (aka Radius Server).

The access point or wireless controller acts as the authenticator. It carries EAP messages between the client and the RADIUS server.

With EAP-TLS, the client and EAP server participate in the TLS exchange and independently derive the same keying material:

Client side                         RADIUS/EAP server side
-----------                         ----------------------
TLS handshake                       TLS handshake
      |                                   |
TLS secret material                 TLS secret material
      |                                   |
EAP-TLS key derivation              EAP-TLS key derivation
      |                                   |
     MSK                                 MSK
      |                                   |
     PMK                                 PMK

The Master Session Key, or MSK, is keying material exported by the EAP method. In the original EAP-TLS key hierarchy described in RFC 5216, the MSK contains 64 octets:

MSK = Key_Material(0,63)

It is divided into two 32-octet portions:

Enc-RECV-Key = MSK(0,31)
Enc-SEND-Key = MSK(32,63)

RFC 5216 identifies Enc-RECV-Key, the first 32 octets of the MSK, as the PMK used by IEEE 802.11. It also describes the two portions as the peer-to-authenticator and authenticator-to-peer encryption keys.

In a RADIUS-based deployment, the EAP server sends the required keying material to the authenticator in a protected RADIUS exchange, commonly through the Microsoft MPPE key attributes:

• MS-MPPE-Recv-Key
• MS-MPPE-Send-Key

Client possesses PMK
Authenticator possesses corresponding PMK

WPA2-Personal

In WPA2-Personal, the PMK is based on the pre-shared credentials.

When a human-readable passphrase is used, the passphrase, together with the SSID, is processed to derive the 256-bit key used as the PMK. If the configured PSK is already a raw 256-bit value, that value functions directly as the PMK.

The 4-Way Handshake does not send the passphrase or PMK over the air.

How Is the PTK Generated?

The Pairwise Transient Key is derived from several values known to both the client and the access point:

PTK = PRF(
    PMK,
    AP MAC address,
    Client MAC address,
    ANonce,
    SNonce
)

The inputs are:

• PMK: The existing master key
• ANonce: A random value generated by the authenticator
• SNonce: A random value generated by the supplicant
• AP MAC address: The authenticator address, often written as AA
• Client MAC address: The supplicant address, often written as SPA

A precise representation normally orders the two MAC addresses and two nonces consistently:

PTK = PRF(
    PMK,
    Min(AA, SPA) || Max(AA, SPA) ||
    Min(ANonce, SNonce) || Max(ANonce, SNonce)
)

The PRF, or pseudo-random function, produces binary keying material. Packet-analysis applications such as Wireshark normally display binary values in hexadecimal notation to make them easier for humans to read.

Changing even one input produces a different PTK. Conversely, when both parties use exactly the same inputs and key-derivation algorithm, they calculate the same PTK.

The Four Messages of the 4-Way Handshake

Access Point                         Client
     |                                  |
     |-------- Message 1: ANonce ------>|

Message 1 normally contains:

• ANonce
• Replay counter
• Key information flags
• No valid MIC in the normal initial exchange

Before receiving Message 1, the client already has the PMK, its own MAC address, the AP’s MAC address, and a locally generated SNonce. After receiving the ANonce, it has every input required to calculate the PTK.

PMK + ANonce + SNonce + AP MAC + Client MAC
                         |
                         v
                        PTK

Access Point                         Client
     |                                  |
     |<------- Message 2: SNonce -------|
     |               + MIC              |

Message 2 normally contains the SNonce, replay counter, a Message Integrity Code, or MIC, and relevant security parameters from the client. The MIC is calculated using the Key Confirmation Key, or KCK, which is part of the PTK.

Once the AP receives the SNonce, it independently derives the same PTK and uses its KCK to verify the MIC. A valid MIC shows that the message was not modified, that the client calculated the same PTK, and therefore that it possesses the corresponding PMK.

Access Point                         Client
     |                                  |
     |-------- Message 3: GTK --------->|
     |         encrypted Key Data       |
     |               + MIC              |

Message 3 normally includes the ANonce, an incremented replay counter, Install and Secure indications, a MIC calculated using the KCK, and encrypted or wrapped Key Data containing the GTK.

The GTK is generated through the authenticator’s group-key hierarchy. It is not calculated from the individual client’s PTK. When the AP delivers it to a client, it protects the GTK using that client-specific Key Encryption Key, or KEK.

GTK
 |
 | encrypted or wrapped using the client's KEK
 v
Protected Key Data in Message 3

The client checks the replay counter, verifies the MIC using the KCK, unwraps the Key Data using the KEK, extracts the GTK, installs the required keys, and prepares the final acknowledgement.

Access Point                         Client
     |                                  |
     |<------- Message 4: ACK ----------|
     |               + MIC              |

Message 4 normally contains the expected replay counter, a Secure indication, and a MIC calculated using the KCK. It carries no new nonce or GTK.

The AP validates the MIC and replay counter, completes the handshake, and authorizes protected data traffic.

Complete Authentication and Handshake Flow

Wi-Fi Client                  Access Point                  RADIUS Server
Supplicant / EAP Peer         Authenticator                  EAP Server
      |                            |                             |
      |<=============== EAP-TLS authentication ===============>  |
      |       EAP messages relayed by the authenticator          |
      |                            |                             |
      | Derives MSK locally        |       Derives MSK locally   |
      | from TLS/EAP key material  |       from TLS/EAP material |
      |                            |                             |
      | Obtains PMK from MSK       |                             |
      |                            |<-- RADIUS Access-Accept ----|
      |                            |    + protected key material |
      |                            |                             |
      | Client possesses PMK       | Authenticator has PMK       |
      |                            |                             |
      |            IEEE 802.11 4-WAY HANDSHAKE                   |
      |                            |                             |
      |                            | Generates ANonce            |
      |<--------- Message 1 -------|                             |
      |           ANonce           |                             |
      |           Replay Counter   |                             |
      |                            |                             |
      | Generates SNonce           |                             |
      | Derives PTK                |                             |
      |---------- Message 2 ------>|                             |
      |           SNonce           |                             |
      |           Replay Counter   |                             |
      |           MIC using KCK    |                             |
      |                            |                             |
      |                            | Derives same PTK            |
      |                            | Verifies MIC using KCK      |
      |<--------- Message 3 -------|                             |
      |           Protected GTK    |                             |
      |           MIC using KCK    |                             |
      |                            |                             |
      | Verifies MIC using KCK     |                             |
      | Unwraps GTK using KEK      |                             |
      | Installs PTK/TK and GTK    |                             |
      |---------- Message 4 ------>|                             |
      |           Replay Counter   |                             |
      |           MIC using KCK    |                             |
      |                            |                             |
      |                            | Completes handshake         |
      |<====== Protected unicast and group data traffic =======> |

PTK and GTK: What Is the Difference?

PTK

The PTK is pairwise and client-specific. It provides the key material used to authenticate EAPOL-Key messages, protect transported key information, and encrypt and integrity-protect unicast data.

Client A <-> AP = PTK-A
Client B <-> AP = PTK-B
Client C <-> AP = PTK-C

GTK

The GTK is a group key used for broadcast and multicast traffic. Clients associated with the same BSS normally receive the applicable GTK from the authenticator. The AP distributes it individually to each client, protecting it with that client’s pairwise KEK.

PTK/TK -> unicast traffic between one client and the AP
GTK    -> broadcast and multicast traffic within the BSS

Understanding the PTK Subkeys

A simplified WPA2/CCMP representation is:

PTK = KCK || KEK || TK

KCK = 128 bits / 16 bytes
KEK = 128 bits / 16 bytes
TK  = 128 bits / 16 bytes

Total = 384 bits / 48 bytes

The exact PTK structure and subkey lengths can vary with the negotiated Authentication and Key Management suite and cipher.

1. KCK: EAPOL-Key Key Confirmation Key

The KCK protects the integrity and authenticity of EAPOL-Key messages. Its most visible role is calculating and validating the EAPOL-Key MIC.

Message 1: Normally no valid MIC
Message 2: MIC calculated using KCK
Message 3: MIC calculated using KCK
Message 4: MIC calculated using KCK

When the AP validates the Message 2 MIC using its locally derived KCK, it confirms that the client calculated the same KCK. Because KCK comes from the PTK and PTK depends on the PMK, a valid MIC demonstrates possession of the required PMK-derived key material.

2. KEK: EAPOL-Key Key Encryption Key

The KEK protects sensitive information transported inside the Key Data field of an EAPOL-Key message. Its best-known use is protecting the GTK when the AP sends it to the client.

The KEK may protect GTK distribution, other protected key data, and IGTK or BIGTK distribution when applicable to protected management-frame configurations.

3. TK: Temporal Key

The TK protects normal unicast 802.11 data traffic between a specific client and the access point. It is used with the negotiated data-protection cipher, such as AES-CCMP, AES-GCMP, or historically TKIP.

Client A <-> AP = TK-A
Client B <-> AP = TK-B
Client C <-> AP = TK-C

One client cannot use its own TK to decrypt another client’s protected unicast traffic.

What Happens After Message 4?

Most explanations stop after Message 4 because the initial security association is complete and client data can begin flowing. However, the AP may later need to replace the GTK because of a configured periodic rotation timer, changes in group membership, security policy, implementation behavior, or a session event.

The AP does not need to repeat the complete 4-Way Handshake merely to distribute a new GTK. It can use the Group Key Handshake.

Group Key Message 1: The AP Sends a New GTK

The AP generates or selects a new GTK, places it in the EAPOL-Key Key Data field, protects it using the client’s KEK, calculates the MIC using the client’s KCK, advances the replay counter, and sends the frame.

The client validates the replay counter and MIC, unwraps the Key Data using the KEK, extracts and installs the new GTK, and prepares an acknowledgement.

Group Key Message 2: The Client Acknowledges the Update

The response normally contains the corresponding replay counter, a MIC calculated using the KCK, and the necessary acknowledgement indication. It normally carries no new GTK or nonce.

The AP checks the replay counter, verifies the MIC, confirms that the client received the update, and marks the Group Key Handshake as complete for that client.

Why Is the Group Key Handshake Useful?

The AP can rotate the GTK without repeating the full 4-Way Handshake, replacing the client’s PTK solely for GTK distribution, repeating 802.1X/EAP authentication, or reassociating the client.

GTK Rotation and Controller Timers

How often the GTK rotates is generally controlled by the wireless infrastructure configuration. The exact setting, valid range, and default value depend on the controller platform, software version, WLAN configuration, and security mode.

Some older Cisco controller references discuss a broadcast-key rotation interval of approximately 3,600 seconds, or one hour, but this should not be treated as a universal default across all Cisco platforms or releases.

An overly aggressive rekey interval creates more Group Key Handshake exchanges. If a AP does not receive an acknowledge after a GTK update, the update may be retried, the client may temporarily lose broadcast or multicast connectivity, or the security association may eventually be removed and established again.

The GTK rotation interval should balance security requirements, client compatibility, broadcast and multicast usage, infrastructure scale, operational stability, and vendor recommendations.

Final Key Hierarchy

EAP authentication
       |
       v
      MSK
       |
       v
      PMK
       |
       +----------------------------------+
       |                                  |
       v                                  v
4-Way Handshake                    Group-key hierarchy
       |                                  |
       v                                  v
      PTK                                GTK
       |
       +------------+------------+
       |            |            |
       v            v            v
      KCK          KEK           TK

KCK -> EAPOL-Key integrity and authentication
KEK -> Protection of distributed key material
TK  -> Unicast data protection
GTK -> Broadcast and multicast data protection

Conclusion

The 4-Way Handshake does much more than exchange four packets. It connects the authentication phase with the encrypted data phase of a Wi-Fi session.

Its core objective is to prove that the client and authenticator possess corresponding PMK material while deriving fresh, session-specific keys without transmitting the PMK itself.

Message 1 -> AP provides ANonce
Message 2 -> Client provides SNonce and proves PMK possession
Message 3 -> AP proves possession and securely distributes GTK
Message 4 -> Client confirms successful processing

After the handshake, KCK authenticates EAPOL-Key exchanges, KEK protects transported key material, TK protects pairwise unicast traffic, and GTK protects broadcast and multicast traffic.

Later, the two-message Group Key Handshake can replace the GTK without repeating the entire authentication and initial 4-Way Handshake.