3
0
mirror of https://git.kernel.org/pub/scm/network/wireless/iwd.git synced 2024-11-07 20:49:22 +01:00
Commit Graph

4005 Commits

Author SHA1 Message Date
James Prestwood
c398672200 dpp: allow enrollee to be authentication initiator
Until now IWD only supported enrollees as responders (configurators
could do both). For PKEX it makes sense for the enrollee to be the
initiator because configurators in the area are already on their
operating channel and going off is inefficient. For PKEX, whoever
initiates also initiates authentication so for this reason the
authentication path is being opened up to allow enrollees to
initiate.
2023-11-02 20:30:18 -05:00
James Prestwood
b8bfbc141d dpp: fix config request header check
The check for the header was incorrect according to the spec.
Table 58 indicates that the "Query Response Info" should be set
to 0x00 for the configuration request. The frame handler was
expecting 0x7f which is the value for the config response frame.

Unfortunately wpa_supplicant also gets this wrong and uses 0x7f
in all cases which is likely why this value was set incorrectly
in IWD. The issue is that IWD's config request is correct which
means IWD<->IWD configuration is broken. (and wpa_supplicant as
a configurator likely doesn't validate the config request).

Fix this by checking both 0x7f and 0x00 to handle both
supplicants.
2023-11-02 20:28:06 -05:00
James Prestwood
a943a81f87 dpp: remove scan_periodic_stop calls
Stopping periodic scans and not restarting them prevents autoconnect
from working again if DPP (or the post-DPP connect) fails. Since
the DPP offchannel work is at a higher priority than scanning (and
since new offchannels are queue'd before canceling) there is no risk
of a scan happening during DPP so its safe to leave periodic scans
running.
2023-11-02 20:27:59 -05:00
James Prestwood
320041eaf2 station: rate limit packet loss roam scans
The packet loss handler puts a higher priority on roaming compared
to the low signal roam path. This is generally beneficial since this
event usually indicates some problem with the BSS and generally is
an indicator that a disconnect will follow sometime soon.

But by immediately issuing a scan we run the risk of causing many
successive scans if more packet loss events arrive following
the roam scans (and if no candidates are found). Logs provided
further.

To help with this handle the first event with priority and
immediately issue a roam scan. If another event comes in within a
certain timeframe (2 seconds) don't immediately scan, but instead
rearm the roam timer instead of issuing a scan. This also handles
the case of a low signal roam scan followed by a packet loss
event. Delaying the roam will at least provide some time for packets
to get out in between roam scans.

Logs were snipped to be less verbose, but this cycled happened
5 times prior. In total 7 scans were issued in 5 seconds which may
very well have been the reason for the local disconnect:

Oct 27 16:23:46 src/station.c:station_roam_failed() 9
Oct 27 16:23:46 src/wiphy.c:wiphy_radio_work_done() Work item 29 done
Oct 27 16:23:47 src/netdev.c:netdev_mlme_notify() MLME notification Notify CQM(64)
Oct 27 16:23:47 src/station.c:station_packets_lost() Packets lost event: 10
Oct 27 16:23:47 src/station.c:station_roam_scan() ifindex: 9
Oct 27 16:23:47 src/wiphy.c:wiphy_radio_work_insert() Inserting work item 30
Oct 27 16:23:47 src/wiphy.c:wiphy_radio_work_next() Starting work item 30
Oct 27 16:23:47 src/station.c:station_start_roam() Using cached neighbor report for roam
Oct 27 16:23:47 src/scan.c:scan_notify() Scan notification Trigger Scan(33)
Oct 27 16:23:47 src/scan.c:scan_request_triggered() Active scan triggered for wdev a
Oct 27 16:23:47 src/scan.c:scan_notify() Scan notification New Scan Results(34)
Oct 27 16:23:47 src/netdev.c:netdev_link_notify() event 16 on ifindex 9
... scan results ...
Oct 27 16:23:47 src/station.c:station_roam_failed() 9
Oct 27 16:23:47 src/wiphy.c:wiphy_radio_work_done() Work item 30 done
Oct 27 16:23:47 src/netdev.c:netdev_mlme_notify() MLME notification Notify CQM(64)
Oct 27 16:23:47 src/station.c:station_packets_lost() Packets lost event: 10
Oct 27 16:23:47 src/station.c:station_roam_scan() ifindex: 9
Oct 27 16:23:47 src/wiphy.c:wiphy_radio_work_insert() Inserting work item 31
Oct 27 16:23:47 src/wiphy.c:wiphy_radio_work_next() Starting work item 31
Oct 27 16:23:47 src/station.c:station_start_roam() Using cached neighbor report for roam
Oct 27 16:23:47 src/scan.c:scan_notify() Scan notification Trigger Scan(33)
Oct 27 16:23:47 src/scan.c:scan_request_triggered() Active scan triggered for wdev a
Oct 27 16:23:48 src/scan.c:scan_notify() Scan notification New Scan Results(34)
Oct 27 16:23:48 src/netdev.c:netdev_link_notify() event 16 on ifindex 9
... scan results ...
Oct 27 16:23:48 src/station.c:station_roam_failed() 9
Oct 27 16:23:48 src/wiphy.c:wiphy_radio_work_done() Work item 31 done
Oct 27 16:23:48 src/netdev.c:netdev_mlme_notify() MLME notification Notify CQM(64)
Oct 27 16:23:48 src/station.c:station_packets_lost() Packets lost event: 10
Oct 27 16:23:48 src/station.c:station_roam_scan() ifindex: 9
Oct 27 16:23:48 src/wiphy.c:wiphy_radio_work_insert() Inserting work item 32
Oct 27 16:23:48 src/wiphy.c:wiphy_radio_work_next() Starting work item 32
Oct 27 16:23:48 src/station.c:station_start_roam() Using cached neighbor report for roam
Oct 27 16:23:48 src/scan.c:scan_notify() Scan notification Trigger Scan(33)
Oct 27 16:23:48 src/scan.c:scan_request_triggered() Active scan triggered for wdev a
Oct 27 16:23:49 src/netdev.c:netdev_link_notify() event 16 on ifindex 9
Oct 27 16:23:49 src/netdev.c:netdev_mlme_notify() MLME notification Del Station(20)
Oct 27 16:23:49 src/netdev.c:netdev_mlme_notify() MLME notification Deauthenticate(39)
Oct 27 16:23:49 src/netdev.c:netdev_deauthenticate_event()
Oct 27 16:23:49 src/netdev.c:netdev_mlme_notify() MLME notification Disconnect(48)
Oct 27 16:23:49 src/netdev.c:netdev_disconnect_event()
Oct 27 16:23:49 Received Deauthentication event, reason: 4, from_ap: false
2023-10-30 09:43:12 -05:00
James Prestwood
3ac5da2535 dbus: add SharedCodeDeviceProvisioning interface definition 2023-10-29 17:28:03 -05:00
James Prestwood
acb1abceae dpp: support mutual authentication
This will be needed for PKEX support. It requires an additional
value, L, be derived and used in some of the hashing functions.
2023-10-29 17:17:21 -05:00
James Prestwood
2f2798afb8 dpp-util: add crypto for PKEX 2023-10-29 17:08:08 -05:00
James Prestwood
0859ed8448 dpp: make the protocol timeout more flexible
Include a specific timeout value so different protocols can specify
different timeouts. For example once the authentication timeout
should not take very long (even 10 seconds seems excessive) but
adding PKEX may warrant longer timeouts.

For example discovering a configurator IWD may want to wait several
minutes before ending the discovery. Similarly running PKEX as a
configurator we should put a hard limit on the time, but again
minutes rather than 10 seconds.
2023-10-29 17:05:35 -05:00
James Prestwood
efdc2a63eb dpp: check configurator role in config request frame
We shouldn't ever get this frame as an enrollee, so disregard
2023-10-29 17:05:10 -05:00
James Prestwood
49b9eae18c offchannel: handle out of order ACKs/events
Its been seen (so far only in mac80211_hwsim + UML) where an
offchannel requests ACK comes after the ROC started event. This
causes the ROC started event to never call back to notify since
info->roc_cookie is unset and it appears to be coming from an
external process.

We can detect this situation in the ROC notify event by checking
if there is a pending ROC command and if info->roc_cookie does
not match. This can also be true for an external event so we just
set a new "early_cookie" member and return.

Then, when the ACK comes in for the ROC request, we can validate
if the prior event was associated with IWD or some external
process. If it was from IWD call the started callback, otherwise
the ROC notify event should come later and handled under the
normal logic where the cookies match.
2023-10-26 09:30:03 -05:00
James Prestwood
0a502562c3 offchannel: Use roc id in offchannel_cancel lookup
Instead of looking up by wdev, lookup by the ID itself. We
shouldn't ever have more than one info per wdev in the queue but
looking up the _exact_ info structure doesn't hurt in case things
change in the future.
2023-10-24 21:21:36 -05:00
James Prestwood
ef27f87dbe station: reload settings in 'netconfig_after_roam' case
If netconfig is canceled before completion (when roaming) the
settings are freed and never loaded again once netconfig is started
post-roam. Now after a roam make sure to re-load the settings and
start netconfig.
2023-10-20 10:25:44 -05:00
James Prestwood
ccb29663cc station: fix unintended netconfig_reset pre-roaming
Commit 23f0f5717c did not correctly handle the reassociation
case where the state is set from within station_try_next_transition.
If IWD reassociates netconfig will get reset and DHCP will need to
be done over again after the roam. Instead get the state ahead of
station_try_next_transition.

Fixes: 23f0f5717c ("station: allow roaming before netconfig finishes")
2023-10-20 10:23:17 -05:00
James Prestwood
c0b92d9498 dpp-util: allow mutual auth in dpp_derive_ke
The Ke derivation requires an additional "L.x" value when
mutual authentication is used.
2023-10-19 09:33:24 -05:00
James Prestwood
808f8eea34 dpp-util: allow for mutual authentication in i/r_auth
When using mutual authentication an additional value needs to
be hashed when deriving i/r_auth values. A NULL value indicates
no mutual authentication (zero length iovec is passed to hash).
2023-10-19 09:25:35 -05:00
James Prestwood
0c9df85f5e dpp: fix retransmits if on operating channel
DPP configurators are running the majority of the protocol on the
current operating channel, meaning no ROC work. The retry logic
was bailing out if !dpp->roc_started with the assumption that DPP
was in between requesting offchannel work and it actually starting.
For configurators, this may not be the case. The offchannel ID also
needs to be checked, and if no work is scheduled we can send the
frame.
2023-10-17 10:35:13 -05:00
James Prestwood
30effaf164 dpp: move/store max_roc setting into dpp_create
This value won't change since its per-phy so initialize it
when creating the DPP state machine rather than every time
DPP is started.
2023-10-17 10:31:32 -05:00
James Prestwood
33ba7f7dcd dpp: rename dpp_presence_timeout to be generic
PKEX will utilize the same offchannel timeout, so rename to
dpp_offchannel_timeout to be more generic.
2023-10-17 10:30:47 -05:00
James Prestwood
d0c1025179 dpp: rename auth_addr to peer_addr
This is more generic and with adding PKEX it makes sense to
refer to it as peer_addr.
2023-10-17 10:20:50 -05:00
James Prestwood
fe9751d4d8 dpp-util: fix typo "COMMIT_REVEAP_RESPONSE" 2023-10-17 10:18:49 -05:00
James Prestwood
6320d6db0f crypto: remove label from prf_plus, instead use va_args
The prf_plus API was a bit restrictive because it only took a
string label which isn't compatible with some specs (e.g. DPP
inputs to HKDF-Expand). In addition it took additional label
aruments which were appended to the HMAC call (and the
non-intuitive '\0' if there were extra arguments).

Instead the label argument has been removed and callers can pass
it in through va_args. This also lets the caller decided the length
and can include the '\0' or not, dependent on the spec the caller
is following.
2023-10-17 10:13:42 -05:00
James Prestwood
dfb76edda8 sae: fix usage of compressed points (after ELL is fixed)
SAE was also relying on the ELL bug which was incorrectly performing
a subtraction on the Y coordinate based on the compressed point type.
Correct this and make the point type more clear (rather than
something like "is_odd + 2").
2023-10-11 10:19:42 -05:00
James Prestwood
06ad1ace00 eap-pwd: fix usage of compressed points (after ELL is fixed)
EAP-PWD was incorrectly computing the PWE but due to the also
incorrect logic in ELL the point converted correctly. This is
being fixed, so both places need the reverse logic.

Also added a big comment explaining why this is, and how
l_ecc_point_from_data behaves since its somewhat confusing since
EAP-PWD expects the pwd-seed to be compared to the actual Y
coordinate (which is handled automatically by ELL).
2023-10-11 10:19:34 -05:00
James Prestwood
2ba88f05e9 dpp-util: fix incorrect ASN1 compressed public key encoding
The prefix to the X coordinate was incorrect when using compressed
points. This has been modified to match the ANSI X9.62 spec.
2023-10-11 10:19:24 -05:00
Denis Kenzior
600bea73ec crypto: use SWAP from useful.h 2023-10-11 09:58:31 -05:00
Denis Kenzior
f86e7283e7 eap: Silence warning
The previous attempt at working around this warning seems to no longer
work with gcc 13

In function ‘eap_handle_response’,
    inlined from ‘eap_rx_packet’ at src/eap.c:570:3:
src/eap.c:421:49: error: ‘vendor_id’ may be used uninitialized [-Werror=maybe-uninitialized]
  421 |         (type == EAP_TYPE_EXPANDED && vendor_id == (id) && vendor_type == (t))
      |                                       ~~~~~~~~~~^~~~~~~
src/eap.c:533:20: note: in expansion of macro ‘IS_EXPANDED_RESPONSE’
  533 |         } else if (IS_EXPANDED_RESPONSE(our_vendor_id, our_vendor_type))
      |                    ^~~~~~~~~~~~~~~~~~~~
