# Why does WPA2-PSK use 4-way handshake instead of 2-way handshake

I don't seem to grasp why is the handshake for PTK in WPA2-PSK 4-way and not 2-way. Isn't it enough to just have these two steps:

1. First party sends Nonce1 to the other party
2. Second party sends to first party Nonce2 and the HMAC(Nonce1, Nonce2, other parameters) using KCK.

I don't understand why does first party have to confirm that it received the nonce and that it knows the shared secret. In fact, even HMAC(Nonce1, Nonce2, etc.) computation is not extremely necessary. Or is it? I mean even if they don't share the same secret, they wouldn't be able to read each other's messages. Of course, communication wouldn't happen, but there's no information leakage either. Or is there?

-

No, two messages is not sufficient to achieve what the WPA2-PSK 4WHS is supposed to do: mutual authenticated key-exchange.

The key term here is mutual authentication. Remember, at the start of the WPA2-PSK handshake we have two entities, the access point and the client, holding (hopefully) the same key, also known as the pairwise master key (PMK). Now they want to authenticate themselves by proving that they are both in possession of the PMK. This is the point of the 4WHS (in addition to establishing session keys).

Now let us consider your suggestion: (1) First party (assume this is the access point, as in WPA2) sends a nonce $N_A$ to the other party (the client). (2) Client responds with his own nonce $N_C$, the access point nonce $N_A$ and potentially some other stuff, and computes an HMAC tag on it using PMK. (3) The access point verifies the response from the client using the PMK. At this point, what can the two parties be sure of?

For the client, the answer is: Nothing! Remember, all the client sees is a lonely nonce $N_A$. This could have been created and sent by anyone. Hence the client can have no guarantee that he is actually talking to the right access point.

For the access point, the situation is slightly better. Since he receives back the nonce he himself created ($N_A$), he can be reasonably certain about the freshness of the response (i.e. this is not a replay), and since the HMAC tag checks out he can be certain that the client must also be in possession of the PMK. (Digression: It is however bad form to use long term keys, like the PMK, directly in your cryptographic computations. Usually one derives temporary keys which are used instead. This is also done in WPA2). Hopefully, this also makes it clear why we need the HMAC tag. It is there to convince the other side that it is in possession of the PMK (and of course to detect tampering, but which is aside the point here).

More generally, in an authentication protocol based on nonces, at least three messages are needed in order to establish mutual authentication. With two messages or less, you would also have to use something like a time-stamp in order to ensure mutual authentication (however, this is non-trivial to do correctly in practice and even harder to model theoretically, see for instance: Modelling Time, or A Step Towards Reduction-based Security Proofs for OTP and Kerberos). Why WPA2 uses 4 messages instead of just 3 I am not sure, however it is similar to the 4WHS in TLS, which also uses the last message to "install" the generated keys.

-
Thanks a lot for your response. I can understand more now. However, even if the client doesn't authenticate the other party, isn't it obvious that it will figure out that the other party doesn't have the PMK, and, consequently, the right sessions keys in the first conversation already? I mean the attacker still doesn't know the PMK, so it wouldn't be able to compute the right sessions keys, which means it wouldn't be able to decrypt messages. Also it wouldn't be able to encrypt them either. Or am I missing something here? – elena Nov 27 '13 at 21:51

The authenticator needs to send "Group Key" to the supplicant. This is why the 3rd message is required, therefore the 4th as an ack from supplicant to authenticator.

-