Do not try to derive a PMKID for EAPOL-key msg 1/4 when going through
4-way handshake to rekey PTK during an association that was started
through FT protocol.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
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>
This is needed to avoid leaving some timers (e.g., for PTK rekeying)
running afrer a STA has disassociated.
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>
The PMK and PMKID information from FILS ERP and FILS PMKSA caching needs
to be stored within struct wpa_state_machine for PTK to work. Without
this, PTK derivation would fail and attempt to go through rekeying would
result in disconnection. Furthermore, wpa_rekey_ptk() timer needs to be
started at the completion of FILS association since the place where it
was done for non-FILS cases at the end of 4-way handshake is not reached
when FILS authentication is used.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
It is possible for the SAE state machine to remove the STA and free the
sta pointer in the mesh use cases. handle_auth_sae() could have
dereferenced that pointer and used freed memory in some cases. Fix that
by explicitly checking whether the STA was removed.
Fixes: bb598c3bdd ("AP: Add support for full station state")
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
ap_free_sta() frees the sta entry, so sta->addr cannot be used after
that call. Fix the sequence of these two calls to avoid use of freed
memory to determine which PMKSA cache entry to remove.
Fixes: 9f2cf23e2e ("mesh: Add support for PMKSA caching")
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
The external authentication command and event does not need to copy the
BSSID/SSID values into struct external_auth since those values are used
before returning from the call. Simplify this by using const u8 * to
external data instead of the array with a copy of the external data.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Extend commit 5ff39c1380 ("SAE: Support external authentication
offload for driver-SME cases") to support external authentication
with drivers that implement AP SME by notifying the status of
SAE authentication to the driver after SAE handshake as the
driver acts as a pass through for the SAE Authentication frames.
Signed-off-by: Srinivas Dasari <dasaris@codeaurora.org>
beacon_set_done did not get reset to zero on disabling interface using
DISABLE control interface command and the subsequent ENABLE command will
caused configuration of Beacon/Probe Response/Association Response frame
IEs twice. The unnecessary two step configuration can be avoided by
resetting beacon_set_done on DISABLE so that ENABLE can bring up the
interface in a single step with fully updated IEs.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
identity_buf may be NULL here. Handle this case explicitly by printing
"N/A" instead relying on snprintf converting this to "(null)" or some
other value based on unexpected NULL pointer.
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Avoid duplicated code in each user of dpp_build_conf_req() by moving the
common encapsulation case into this helper function.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
When connected using FT-SAE key mgmt, use PMK from PMKSA cache as XXKey
for PMK-R0 and PMK-R1 derivations. This fixes an issue where FT key
hierarchy could not be established due to missing (not yet configured)
XXKey when using SAE PMKSA caching for the initial mobility domain
association.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Ethernet frames have minimum length of 64 octets and shorter frames may
end up getting arbitrary padding in the end. This would result in the
FT/RRB receiver rejecting the frame as an incorrectly protected one.
Work around this by padding the message so that it is never shorter than
the minimum Ethernet frame.
Unfortunately, this padding is apparently not enough with all Ethernet
devices and it is still possible to see extra two octet padding at the
end of the message even if larger frames are used (e.g., showed up with
128 byte frames). For now, work around this by trying to do AES-SIV
decryption with two octets shorter frame (ignore last two octets) if the
first attempt fails.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Merge the practically copy-pasted implementations in wpa_supplicant and
hostapd into a single shared implementation in dpp.c for managing
configurator and boostrapping information. This avoid unnecessary code
duplication and provides a convenient location for adding new global DPP
data.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
The memcpy calls added for exposing the PMK from wpa_auth module could
end up trying to copy the same memory buffer on top of itself.
Overlapping memory areas are not allowed with memcpy, so this could
result in undefined behavior. Fix this by making the copies conditional
on the updated value actually coming from somewhere else.
Fixes: b08c9ad0c7 ("AP: Expose PMK outside of wpa_auth module")
Signed-off-by: Jouni Malinen <j@w1.fi>
This code was after the FILS handling that would have encrypted the
frame. While FILS and OWE are never used together, the OWE handling
should really be before the FILS handling since no IEs can be added
after the FILS encryption step. In addition, the Diffie-Hellman
Parameter element is not a Vendor Specific element, so it should be
before some of the Vendor Specific elements even though it is not
defined in IEEE 802.11.
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>
DPP allows Diffie-Hellman exchange to be used for PFS in PTK derivation.
This requires an additional Z.x (x coordinate of the DH shared secret)
to be passed to wpa_pmk_to_ptk(). This commit adds that to the function
and updates all the callers to pass NULL,0 for that part in preparation
of the DPP specific changes to start using this.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
The previous OWE implementation on the AP side rejected any
(Re)Association Request frame with the Diffie-Hellman Parameter element
if AKM was not OWE. This breaks compatibility with DPP PFS, so relax
that rule to allow DPP AKM to be used as well. While this commit alone
does not add support for PFS, this allows interoperability between
non-PFS implementation on the AP and a newer PFS implementation on the
STA.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Share a single parsing implementation for both hostapd and
wpa_supplicant to avoid code duplication. In addition, clean up the
implementation to be more easily extensible.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
The queue_len * 50 ms wait time was too large with the retransmission
timeouts used in the mesh case for SAE. The maximum wait of 750 ms was
enough to prevent successful completion of authentication after having
hit the maximum queue length. While the previous commit is enough to
allow this to complete successfully in couple of retries, it looks like
a smaller wait time should be used here even if it means potentially
using more CPU.
Drop the processing wait time to queue_len * 10 ms so that the maximum
wait time is 150 ms if the queue is full.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
The previous design of simply queuing all SAE commit messages was not
exactly good at allowing recovery from a flooding state if the valid
peer used frequent retransmissions of the SAE message. This could
happen, e.g., with mesh BSSs using SAE. The frequent retransmissions and
restarts of SAE authentication combined with SAE confirm messages
bypassing the queue ended up in not being able to finish SAE exchange
successfully.
Fix this by modifying the queuing policy to queue SAE confirm messages
if there is a queued SAE commit message from the same peer so that the
messages within the same exchange do not get reordered. In addition,
replace queued SAE commit/confirm message if a new matching message is
received from the same peer STA. This is useful for the case where the
peer restarts SAE more quickly than the local end has time to process
the queued messages.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Use this new message from Enrollee to Configurator to indicate result of
the config object provisioning if both devices support protocol version
2 or newer.
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>
This gets rid of a confusing error message "FILS: Failed to add PMKSA
cache entry based on ERP" for cases where PMKSA caching is disabled in
hostapd (disable_pmksa_caching=1). Functionality remains unchanged,
i.e., no cache entry was added before this change either.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
hostapd configuration parameters fragm_threshold and rts_threshold were
documented to disable the threshold with value -1 and not change driver
configuration if the parameter is not included. However, -1 was mapped
into not changing the driver value, so the explicit disabling part did
not work.
Replace the default values for these to be -2 so that explicitly set
configuration value -1 can be distinguished from the case of not
including the parameter. Map the -1 value to a driver request to disable
the threshold. Ignore any error from this operation just in case to
avoid breaking functionality should some drivers not accept the (u32) -1
value as a threshold value request to disable the mechanism.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
This patch added 'check_cert_subject' support to match the value of
every field against the DN of the subject in the client certificate. If
the values do not match, the certificate verification will fail and will
reject the user.
This option allows hostapd to match every individual field in the right
order, also allow '*' character as a wildcard (e.g OU=Development*).
Note: hostapd will match string up to 'wildcard' against the DN of the
subject in the client certificate for every individual field.
Signed-off-by: Paresh Chaudhary <paresh.chaudhary@rockwellcollins.com>
Signed-off-by: Jared Bents <jared.bents@rockwellcollins.com>
Signed-off-by: Jouni Malinen <j@w1.fi>
Include only one of hostapd_mgmt_rx() and hostapd_action_rx() functions
in the build. Previously, NEED_AP_MLME builds (i.e., cases where hostapd
AP MLME implementation is included) included both of these functions and
both were tried in sequence. In addition to being difficult to
understand, that could result in unexpected behavior if
hostapd_mgmt_rx() rejected a frame and return 0 to allow
hostapd_action_rx() to attempt to process the frame.
All the operations included in hostapd_action_rx() are supposed to be
available through the hostapd_mgmt_rx() call in handle_action() and
those should result in the exact same Category/Action-based handler
function to be called in the end. As such, this should not result in
different behavior. And if there is a difference, that would be pointing
at a hidden bug that would need to be fixed anyway. Furthermore, builds
without NEED_AP_MLME would not have any difference in behavior or
contents of the binary either.
Signed-off-by: Jouni Malinen <j@w1.fi>
There is no need to go through the following handler calls in
hostapd_action_rx() after having found the matching WLAN_ACTION_WNM
handler.
Signed-off-by: Jouni Malinen <j@w1.fi>
hostapd_action_rx() was pointing at incorrect field (Action vs.
Category) for the wpa_ft_action_rx() call and the length check for SA
Query Action frames. This resulted in those frames getting dropped as
invalid (FT) or ignored as truncated (SA Query). Fix this by pointing to
the correct place at the beginning of the frame body.
This issue had a long history. These were broken during cleanup in
commit dbfb8e82ff ("Remove unnecessary EVENT_RX_ACTION") which
actually fixed the initial reason for the error accidentally. It was
just that that error was needed to cancel out another earlier error..
One of the errors came from misuse of the EVENT_RX_ACTION API in commit
deca6eff74 ("atheros: Add new IEEE 802.11r driver_ops"). That pointed
struct rx_action data/len to cover the Action frame from the Category
field to the end of the frame body while the API was documented to cover
Action field to the end of the frame body. This error was cancelled by
another error in commit 88b32a99d3 ("FT: Add FT AP support for drivers
that manage MLME internally") that called wpa_ft_action_rx() with the
struct rx_action::data field as the second argument. That argument needs
to point to the Category field, but that struct rx_action field was
supposed to point to the Action field.
Number of the Action frame handlers added into hostapd_action_rx() had
been fixed more or less accidentally after this in various other
commits, but the FT and SA Query handlers had ended up maintaining the
incorrect operations. This is now fixing those.
This seems to fix at least some cases of FT-over-DS with drivers that
use driver-based AP MLME. Such drivers might use internal SA Query
processing, so it is not clear whether that part actually fixes any real
issues.
Signed-off-by: Jouni Malinen <j@w1.fi>
Copy the Finite Cyclic Group field value from the request to the
response Authentication frame if we end up rejecting the request due to
unsupported group.
IEEE Std 802.11-2016 has conflicting statements about this behavior.
Table 9-36 (Presence of fields and elements in Authentication frames)
indicates that the Finite Cyclic Group field is only included with
status code values 0 (success) and 76 (anti-clogging token request)
while SAE protocol description implying that the Finite Cyclic Group
field is set to the rejected group (12.4.8.6.3 and 12.4.8.6.4).
The standard language needs to cleaned up to describe this
unambiguously, but since it looks safe to add the field into the
rejection case and since there is desire to have the field present to be
able to implement what exactly is stated in 12.4.8.6.4, it looks
reasonable to move ahead with the AP mode implementation change. There
is no change in wpa_supplicant for now to modify its behavior based on
whether this field is present, i.e., wpa_supplicant will continue to
work with both the old and new hostapd behavior for SAE group
negotiation.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
The new hostapd configuration parameter wps_cred_add_sae=1 can be used
to request hostapd to add SAE configuration whenever WPS is used to
configure the AP to use WPA2-PSK and the credential includes a
passphrase (instead of PSK). This can be used to enable WPA3-Personal
transition mode with both SAE and PSK enabled and PMF enabled for PSK
and required for SAE associations.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Do not start SAE authentication from scratch if a STA starts a new
attempt for the same group while we still have previously generated PWE
available. Instead, use the previously generated PWE as-is and skip
anti-clogging token exchange since the heavy processing is already
completed. This saves unnecessary processing on the AP side in case the
STA failed to complete authentication on the first attempt (e.g., due to
heavy SAE load on the AP causing a timeout) and makes it more likely for
a valid STA to be able to complete SAE authentication during a DoS
attack.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Add a 16-bit token index into the anti-clogging token. This can be used
to enforce only a single use of each issued anti-clogging token request.
The token value is now token-index |
last-30-octets-of(HMAC-SHA256(sae_token_key, STA-MAC-address |
token-index)), i.e., the first two octets of the SHA256 hash value are
replaced with the token-index and token-index itself is protected as
part of the HMAC context data.
Track the used 16-bit token index values and accept received tokens only
if they use an index value that has been requested, but has not yet been
used. This makes it a bit more difficult for an attacker to perform DoS
attacks against the heavy CPU operations needed for processing SAE
commit since the attacker cannot simply replay the same frame multiple
times and instead, needs to request each token separately.
While this does not add significant extra processing/CPU need for the
attacker, this can be helpful in combination with the queued processing
of SAE commit messages in enforcing more delay during flooding of SAE
commit messages since the new anti-clogging token values are not
returned before the new message goes through the processing queue.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
This allows better control of processing new SAE sessions so that other
operations can be given higher priority during bursts of SAE requests,
e.g., during a potential DoS attack. The receive commit messages are
queued (up to maximum of 15 entries) and processed from eloop callback.
If the queue has multiple pending entries, more wait time is used to go
through the each new entry to reduce heavy CPU load from SAE processing.
Enable anti-clogging token use also based on the pending commit message
queue and not only based on the already started sessions.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Change the AP mode default for SAE to enable only the group 19 instead
of enabling all ECC groups that are supported by the used crypto library
and the SAE implementations. The main reason for this is to avoid
enabling groups that are not as strong as the mandatory-to-support group
19 (i.e., groups 25 and 26). In addition, this disables heavier groups
by default.
In addition, add a warning about MODP groups 1, 2, 5, 22, 23, and 24
based on "MUST NOT" or "SHOULD NOT" categorization in RFC 8247. All the
MODP groups were already disabled by default and would have needed
explicit configuration to be allowed.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
This extension of VLAN assignment code had a bug in one of the code
paths where vlan_id could have been left uninitialized. This could
result in SAE authentication getting rejected in cases where VLAN
assignment is not used if the uninitialized stack memory had nonzero
value.
Fixes: dbfa691df4 ("VLAN assignment based on used WPA/WPA2 passphrase/PSK")
Signed-off-by: Jouni Malinen <j@w1.fi>
Avoid an unnecessary unsigned integer overflow warning due to loop index
j-- use.
hostapd.c:661:10: runtime error: unsigned integer overflow: 0 - 1 cannot be represented in type 'unsigned int'
Signed-off-by: Jouni Malinen <j@w1.fi>
(&mgmt->u.deauth.reason_code + 1) is not exactly clean and now that we
have the u8 variable[] member in the struct after this field, use that
directly to avoid clang compiler warning:
ctrl_iface_ap.c:454:18: error: taking address of packed member
'reason_code' of class or structure 'ieee80211_mgmt::(anonymous
union)::(anonymous)' may result in an unaligned pointer value
[-Werror,-Waddress-of-packed-member]
Signed-off-by: Jouni Malinen <j@w1.fi>
Split the check and decrementation into separate steps to avoid an
unnecessary UBSan warning.
hostapd.c:1895:14: runtime error: unsigned integer overflow: 0 - 1 cannot be represented in type 'size_t' (aka 'unsigned long')
Signed-off-by: Jouni Malinen <j@w1.fi>
hapd->conf might be NULL in case initialized failed, so better be
prepared for that when debug printing interface name in the deinit path.
hostapd.c:312:54: runtime error: member access within null pointer of type 'struct hostapd_bss_config'
hostapd.c:351:29: runtime error: member access within null pointer of type 'struct hostapd_bss_config'
hostapd.c:2158:18: runtime error: member access within null pointer of type 'struct hostapd_bss_config'
Signed-off-by: Jouni Malinen <j@w1.fi>
iface->num_bss is unsigned integer, so need to explicit typecast it to
unsigned before decrementation by one even when the result is stored in
an unsigned integer.
../src/ap/hostapd.c:2185:26: runtime error: unsigned integer overflow: 0 - 1 cannot be represented in type 'unsigned long'
Signed-off-by: Jouni Malinen <j@w1.fi>
According to IEEE Std 802.11-2016, 9.4.2.25 when fields of an RSNE are
not included, the default values are used. The cipher suite defaults
were hardcoded to CCMP in the previous implementation, but the default
is actually different for DMG: GCMP (per 9.4.2.25.2).
It is not possible to find out from the RSNE if the network is non-DMG
or DMG, so callers of wpa_parse_wpa_ie_rsn() need to handle this case
based on context, which can be different for each caller.
In order to fix this issue, add flags to the wpa_ie_data indicating
whether pairwise/group ciphers were included in the RSNE. Callers can
check these flags and fill in the appropriate ciphers. The
wpa_parse_wpa_ie_rsn() function still initializes the ciphers to CCMP by
default so existing callers will not break. This change also fixes some
callers which need to handle the DMG network case.
Signed-off-by: Lior David <liord@codeaurora.org>
The Wi-Fi Alliance Multi-AP Specification v1.0 allows onboarding of a
backhaul STA through WPS. To enable this, the WPS Registrar offers a
different set of credentials (backhaul credentials instead of fronthaul
credentials) when the Multi-AP subelement is present in the WFA vendor
extension element of the WSC M1 message.
Add new configuration options to specify the backhaul credentials for
the hostapd internal registrar: multi_ap_backhaul_ssid,
multi_ap_backhaul_wpa_psk, multi_ap_backhaul_wpa_passphrase. These are
only relevant for a fronthaul SSID, i.e., where multi_ap is set to 2 or
3. When these options are set, pass the backhaul credentials instead of
the normal credentials when the Multi-AP subelement is present.
Ignore the Multi-AP subelement if the backhaul config options are not
set. Note that for an SSID which is fronthaul and backhaul at the same
time (i.e., multi_ap == 3), this results in the correct credentials
being sent anyway.
The security to be used for the backaul BSS is fixed to WPA2PSK. The
Multi-AP Specification only allows Open and WPA2PSK networks to be
configured. Although not stated explicitly, the backhaul link is
intended to be always encrypted, hence WPA2PSK.
To build the credentials, the credential-building code is essentially
copied and simplified. Indeed, the backhaul credentials are always
WPA2PSK and never use per-device PSK. All the options set for the
fronthaul BSS WPS are simply ignored.
Signed-off-by: Davina Lu <ylu@quantenna.com>
Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Marianna Carrera <marianna.carrera.so@quantenna.com>