src/eap.c: In function ‘eap_rx_packet’:
src/eap.c:431:18: note: ‘vendor_id’ was declared here
  431 |         uint32_t vendor_id;
      |                  ^~~~~~~~~
2023-10-06 23:24:25 -05:00
Denis Kenzior
073292315f band: Silence warning
width must be initialized since it depends on best not being NULL.  If
best passes the non-NULL check above, then width must be initialized
since both width and best are set at the same time.
2023-10-06 23:21:48 -05:00
James Prestwood
0cb3e4af30 station: check disabled band configuration in station_init
For IWD to work correctly either 2.4GHz or 5GHz bands must be enabled
(even for 6GHz to work). Check this and don't allow IWD to initialize
if both 2.4 and 5GHz is disabled.
2023-10-03 11:32:44 -05:00
Denis Kenzior
66f47343d9 wiphy: Remove unused wiphy_supports_adhoc_rsn() 2023-09-30 17:21:30 -05:00
Denis Kenzior
6e5df64f6d wiphy: Remove unused wiphy_can_offchannel_tx() 2023-09-30 17:20:29 -05:00
Denis Kenzior
71c125193f wiphy: Remove unused wiphy_get_permanent_address() 2023-09-30 17:19:22 -05:00
James Prestwood
c972684e1a wiphy: remove wiphy_get_allowed_freqs
This was recently added but with the modifications to
wiphy_band_is_disabled() its no longer needed.
2023-09-29 21:57:08 -05:00
James Prestwood
06ed56e78f scan: remove use of wiphy_get_allowed_freqs to optimize 6ghz path
wiphy_get_allowed_freqs was only being used to see if 6GHz was disabled
or not. This is expensive and requires several allocations when there
already exists wiphy_is_band_disabled(). The prior patch modified
wiphy_is_band_disabled() to return -ENOTSUP which allows scan.c to
completely remove the need for wiphy_get_allowed_freqs.

