i read that wpa3 is software so think we can add support to it...
1 Like
Of course, there's the question of client support as well. There's a "WPA3-Personal Transition Mode" for non-enterprise APs, which likely would need to be implemented during the 5-10+ years until WPA-2 devices are either updated or are replaced.
A WPA3-Personal access point (AP) in transition mode enables WPA2-Personal and WPA3-Personal simultaneously on a single basic service set (BSS) to support client devices using a mix of WPA2-Personal and WPA3-Personal with the same passphrase. Client devices that support both WPA2-Personal and WPA3-Personal connect using the higher-security method of WPA3-Personal when available. To ensure interoperability with legacy devices that do not support PMF, WPA3-Personal Transition Mode configures the network as PMF capable (Management Frame Protection Capable bit = 1 and Management Frame Protection Required bit = 0), rather than PMF required.
The full benefits of WPA3-Personal are only available when not operating in WPA3-Personal Transition Mode. Once WPA3-Personal availability reaches a sufficient level amongst client devices, network owners should disable WPA3-Personal Transition Mode.
Having read through the "specs", they don't look "directly actionable" in their detail. Most are 7 pages or less.
If there is more and it can be truly a software-only implementation, I would think that hostap would implement it.
http://lists.infradead.org/pipermail/hostap/2018-March/038334.html
The master branch of hostap.git includes support for WPA3 and DPP.
i read that wpa3 improve security so we just need hardware capable of hardware encryption... Any modern router should already support it...
If you find the commit that adds wpa3 support to hostapd i can try to make a backport patch!
1 Like
At least as I read Wi-Fi CERTIFIED WPA3 Technology Overview.pdf, the primary security "improvement" is not any "new" crypto for non-enterprise networks, but primarily the replacement of PSK with SAE along with mandating CCMP and protected management frames (the latter of the two already are available with WPA2, but not mandated).
Of those, SAE is the "most interesting" as it helps reduce the risk of password extraction/guessing. SAE is already used by 802.11s.
1 Like
i sent a mail to hostapd mailing list...
they say that wpa3 is already suppoterd but i can't find any commit on the git repo...
Any idea?
well, WPA3 feels more like a extension to WPA2 than something completely new. You can find the spec documents (on github 
) and many articles on the web about "WPA3 features"... and their implications.
(Sorry, but I'm not going to write them all down.)
When you know what feature(s) you are most interested, then enable the options in hostapd & wpa_supplicant build config:
CONFIG_OWE - Opportunistic wireless encryption
(encryption without authentication - that thing that is useful for (public) hotspots)
CONFIG_DPP - Device Provisioning Protocol ( Wi-Fi Easy Connect(TM) )
(The "Connect a IoT-device with the help of your smartphone" feature.)
CONFIG_SAE - Simultaneous Authentication of Equals
(This is the PSK-replacement. It's resistant to offline dictionary attacks. it implements forward secrecy, etc.)
(CONFIG_SUITEB)
CONFIG_SUITEB192
(Optional 192-bit security mode for "WPA3-Enterprise")
(Note: You probably want to build the "full" variant. And if you are planning to built wpa_supplicant or wpad, you'll have to enable 11W in the wpa_supplicant build config... as well as openssl (ideally of course with openssl 1.1.x - of course wolfssl could work as well but I haven't tested that one yet). so: Pick your poison 
)
(Note2: Of course: OWE, SAE need to be configured on the OpenWrt device too. Luckily, you can find some notes in the current hostapd.conf about how to enable and use these things.)
good luck 
Ummmm so we still don't have wpa3 but we have the modes that require wpa3 right?
As soon as there are some WPA3 clients, all the hooks appear to be in place in the master branch of hostap. Someday some hooks in LuCI likely would be helpful, but I'm not holding my breath for WPA3 Wi-Fi Certified compliant client devices in the next year or two. Or five...
I agree with @chunkeey assessment, an extension to WPA2 -- there isn't anything new in terms of benefit for most home users other than SAE instead of PSK and maybe that the DPP is somewhat better than the mess of the WPA2 easy-connect debacle.
How do I use WAP3 then if it's included in Master?
I have a WLAN where all devices should be capable of WPA3. I'm ready to test!
Well, from what I know only the SAE part (CONFIG_SAE) is really a required part of the WPA3 spec. OWE, DPP and the NSA Suite-B 192Bit ciphers are optional / feature specific.
So you just have to enable the options in the hostapd and wpa_supplicant build config files (it's easier to start from the -full + -openssl variants). Then build and install the package... And you are "Done"...
Well not really, you'll have to "know" what you are doing in regards to the runtime-config generation. And most importantly you have to know what you actually want. As far as SAE goes, it introduces a couple of new parameters that sort of either replaces or extends the "wpa_passphrase".
For now, the easiest way to deal with them at them moment is to specify them with the help of the "hostapd_options" in uci /e/c/wireless. From what I can tell, the "full" integration into the existing hostapd.sh and LuCI will be really tricky though. Unless of course you have no problems running your own custom solution.
3 Likes
is it chipset specific or driver support is needed only? looking ar9271 datasheet there is no mention of 11w, yet client driver for windows exposes MFP option in advanced settings
Well, I don't want to post the WPA3_Specification_v1.0.pdf here. But if you get the document (The Version I have is just 7 pages!) go look in Section 2.1.1 and 2.1.2 it tells you there that Protected Management Frames feature is required for SAE.
Any news on that? Would be great to have WPA3 support for open wifi. Having traffic encryption to each client in an open wlan would be awesome.
I dont think that its important to have WPA3-closed-source device first. It would be great benefit also in the worldwide press when OpenWrt is the first firmware that supports WPA3. Client and AP mode can be done in OpenWrt itself.
So WPA3 support available for the people on the planet would be first available for free software users of free wlan devices with free ath9k chipsets. Thats would be awesome.
PS: Could someone rename the topic here from lede to OpenWrt?
An interesting post by someone who got it to work:
1 Like
From what I understood previously, and from your link, OpenWrt needs:
- to enable the
CONFIG_SAEflag in wpad-mini and/or wpad - add WPA3 "stuff" to LuCI and UCI
- DONE!
2 Likes
Well, wpad-mini will probably need 11W too, since WPA3 hijacks the MFP feature bits. But otherwise yes: uci/LuCI is holding it back since nobody knows how complete the uci/LuCI integration should be.
2 Likes
Funny this topic is coming up now, I'm playing with my A5V11 to see if I can get WPA3 to work on it.
Note that it appears you need either OpenSSL or WolfSSL, so the wpad-mini won't work (simply enabling SAE causes it to fail during compile).
I've built a build with CONFIG_SAE and CONFIG_OWE set on wpad-wolfssl and it seems to compile just fine. I'm just trying to get it to fit into 4MB of flash along with zram and Luci (if I minify lua sources I can get it to fit, but I want to play around with non-minified sources).
I'm trying now to compile wpad-mini with a reference with WolfSSL and SAE/OWE, we'll see how that works...
wpad-mesh supports SAE for 802.11s and may be sufficient. Selecting the "full" wpad might be an easier path to follow than trying to "hack" wpad-mini into submission, at least for exploratory purposes.
1 Like
I have a feeling you're right...
1 Like