Re: WPA3 SAE passphrase limitation

[James Prestwood <prestwoj@gmail.com>]

On Mon, 2022-12-05 at 12:48 -0600, Denis Kenzior wrote:
> Hi Emil,
> 
> On 12/5/22 11:44, Emil Velikov wrote:
> > On Mon, 5 Dec 2022 at 16:58, Denis Kenzior <denkenz@gmail.com>
> > wrote:
> > > 
> > > Hi Emil,
> > > 
> > > On 12/5/22 10:19, Emil Velikov wrote:
> > > > Greetings list,
> > > > 
> > > > I was playing around with a router using WPA3 Personal (only) +
> > > > CCMP-128 (AES) and noticed something odd. Namely: the 8
> > > > character
> > > > limitation imposed by WPA2 is enforced with WPA3/SAE.
> > > > 
> > > 
> > > What 8 character limitation?
> > > 
> > On all the routers that I've tried the WPA2-Personal passphrase
> > must
> > be at 8-64 characters long. Anything outside of that and the router
> > will refuse. Although I admit that I'm not aware if that's required
> > by
> > the spec or otherwise.
> > 
> 
> Right.  8-63 actually and it is mandated by 802.11.  The worst part
> is that for 
> some reason they mandated ASCII only as well.
> 
> In WPA2 the passphrase is only used to generate the PSK.  Hence
> 802.11 refers to 
> it as passphrase -> psk 'mapping'.
> 
> > On the other hand I can use a passphrase outside of that range with
> > WPA3 only routers.
> 
> This doesn't apply for WPA3 since the passphrase is used directly. 
> No need to 
> generate the PSK.
> 
> > 
> > > > Whenever I try to use such a passphrase (via iwctl) I get an
> > > > error
> > > > "Argument format is invalid".
> > > > 
> > > 
> > > Refer to crypto_passphrase_is_valid() for what we consider a
> > > valid passphrase.
> > > 
> > > > I realise it's not the best practice but the exact same router
> > > > just
> > > > works with my Android Pixel phone.
> > > > 
> > > > Would anyone be interested in fixing this bug? Alternatively
> > > > any
> > > > pointers where the validation happens would be appreciated.
> > > > 
> > > 
> > > What bug?  In theory the passphrase can be anything for SAE-only
> > > networks, but
> > > since there are plenty of cases where hybrid networks exist,
> > > managing separate
> > > SAE and non-SAE passphrases becomes tricky.
> > > 
> > 
> > Whenever I try to use short passphrases ("testing", "foobar" or
> > "foo123") with a WPA3 only network, IWD fails to connect as
> > mentioned
> > earlier. I don't have the spec to confirm, but this sounds like a
> > bug.
> 
> Just a design decision.  When we started WPA3 was still rather
> uncommon and 
> hybrid networks were (and probably still are) typical.  Since you
> want to roam 
> between WPA3/WPA2 access points, enforcing the same passphrase
> requirements made 
> sense.
> 
> > 
> > Can IWD detect if the network is WPA2+WPA3 or WPA3 only?
> 
> Not really.  You can have a network composed of WPA3-only, WPA2-only
> or 
> WPA2/WPA3 hybrid APs.
> 
> About the only thing we can do is 'assume' WPA3 when:
> 1. The user entered a non-conforming passphrase, and
> 2. The current connection candidate is a WPA3-only AP,
> 3. Connection succeeded

There is also the case of network profiles which we know even less
about compared to agent requests. We could allow <8 character
passphrases and just force WPA3 for these profiles too... but its still
a rather weird side effect having a short passphrase force WPA3.

> 
> We'd then need to make sure to set the WPA2 transition disabled flag
> and make 
> sure we don't try to generate / or save a PSK.  The transition
> disabled 
> indication would make sure we can't connect to WPA2 APs in the same
> network.
> 
> > 
> > It so, would it make sense to omit the `passphrase_len < 8 ||
> > passphrase_len > 63` restriction in crypto_passphrase_is_valid()
> > when
> > the network is in WPA3 only case?
> > 
> 
> See above.  It is not that simple, but can be done.
> 
> Regards,
> -Denis
>