Before we go through the SA query procedure , have a look at the below link about WPA3 4-way handshake and key hierarchy.

WPA3-Keys Generation

---

SA-Query Procedure

The below figure shows the one of the examples to know when this SA Query procedure is going to get triggered.

Test Scenario to trigger the SA Query Procedure

Below scenario is the one of the examples to trigger SA Query Procedure.

• AP and STA has a secure PMF Association.
• Now Assume that Attacker has Spoofed the MAC Address of a Connected Station and sends the Association Request to the AP.
• Now the AP gets the Association Request from the spoofed MAC Address , it wants to check whether the Association Request has come from the genuine client or from the Attacker. AP wants to check this because sometimes AP will still have the Valid Association even if the real client gets disconnected.
• Now the AP wants to check whether the real client still exists or it is a Fake Association Request.
• At this point AP triggers the SAQuery Procedure to know whether the client still exists.
  • Now the AP sends the SAQuery Request to the Client, If the client gives SAQuery Response, it means that the association request has come from the Fake client.
  • If the Client doesn’t give SAQuery response , it means that real client got disconnected.

SA Query Request/Response Frame Format

The below figure is the SA Query Frame Request Frame format. It is a Management Action Frame.

The below figure the SA Query Response Frame Format.

Here Transaction identifier is used to identify the SAQuery Session, and it going to be unique for the SAQuery Request/Response frames. This 2 Byte data is going to be the random from the initiator.

If the Initiator sends the SA Query request to the receiver, it has some 2 Byte transaction identifier and the receiver has to respond with the same transaction identifier to the initiator. We can’t see this in wireshark because it is encrypted.

Transaction Identifier is Unique for SA Query Procedure.

SA Query Request/Response Verification

Below capture shows the SAQuery Request and Response frame details. I have captured the required frames in wireshark. This SA Query Request and Response procedure has 12 Bytes of encrypted data.

Length of Encrypted Data for SA Query = 12 Bytes

SA Query Category : 1 Byte

SA Query Action : 1 Byte

SA Query Transaction ID : 2 Byte

CCMP MIC for Data : 8 Byte

Total = 12 Byte of Encrypted Data

Now we will decrypt the SA Query Request frame. Before we decrpyt the request frame we should be knowing the Temporal Key that got generated at the time of 4-way handshake. Verifying this SA Query procedure will be same for WPA2-PMF and WPA3 if we know the TK.

We use TK here, because the SA query frames are unicast.

SA Query Request Decrypt

Before we decrypt the SA Query Frames , we should know the what is the input that we are going to give to the CCMP program to decrypt the data.

Input to the CCMP to decrypt the SA Query Frames.

1) Temporal Key to the CCMP.

2) Packet Number (We can get this from the CCMP Header, we should properly pull the Packet Number from CCMP header)

3) Encrypted Frame. (output will be the plain text)

Now we will open the SA Query Request frame from wireshark and then we will decrypt the SA Query Request. We have to decrypt the data using the CCMP and it is not an easy task to that without private key.

We should properly give the input to the CCMP program, if not decryption will be failed.

Observe the below SAQuery Request Frame and its Encrypted data.

Now we will decrypt the SAQuery Request frame and observe the below details after the decryption. Once we decrypt the SA Query Request we will see the below info and we will get the plain text. The below figure shows the decrypted the SA Query Request frame and we can see the SA Query frame details in a clear text.

Note that In the above decryption process, we see the plain text data of SAQuery Request.

SA Query Category : 08

SA Query Request : 00

Transaction Identifier : 29 02

Note that Responder should also send SA Query Response with the same Transaction Identifier so that the initiator verifies that it has come from the genuine client and MIC will also get verified.

SA Query Response Decrypt

Now we will decrypt the SA Query Response and then we will verify the transaction identifier that is being sent in the SA Query Response frame.

Observe the below Wireshark capture for SA Query Response frame.

Now we will decrypt the SA Query response frame and then we will verify the text that is being sent in the SA Query response frame.

Now observe that the transaction identifier is same in the SA Query response as well. And the generated MIC also will get verified at the receiver to make sure that it has been sent from the genuine client.

Observe that the Transaction identifier is same in the Response as well, and it should be the same, if the TID is not same then SA Query procedure fails.

Note that In the above decryption process, we see the plain text data of SAQuery Response.

SA Query Category : 08

SA Query Response : 01

Transaction Identifier : 29 02 (It should be same as seen in the SA Query Request)

---

If the Transaction Identifier is not the same as what was sent in SA Query Request Frame , then the AP ignores the Response frame.

The same Transaction identifier should be maintained for the SAQuery Session.

So, This is how the SA Query Request and Response gets verified.

If you want to decrypt the traffic we should have the Temporal Key which is used to encrypt the Unicast data between client and AP. MIC value should also get verified properly based on the data that is being sent. If the MIC fails the AP/Client ignores the frames.