WPA3 SAE passphrase limitation

WPA3 SAE passphrase limitation

[Emil Velikov]

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.

Whenever I try to use such a passphrase (via iwctl) I get an error
"Argument format is invalid".

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.

Thanks in advance,
Emil

Re: WPA3 SAE passphrase limitation

[Denis Kenzior]

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?

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

Regards,
-Denis

Regards,
-Denis

Re: WPA3 SAE passphrase limitation

[Emil Velikov]

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.

On the other hand I can use a passphrase outside of that range with
WPA3 only routers.

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

Can IWD detect if the network is WPA2+WPA3 or WPA3 only?

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?

Thanks again,
Emil

Re: WPA3 SAE passphrase limitation

[Denis Kenzior]

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

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

Re: WPA3 SAE passphrase limitation

[James Prestwood]

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
> 

Re: WPA3 SAE passphrase limitation

[Denis Kenzior]

Hi James,

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

This isn't only about < 8 chars.  It is also about allowing UTF8 passphrases, 
which is kinda desirable.

I would think the same restrictions would apply to saved profiles:
1. non-compliant passphrase
2. PSK setting must not be set
3. transition disable indication set.

If the above 3 are met, then we would allow this and the network would be 
treated as WPA3-only.

Regards,
-Denis

Re: WPA3 SAE passphrase limitation

[Emil Velikov]

Greetings Denis,

On Mon, 5 Dec 2022 at 18:48, Denis Kenzior <denkenz@gmail.com> wrote:
>
> Hi Emil,

(snip)
>
> 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.
>
Thank you for the much needed crash course, it's deeply appreciated.

(snip)
> >
> > 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
>
> 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.
>
From my non-expert POV, the above heuristics look perfectly reasonable.

To distinguish WPA3 only connections, from transition WPA2/WPA3
connections, one could store the profile as "$BSSID.sae" files. Where
the usual "$BSSID.psk" ones are preserved for WPA2 compatible
connections. To preserve backwards compatibility IWD could:
 - if the AP is WPA3 capable (regardless if it also supports WPA2) -
try the sae profile
 - if the connection is unsuccessful and the AP is WPA1/WPA2 capable -
try the psk profile

The above have some obvious caveats, but overall would help with:
 - providing clear distinction for the user about the connection types
 - keep connection type specifics where applicable - no more
PreSharedKey in .sae files, no SAE-PT-GroupXX in .psk files...
 - roaming between WPA2/WPA3 AP and WPA3-only AP with the same BSSID,
yet different passphrase

Mind you, I'm not sure if the last point is allowed in the spec. So
please take all the above with a healthy pinch of salt.

> >
> > 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.
>
Makes sense - for the time being I'll stick to 8-63 character
passphrases even for WPA3 only networks.

As always, thank you for the helpful and enlightening reply \o/
-Emil

Re: WPA3 SAE passphrase limitation

[Denis Kenzior]

Hi Emil,

> 
> To distinguish WPA3 only connections, from transition WPA2/WPA3
> connections, one could store the profile as "$BSSID.sae" files. Where
> the usual "$BSSID.psk" ones are preserved for WPA2 compatible
> connections. To preserve backwards compatibility IWD could:
>   - if the AP is WPA3 capable (regardless if it also supports WPA2) -
> try the sae profile
>   - if the connection is unsuccessful and the AP is WPA1/WPA2 capable -
> try the psk profile

This would be a much more invasive change, especially since iwd deals in 
'logical' networks.  Not sure that it would makes sense to store settings about 
a logical network in two separate profiles.  Possibly?

But... network-centric settings (see man 5 iwd.network) would need to be 
duplicated and synchronized.  So what you suggest becomes a lot more complicated 
to implement.

Supporting non-ASCII & arbitrary length passphrases for WPA3-only can already be 
accomplished by setting TransitionDisable and DisabledTransitionModes in the 
network file along with loosening the passphrase validity checking rules as 
discussed upthread.

> 
> The above have some obvious caveats, but overall would help with:
>   - providing clear distinction for the user about the connection types

Both WPA3 and WPA2 are PSK networks.  And really, most users don't ever need to 
see/edit the files in /var/lib/iwd.

>   - keep connection type specifics where applicable - no more
> PreSharedKey in .sae files, no SAE-PT-GroupXX in .psk files...

Possibly, but see above.

>   - roaming between WPA2/WPA3 AP and WPA3-only AP with the same BSSID,
> yet different passphrase

So in theory it is indeed possible to have a different passphrase between WPA3 
and WPA2 APs in the same network.  But I don't think separating the PSK networks 
into .psk and .sae profiles is the answer.

Adding additional entries for SAE-specific passphrase and passphrase identifiers 
might be possible.  But this only works for static setups where the profile 
isn't (supposed to be) changed by iwd itself.

When we ask a user for the passphrase (and eventually write it to disk) we just 
don't know whether the user entered a 'global' passphrase, 'sae-only' 
passphrase, etc.  So for now we assume the passphrase is 'global' and apply 
passphrase restrictions accordingly.

> 
> Mind you, I'm not sure if the last point is allowed in the spec. So
> please take all the above with a healthy pinch of salt.
> 

It is.  It is even possible to have 'password identifiers' and use different 
passphrases per password id.  All sorts of complex setups are possible.  The 
question is how do you make it 'just work'?

Regards,
-Denis