Some legacy stations copy previously reserved RSN capability bits,
including OCVC, in (Re)Association Request frames from the AP's RSNE but
do not indicate MFP capability and/or do not send OCI in RSN handshakes.
This is causing connection failures with such erroneous STAs.
To improve interoperability with such legacy STAs allow a workaround OCV
mode to be enabled to ignore OCVC=1 from the STA if it does not follow
OCV requirements in the first protected exchange. This covers cases
where a STA claims to have OCV capability, but it does not negotiate use
of management frame protection or does not include OCI in EAPOL Key msg
2/4, FT Reassociation Request frame, or FILS (Re)Association Reqest.
The previous behavior with ocv=1 is maintained, i.e., misbehaving STAs
are not allowed to connect. When the new workaround mode is enabled with
ocv=2, the AP considers STA as OCV capable on below criteria
- STA indicates both OCV and MFP capability
- STA sends OCI during connection attempt in a protected frame
Enabling this workaround mode reduced OCV protection to some extend
since it allows misbehavior to go through. As such, this should be
enabled only if interoperability with misbehaving STAs is needed.
Signed-off-by: Veerendranath Jakkam <vjakkam@codeaurora.org>
Allow STA entry to be removed and re-added to the driver with PMF is
used with FT. Previously, this case resulted in cfg80211 rejecting STA
entry update after successful FT protocol use if the association had not
been dropped and it could not be dropped for the PMF case in
handle_auth().
Signed-off-by: Jouni Malinen <j@w1.fi>
Support Extended Key ID in hostapd according to IEEE Std 802.11-2016.
Extended Key ID allows to rekey pairwise keys without the otherwise
unavoidable MPDU losses on a busy link. The standard is fully backward
compatible, allowing an AP to serve STAs with and without Extended Key
ID support in the same BSS.
Signed-off-by: Alexander Wetzel <alexander@wetzel-home.de>
This is a workaround needed to keep FT protocol backwards compatible for
the cases where either the AP or the STA uses RSNXE, but the other one
does not. This commit adds setting of the new field to 1 in
Reassociation Request/Response frame during FT protocol when the STA/AP
uses RSNXE in other frames. This mechanism is described in 20/332r3.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
This is needed to be able to compare the received RSNXE to a protected
version in EAPOL-Key msg 2/4.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Hardcode this to be defined and remove the separate build options for
PMF since this functionality is needed with large number of newer
protocol extensions and is also something that should be enabled in all
WPA2/WPA3 networks.
Signed-off-by: Jouni Malinen <j@w1.fi>
This is needed to allow PTK rekeying to be performed through 4-way
handshake in an association started through FT protocol.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
FT rules for PTK derivation do not use PMK. Remove the unused argument
to the PTK derivation function.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Use Diffie-Hellman key exchange to derivate additional material for
PMK-to-PTK derivation to get PFS. The Diffie-Hellman Parameter element
(defined in OWE RFC 8110) is used in association frames to exchange the
DH public keys. For backwards compatibility, ignore missing
request/response DH parameter and fall back to no PFS in such cases.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Derive PMKR1Name during the FILS authentication step, verify that the
station uses matching PMKR1Name in (Re)Association Request frame, and
add RSNE[PMKR1Name] into (Re)Association Response frame when going
through FT initial mobility domain association using FILS. These steps
were missed from the initial implementation, but are needed to match the
IEEE 802.11ai requirements for explicit confirmation of the FT key
hierarchy (similarly to what is done in FT 4-way handshake when FILS is
not used).
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
The MIC field is now a variable length field, so make FTE generation in
hostapd aware of the two different field lengths.
Signed-off-by: Jouni Malinen <j@w1.fi>
FILS calls wpa_ft_store_pmk_r0() from wpa_auth.c. This is moved into a
new function wpa_ft_store_pmk_fils() in preparation of additional
information being needed.
Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
Previously, the association that used SAE authentication ended up
recalculating the PMKID for EAPOL-Key msg 1/4 using incorrect
PMK-to-PMKID derivation instead of using the previously derived PMKID
from SAE. The correct PMKID was used only when going through PMKSA
caching exchange with a previously derived PMKSA from SAE.
Fix this by storing the SAE PMKID into the state machine entry for the
initial SAE authentication case when there is no explicit PMKSA entry
attached to the station.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
This allows hostapd testing functionality to be forced to send out a
plaintext EAPOL-Key frame with the RESEND_* command. That can be useful
in seeing how the station behaves if an unencrypted EAPOL frame is
received when TK is already configured.
This is not really perfect since there is no convenient way of sending
out a single unencrypted frame in the current nl80211 design. The
monitor interface could likely still do this, but that's not really
supposed to be used anymore. For now, clear and restore TK during this
operation. The restore part is not really working correctly, though,
since it ends up clearing the TSC value on the AP side and that shows up
as replay protection issues on the station. Anyway, this is sufficient
to generate sniffer captures to analyze station behavior.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This was originally added to allow the IEEE 802.11 protocol to be
tested, but there are no known fully functional implementations based on
this nor any known deployments of PeerKey functionality. Furthermore,
PeerKey design in the IEEE Std 802.11-2016 standard has already been
marked as obsolete for DLS and it is being considered for complete
removal in REVmd.
This implementation did not really work, so it could not have been used
in practice. For example, key configuration was using incorrect
algorithm values (WPA_CIPHER_* instead of WPA_ALG_*) which resulted in
mapping to an invalid WPA_ALG_* value for the actual driver operation.
As such, the derived key could not have been successfully set for the
link.
Since there are bugs in this implementation and there does not seem to
be any future for the PeerKey design with DLS (TDLS being the future for
DLS), the best approach is to simply delete all this code to simplify
the EAPOL-Key handling design and to get rid of any potential issues if
these code paths were accidentially reachable.
Signed-off-by: Jouni Malinen <j@w1.fi>
Do not reinstall TK to the driver during Reassociation Response frame
processing if the first attempt of setting the TK succeeded. This avoids
issues related to clearing the TX/RX PN that could result in reusing
same PN values for transmitted frames (e.g., due to CCM nonce reuse and
also hitting replay protection on the receiver) and accepting replayed
frames on RX side.
This issue was introduced by the commit
0e84c25434 ('FT: Fix PTK configuration in
authenticator') which allowed wpa_ft_install_ptk() to be called multiple
times with the same PTK. While the second configuration attempt is
needed with some drivers, it must be done only if the first attempt
failed.
Signed-off-by: Mathy Vanhoef <Mathy.Vanhoef@cs.kuleuven.be>
This new AKM is used with DPP when using the signed Connector to derive
a PMK. Since the KCK, KEK, and MIC lengths are variable within a single
AKM, this needs number of additional changes to get the PMK length
delivered to places that need to figure out the lengths of the PTK
components.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Derive PMK-R0 and the relevant key names when using FILS authentication
for initial FT mobility domain association.
Signed-off-by: Jouni Malinen <j@w1.fi>
Enable use of FT RRB without configuring each other AP locally. Instead,
broadcast messages are exchanged to discover APs within the local
network.
When an R0KH or R1KH is discovered, it is cached for one day.
When a station uses an invalid or offline r0kh_id, requests are always
broadcast. In order to avoid this, if r0kh does not reply, a temporary
blacklist entry is added to r0kh_list.
To avoid blocking a valid r0kh when a non-existing pmk_r0_name is
requested, r0kh is required to always reply using a NAK. Resend requests
a few times to ensure blacklisting does not happen due to small packet
loss.
To free newly created stations later, the r*kh_list start pointer in
conf needs to be updateable from wpa_auth_ft.c, where only wconf is
accessed.
Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
This adds a counter and adds sequence numbering to FT RRB packets. The
sequence number is checked against r0kh/r1kh sequence number cache.
Special attention is needed in case the remote AP reboots and thus loses
its state. I prefer it to recover automatically even without synchronized
clocks. Therefore an identifier called dom is generated randomly along the
initial sequence number. If the dom transmitted does not match or the
sequence number is not in the range currently expected, the sender is asked
for a fresh confirmation of its currently used sequence numbers. The packet
that triggered this is cached and processed again later.
Additionally, in order to ensure freshness, the remote AP includes an
timestamp with its messages. It is then verified that the received
messages are indeed fresh by comparing it to the older timestamps
received and the time elapsed since then. Therefore FT_RRB_TIMESTAMP is
no longer needed.
This assigns new OUI 00:13:74 vendor-specific subtype 0x0001 subtypes:
4 (SEQ_REQ) and 5 (SEQ_RESP).
This breaks backward compatibility, i.e., hostapd needs to be updated
on all APs at the same time to allow FT to remain functional.
Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
Convert FT RRB into a new TLV based format. Use AES-SIV as AEAD cipher
to protect the messages.
This needs at least 32 byte long keys. These can be provided either
by a config file change or letting a KDF derive the 32 byte key used
from the 16 byte key given.
This breaks backward compatibility, i.e., hostapd needs to be updated on
all APs at the same time to allow FT to remain functional.
Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
The struct wpa_stsl_negotiation seemed to have been for some kind of
tracking of state of PeerKey negotiations within hostapd. However,
nothing is actually adding any entries to wpa_auth->stsl_negotiations or
using this state. Since PeerKey does not look like something that would
be deployed in practice, there is no justification to spend time on
making this any more complete. Remove the dead code now instead of
trying to figure out what it might be used for.
Signed-off-by: Jouni Malinen <j@w1.fi>
wpa_group_update_count and wpa_pairwise_update_count can now be used to
set the GTK and PTK rekey retry limits (dot11RSNAConfigGroupUpdateCount
and dot11RSNAConfigPairwiseUpdateCount). Defaults set to current
hardcoded value (4).
Some stations may suffer from frequent deauthentications due to GTK
rekey failures: EAPOL 1/2 frame is not answered during the total timeout
period of currently ~3.5 seconds. For example, a Galaxy S6 with Android
6.0.1 appears to go into power save mode for up to 5 seconds. Increasing
wpa_group_update_count to 6 fixed this issue.
Signed-off-by: Günther Kelleter <guenther.kelleter@devolo.de>
Instead of copying the struct wpa_auth_callbacks, just keep a pointer to
it, keep the context pointer separate, and let the user just provide a
static const structure. This reduces the attack surface of heap
overwrites, since the function pointers move elsewhere.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Previously, CONFIG_IEEE80211R enabled build that supports FT for both
station mode and AP mode. However, in most wpa_supplicant cases only
station mode FT is required and there is no need for AP mode FT.
Add support to differentiate between station mode FT and AP mode FT in
wpa_supplicant builds by adding CONFIG_IEEE80211R_AP that should be used
when AP mode FT support is required in addition to station mode FT. This
allows binary size to be reduced for builds that require only the
station side FT functionality.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
This implements processing of FILS Authentication frame for FILS shared
key authentication with ERP and PMKSA caching.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
In addition to the PTK length increasing, the length of the PMK was
increased (from 256 to 384 bits) for the 00-0f-ac:12 AKM. This part was
missing from the initial implementation and a fixed length (256-bit) PMK
was used for all AKMs.
Fix this by adding more complete support for variable length PMK and use
384 bits from MSK instead of 256 bits when using this AKM. This is not
backwards compatible with the earlier implementations.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This ensures that group key is set as long as the interface exists.
Additionally, ifconfig_up is needed as wpa_group will enter
FATAL_FAILURE if the interface is still down. Also vlan_remove_dynamic()
is moved after wpa_auth_sta_deinit() so vlan_remove_dynamic() can check
it was the last user of the wpa_group.
Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
Previously, struct wpa_group was created when the first station enters
the group and the struct wpa_group was not freed when all station left
the group. This causes a problem because wpa_group will enter
FATAL_FAILURE when a wpa_group is running while the AP_VLAN interface
has already been removed.
Fix this by adding a reference counter to struct wpa_group and free a
group if it is unused.
Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
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 extends the earlier PeerKey station side design to be used on the
AP side as well by passing pointer and already validated length from the
caller rather than parsing the length again from the frame buffer. This
avoids false warnings from static analyzer (CID 62870, CID 62871,
CID 62872).
Signed-off-by: Jouni Malinen <j@w1.fi>
If the 4-way handshake ends up having to retransmit the EAPOL-Key
message 1/4 due to a timeout on waiting for the response, it is possible
for the Supplicant to change SNonce between the first and second
EAPOL-Key message 2/4. This is not really desirable due to extra
complexities it causes on the Authenticator side, but some deployed
stations are doing this.
This message sequence looks like this:
AP->STA: EAPOL-Key 1/4 (replay counter 1, ANonce)
AP->STA: EAPOL-Key 1/4 (replay counter 2, ANonce)
STA->AP: EAPOL-Key 2/4 (replay counter 1, SNonce 1)
AP->STA: EAPOL-Key 3/4 (replay counter 3, ANonce)
STA->AP: EAPOL-Key 2/4 (replay counter 2, SNonce 2)
followed by either:
STA->AP: EAPOL-Key 4/4 (replay counter 3 using PTK from SNonce 1)
or:
AP->STA: EAPOL-Key 3/4 (replay counter 4, ANonce)
STA->AP: EAPOL-Key 4/4 (replay counter 4, using PTK from SNonce 2)
Previously, Authenticator implementation was able to handle the cases
where SNonce 1 and SNonce 2 were identifical (i.e., Supplicant did not
update SNonce which is the wpa_supplicant behavior) and where PTK
derived using SNonce 2 was used in EAPOL-Key 4/4. However, the case of
using PTK from SNonce 1 was rejected ("WPA: received EAPOL-Key 4/4
Pairwise with unexpected replay counter" since EAPOL-Key 3/4 TX and
following second EAPOL-Key 2/4 invalidated the Replay Counter that was
used previously with the first SNonce).
This commit extends the AP/Authenticator workaround to keep both SNonce
values in memory if two EAPOL-Key 2/4 messages are received with
different SNonce values. The following EAPOL-Key 4/4 message is then
accepted whether the MIC has been calculated with the latest SNonce (the
previously existing behavior) or with the earlier SNonce (the new
extension). This makes 4-way handshake more robust with stations that
update SNonce for each transmitted EAPOL-Key 2/4 message in cases where
EAPOL-Key message 1/4 needs to be retransmitted.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
If the PMK-R1 needs to be pulled for the R0KH, the previous
implementation ended up rejecting the over-the-air authentication and
over-the-DS action frame unnecessarily while waiting for the RRB
response. Improve this by postponing the Authentication/Action frame
response until the pull response is received.
Signed-off-by: Jouni Malinen <j@w1.fi>
This allows hostapd to set a different management group cipher than the
previously hardcoded default BIP (AES-128-CMAC). The new configuration
file parameter group_mgmt_cipher can be set to BIP-GMAC-128,
BIP-GMAC-256, or BIP-CMAC-256 to select one of the ciphers defined in
IEEE Std 802.11ac-2013.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This new mechanism allows P2P Client to request an IPv4 address from the
GO as part of the 4-way handshake to avoid use of DHCP exchange after
4-way handshake. If the new mechanism is used, the assigned IP address
is shown in the P2P-GROUP-STARTED event on the client side with
following new parameters: ip_addr, ip_mask, go_ip_addr. The assigned IP
address is included in the AP-STA-CONNECTED event on the GO side as a
new ip_addr parameter. The IP address is valid for the duration of the
association.
The IP address pool for this new mechanism is configured as global
wpa_supplicant configuration file parameters ip_addr_go, ip_addr_mask,
ip_addr_star, ip_addr_end. For example:
ip_addr_go=192.168.42.1
ip_addr_mask=255.255.255.0
ip_addr_start=192.168.42.2
ip_addr_end=192.168.42.100
DHCP mechanism is expected to be enabled at the same time to support P2P
Devices that do not use the new mechanism. The easiest way of managing
the IP addresses is by splitting the IP address range into two parts and
assign a separate range for wpa_supplicant and DHCP server.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
If configuration of the group key to the driver fails, move the WPA
group into failed state and indication group setup error to avoid cases
where AP could look like it is working even through the keys are not set
correctly.
Signed-hostap: Jouni Malinen <j@w1.fi>
This can be used to implement per-device PSK selection based on the
peer's P2P Device Address instead of P2P Interface Address.
Signed-hostap: Jouni Malinen <j@w1.fi>
Replace CONFIG_IEEE80211V with CONFIG_WNM to get more consistent build
options for WNM-Sleep Mode operations. Previously it was possible to
define CONFIG_IEEE80211V without CONFIG_WNM which would break the build.
In addition, IEEE 802.11v has been merged into IEEE Std 802.11-2012 and
WNM is a better term to use for this new functionality anyway.
Signed-hostap: Jouni Malinen <j@w1.fi>
Some supplicant implementations (e.g., Windows XP WZC) update SNonce for
each EAPOL-Key 2/4. This breaks the workaround on accepting any of the
pending requests, so allow the SNonce to be updated even if we have
already sent out EAPOL-Key 3/4.
While the issue was made less likely to occur when the retransmit
timeout for the initial EAPOL-Key msg 1/4 was increased to 1000 ms,
this fixes the problem even if that timeout is not long enough.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
This is a workaround for Windows 7 supplicant rejecting WPA msg 3/4
in case it used Secure=1 in msg 2/4. This can happen, e.g., when
rekeying PTK after EAPOL-Key Error Request (Michael MIC failure)
from the supplicant.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
Some deployed supplicants update their SNonce for every receive
EAPOL-Key message 1/4 even when these messages happen during the
same 4-way handshake. Furthermore, some of these supplicants fail
to use the first SNonce that they sent and derive an incorrect PTK
using another SNonce that does not match with what the authenticator
is using from the first received message 2/4. This results in
failed 4-way handshake whenever the EAPOL-Key 1/4 retransmission
timeout is reached. The timeout for the first retry is fixed to
100 ms in the IEEE 802.11 standard and that seems to be short
enough to make it difficult for some stations to get the response
out before retransmission.
Work around this issue by increasing the initial EAPOL-Key 1/4
timeout by 1000 ms (i.e., total timeout of 1100 ms) if the station
acknowledges reception of the EAPOL-Key frame. If the driver does
not indicate TX status for EAPOL frames, use longer initial
timeout (1000 ms) unconditionally.
Veerendranath Jakkam
Jouni Malinen
Jouni Malinen
Alexander Wetzel
Mathy Vanhoef
Michael Braun
Jouni Malinen
Günther Kelleter
Johannes Berg
Ilan Peer
Xi Chen
Jouni Malinen