Nothing makes me channel my inner Jerry Seinfeld in Wi-Fi like the 4-Way Handshake for client authentication. You look it up and get a diagram depicting the same story with 100 different variations. Some mention the RSN IEs and others mention whether the GTK is encrypted or not. The phrase "If needed" occasionally precedes the GTK derivation, but how often do we even have WLANs with only unicast traffic?

Our source of truth, the 802.11-2020 standard, also mentions IGTKs and BIGTKs in addition to the MSKs, PMKs, PTKs, GTKs, KEKs, KCKs, and TEKs, to add to the 802.11i Key-pocalypse. (1)

So what gives?

Well, here's my interpretation of the 4-way handshake after collating multiple sources together.
I used a research article from the Fordham Center for Cybersecurity as my starting point because it has the most complete diagram I have seen. (2) The standard does describe these functions, of course, just not in the same page.

Before the Handshake
If the association frames indicate an RSN is in use, the client and AP each generate the PMK/GMK independently. A GMK is just the group traffic peer to the PMK, used for broadcast and multicast traffic; the standard says it "might be used to derive a group temporal key (GTK)" which does not instill the most confidence, but here we are.
What about the MSK (Master Session Key)? This is used in 802.1x/Enterpise SSIDs. The MSK is generated between the Authentication Server and Authenticator. Then, the first "PMK-length" bits of the MSK become the PMK.
Conversely in PSK/Personal SSIDs, there is no MSK and the passphrase you enter becomes the PMK eventually. To get the PSK in Personal SSIDs, a PBKDF2 (Password-Based Key Derivation Function 2) takes the passphrase and SSID name as input where:
PSK = PBKDF2(passphrase, ssid name, 4096, 256/8)
4096 means it's hashed that many times.
256 is the size of the PSK in bits.
The standard then says "If the RSNA AP does not advertise support for SAE [...], the non-DMG STA may invoke Open System Authentication and use the PSK as the PMK" if PSK/Personal authentication is in use. So unless we are using SAE for WPA3, the PMK = PSK and that also explains the abbreviated notation in the diagram of "PBKDF2(PSK, SSID, HMAC SHA-1)". HMAC SHA-1 is the type of key derivation function used.
Confused yet? I can now at least move onto the actual handshake at least after figuring out how the client and AP get the PMK/GMK.
Fortunately, the actual handshake process is less complicated than key derivations.
The AP generates an ANonce. An ANonce (Authenticator Nonce) is a random number assigned to the AP. Then, the AP sends the ANonce and its own MAC address to the client.
Upon receiving the frame, the client generates an SNonce (Supplicant Nonce) or a random number assigned to the client. Using the ANonce, SNonce, PMK, AP MAC, and Client MAC, the client calculates the PTK. A MIC is also calculated by the client using the KCK (more on that later) to ensure the message has not been altered once it leaves the client.
Message 2
In Message 2, the client sends the SNonce, the MIC it just calculated, and its own MAC address to the AP. Once the AP received this information, the AP derives the PTK using the same formula: the ANonce, SNonce, PMK, AP MAC, and Client MAC are hashed together in a PRF (Psuedo Random Function) chosen by the AKM suite in use. If multicast or broadcast traffic is used, the AP will also generate the GTK in a similar fashion.
The AP also calculates the MIC and ensures it matches the value sent by the client in Message 2. If these values match, congratulations, you're past the hard part. The rest of the handshake is mostly installing the PTK/GTK.
Message 3
The AP sends the encrypted GTK and another MIC to the client. Then, the client decrypts the GTK with the PTK and installs both the PTK and GTK. Yet again, the client generates a MIC and verifies the one sent by the AP in Message 3.
Message 4
The client sends a final MIC to the AP. When the AP receives Message 4, it installs the PTK and now they can pass encrypted data traffic between each other. ❤️
Those Other Keys - IGTK, BIGTK, KCK, KEK, TEK...
The IGTK or integrity group temporal key is defined by the standard as a "random value, assigned by the broadcast/multicast source STA, which is used to protect group MMPDUs (MAC Management Protocol Data Units) from that source STA".
In other words, when MFP/802.11w is in use, the IGTK protects management frame traffic by representing the encrypted session to transmit MSDUs.
Similarly the BIGTK is the beacon integrity group temporal key. This key specifically protects beacon frames "if beacon protection is enabled" which means beacon protection requires WPA3 and MFP. BIGTKs are a step to prevent beacon spoofing. Why have I not seen this mentioned before actually reading the standard? Bah-humbug.
KEKs or EAPOL-Key Encryption Keys provide confidentiality and ensure the PTK/GTK is not visible.
KCKs or EAPOL-Key Confirmation Keys provide integrity and ensure the PTK/GTK is not altered.
The TEK or Temporal Encryption Key is the specific section of the PTK/GTK that encrypts the traffic.
There's one catch though: the KEK and KCK are actually part of the PTK/GTK. The PTK/GTK has up to five components:
a KCK
a KEK
a TEK
a second KCK for fast transition, if used
a second KEK for fast transition, if used
Hopefully, this clears up some 4-way handshake mysteries and prevents at least one Wi-Fi student from recoiling in fear. Or perhaps I just opened Pandora's Box? 🤔
Sources: