I suggest reading through the relevant standards yourself; they are available for free from IEEE.
"WPA2" was originally defined in amendment 802.11i, but has been integrated into the main 802.11 document in the later versions, so you can search either for the original 802.11i-2004 document or the full 802.11-2020 (section 12 "Security").
WPA/WPA2 build on the 802.1X standard used for authentication in wired LANs; see 802.1X-2020 for some additional details.
I am capturing a wpa2 handshake with wireshark, and there is the type value of 03 which is a key I wonder if this type is constant for wpa2 handshakes, also the value of other types, if there were to be, for example what does 01 or 02 or 04 would have looked like if the access point were to use that ?
IEEE 802.11i-2004 (which defines RSN aka "WPA2") says:
The fields of a EAPOL-Key frame are as follows:
a)Descriptor Type. This field is one octet and has a value defined by IEEE P802.1X-REV, identifying the IEEE 802.11 key descriptor.
Within IEEE 802.1X-2010, table 11-5 has the following key types defined:
Assignment |
Value |
RC4 Key Descriptor Type (deprecated) |
1 |
IEEE 802.11 Key Descriptor Type |
2 |
There is no explanation for the use of RC4 in the 802.1X standard, but it's highly likely to be the "Dynamic WEP" or "WEP (802.1X)" mechanism that was the predecesor of WPA-Enterprise, as it did use EAP (and presumably EAPOL) to produce an RC4 WEP key.
What does install do exactly ? it is sent by the router only on the 3rd way of the handshake, it means the mic is confirmed and the client can install the keys on its local machine ?
Yes, it's the point where the client will enable traffic encryption.
IEEE 802.11i says in section "8.5.3.7 4-Way Handshake analysis (informative)":
Message 1 delivers ANonce to the Supplicant and initiates negotiation for a new PTK. It identifies AA as the peer STA to the Supplicant’s STA. If an adversary modifies either of the addresses or ANonce, the Authenticator will detect the result when validating the MIC in Message 2. Message 1 does not carry a MIC, as it is impossible for the Supplicant to distinguish this message from a replay without maintaining state of all security associations through all time (PMK might be a static key).
Message 2 delivers SNonce to the Authenticator so it can derive the PTK. If the Authenticator selected ANonce randomly, Message 2 also demonstrates to the Authenticator that the Supplicant is live, that the PTK is fresh, and that there is no man-in-the-middle attack, as the PTK includes the IEEE 802 MAC
addresses of both. Inclusion of ANonce in the PTK derivation also protects against replay. The MIC prevents undetected modification of Message 2 contents.
Message 3 confirms to the Supplicant that there is no man-in-the-middle attack. If the Supplicant selected SNonce randomly, it also demonstrates that the PTK is fresh and that the Authenticator is live. The MIC again prevents undetected modification of Message 3.
While Message 4 serves no cryptographic purpose, it serves as an acknowledgment to Message 3. It is required to ensure reliability and to inform the Authenticator that the Supplicant has installed the PTK and GTK and hence can receive encrypted frames.
Also, on 3rd handshake of the wpa 4-way handshake (the router sends), I see something as wpa key data, is this what is used for encrypting/decrypting or is it the actual data that is encrypted? if it is encrypted.. what data does it contain ?
Again from IEEE 802.11i, it contains:
Key Data = the AP’s Beacon/Probe Response frame’s RSN information element, and, optionally, a second RSN information element that is the Authenticator’s pairwise cipher suite assignment, and, if a group cipher has been negotiated, the encapsulated GTK and the GTK’s key identifier (see 8.5.2)
Actual encrypted traffic won't be carried in EAPOL frames.