In previous blogs, I talked about the 4-way handshake. During this process, the PTK and the GTK are sent and installed. This is done by EAP over LAN-key frames (EAPOL-keys), but this is not used only by the 4-way handshake. The other handshakes that use this process are:
– Group Key handshake
– PeerKey handshake
– TDLS PeerKey handshake
The 4-way handshake is the process after the 802.1X/EAP exchange, and during this process the PTK and the GTK are generated. This process will be initiated when the EAP-success frame is sent from the access point. The EAPOL messages are between the supplicant and the authenticator and have six purposes:
– Confirm that there is a PMK at the peer station
– Ensure that the PMK is current
– Derive a PTK from the PMK
– Install the PTK on the supplicant and the authenticator
– Send the GTK from authenticator to supplicant and install this key
– Confirm the selection of the cipher suite
During the 802.1X/EAP exchange the MSK is generated and before starting the 4-way handshake the master keys (PMK and GMK) are derived from the MSK. A pseudo-random function (PRF) is used to create the PTK. The input for this function is the PMK, some random numerical values (nonce), and mac addresses. The nonce are unique and only one-time generated. There are two types of nonce. The supplicant nonce (SNonce) and the authenticator nonce (ANonce). The mac addresses are the mac address from the supplicant (SPA) and from the authenticator (AA). The PRF used all those values to create the PTK.
PTK = PRF(PMK + ANonce + SNonce + AA + SPA)
4-Way Handshake
As the name says, the 4-way handshake is 4 steps.\r\nDuring the first step the nonce are created. The supplicant creates the SNonce and the authenticator creates the ANonce. The first EAPOL-key frame (M1) is from the authenticator to the supplicant and carries the ANonce. After this message, the supplicant has the ANonce, his own SNonce, the PMK from the 802.1X/EAP exchange, and both of the mac addresses (supplicant and authenticator). This is all that the supplicant needs to create the PTK with the PRF.
The second step is that the supplicant sends the EAPOL-key (M2) frame to the authenticator. This frame carries the SNonce and a message integrity code (MIC). In this frame is also the security capabilities (RSNIE) from the supplicant. Now the authenticator has all the values for the PRF and is able to create the PTK. The MIC is also validated during this process. At this point both the supplicant and the authenticator have the PTK to encrypt and decrypt the unicast traffic.
The third step is from the authenticator to the supplicant. This third EAPOL-key (M3) frame has the ANonce, RSNIE from the authenticator, and a MIC. If necessary, the authenticator derives the GTK from the GMK and sends this also to the supplicant. The GTK will be encrypted with the PTK. The supplicant will install the PTK and in the fourth step the supplicant sends the EAPOL-key (M4) frame and this is a reply that all the keys are installed and the blocked port is now open. The supplicant can now send the data to the authenticator and can encrypt this with the PTK (or GTK when multicast or broadcast traffic is sent).
Group Key Handshake
As mentioned many times the PTK is per client per session only. The GTK is per authenticator for multiple supplicants. This one is not unique and there are configurations that the GTK will re-derive from the GMK. In this case it is not necessary to go through the whole 4-way handshake, but rather only repeat the last two steps of the 4-way handshake.
The authenticator derives a new GTK from the GMK and this is sent in a EAPOL-key to the supplicant. This frame has also a MIC and is encrypted with the PTK that is installed during the 4-way handshake process. The supplicant decrypts the frame and validates the MIC. When the MIC is validated the new GTK will be installed.
\r\nThe supplicant replies with a new EAPOL-key to confirm that the key is installed and also a MIC is in this EAPOL-frame that the authenticator validates and after that the GTK is also installed on the authenticator.
PeerKey Handshake
Within a BSS, the communication is, most of the time, from the client to the access point, but peer-to-peer communication is possible. I am not talking about an IBSS because in that situation there is no access point. Most of the time, peer-to-peer traffic is blocked within a BSS (client isolation). There is a way to communicate between two clients that is secure, and this is defined in 802.11-2012. When a client is associated with an access point, a station-to-station link (STSL) can be established between two clients, and both clients are associated to an access point. Before the STSL is established a PeerKey Handshake process finds place. There are two different handshakes in this process.
SMK Handshake is a frame exchange in between the two clients for creating the master key. This master key, station-to-station link master key (SMK), process is initiated by one client through the access point to another client that must associate to the same access point.
The second handshake is the 4-Way STK handshake. This is comparable to the 4-way handshake to derive the PTK from the PMK. With the 4-way STK handshake the STK is derived from the SMK. The SMK is the seeding material for this process to create the STSL transient key (STK). This key is used for encrypting and decrypting the data.
Both clients stay associated with the access point, but have also this secure STSL to communicate directly to a client. This process is defined within the 802.11i amendment but never really implemented.
TDLS Peer Key Handshake
Tunneled direct link setup (TDLS) is defined in the 802.11z-2010 amendment. This is an enhanced mechanism for station-to-station communication (direct link communication). Wi-Fi alliance also introduced Wi-Fi CERTIFIED TDLS as a certification program. The devices must be associated to the same access point in the BSS. TDLS is invented for streaming high quality videos between clients and not through the access point for performance reasons. The clients leave the channel and establish a new 40 MHz channel in the 5 GHz for private communication. The client is still associated with the access point and switches back to this channel for access point communication. The access point is not aware of this TDLS communication. The handshake is between the two clients that want this direct link to communicate. The TDLS Peer Key (TPK) handshake is part of the setup. After the handshake is finished a successful direct link is established and there is a TPK security association (TPKSA) between the clients.
The handshake contains three messages between the client that initiates this direct link communication and the client that is part of this direct link. The communication goes through the access point, and again the clients need to be associated to the same access point. During this handshake, the TDLS Peer Key (TPK) is exchanged to encypt and decrypt the unicast traffic.
