Welcome To WLAN Testing : May 2020

What is Four-Way handshake?
Between Access point (Authenticator) and WiFi client (Supplicant) four messages are exchanged to generate encrypted keys used to encrypt and decrypt 802.11 data frames.

Key Hierarchy (Source from CWSP Study Guide)

Master Session Key (MSK):
Also known as AAA key which is generated either from 802.1X/EAP authentication (EAP-TLS or PEAP etc) process or PSK authentication.
In 802.1X/EAP authentication, generating MSK is depends on EAP method and key length is atleast 64 octets. Below are the attribute value pairs seen in Access-Accept

Enc-RECV-Key = MSK(0,31) = Peer to Authenticator Encryption Key
               (MS-MPPE-Recv-Key in [RFC2548]). Also known as the PMK in [IEEE-802.11]
Enc-SEND-Key = MSK(32,63) = Authenticator to Peer Encryption Key
               (MS-MPPE-Send-Key in [RFC2548])
RECV-IV      = IV(0,31) = Peer to Authenticator Initialization Vector
SEND-IV      = IV(32,63) = Authenticator to Peer Initialization Vector

In Personal/PSK authentication, we configure passphrase 8-63 characters. This passphrase converts into 256 bits PSK using below formula (Passphrase to PSK mapping)

PSK = PBKDF2 (PassPhrase, ssid, ssidLength, 4096, 256)

Pairwise Master Key (PMK):
When 802.1X is configured, MSK seeding material or keying material used to create Master Key called PMK. PMK is derived from MSK seeding material. PMK is first 256 bits of MSK. Now PMK is known to client (Supplicant) and Radius Server. PMK is sent via secure channel from Radius server to Access Point (Authenticator) in Access-Accept packet as attribute value pairs (Enc-RECV-Key)

When Personal/PSK is configured, the PSK will become the Pairwise Master Key (PMK), so basically the PSK is equal to the PMK.

Group Master Key (GMK):
The access point generates GMK simply by choosing a 256-bit cryptographic-quality random number. GMK may be regenerated at configured interval time to reduce the risk of GMK being compromised.

Pairwise Transient Key (PTK):
PTK is used to encrypt all unicast transmission between Access point & client. PTK is unique between a client and Access point. PTK is derived from PMK

PTK = PRF (PMK + Anonce + SNonce + MAC (AA)+ MAC (SA))

PMK
Anonce is a random number generated by an Access point/Authenticator
Snonce a random number generated by the Client/Supplicant
MAC addresses of Client/Supplicant
MAC address of Access point/Authenticator
PRF is a pseudo-random function which is applied to all the input.

PTK consist of 5 different keys

1. Key Confirmation Key (KCK)-is 128 bit long and used to provide data integrity during 4 -Way Handshake & Group Key Handshake.
2. Key Encryption Key (KEK) is 128 bit long and used by EAPOL-Key frames to provide data privacy during 4-Way Handshake & Group Key Handshake.
3. Temporal Key is 128 bit long and used to encrypt & decrypt MSDU of 802.11 data frames between supplicant & authenticator
4. Temporal MIC-1 is 64 bit long used only with TKIP configurations for unicast packets sent by access points for providing Message Authentication Codes (MACs)
5. Temporal MIC-2 is 64 bit long used only with TKIP configurations for unicast packets sent by clients for providing Message Authentication Codes (MACs)

Group Transient Key (GTK):
GTK is used to encrypt all broadcast/multicast transmission between Access point & multiple clients and it is shared to all the clients connected to Access point. GTK which is 256 bits is derived from the GMK by combining with a nonce value and the MAC address of the access point. Two keys are required:

Group Encryption key (128 bits)
Group Integrity key (128 bits)

Four-Way Handshake Flow

Message 1/4

Access point (Authenticator) sends EAPOL-Key frame containing an random number called ANonce to client (supplicant) with a Key Replay Counter, which is a number that is used to match each pair of messages sent, and discard replayed messages.

Now client knows its own SNonce and SA as well as the AA (from Beacons, Probe Response and/or Association Response) and PMK. Client have all necessary inputs to generate PTK using pseudo-random function(PRF)

