Kernel
/
iwd
mirror of https://git.kernel.org/pub/scm/network/wireless/iwd.git
3
0
Fork 0
Code Releases Activity
iwd/src/ft.h

92 lines
2.9 KiB
C
Raw Normal View History

netdev: Handle the FT Authentication Response message Parse the second message of the FT transition, validate and build the third message, the Reassociation Request.
2017-01-12 09:36:01 +01:00
/*
*
* Wireless daemon for Linux
*
treewide: Move the Intel copyright forward to 2019
2019-10-25 00:43:08 +02:00
* Copyright (C) 2017-2019 Intel Corporation. All rights reserved.
netdev: Handle the FT Authentication Response message Parse the second message of the FT transition, validate and build the third message, the Reassociation Request.
2017-01-12 09:36:01 +01:00
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library; if not, write to the Free Software
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
*
*/
ft: create class for FT-over-DS targets FT-over-DS is being separated into two independent stages. The first of which is the processing of the action frame response. This new class will hold all the parsed information from the action frame and allowing it to be retrieved at a later time when IWD needs to roam. Initial info class should be created when the action frame is being sent out. Once a response is received it can be parsed with ft_over_ds_parse_action_response. This verifies the frame and updates the ft_ds_info class with the parsed data. ft_over_ds_prepare_handshake is the final step prior to Reassociation. This sets all the stored IEs, anonce, and KH IDs into the handshake and derives the new PTK.
2021-04-30 01:08:36 +02:00
struct handshake_state;
ft: netdev: prep for FT isolation into ft.c Currently netdev handles caching FT auth information and uses FT parsers/auth-proto to manage the protocol. This sets up to remove this state machine from netdev and isolate it into ft.c. This does not break the existing auth-proto (hence the slight modifications, which will be removed soon). Eventually the auth-proto will be removed from FT entirely, replaced just by an FT state machine, similar to how EAPoL works (netdev hooks to TX/RX frames).
2022-09-27 21:47:21 +02:00
struct scan_bss;
typedef int (*ft_tx_frame_func_t)(uint32_t ifindex, uint16_t frame_type,
uint32_t frequency,
const uint8_t *dest, struct iovec *iov,
size_t iov_len);
ft: create class for FT-over-DS targets FT-over-DS is being separated into two independent stages. The first of which is the processing of the action frame response. This new class will hold all the parsed information from the action frame and allowing it to be retrieved at a later time when IWD needs to roam. Initial info class should be created when the action frame is being sent out. Once a response is received it can be parsed with ft_over_ds_parse_action_response. This verifies the frame and updates the ft_ds_info class with the parsed data. ft_over_ds_prepare_handshake is the final step prior to Reassociation. This sets all the stored IEs, anonce, and KH IDs into the handshake and derives the new PTK.
2021-04-30 01:08:36 +02:00
ft: netdev: move Authenticate IE building into ft.c Since FT already handles processing the FT IE's (and building for associate) it didn't make sense to have all the IE building inside netdev_build_cmd_ft_authenticate. Instead this logic was moved into ft.c, and an iovec is now passed from FT into netdev_ft_tx_authenticate. This leaves the netdev command builder unburdened by the details of FT, as well as prepares for FT-over-DS.
2019-05-09 19:14:12 +02:00
typedef void (*ft_tx_authenticate_func_t)(struct iovec *iov, size_t iov_len,
void *user_data);
ft: netdev: prep for FT isolation into ft.c Currently netdev handles caching FT auth information and uses FT parsers/auth-proto to manage the protocol. This sets up to remove this state machine from netdev and isolate it into ft.c. This does not break the existing auth-proto (hence the slight modifications, which will be removed soon). Eventually the auth-proto will be removed from FT entirely, replaced just by an FT state machine, similar to how EAPoL works (netdev hooks to TX/RX frames).
2022-09-27 21:47:21 +02:00
typedef int (*ft_tx_associate_func_t)(uint32_t ifindex, uint32_t freq,
const uint8_t *prev_bssid,
struct iovec *ie_iov, size_t iov_len);
ft: get OCI prior to reassociation This modifies the FT logic to fist call get_oci() before reassociation. This allows the OCI to be included in reassociation and in the 4-way handshake later on. The code path for getting the OCI had to be slightly changed to handle an OCI that is already set. First the handshake chandef is NULL'ed out for any new connection. This prevents a stale OCI from being used. Then some checks were added for this case in netdev_connect_event and if chandef is already set, start the 4-way handshake.
2021-09-28 17:46:54 +02:00
typedef int (*ft_get_oci)(void *user_data);
netdev: Handle the FT Authentication Response message Parse the second message of the FT transition, validate and build the third message, the Reassociation Request.
2017-01-12 09:36:01 +01:00
ft: create class for FT-over-DS targets FT-over-DS is being separated into two independent stages. The first of which is the processing of the action frame response. This new class will hold all the parsed information from the action frame and allowing it to be retrieved at a later time when IWD needs to roam. Initial info class should be created when the action frame is being sent out. Once a response is received it can be parsed with ft_over_ds_parse_action_response. This verifies the frame and updates the ft_ds_info class with the parsed data. ft_over_ds_prepare_handshake is the final step prior to Reassociation. This sets all the stored IEs, anonce, and KH IDs into the handshake and derives the new PTK.
2021-04-30 01:08:36 +02:00
typedef void (*ft_ds_free_func_t)(void *user_data);
struct ft_ds_info {
uint8_t spa[6];
uint8_t aa[6];
uint8_t snonce[32];
uint8_t mde[3];
uint8_t *fte;
ft: netdev: store FT-over-DS target RSNE/WPA Keep track of the target BSS's authenticator IE for verification. It should not be assumed that the target BSS and original RSNE/WPA IE matches.
2021-09-28 23:27:39 +02:00
uint8_t *authenticator_ie;
ft: create class for FT-over-DS targets FT-over-DS is being separated into two independent stages. The first of which is the processing of the action frame response. This new class will hold all the parsed information from the action frame and allowing it to be retrieved at a later time when IWD needs to roam. Initial info class should be created when the action frame is being sent out. Once a response is received it can be parsed with ft_over_ds_parse_action_response. This verifies the frame and updates the ft_ds_info class with the parsed data. ft_over_ds_prepare_handshake is the final step prior to Reassociation. This sets all the stored IEs, anonce, and KH IDs into the handshake and derives the new PTK.
2021-04-30 01:08:36 +02:00
struct ie_ft_info ft_info;
void (*free)(struct ft_ds_info *s);
};
void ft_ds_info_free(struct ft_ds_info *info);
ft: make Authenticate OCVC settable by caller The FT-over-DS action stage builds an FT-Request which contains an RSNE. Since FT-over-DS will not support OCV add a boolean to ft_build_authenticate_ies so the OCVC bit can be disabled rather than relying on the handshake setting.
2021-09-28 17:46:57 +02:00
bool ft_build_authenticate_ies(struct handshake_state *hs, bool ocvc,
ft: expose ft_build_authenticate_ies The building of the FT IEs for Action/Authenticate frames will need to be shared between ft and netdev once FT-over-DS is refactored. The building was refactored to work off the callers buffer rather than internal stack buffers. An argument 'new_snonce' was included as FT-over-DS will generate a new snonce for the initial action frame, hence the handshakes snonce cannot be used.
2021-04-27 21:49:41 +02:00
const uint8_t *new_snonce, uint8_t *buf,
size_t *len);
ft: break up FT action parsing into two steps This is to prepare for multiple concurrent FT-over-DS action frames. A list will be kept in netdev and for lookup reasons it needs to parse the start of the frame to grab the aa/spa addresses. In this call the IEs are also returned and passed to the new ft_over_ds_parse_action_response. For now the address checks have been moved into netdev, but this will eventually turn into a queue lookup.
2021-05-13 01:01:40 +02:00
int ft_over_ds_parse_action_response(const uint8_t *frame, size_t frame_len,
const uint8_t **spa_out,
const uint8_t **aa_out,
const uint8_t **ies_out,
size_t *ies_len);
bool ft_over_ds_parse_action_ies(struct ft_ds_info *info,
ft: create class for FT-over-DS targets FT-over-DS is being separated into two independent stages. The first of which is the processing of the action frame response. This new class will hold all the parsed information from the action frame and allowing it to be retrieved at a later time when IWD needs to roam. Initial info class should be created when the action frame is being sent out. Once a response is received it can be parsed with ft_over_ds_parse_action_response. This verifies the frame and updates the ft_ds_info class with the parsed data. ft_over_ds_prepare_handshake is the final step prior to Reassociation. This sets all the stored IEs, anonce, and KH IDs into the handshake and derives the new PTK.
2021-04-30 01:08:36 +02:00
struct handshake_state *hs,
ft: break up FT action parsing into two steps This is to prepare for multiple concurrent FT-over-DS action frames. A list will be kept in netdev and for lookup reasons it needs to parse the start of the frame to grab the aa/spa addresses. In this call the IEs are also returned and passed to the new ft_over_ds_parse_action_response. For now the address checks have been moved into netdev, but this will eventually turn into a queue lookup.
2021-05-13 01:01:40 +02:00
const uint8_t *ies,
size_t ies_len);
ft: create class for FT-over-DS targets FT-over-DS is being separated into two independent stages. The first of which is the processing of the action frame response. This new class will hold all the parsed information from the action frame and allowing it to be retrieved at a later time when IWD needs to roam. Initial info class should be created when the action frame is being sent out. Once a response is received it can be parsed with ft_over_ds_parse_action_response. This verifies the frame and updates the ft_ds_info class with the parsed data. ft_over_ds_prepare_handshake is the final step prior to Reassociation. This sets all the stored IEs, anonce, and KH IDs into the handshake and derives the new PTK.
2021-04-30 01:08:36 +02:00
ft: netdev: station: support FT-over-DS FT-over-DS is a way to do a Fast BSS Transition using action frames for the authenticate step. This allows a station to start a fast transition to a target AP while still being connected to the original AP. This, in theory, can result in less carrier downtime. The existing ft_sm_new was removed, and two new constructors were added; one for over-air, and another for over-ds. The internals of ft.c mostly remain the same. A flag to distinguish between air/ds was added along with a new parser to parse the action frames rather than authenticate frames. The IE parsing is identical. Netdev now just initializes the auth-proto differently depending on if its doing over-air or over-ds. A new TX authenticate function was added and used for over-ds. This will send out the IEs from ft.c with an FT Request action frame. The FT Response action frame is then recieved from the AP and fed into the auth-proto state machine. After this point ft-over-ds behaves the same as ft-over-air (associate to the target AP). Some simple code was added in station.c to determine if over-air or over-ds should be used. FT-over-DS can be beneficial in cases where the AP is directing us to roam, or if the RSSI falls below a threshold. It should not be used if we have lost communication to the AP all (beacon lost) as it only works while we can still talk to the original AP.
2019-05-09 20:16:28 +02:00
struct auth_proto *ft_over_air_sm_new(struct handshake_state *hs,
ft_tx_authenticate_func_t tx_auth,
ft_tx_associate_func_t tx_assoc,
ft: get OCI prior to reassociation This modifies the FT logic to fist call get_oci() before reassociation. This allows the OCI to be included in reassociation and in the 4-way handshake later on. The code path for getting the OCI had to be slightly changed to handle an OCI that is already set. First the handshake chandef is NULL'ed out for any new connection. This prevents a stale OCI from being used. Then some checks were added for this case in netdev_connect_event and if chandef is already set, start the 4-way handshake.
2021-09-28 17:46:54 +02:00
ft_get_oci get_oci,
ft: netdev: station: support FT-over-DS FT-over-DS is a way to do a Fast BSS Transition using action frames for the authenticate step. This allows a station to start a fast transition to a target AP while still being connected to the original AP. This, in theory, can result in less carrier downtime. The existing ft_sm_new was removed, and two new constructors were added; one for over-air, and another for over-ds. The internals of ft.c mostly remain the same. A flag to distinguish between air/ds was added along with a new parser to parse the action frames rather than authenticate frames. The IE parsing is identical. Netdev now just initializes the auth-proto differently depending on if its doing over-air or over-ds. A new TX authenticate function was added and used for over-ds. This will send out the IEs from ft.c with an FT Request action frame. The FT Response action frame is then recieved from the AP and fed into the auth-proto state machine. After this point ft-over-ds behaves the same as ft-over-air (associate to the target AP). Some simple code was added in station.c to determine if over-air or over-ds should be used. FT-over-DS can be beneficial in cases where the AP is directing us to roam, or if the RSSI falls below a threshold. It should not be used if we have lost communication to the AP all (beacon lost) as it only works while we can still talk to the original AP.
2019-05-09 20:16:28 +02:00
void *user_data);
struct auth_proto *ft_over_ds_sm_new(struct handshake_state *hs,
netdev: ft: refactor FT into an auth-proto Since FT operates over Authenticate/Associate, it makes the most sense for it to behave like the other auth-protos. This change moves all the FT specific processing out of netdev and into ft.c. The bulk of the changes were strait copy-pastes from netdev into ft.c with minor API changes (e.g. remove struct netdev). The 'in_ft' boolean unforunately is still required for a few reasons: - netdev_disconnect_event relies on this flag so it can ignore the disconnect which comes in when doing a fast transition. We cannot simply check netdev->ap because this would cause the other auth-protos to not handle a disconnect correctly. - netdev_associate_event needs to correctly setup the eapol_sm when in FT mode by setting require_handshake and use_eapol_start to false. This cannot be handled inside eapol by checking the AKM because an AP may only advertise a FT AKM, and the initial mobility association does require the 4-way handshake.
2019-05-07 20:53:42 +02:00
ft_tx_associate_func_t tx_assoc,
void *user_data);
ft: create class for FT-over-DS targets FT-over-DS is being separated into two independent stages. The first of which is the processing of the action frame response. This new class will hold all the parsed information from the action frame and allowing it to be retrieved at a later time when IWD needs to roam. Initial info class should be created when the action frame is being sent out. Once a response is received it can be parsed with ft_over_ds_parse_action_response. This verifies the frame and updates the ft_ds_info class with the parsed data. ft_over_ds_prepare_handshake is the final step prior to Reassociation. This sets all the stored IEs, anonce, and KH IDs into the handshake and derives the new PTK.
2021-04-30 01:08:36 +02:00
bool ft_over_ds_prepare_handshake(struct ft_ds_info *info,
struct handshake_state *hs);
ft: netdev: prep for FT isolation into ft.c Currently netdev handles caching FT auth information and uses FT parsers/auth-proto to manage the protocol. This sets up to remove this state machine from netdev and isolate it into ft.c. This does not break the existing auth-proto (hence the slight modifications, which will be removed soon). Eventually the auth-proto will be removed from FT entirely, replaced just by an FT state machine, similar to how EAPoL works (netdev hooks to TX/RX frames).
2022-09-27 21:47:21 +02:00
void __ft_set_tx_frame_func(ft_tx_frame_func_t func);
void __ft_set_tx_associate_func(ft_tx_associate_func_t func);
int __ft_rx_associate(uint32_t ifindex, const uint8_t *frame,
size_t frame_len);
void __ft_rx_action(uint32_t ifindex, const uint8_t *frame, size_t frame_len);
void ft_clear_authentications(uint32_t ifindex);
int ft_action(uint32_t ifindex, uint32_t freq, const struct scan_bss *target);
int ft_associate(uint32_t ifindex, const uint8_t *addr);