Use struct eap_config as-is within struct eap_sm and EAPOL authenticator
to avoid having to duplicate all the configuration variables at each
interface. Split the couple of session specific variables into a
separate struct to allow a single const struct eap_config to be used.
Signed-off-by: Jouni Malinen <j@w1.fi>
The implementation was previously hardcoded to use only the non-expanded
IETF EAP methods in Phase 2. Extend that to allow vendor EAP methods
with expanded header to be used.
Signed-off-by: Jouni Malinen <j@w1.fi>
This was already allowed with EAP-PEAP, but EAP-TEAP was hardcoded to
use only the non-expanded EAP types. Extend that to allow vendor EAP
types to be used.
Signed-off-by: Jouni Malinen <j@w1.fi>
The implementation was previously hardcoded to use only the non-expanded
IETF EAP methods in Phase 2. Extend that to allow vendor EAP methods
with expanded header to be used.
Signed-off-by: Jouni Malinen <j@w1.fi>
This was already allowed with EAP-PEAP, but EAP-FAST was hardcoded to
use only the non-expanded EAP types. Extend that to allow vendor EAP
types to be used.
Signed-off-by: Jouni Malinen <j@w1.fi>
The implementation was previously hardcoded to allow only the Microsoft
SoH expanded EAP method in Phase 2 in addition to non-expanded EAP
methods. Extend that to allow any vendor EAP method with an expanded
header to be used.
Signed-off-by: Jouni Malinen <j@w1.fi>
The implementation was previously hardcoded to use only the non-expanded
IETF EAP methods in Phase 2. Extend that to allow vendor EAP methods
with expanded header to be used.
Signed-off-by: Jouni Malinen <j@w1.fi>
This was already allowed with EAP-PEAP, but EAP-TTLS was hardcoded to
use only the non-expanded EAP types. Extend that to allow vendor EAP
types to be used.
Signed-off-by: Jouni Malinen <j@w1.fi>
This cleans up coding style of the EAP implementation by avoiding
typedef of an enum hiding the type of the variables.
Signed-off-by: Jouni Malinen <j@w1.fi>
The new eap_teap_separate_result=1 hostapd configuration parameter can
be used to test TEAP exchange where the Intermediate-Result TLV and
Crypto-Binding TLV are send in one message exchange while the Result TLV
exchange in done after that in a separate message exchange.
Signed-off-by: Jouni Malinen <j@w1.fi>
If the Crypto-Binding TLV for the last EAP method has been validated
successfully in a previous message exchange with Intermediate-Result TLV
and no new EAP method has been started, Result TLV can be accepted
without an additional Crypto-Binding TLV. This allows the server to go
through additional message exchanges after inner EAP method, if needed.
Signed-off-by: Jouni Malinen <j@w1.fi>
It is not sufficient for the peer to include only the Result TLV if the
server included both the Intermediate-Result TLV and Result TLV.
Signed-off-by: Jouni Malinen <j@w1.fi>
Previously, only the Result TLV was added when writing Crypto-Binding
TLV response. This is not sufficient, since RFC 7170 require
Intermediate-Result TLV response to be included from the peer if the
server included Intermediate-Result TLV.
Signed-off-by: Jouni Malinen <j@w1.fi>
This version of TLS PRF is needed when using TEAP with TLS ciphersuites
that are defined to use SHA384 instead of SHA256.
Signed-off-by: Jouni Malinen <j@w1.fi>
In addition, update the generation script to allow convenient update of
the server and user certificates without having to generate new keys.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
The previously used single TOD policy was split into two policies:
TOD-STRICT and TOD-TOFU. Report these separately in the
CTRL-EVENT-EAP-PEER-CERT events (tod=1 for TOD-STRICT and tod=2 for
TOD-TOFU).
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
This is needed for the drivers implementing SME to include the PMKID in
the Association Request frame directly following SAE authentication.
This commit extends the commit d2b2083843 ("SAE: Allow PMKID to be
added into Association Request frame following SAE") for drivers with
internal SME that use the external authentication mechanism.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
pending_bssid is cleared in the connected state and thus is not valid if
SAE authentication is done to a new BSSID when in the connected state.
Hence use the BSSID from ext_auth_bssid while configuring the PMK for
the external authentication case. This is required for roaming to a new
BSSID with driver-based-SME while the SAE processing happens with
wpa_supplicant.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
A new DH public key is sent through this interface to the driver after
every successful connection/roam to a BSS. This helps to do OWE roaming
to a new BSS with drivers that implement SME/MLME operations during
roaming.
This updated DH IEs are added in the subsequent (Re)Association Request
frame sent by the station when roaming. The DH IE from the roamed AP is
given to wpa_supplicant in the roam result event. wpa_supplicant shall
further process these DH IEs to generate the PMK for the 4-way
handshake.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Update Connection Params is intended for drivers that implement
internal SME and expect these updated connection params from
wpa_supplicant. Do not send this request for the drivers using
SME from wpa_supplicant.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
If FT over-the-DS case is enforced through the "FT_DS <BSSID>" control
interface command, the PMF capability check during BSS selection is not
used and that could have allowed PMF to be disabled in the over-the-DS
case even if the local network profile mandated use of PMF. Check
against this explicitly to avoid unexpected cases if the APs within the
same mobility domain are not configured consistently.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
PMF capability check is done as part of BSS selection routines, but
those are not used when going through the enforced roaming operation
("ROAM <BSSID>" control interface command). While that mechanism is
mainly for testing purposes, extend it to do the same check for PMF to
prevent cases where forced roaming could end up disabling PMF against
the local profile requirement.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Commit e820cf952f ("MFP: Add MFPR flag into station RSN IE if 802.11w
is mandatory") added indication of MFPR flag in non-FT cases, but forgot
to do so for the FT protocol cases where a different function is used to
build the RSNE. Do the same change now for that FT specific case to get
consistent behavior on indicating PMF configuration state with MFPR.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
An OCE AP with WPA2 enabled shall require PMF negotiation when
associating with an OCE STA. An OCE STA-CFON may negotiate PMF with a
STA when it is operating as an AP. Don't select an OCE AP for connection
if PMF is not enabled.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
When required_roaming_consortium is set in a credential, station
should match this against Roaming Consortium(s) for a BSS similar
to how it is matching for roaming_consortiums during Interworking
credentials availability check for roaming_consortium.
In the context of Hotspot 2.0 PPS MO, this means addressing matching
part in the same manner for HomeSP/HomeOIList/<X+>/HomeOI regardless of
how HomeSP/HomeOIList/<X+>/HomeOIRequired is set (i.e., the required
part is used as an independent check for the AP advertising the needed
information while the "credential can be used here and this is a home
network" part is shared).
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
IEEE Std 802.11-2016 does not require this behavior from a SAE STA, but
it is not disallowed either, so it is useful to have an option to
identify the derived PMKSA in the immediately following Association
Request frames. This is disabled by default (i.e., no change to previous
behavior) and can be enabled with a global wpa_supplicant configuration
parameter sae_pmkid_in_assoc=1.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
This is not used only with FT, so make the comments less confusing and
include the function in all builds to make it available for
non-FT/non-FILS builds.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
The wlan.mesh.config doesn't have to be the last element of beacon. Things
like VHT or HE oper/cap are usually follow the mesh configuration element.
The workaround must first get the position of a correct reference value in
wlan.mesh.config (ps_protocol) and then calculate the correct
wlan.mesh.config.cap offset based on that.
Reported-by: Johannes Berg <johannes@sipsolutions.net>
Fixes: 2cbaf0de22 ("tests: Work around tshark bug in wpas_mesh_max_peering")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
HE (802.11ax) is also supported on 2.4 GHz. And the 2.4 GHz band isn't
supposed to use VHT operations. Some codepaths in wpa_supplicant will
therefore not initialize the freq->bandwidth or the freq->center_freq1/2
members. As a result, the nl80211_put_freq_params() will directly return
an error (-1) or the kernel will return an error due to the invalid
channel definition.
Instead, the channel definitions should be created based on the actual
HT/VHT/none information on 2.4 GHz.
Fixes: ad9a1bfe78 ("nl80211: Share VHT channel configuration for HE")
Signed-off-by: Sven Eckelmann <seckelmann@datto.com>
