From: James Prestwood <prestwoj@gmail.com>
To: Denis Kenzior <denkenz@gmail.com>, iwd@lists.linux.dev
Subject: Re: [PATCH 04/10] network: add support for SAE password identifiers
Date: Wed, 6 Dec 2023 11:53:07 -0800 [thread overview]
Message-ID: <69446eba-89cc-4279-8e47-151bdb6798b8@gmail.com> (raw)
In-Reply-To: <69055eff-521d-4e2d-b3c9-c98bb7ba36fb@gmail.com>
On 12/6/23 11:44, Denis Kenzior wrote:
> Hi James,
>
>>>> Loading the PSK will fail if there is no password identifier set
>>>> and the BSS sets the "exclusive" bit. If a password identifier is
>>>
>>> I'm not so sure about this. The trouble is that this logic is
>>> sufficient for the initial connection, but isn't sufficient when you
>>> consider re-association.
>> Your right, roaming would be entirely broken between BSS's that
>> mismatch using password identifiers. Maybe even hunt-and-peck and
>> H2E? not entirely sure. We
>
> Well, ReAssociate would just use SAE passphrase directly, so it would
> work in theory... But it is a bit of a strange case.
>
>> would need to re-derive the point for each roam, like in
>> network_set_handshake_secrets_psk().
>
> ?? You mean SAE-H2E with password identifier for BSSes that report
> exclusive/in-use bit and SAE-H2E for BSSes without? Or something else?
Yeah, I'm talking about multiple H2E BSS's that set or don't set the
exclusive/in-use bits. Maybe it would be ok actually. I got concerned
when I saw the points being set into the handshake in
network_set_handshake_secrets_psk() (which happens on roaming) but it
looks like this is only used for initial SAE association. Maybe
roaming/FT would be ok? But this is all moot if we just bail early if
the password identifier setting does not match the BSS's capabilities.
>>>
>>> This likely needs to be taken into consideration much later, when
>>> building the actual handshake state.
>>
>> Yeah, we'd need to move this into network_set_handshake_secrets_psk
>> and rederive the points. And actually if we do this storing the
>> points in the network profile doesn't make a whole lot of sense
>> anymore since its being rederived every time.
>
> I would hate for this to be the outcome. Re-deriving the PT is pretty
> expensive.
>
>>
>> Alternatively we just keep it how I have it and tell they user
>> they're network isn't configured properly :)
>
> I think it could be argued that if PasswordIdentifier is set, then any
> BSSes that are not H2E/do not set the in-use bit are not connectable.
This works for me. Much easier and will enforce a properly configured
network.
>
> Regards,
> -Denis
next prev parent reply other threads:[~2023-12-06 19:53 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-05 15:46 [PATCH 01/10] scan: parse password identifier/exclusive bits James Prestwood
2023-12-05 15:46 ` [PATCH 02/10] network: pass scan_bss into network_load_psk James Prestwood
2023-12-05 15:46 ` [PATCH 03/10] handshake: add password identifier/setter James Prestwood
2023-12-05 15:46 ` [PATCH 04/10] network: add support for SAE password identifiers James Prestwood
2023-12-06 17:08 ` Denis Kenzior
2023-12-06 18:44 ` James Prestwood
2023-12-06 19:44 ` Denis Kenzior
2023-12-06 19:53 ` James Prestwood [this message]
2023-12-05 15:46 ` [PATCH 05/10] sae: include password identifier IE in commit James Prestwood
2023-12-05 15:46 ` [PATCH 06/10] doc: document [Security].PasswordIdentifier James Prestwood
2023-12-05 15:46 ` [PATCH 07/10] auto-t: add H2E password identifier test James Prestwood
2023-12-05 15:46 ` [PATCH 08/10] mpdu: add unknown password identifier status James Prestwood
2023-12-05 15:46 ` [PATCH 09/10] sae: add debugging for incorrect password identifier James Prestwood
2023-12-05 15:46 ` [PATCH 10/10] auto-t: throw exception if executable is missing James Prestwood
2023-12-06 17:00 ` [PATCH 01/10] scan: parse password identifier/exclusive bits Denis Kenzior
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=69446eba-89cc-4279-8e47-151bdb6798b8@gmail.com \
--to=prestwoj@gmail.com \
--cc=denkenz@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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).