scan_wiphy_watch was also slightly re-ordered to avoid allocating
freqs_6ghz if the scan request was being completed.
2023-09-29 21:39:58 -05:00
James Prestwood
970d23a858 wiphy: make wiphy_band_is_disabled return more descriptive
The function wiphy_band_is_disabled() return was a bit misleading
because if the band was not supported it would return true which
could be misunderstood as the band is supported, but disabled.
There was only one call site and because of this behavior
wiphy_band_is_disabled needed to be paired with checking if the
band was supported.

To be more descriptive to the caller, wiphy_band_is_disabled() now
returns an int and if the band isn't supported -ENOTSUP will be
returned, otherwise 1 is returned if the band is disabled and 0
otherwise.
2023-09-29 21:32:45 -05:00
James Prestwood
0bb99bcc33 doc: document disabling bands with a 0.0 modifier 2023-09-29 10:19:03 -05:00
James Prestwood
52c098ea74 station: support user-disabled bands
This adds support to allow users to disable entire bands, preventing
scanning and connecting on those frequencies. If the
[Rank].BandModifier* options are set to 0.0 it will imply those
bands should not be used for scanning, connecting or roaming. This
now applies to autoconnect, quick, hidden, roam, and dbus scans.

This is a station only feature meaning other modules like RRM, DPP,
WSC or P2P may still utilize those bands. Trying to limit bands in
those modules may sometimes conflict with the spec which is why it
was not added there. In addition modules like DPP/WSC are only used
in limited capacity for connecting so there is little benefit gained
to disallowing those bands.
2023-09-29 10:11:40 -05:00
James Prestwood
e83070e074 scan: filter user-disabled bands for periodic scans.
To support user-disabled bands periodic scans need to specify a
frequency list filtered by any bands that are disabled. This was
needed in scan.c since periodic scans don't provide a frequency
list in the scan request.

If no bands are disabled the allowed freqs API should still
result in the same scan behavior as if a frequency list is left
out i.e. IWD just filters the frequencies as opposed to the kernel.
2023-09-29 10:10:33 -05:00
James Prestwood
6463fa2561 scan: allow splitting of scans with defined frequencies
Currently the only way a scan can be split is if the request does
not specify any frequencies, implying the request should scan the
entire spectrum. This allows the scan logic to issue an extra
request if 6GHz becomes available during the 2.4 or 5GHz scans.
This restriction was somewhat arbitrary and done to let periodic
scans pick up 6GHz APs through a single scan request.

But now with the addition of allowing user-disabled bands
periodic scans will need to specify a frequency list in case a
given band has been disabled. This will break the scan splitting
code which is why this prep work is being done.

The main difference now is the original scan frequencies are
tracked with the scan request. The reason for this is so if a
request comes in with a limited set of 6GHz frequences IWD won't
end up scanning the full 6GHz spectrum later on.
2023-09-29 10:08:03 -05:00
James Prestwood
112b1de2ee wiphy: add wiphy_get_allowed_freqs
This is more or less copied from scan_get_allowed_freqs but is
going to be needed by station (basically just saves the need for
station to do the same clone/constrain sequence itself).

One slight alteration is now a band mask can be passed in which
provides more flexibility for additional filtering.
2023-09-27 14:22:13 -05:00
James Prestwood
e4fb9786c5 scan: add scan_get_band_rank_modifier
This exposes the [Rank].BandModifier* settings so other modules
can use then. Doing this will allow user-disabling of certain
bands by setting these modifier values to 0.0.
2023-09-27 14:21:28 -05:00
James Prestwood
043a050e57 doc: document [Rank].BandModifier2_4Ghz 2023-09-27 14:21:19 -05:00
James Prestwood
f5ae310eae scan: add [Rank].BandModifier2_4Ghz
Similar to the 5/6Ghz options, allow modifying the rank for 2.4Ghz
scan results.
2023-09-27 14:20:53 -05:00
James Prestwood
59033bc705 wiphy: fix wiphy_contrain_freq_set skipping last channel
The loop iterating the frequency attributes list was not including
the entire channel set since it was stopping at i < band->freqs_len.
The freq_attrs array is allocated to include the last channel:

