Wireless Daemon for Linux
 help / color / mirror / Atom feed
From: James Prestwood <prestwoj@gmail.com>
To: John Brandt <brandtwjohn@gmail.com>, iwd@lists.linux.dev
Subject: Re: [PATCH 08/11] ap: add support to handle SAE authentication
Date: Wed, 24 Apr 2024 05:06:10 -0700	[thread overview]
Message-ID: <5476c11a-764e-43fa-9ac3-52adb811138b@gmail.com> (raw)
In-Reply-To: <20240421125050.6649-9-brandtwjohn@gmail.com>

Hi John,

On 4/21/24 5:50 AM, John Brandt wrote:
> When the client requests SAE authentication, and it is enabled, allocate
> an auth_proto instance to handle SAE authentication. This also adds a
> new function to send SAE frames in AP mode that can be used by the
> auth_proto instance.
> ---
>   src/ap.c | 64 ++++++++++++++++++++++++++++++++++++++++++++++++--------
>   1 file changed, 55 insertions(+), 9 deletions(-)
>
> diff --git a/src/ap.c b/src/ap.c
> index 14268551..ab0cbdcd 100644
> --- a/src/ap.c
> +++ b/src/ap.c
> @@ -59,6 +59,8 @@
>   #include "src/diagnostic.h"
>   #include "src/band.h"
>   #include "src/common.h"
> +#include "src/sae.h"
> +#include "src/auth-proto.h"
>   
>   struct ap_state {
>   	struct netdev *netdev;
> @@ -132,6 +134,7 @@ struct sta_state {
>   	uint8_t *assoc_ies;
>   	size_t assoc_ies_len;
>   	uint8_t *assoc_rsne;
> +	struct auth_proto *auth_proto;
>   	enum ie_rsn_akm_suite akm_suite;
>   	struct eapol_sm *sm;
>   	struct handshake_state *hs;
> @@ -2595,6 +2598,35 @@ static void ap_auth_reply(struct ap_state *ap, const uint8_t *dest,
>   				ap_auth_reply_cb, NULL);
>   }
>   
> +static void sae_auth_reply(const uint8_t *data, size_t len, void *user_data)
> +{
> +	struct sta_state *sta = (struct sta_state *)user_data;
> +	struct ap_state *ap = (struct ap_state *)sta->ap;
> +	const uint8_t *addr = netdev_get_address(ap->netdev);
> +	uint8_t sae_buf[2048];

Could probably pare this down a bit. I don't mind if we leave a little 
room but 2048 seems a bit much. In a commit we've got the header + 48 + 
96 bytes for the scalar/element + 32 bytes of a token + some other bytes 
here and there. You could probably at least half this and to be safe you 
could:

if (L_WARN_ON(len > sizeof(sae_buf))
     return;
> +	struct mmpdu_header *mpdu = (struct mmpdu_header *) sae_buf;
> +	struct mmpdu_authentication *auth;
> +
> +	memset(mpdu, 0, sizeof(*mpdu));
> +
> +	/* Header */
> +	mpdu->fc.protocol_version = 0;
> +	mpdu->fc.type = MPDU_TYPE_MANAGEMENT;
> +	mpdu->fc.subtype = MPDU_MANAGEMENT_SUBTYPE_AUTHENTICATION;
> +	memcpy(mpdu->address_1, sta->addr, 6);	/* DA */
> +	memcpy(mpdu->address_2, addr, 6);	/* SA */
> +	memcpy(mpdu->address_3, addr, 6);	/* BSSID */
> +
> +	/* Authentication body */
> +	auth = (void *) mmpdu_body(mpdu);
> +	auth->algorithm = L_CPU_TO_LE16(MMPDU_AUTH_ALGO_SAE);
> +
> +	/* SAE elements */
> +	memcpy(sae_buf + 26, data, len);
> +	ap_send_mgmt_frame(ap, mpdu, 26 + len,
> +				ap_auth_reply_cb, NULL);
> +}
> +
>   /*
>    * 802.11-2016 9.3.3.12 (frame format), 802.11-2016 11.3.4.3 and
>    * 802.11-2016 12.3.3.2 (MLME/SME)
> @@ -2664,7 +2696,7 @@ static void ap_auth_cb(const struct mmpdu_header *hdr, const void *body,
>   	 * than State 1."
>   	 */
>   	if (sta)
> -		goto done;
> +		goto have_sta;
>   
>   	/*
>   	 * Per 12.3.3.2.3 with Open System the state change is immediate,
> @@ -2679,18 +2711,32 @@ static void ap_auth_cb(const struct mmpdu_header *hdr, const void *body,
>   		ap->sta_states = l_queue_new();
>   
>   	sta->akm_suite = akm_suite;
> +	if (sta->akm_suite == IE_RSN_AKM_SUITE_SAE_SHA256) {
> +		sta->hs = netdev_handshake_state_new(sta->ap->netdev);
> +		handshake_state_set_authenticator(sta->hs, true);
> +		handshake_state_set_passphrase(sta->hs, ap->passphrase);
> +		handshake_state_set_supplicant_address(sta->hs, sta->addr);
> +		handshake_state_set_authenticator_address(sta->hs, bssid);
> +
> +		sta->auth_proto = sae_sm_new(sta->hs, sae_auth_reply, NULL, sta);
> +	}
>   
>   	l_queue_push_tail(ap->sta_states, sta);
>   
> -	/*
> -	 * Nothing to do here netlink-wise as we can't receive any data
> -	 * frames until after association anyway.  We do need to add a
> -	 * timeout for the authentication and possibly the kernel could
> -	 * handle that if we registered the STA with NEW_STATION now (TODO)
> -	 */
>   
> -done:
> -	ap_auth_reply(ap, from, 0);
> +have_sta:
> +	if (sta->akm_suite == IE_RSN_AKM_SUITE_SAE_SHA256) {
> +		auth_proto_rx_authenticate(sta->auth_proto, (const uint8_t *)hdr,
> +					   body + body_len - (void *) hdr);
> +	} else {
> +		/*
> +		 * Nothing to do here netlink-wise as we can't receive any data
> +		 * frames until after association anyway.  We do need to add a
> +		 * timeout for the authentication and possibly the kernel could
> +		 * handle that if we registered the STA with NEW_STATION now (TODO)
> +		 */
> +		ap_auth_reply(ap, from, 0);
> +	}
>   }
>   
>   /* 802.11-2016 9.3.3.13 (frame format), 802.11-2016 11.3.4.5 (MLME/SME) */

  reply	other threads:[~2024-04-24 12:06 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-21 12:50 [PATCH 00/11] Basic SAE support for AP mode John Brandt
2024-04-21 12:50 ` [PATCH 01/11] ap: ability to advertise PSK and SAE John Brandt
2024-04-21 12:50 ` [PATCH 02/11] ap: accept PSK/SAE in auth depending on config John Brandt
2024-04-24 12:05   ` James Prestwood
2024-04-21 12:50 ` [PATCH 03/11] sae: add function sae_set_group John Brandt
2024-04-24 12:05   ` James Prestwood
2024-04-21 12:50 ` [PATCH 04/11] sae: refactor and add function sae_calculate_keys John Brandt
2024-04-24 12:06   ` James Prestwood
2024-04-21 12:50 ` [PATCH 05/11] sae: make sae_process_commit callable in AP mode John Brandt
2024-04-24 12:08   ` James Prestwood
2024-04-21 12:50 ` [PATCH 06/11] sae: verify offered group " John Brandt
2024-04-21 12:50 ` [PATCH 07/11] sae: support reception of Confirm frame by AP John Brandt
2024-04-24 12:08   ` James Prestwood
2024-04-21 12:50 ` [PATCH 08/11] ap: add support to handle SAE authentication John Brandt
2024-04-24 12:06   ` James Prestwood [this message]
2024-04-21 12:50 ` [PATCH 09/11] ap: enable start of 4-way HS after SAE John Brandt
2024-04-21 12:50 ` [PATCH 10/11] eapol: support PTK derivation with SHA256 John Brandt
2024-04-21 12:50 ` [PATCH 11/11] eapol: encrypt key data for AKM-defined ciphers John Brandt
2024-04-22 13:52 ` [PATCH 00/11] Basic SAE support for AP mode James Prestwood
2024-04-24 12:07   ` James Prestwood
2024-04-29  0:04     ` John Brandt
2024-04-29 12:00       ` James Prestwood
2024-04-30 23:27         ` KeithG

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5476c11a-764e-43fa-9ac3-52adb811138b@gmail.com \
    --to=prestwoj@gmail.com \
    --cc=brandtwjohn@gmail.com \
    --cc=iwd@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox