Use the TKs from the PTK file (-T command line argument) to try to
decrypt encrypted Management frames if no BSS/STA key can be found based
on addresses.
Signed-off-by: Jouni Malinen <j@w1.fi>
Extend the fils_pmk_to_ptk() to also derive Key Derivation
Key (KDK) which can later be used for secure LTF measurements.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Extend the wpa_pmk_r1_to_ptk() to also derive Key Derivation
Key (KDK), which can later be used for secure LTF measurements.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Verify that RSNE, MDE, and FTE have valid information in FT
Reassociation Response frames. In addition, decrypt GTK, IGTK, and BIGTK
from the frame.
Signed-off-by: Jouni Malinen <j@w1.fi>
It is expected for the STA entry on the target AP to move directly from
State 1 to State 3 when performing FT over-the-DS (i.e., FT Action
Request/Response frame exchange through the old AP followed by
Reassociation Request/Response frame exchange with the target AP).
Signed-off-by: Jouni Malinen <j@w1.fi>
Previously, missing CCMP protection on Robust Management frames was
reported based on the STA having indicated MFPC=1. That is not accurate
since the AP/BSS may have MFPC=0. Report this failure only if both the
AP and STA have indicated MFPC=1, i.e., when PMF has been negotiated for
the association.
Signed-off-by: Jouni Malinen <j@w1.fi>
If no Beacon or Probe Response frame has been seen in the capture, use
the IEs from EAPOL-Key msg 3/4 to set up BSS information.
Signed-off-by: Jouni Malinen <j@w1.fi>
The previous implementation tried to update STA IE information based on
EAPOL-Key msg 2/4 to be able to handle captures that do not include the
(Re)Association Request frame. This was not sufficient (OSEN was not
included) and was done too late (the parsed information is needed for
PMK-to-PTK derivation).
Move the IE update step to happen before trying to derive the PTK if no
(Re)Association Request frame has been seen.
Signed-off-by: Jouni Malinen <j@w1.fi>
Fetch the BIGTK from EAPOL-Key msg 3/4 and use it to validate MME in
Beacon frames when the AP uses Beacon protection.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Track PMK-R0/PMK-R0-Name from the initial mobility domain association
and derive PMK-R1/PTK when the station uses FT protocol. This allows
frames from additional roaming cases to be decrypted.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
If a sniffer capture does not include FCS for each frame, but may
included frames with invalid FCS, it would be possible for wlantest to
try to decrypt the first received frame and fail (e.g., due to CCMP MIC
mismatch) because that particular frame was corrupted and then ignore
the following retry of that frame as a duplicate even if that retry has
different payload (e.g., if its reception did not show corruption).
Work around this by skipping duplicate frame detection immediately
following a decryption failure.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
This part is missing from IEEE Std 802.11ai-2016, but the lack of DHss
here means there would not be proper PFS for the case where PMKSA
caching is used with FILS SK+PFS authentication. This was not really the
intent of the FILS design and that issue was fixed during REVmd work
with the changes proposed in
https://mentor.ieee.org/802.11/dcn/17/11-17-0906-04-000m-fils-fixes.docx
that add DHss into FILS-Key-Data (and PTK, in practice) derivation for
the PMKSA caching case so that a unique ICK, KEK, and TK are derived
even when using the same PMK.
Note: This is not backwards compatible, i.e., this breaks PMKSA caching
with FILS SK+PFS if only STA or AP side implementation is updated.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Try to derive PTK when FILS shared key authentication is used without
PFS. The list of available PMKs is interpreted as rMSK for this purpose
and PMK and PTK is derived from that. If the resulting PTK (KEK) can be
used to decrypt the encrypted parts of (Re)Association Request/Response
frames, mark the PTK as derived so that encrypted frames during the
association can be decrypted. In addition, write a decrypted version of
the (Re)Association Request/Response frames into the output file.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This adds minimal support for deriving keys for FT-PSK to allow the
initial mobility domain association to be analyzed in more detail.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Remove the length field from struct ieee802_11_elems since the only
allowed element length is five and that is checked by the parser.
Signed-off-by: Jouni Malinen <j@w1.fi>
These functions did not verify that the received frame is long enough to
contain the beginning of the variable length IE area. A truncated frame
could have caused a segmentation fault due to reading beyond the buffer.
Signed-off-by: Jouni Malinen <j@w1.fi>
This modifies struct wpa_ptk to allow the length of KCK and KEK to be
stored. This is needed to allow longer keys to be used, e.g., with
Suite B 192-bit level.
Signed-off-by: Jouni Malinen <j@w1.fi>
This adds debug information from wlantest into pcapng frame comments to
make the information more convenient to use, e.g., in Wireshark.
Signed-hostap: Jouni Malinen <j@w1.fi>
These can be useful in tests involving association state mismatch
between the AP and the STA (i.e., STA assumes it is still associated
but the AP does not have association state). In such a case, the AP
would be sending out unprotected Deauthentication or Disassociation
frames with reason code 6 or 7 depending on what frame is triggering
this.
The Timeout Interval element needs to use Association Comeback time
for the case when (Re)Association Response frame uses Status Code 30.
Verify this before incrementing the (re)assocresp_comeback counters.
The output file includes all the capture (or read from wireless PCAP
file) frames in their original contents and another copy of each
frame that is decrypted in wlantest (including EAPOL-Key Key Data
field).
Allow pre-configuration of passphrases (-p<passphrase>) to provide
enough information for wlantest to be able to derive PMK for each
BSS and PTK for each STA going through 4-Way Handshake (at least
message 2 and 3 needs to be received).