band->freq_attrs = l_new(struct band_freq_attrs, num_channels + 1);
band->freqs_len = num_channels;

So instead the for loop should use i <= band->freqs_len. (I also
changed this to start the loop at 1 since channel zero is invalid).
2023-09-25 09:30:26 -05:00
James Prestwood
e74dd446fb station: fall back to reassociation under certain FT failures
The auth/action status is now tracked in ft.c. If an AP rejects the
FT attempt with "Invalid PMKID" we can now assume this AP is either
mis-configured for FT or is lagging behind getting the proper keys
from neighboring APs (e.g. was just rebooted).

If we see this condition IWD can now fall back to reassociation in
an attempt to still roam to the best candidate. The fallback decision
is still rank based: if a BSS fails FT it is marked as such, its
ranking is reset removing the FT factor and it is inserted back
into the queue.

The motivation behind this isn't necessarily to always force a roam,
but instead to handle two cases where IWD can either make a bad roam
decision or get 'stuck' and never roam:

  1. If there is one good roam candidate and other bad ones. For
     example say BSS A is experiencing this FT key pull issue:
         Current BSS: -85dbm
         BSS A:       -55dbm
         BSS B:       -80dbm
     The current logic would fail A, and roam to B. In this case
     reassociation would have likely succeeded so it makes more sense
     to reassociate to A as a fallback.

  2. If there is only one candidate, but its failing FT. IWD will
     never try anything other than FT and repeatedly fail.

Both of the above have been seen on real network deployments and
result in either poor performance (1) or eventually lead to a full
disconnect due to never roaming (2).
2023-09-01 22:56:25 -05:00
James Prestwood
0007699677 ft: track FT auth/action response status
Certain return codes, though failures, can indicate that the AP is
just confused or booting up and treating it as a full failure may
not be the best route.

For example in some production deployments if an AP is rebooted it
may take some time for neighboring APs to exchange keys for
current associations. If a client roams during that time it will
reject saying the PMKID is invalid.

