Re: [PATCH 04/10] network: add support for SAE password identifiers

[Denis Kenzior <denkenz@gmail.com>]

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?

>>
>> 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.

Regards,
-Denis