WPA3. Под ковром.

После анонса WPA3 многие отметили что его часть, касающаяся защиты открытых сетей уж очень сильно похожа на OWE (Opportunistic Wireless Encryption).

Сам RFC 8110 может на первый взгляд показаться слегка запутанным. На самом деле, все очень просто. https://tools.ietf.org/html/rfc8110

Изначально все родилось из идеи использовать для открытых сетей SSID в качестве пароля (PSK).
Пруф: https://github.com/wkumari/draft-wkumari-owe

Подразумевалось, что точка доступа должна анонсировать подобный режим и клиенты в случае поддержки переходили на такой способ аутентификации. Это не особо помогало от атак MITM и Evil Twin (от них мало что спасает), но исключало или сильно усложняло пассивное прослушивание.
Драфт за драфтом стандарт допиливался.
В итоге от этой идеи отказались и решили усилить подключение вместо SSID в качестве PSK протоколом Диффи-Хеллмана.

Давайте немного разберем итоговый RFC.

4.2. OWE Discovery
Тут отмечается, что точка доступа анонсирует поддержку OWE прямо в beacon, а так же отвечает на запросы клиентов служебным кадром с данной опцией. Пока все просто и понятно.

4.3. OWE Association
Процедура Association с самых первых стандартов выполняется всегда при подключении к вайфай точке доступа. Точка доступа и клиент в этот момент договариваются о том, какой тип шифрования будут использовать. Если тип шифрования open, то клиент с точкой просто обмениваются сообщениями туда-сюда и устанавливается полноценное соединение. Если на точке включен OWE, то в служебные кадры добавляются открытые ключи точки и клиента (там ошибка синтаксическая в RFC). Дальше генерируется PMK - общий ключ на основе конкатенации открытых ключей, его идентификатора, хэша и хитрой магии. То есть, точка и клиент договорились о том каким ключем будут шифровать сообщения для инициализации сессионного ключа Pairwise Transient Key (PTK). Которым уже будет шифроваться трафик между самой точкой и клиентом.
Получается три ступени: снюхались, сгенерировали мастер-ключ PMK через Диффи-Хеллмана, потом на его основе сгенерировали сессионный ключ PTK для шифрования трафика (те самые 4 рукопожатия).
ПРОФИТ!

Что же касается слов про 192-bit CNSA security suite, тут все достаточно прозаично. Это, похоже, значение по умолчанию для длины Key-Confirmation-Key (KCK).
Данный ключ используется для защиты во время согласования ключа PTK. Это если совсем по-простому "на салфетках".

Выводы:

1) Теперь не будет никаких предварительно известных ключей и криптостойкость итогового ключа шифрования не зависит от вашего пароля, даже если он состоит из нескольких цифр в порядке возрастания.

2) Появилась возможность стойко шифровать соединение "без пароля" в открытых сетях. Это значит, что подключаться к хотспотам в ресторанах станет чуточку безопаснее, но все равно расслабляться не стоит. Лучше использовать VPN.
3) Альянс не стал ничего придумывать и просто решил утвердить RFC в качестве стандарта. Ну, пускай так.