Use the ft_associate call return to communicate the status (if any)
that was in the auth/action response. If there was a parsing error
or no response -ENOENT is still returned.
2023-09-01 22:49:21 -05:00
Salahaldeen Altous
4a0a973790 doc: APRanges is deprecated (use APAddressPool instead) 2023-08-08 00:00:05 -05:00
James Prestwood
822ad91faa scan: remove unneeded debug prints
Removed several debug prints which are very verbose and provide
little to no important information.

The get_scan_{done,callback} prints are pointless since all the
parsed scan results are printed by station anyways.

Printing the BSS load is also not that useful since it doesn't
include the BSSID. If anything the BSS load should be included
when station prints out each individual BSS (along with frequency,
rank, etc).

The advertisement protocol print was just just left in there by
accident when debugging, and also provides basically no useful
information.
2023-08-07 23:59:17 -05:00
James Prestwood
b736f07e2e netdev: relax requirement for OWE AKM in assoc reply
Some APs don't include the RSNE in the associate reply during
the OWE exchange. This causes IWD to be incompatible since it has
a hard requirement on the AKM being included.

This relaxes the requirement for the AKM and instead warns if it
is not included.

Below is an example of an association reply without the RSN element

IEEE 802.11 Association Response, Flags: ........
     Type/Subtype: Association Response (0x0001)
     Frame Control Field: 0x1000
     .000 0000 0011 1100 = Duration: 60 microseconds
     Receiver address: 64:c4:03:88:ff:26
     Destination address: 64:c4:03:88:ff:26
     Transmitter address: fc:34:97:2b:1b:48
     Source address: fc:34:97:2b:1b:48
     BSS Id: fc:34:97:2b:1b:48
     .... .... .... 0000 = Fragment number: 0
     0001 1100 1000 .... = Sequence number: 456
IEEE 802.11 wireless LAN
     Fixed parameters (6 bytes)
     Tagged parameters (196 bytes)
         Tag: Supported Rates 6(B), 9, 12(B), 18, 24(B), 36, 48, 54, [Mbit/sec]
         Tag: RM Enabled Capabilities (5 octets)
         Tag: Extended Capabilities (11 octets)
         Ext Tag: HE Capabilities (IEEE Std 802.11ax/D3.0)
         Ext Tag: HE Operation (IEEE Std 802.11ax/D3.0)
         Ext Tag: MU EDCA Parameter Set
         Ext Tag: HE 6GHz Band Capabilities
         Ext Tag: OWE Diffie-Hellman Parameter
             Tag Number: Element ID Extension (255)
             Ext Tag length: 51
             Ext Tag Number: OWE Diffie-Hellman Parameter (32)
             Group: 384-bit random ECP group (20)
             Public Key: 14ba9d8abeb2ecd5d95e6c12491b16489d1bcc303e7a7fbd…
         Tag: Vendor Specific: Broadcom
         Tag: Vendor Specific: Microsoft Corp.: WMM/WME: Parameter Element

Reported-By: Wen Gong <quic_wgong@quicinc.com>
Tested-By: Wen Gong <quic_wgong@quicinc.com>
2023-07-14 09:09:51 -05:00
James Prestwood
9479c31a72 handshake: add FT_OVER_8021X AKM for SHA256 PMKID derivation
Hostapd commit b6d3fd05e3 changed the PMKID derivation in accordance
with 802.11-2020 which then breaks PMKID validation in IWD. This
breaks the FT-8021x AKM in IWD if the AP uses this hostapd version
since the PMKID doesn't validate during EAPoL.

This updates the PMKID derivation to use the correct SHA hash for
this AKM and adds SHA1 based PMKID checking for interoperability
with older hostapd versions.
2023-07-05 18:16:01 +02:00
James Prestwood
8c4633ef72 handshake: split handshake_state_get_pmkid into separate APIs
The PMKID derivation has gotten messy due to the spec
updating/clarifying the hash size for the FT-8021X AKM. This
has led to hostapd updating the derivation which leaves older
hostapd versions using SHA1 and newer versions using SHA256.

To support this the checksum type is being fed to
handshake_state_get_pmkid so the caller can decide what sha to
use. In addition handshake_state_pmkid_matches is being added
which uses get_pmkid() but handles sorting out the hash type
automatically.

This lets preauthentication use handshake_state_get_pmkid where
there is the potential that a new PMKID is derived and eapol
can use handshake_state_pmkid_matches which only derives the
PMKID to compare against the peers.
2023-06-26 21:55:24 -05:00