Negotiation of Security Association (SA) parameters is crucial for Robust Security Network Association (RSNA) establishment.
Access Points (APs) broadcast supported security features via beacon or probe response frames.
Stations (STAs) negotiate security parameters during association, reassociation, or SA establishment.
Methods for PMKSA Establishment
Two primary methods exist for establishing a Pairwise Master Key Security Association (PMKSA):
Personal (PSK-based):
Both the AP and STA possess a Pre-Shared Key (PSK), which is used to derive the Pairwise Master Key (PMK).
SAE (Simultaneous Authentication of Equals) requires four authentication messages to derive a PMK based on the PSK.
Proof of PMK knowledge during the 4-way handshake mutually authenticates the STA and AP and establishes the Pairwise Transient Key (PTK).
Enterprise (802.1X-based):
The supplicant authenticates directly with the Authentication Server (AS) through the AP, which acts as a pass-through for the authentication credentials.
Upon successful authentication by the AS, the PMK is securely sent from the AS to the AP, enabling the AP and the supplicant to engage in the 4-way handshake to establish the PTK.
4-Way Handshake
Involves the exchange of nonces in plaintext, followed by Robust Security Network Element (RSNE) with integrity protection for the negotiation of SA parameters.
Includes the cryptographically protected delivery of temporary keys (Group Temporal Key [GTK], Individual GTK [IGTK], Broadcast Integrity GTK [BIGTK]) to group members.
After a PTKSA is established, the AP permits the STA to communicate encrypted with the Distribution System (DS).
A PTKSA refers to temporary keys used for the protection of each session.
GTKSA Establishment
The establishment of a Group Temporal Key Security Association (GTKSA) is part of either the 4-way handshake or a separate handshake that leads to the agreement of a group key (GTK) derived from a Group Master Key (GMK).
GTK: A key shared between all STAs associated with the same AP.
The PMK differs from the GMK; each PMK corresponds one-to-one between an STA and the AP; the AP controls GTK generation (from the GMK) via key transport.
In Independent Basic Service Set (IBSS) or Personal Basic Service Set (PBSS), each STA defines its own GTKSA used to encrypt group-addressed transmissions and stores a separate GTKSA for each peer STA for decrypting encrypted group-addressed traffic.
SMKSA and TPKSA
A Shared Master Key Security Association (SMKSA) or Tunneled Peer Key Security Association (TPKSA) protects direct communication between two STAs that have an RSNA with the same AP.
For SMKSA, an STA (initiator) requests the AP to establish an SMKSA with another STA (peer). The AP sends the same key (SMK) to both STAs, enabling secure direct communication.
This function is crucial for real-time applications sensitive to delays, especially if the network APs are overloaded.
Direct Link Setup (DLS): Ratified in 802.11e-2005, was the first to introduce direct STA-to-STA frame transfer within a BSS (Basic Service Set).
DLS requires the AP, but few APs supported this.
The SMKSA (and the Station Key Security Association [STKSA] derived from it) for secure DLS are built using the PeerKey handshake, according to the 802.11-2016 standard.
Tunneled Direct Link Setup (TDLS): Published as 802.11z-2010, enables more efficient STA-to-STA direct communication without AP support. A TDLS direct link is established between the STAs, maintaining the connection with the AP for both STAs.
The TDLS PeerKey (TPK) security association (TPKSA) results from a successful completion of the TPK handshake and secures a TDLS session.
Nearby communication between STAs not associated with the same AP can be achieved using Wi-Fi Direct (also known as Wi-Fi P2P).
TDLS optimizes network utilization, while Wi-Fi Direct quickly connects devices even without a Wi-Fi network.
Pairwise vs. Group Keys
Pairwise keys are used for one-to-one communication.
Group keys are shared among multiple devices, used for one-to-many communication.
RSNE
STAs and APs negotiate RSNA parameters using RSNE (Robust Security Network Element).
A STA sends RSNES to APs via association or reassociation requests.
An AP sends RSNES to STAS via beacon and probe response frames.
An RSNE (maximum length = 255 bytes) includes:
An element ID (element ID = 48).
Length and version (version = 1) fields of the RSNA protocol.
Group Data Cipher Suite: Indicates the confidentiality and integrity algorithms to be used for protecting broadcast/multicast data frames in the BSS. Length: 0 or 4 bytes. Values include: 00-0F-AC:00 (Use group cipher suite), 00-0F-AC:01 (WEP), 00-0F-AC:02 (TKIP), 00-0F-AC:04 (CCMP) default, 00-0F-AC:05 (WEP-104), 00-0F-AC:06 (BIP-CMAC-128), 00-0F-AC:08 (GCMP-128), 00-0F-AC:09 (GCMP-256), 00-0F-AC:10 (CCMP-256).
Pairwise Cipher Suite Count: Records the number of different pairwise cipher suites proposed or published. Length: 0 or 2 bytes.
Pairwise Cipher Suite List: Four times the length of the previous field (0 or 4×m bytes).
When a STA supports several ciphers, it will attempt to choose the strongest cipher that is supported by both the STA and the AP. These suites are used in the context of Group Data Cipher Suite, Pairwise Cipher Suite, and Group Management Cipher Suite
Broadcast/multicast integrity protocol (BIP)
Authentication and Key Management (AKM) Suite Count (AKMC)
The standard defines AKM suite selectors with the format Organizationally Unique Identifier (OUI):N.
Some AKM methods are:
00-0F-AC:1: Authentication negotiated over IEEE 802.1X.
00-0F-AC:2: PSK.
00-0F-AC:3: Fast BSS Transition authentication negotiated over IEEE 802.1X using SHA-256 for key derivation.
00-0F-AC:4: Fast BSS Transition authentication negotiated over PSK.
00-0F-AC:5: Authentication negotiated over IEEE 802.1X or using PMKSA caching using SHA-256 for key derivation.
00-0F-AC:6: PSK using SHA-256 for key derivation.
00-0F-AC:7: TDLS using SHA-256 for key derivation.
00-0F-AC:8: SAE.
00-0F-AC:9: Fast BSS Transition over SAE.
00-0F-AC:10: APPeerKey: Authentication with SHA-256.
00-0F-AC:11: 802.1X with suite B compliant EAP SHA-256.
00-0F-AC:12: 802.1X with suite B compliant EAP SHA-384.
00-0F-AC:14: AES-SIV-256.
00-0F-AC:15: AES-SIV-512.
00-0F-AC:13: FT authentication negotiated over IEEE Std 802.1X
00-0F-AC:19: FT authentication using PSK and SHA-384 for key derivation
00-0F-AC:20: PSK using SHA-384 for key derivation
Vendor-specific AKM mechanisms may be added.
AKM suite list: Contains the list of AKM suites, with a length four times the AKMC value.
RSN Capabilities
Contains subfields:
Preauthentication (bit 0): Indicates AP support for preauthentication.
No Pairwise (bit 1): Indicates a non-AP STA's capability; IBSS STAs and APs set this to 0. Set to 0 if the
STA supports WEP default key 0 and pairwise keys simultaneously. Set to 1 if simultaneous support is not possible.This bit is set to 1 in a TSN when the STA selects TKIP as the pairwise cipher suite
Replay counters (bits 2-3, 4-5): Define the number of replay counters supported per PTKSA and GTKSA, respectively (1, 2, 4, 16 replay counters, with values 0, 1, 2, 3). Separate replay counter per frame priority.
Joint Multi-band RSNA (bit 8): A single 4-way handshake can establish PTKSAs for multiple bands.
PeerKey enabled (bit 9): Signals support for PeerKey/TPK handshake.
Protected block ack agreement capable (PBAC) (bit 12): Indicates support for Protected Block Ack Agreement, which reduces protocol overhead and increases network throughput.
Extended Key ID for Individually Addressed Frames (bit 13): Set to 1 to indicate that the STA supports Key ID values in the range 0 to 1 for a PTKSA when the cipher suite is CCMP or GCMP. If set to 0, it indicates that the STA only supports Key ID 0 for a PTKSA - This info is used during the 4-way handshake (msg. 3). Note that the Key ID is used as an input to the TK derivation process, allowing for the generation of two distinct TKs from the same PTKSA
PMKID
PMKID Count (PMKC): Records the number of PMKIDS in an RSNE.
PMKID List: Contains a list of zero or more PMKIDS.
A PMKID may refer to:
A cached PMKSA created through preauthentication against the specific AP (following an initial EAP (802.1X) authentication).
A cached PMKSA created through EAP (802.1X) or SAE authentication.
A cached PMKSA created through a PSK.
A STA may choose not to include a PMKID in the RSNE field if it does not intend to use that specific PMKSA (indicating that the PMKID is not applicable).
PMK Caching (also known as “fast secure roam-back") was introduced in IEEE 802.11i-2004. It allows a STA that has previously authenticated with an AP to bypass a full authentication exchange upon reconnection. Instead, only the 4-way handshake is performed to re-establish the transient encryption keys (PTK, GTK, etc.). This mechanism is distinct from preauthentication.
PMK Caching and Fast Secure Roam-back
STA roams back to a previous AP using cached PMKIDs to execute only the 4-way handshake.
Group Management Cipher Suite
Contains the cipher suite selector used to protect group-addressed robust management frames.
When Management Frame Protection is negotiated, the negotiated pairwise cipher suite protects unicast management frames, and the group management cipher suite protects group-addressed robust management frames.
RSNE Structure
RSNE field order shows various parameters like element ID, length, version, cipher suites, AKM suites, RSN capabilities, PMKID, and group management cipher suite.
Example RSNE Information from Beacon Frame:
Tag Number: RSN Information (48)
Tag length and RSN Version are specified.
Group Cipher Suite is AES (CCM).
Pairwise Cipher Suite Count: 1
Pairwise Cipher Suite List: AES (CCM)
Auth Key Management (AKM) Suite Count: 2. Lists PSK and SAE (SHA256).
RSN Capabilities and their configurations are detailed.
Transmitter capabilities on pre-authentication, pairwise keys, replay counters, and management frame protection.
Joint Multi-band RSNA and PeerKey status.
RSN SA Establishment
Various messages and protocols are needed for RSNA establishment.
RSNA contains security associations: PMKSA, PTKSA, and optionally GTKSA, IGTKSA, BIGTKSA, SMKSA, TPKSA, etc.
Protocols involved are described.
RSN Capabilities Announcement
APs announce their RSN capabilities through RSNES in beacon or probe response frames.
If RSNES differ between beacon and probe response messages, the STA uses the one in the probe response message, because the Probe Response is a direct answer to a specific query from the STA.
Open System Authentication
After learning the AP's RSN capabilities, the STA uses the open system process to announce its identity to the AP.
No cryptographic protection is provided at this stage, unless SAE is employed
In WPA3-Personal, SAE authentication based on the Dragonfly Key Exchange is used to calculate the PMK with Elliptic-curve cryptography (ECC).
SAE assumes the exchange of 4 authentication frames sent in the so-called "Commit” and “Confirm" pairs between the STA and the AP, and in a BSS it is always initiated by the STA
802.11 Association
Parameter negotiation takes place during the association or reassociation of an STA with the AP.
The STA selects its security parameters, choosing those common with the AP's RSNE.
These include pairwise cipher suite, authentication and key management suite, group data cipher suite, and group management suite.
The STA creates an RSNE with selected parameters and, in case of reassociation, adds any PMKID it maintains with the AP.
It sends the RSNE as part of the (re)association request to the AP.
Mutual Authentication
The 802.11 standards define three basic authentication methods: PSK, SAE, and 802.1X.
PSK, SAE: PMK is derived from PSK, or generated using ECC algorithm
802.1X: The AP (Authenticator) transmits EAP messages between the STA (supplicant) and the AS. After successful authentication, the STA and the AS create the PMK, which the AS notifies to the AP over a secure channel (e.g., RADIUS over TLS/DTLS).
RSNA Establishment Flowchart
The process includes beacon, probe requests/responses, SAE authentication, open System authentication, (re)association requests/responses, 802.1X authentication, 4-way handshake, and group key handshake.
EAPOL Exchange
The authenticator can initiate an Extensible Authentication Protocol over LAN (EAPOL) exchange by sending an EAP-Request-Identity frame to refresh the keys.
Steps include association requests/responses, EAPOL-Start, EAP-Request/Identity, EAP-Response/Identity, EAP-Request/Method, EAP-Response/Method, EAP-Success, EAPOL-Key, and data exchange.
4-Way Handshake
It is the final step for RSNA establishment.
It creates PTK for frame protection.
It authenticates the negotiation procedure during (re)association.
It creates additional keys for protecting the messages of the 4-way handshake.
The handshake is initiated by the AP.
Two parties exchange nonces, which are used in the derivation of the PTK from the PMK.
The AP delivers the GTK for protecting group communications, and optionally IGTK and BIGTK for protecting robust management frames.
The integrity of messages 2 through 4 of the 4-way handshake is ensured. Therefore, nonces and RSNES cannot be altered without the recipient noticing.
Group keys (GTK, IGTK, BIGTK) are transmitted encrypted by the AP within the third message of the 4-way handshake.
Group Key Handshake
The AP can send the encrypted GTK, IGTK, and BIGTK to the STA as part of a separate 2-message handshake to avoid performing a full 4-way handshake when only the group keys need to be updated.
The GTK is accompanied by a sequence number to protect against replay of multicast or broadcast data messages from the AP to the member STAS.
The IGTK and BIGTK are used to protect the integrity of group-addressed management frames and broadcast management frames, respectively.
SMKSA/TPKSA Establishment
After completing the 4-way handshake and regardless of group key exchange, an STA can request the AP to establish an SA with another STA (SMKSA) associated with the same AP.
If the AP has already completed the 4-way handshake with the second STA, it creates the SMKSA first with that STA (peer) and then with the requesting STA (initiator).
TPKSA establishment is similar to SMKSA.
Upon completion of the above steps and using the PTK (and optionally GTK, IGTK, BIGTK) and the cipher suites negotiated by the two parties, the STA and the AP can exchange data and use the corresponding security services (confidentiality, integrity, anti-replay, etc.).
Enterprise 802.11 RSNA: Authentication
After completing the security parameter negotiation, and once the two parties agree on a mutually acceptable identity authentication mechanism, the STA and the AS exchange EAP messages with the help of the AP.
The most preferred method for creating the PMK in an Enterprise RSN is through mutual authentication, which is critical for establishing a secure key. The standard recommends the use of asymmetric EAP methods, such as those employing public-key cryptography.
This is because using the same secret (password) for both AS and STA authentication effectively reduces security to that of a PSK, negating the benefits of 802.1X
*Two of the strongest EAP methods, which ensure that STA identity authentication is conducted over a protected channel, are PEAP and EAP-TTLS.
The communication between the AP (Authenticator) and the AS must be secured by mechanisms outside of 802.11, such as RADIUS over TLS (RadSec - RFC 6614) or IPsec, to protect the sensitive authentication data
*Note that the "preference" is driven by security needs, not just arbitrary choice
PMK caching, preauthentication, and fast BSS transition procedures, specifically 802.11r (also known as fast roaming), are employed to mitigate the overhead
PMKSA Caching and Reuse
Each PMKSA has a unique identifier (PMKID). By including this in the first message of the 4-way handshake, the AP helps both itself and the STA quickly establish the PTKSA by referencing a pre-existing PMKSA
PMKID Calculation Formulas:
If the negotiated AKM is 00-OF-AC:5 or 00-OF-AC:6, or 00-OF-AC:11 then PMKID=Truncate−128(HMAC−SHA−256(PMK,"PMKName"∣∣AA∣∣SPA))
If the negotiated AKM is 00-OF-AC:12, then PMKID=Truncate−128(HMAC−SHA−384(PMK,"PMKName"∣∣AA∣∣SPA))
Inactivity: If a STA hasn't been active for a certain period.
Cache Full: To make space for new entries.
Security Policies: Changes in security configurations.
AP Reboot or Software Update: Events that typically clear the cache.
The STA is required to repeat the identity authentication procedures (SAE or 802.1X) and the 4-way handshake in these cases.
Pre-authentication process
RSNs support the pre-authentication process to expedite potential handoffs, relying on the 802.1X and EAP framework.
Before an STA handoff to another BSS, the STA may decide to pre-authenticate to an AP with which it is likely to associate in the future, which accelerates the association process with the destination AP, establishing a new PMKSA between the STA and the destination AP.
The STA sends an 802.1X/EAP identity authentication request to the current AP, but with the DA field in the MAC header referring to the destination AP.
The destination AP then communicates with the authentication server to complete the 802.1x/EAP process, and current AP acts as a proxy for the mutual authentication of the STA with the destination AP
After successful authentication, the STA and the destination AP store the PMK and PMKID and proceeds with the 4-way handshake.
PSK-Based Methods
IEEE 802.1X/EAP can provide strong authentication service, it is not easily implementable in terms of cost and management procedures for SOHO environments and a solution here would be for the AP to provide AS services
Otherwise, a PSK that is installed on both the STA and the AP should be used. This is the case of 802.11 Personal setup. In this way, the PSK acts as PMK. This does not apply to SAE authentication. SAE generates a PMK using ECC, with the Wi-Fi passphrase as a password
Weaknesses of PSK-Based Methods
PSK is generated from a passphrase entered by the administrator and then extended by the system. It's vulnerable to offline dictionary attacks.
PBKDF2 (Password-Based Key Derivation Function 2) is a key derivation function. These types of functions are used to reduce susceptibility to brute-force attacks due to the high computational cost.
DK equals PBKDF2(PRF, password, Salt, c, len), where "DK" is the generated derived key, “PRF" is a pseudorandom function, such as HMAC-SHA-1 or HMAC-SHA-256, "password" is the master secret from which a derived key is generated, “salt” is a sequence of bits (the cryptographic salt), c is the desired number of iterations, and