PTK = PRF (PMK + Anonce + SNonce + MAC (AA)+ MAC (SA))

Message 2/4

Client (Supplicant) replies to the first EAPOL Key message, sends the used SNonce as clear text to the AP which is “protected” by a cryptographic hash (HMAC-SHA1) called Message Integrity Code (MIC) for integrity of the installed key on the client side. The Access point derive PTK and will generate its own MIC. Now Access point compare it with the MIC in this message, if they match, EAPOL-Key message 3 is send. This message also includes the Robust Security Network Information Element (RSN IE).

Message 3/4

This Message is the last unencrypted key message, as long as no retransmission(s) occur and the pairwise temporal key remains valid. Access point (Authenticator) sends EAPOL-Key frame containing ANonce, RSN-IE & MIC and informs the client about the installation of the PTK. If necessary, Access point (Authenticator) will derive GTK from GMK and the receive sequence counter (RSC) for the GTK. The GTK will be delivered to client and mentioned in the WPA Key Data field which is encrypted with the PTK.

Message 4/4

Client (Supplicant) sends final EAPOL-Key frame to Access point to acknowledges the installation of PTK and GTK afterwards, encrypted Unicast and Broad-/Multicast transmission can start now.

EAP-TLS

Extensible Authentication Protocol – Transport Layer Security which is defined in RFC 5216 required both client and server certificates for authentication. It is one of the strongest secure EAP method since both client and server are mutually authenticated with certificates.

Before starting EAP- TLS packet flow, we need to understand required certificates for the client and server to authenticate.

Assume CA-client issues the client (personal) certificate to the client, and CA-server issues the server certificate to the server. If the server want to authenticate client, the server will verify the client's digital signature in client certificate with the public key of CA-client. Similarly client will do the same.
For Server and Client authentication, server side requires

Server certificate issued to the server by CA-server
Server's private key
CA certificate of CA-client

and the client side requires

Client (personal) certificate issued to the client by CA-client
Client's private key
CA certificate of CA-server

Below is EAP-TLS Process (Image from CWSP study guide)

1. An optional "EAPOL-Start" frame sent from the client to the Access Point to trigger EAP authentication.

2. Access point sends "EAP Request, Identity" message to the client. There is an "EAP Response, Identity" message from the client to Access Point. Identity is the username configured in client. Access Point forward this EAP response to Radius server as Access Request.

EAP-Request, Identity

EAP-Response, Identity

3. Radius server sends Access-Challenge to Access Point with EAP type. Now Access point forward as EAP Packet Request to the client. Here check value of Type is "13" for EAP-TLS in Extensible Authentication Protocol and the start bit is set to "True".

NOTE: If EAP Request type value other than 13 and start bit set, then the client will respond with Legacy NAK and tells to Access Point that the desired auth type as EAP-TLS (13)

4) Once desired EAP-Type is confirmed, client sends "Client Hello" to Access point. This is forwarded to Radius server.
"Client Hello" message lists cryptographic information such as the TLS version, the CipherSuites, data compression methods supported by the client. This message also contains a random byte string that is used in subsequent computations and session ID.

5) Radius server responds with "Server Hello, Certificate, Certificate Request, Server Hello done" to the "Client Hello".
Server chose the CipherSuite from the list provided by the client in "Client Hello", the session ID, and another random byte string. The server also sends its digital certificate. If the server requires a client digital certificate for authentication, it sends a "Certificate Request" which includes a list of the types of certificates supported and the Distinguished Names of acceptable Certification Authorities (CAs).

6) Client sends "Certificate, Client Key Exchange, Certificate verify, Change cipher spec, Encrypted Handshake message" to Access point. This is forwarded to Radius server.
If the server asks "client certificate request", the client sends a random byte string encrypted with the client's private key, together with the client's digital certificate.
Client sends the random byte string which is encrypted with the server's public key that enables both the client and the server to compute the secret key to be used for encrypting subsequent message data.
Also client verifies the server's digital certificate signature with server's CA public key.

7) Radius server responds with "Change Cipher Spec, Encrypted Handshake" in response to the "Certificate, Client key exchange, Certificate verify, Change Cipher Spec, Encrypted Handshake".