I'm finding the same on both sae and sae-mixed.
Android devices and older ios devices continue to connect fine.
Thus wpa2 works and wpa3 does not.
The Apple implementation doesn't, no.
Or, there is an incompatibility with hostapd, but I find that unlikely. Someone hasn't followed the standards.
The problem is not many people have wpa3 routers yet, so not many bug reports coming in. I've found almost nothing googling this issue.
I recently setup WPA3 on OpenWrt (see Auth_type in hostapd.sh (WPA3)) and I'm seeing the same problem. Even if I set the Wifi to be WPA3/WPA2 iOS13 fails to connect which suggests that there's a bug in Apple's implementation.
I see others are having the same problem:
there is a report that apple devices send an sae handshake (Wpa3 support in OpenWrt?)
but also that the wifi-dialog only mentions wpa3-eap (not sae(psk) nor owe)...
Suggested workaround (I hesitate to call it a fix): Wpa3 support in OpenWrt?
- Open
/etc/config/wireless - Add
option auth_cache '1'to your access point.
Worked for me.
Latest OpenWrt have now auth_cache enabled by default when WPA3 is enabled: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=3034f8c3b85e70b1dd9b4cd5cd33e9d2cd8be3b8
@mistepien, @lantis1008, @parsley72, would you guys mind reporting this bug to Apple? Here's where you can report iPhone bugs and iPad bugs. I've already filed a report, but more reports can't hurt.
Did it months ago.
No response.
FYI, it is actually not necessary to enable opportunistic key caching to get iOS 13 to behave. Enabling PMKSA caching is sufficient. I have a hostapd instance on a Debian machine where I enabled WPA3-Personal and ran into the same connection issues with my wife's iOS 13 devices. After enabling PMKSA caching they both connect again. Opportunistic key caching is still disabled in my configuration.
It may well be the case that Apple is doing the right thing here. At least according to this presentation [1], PMK caching is a requirement for WPA3-Personal:
WPA3-Personal Supplemental Requirements
- Protected Management Frame (PMF)
- PMK caching to avoid ECDH computation on reassociation
If this statement is correct, it might be the correct behavior of iOS 13 to refuse connecting to an AP if PMK caching is disabled. I could not find any information about this requirement elsewhere, though.
Edit: Assuming PMK caching is an effective measure to prevent side channel attacks against elliptic curves, then this document by the WiFi Alliance supports the statement above [2]:
SAE implementations must avoid differences in code execution that allow side channel information collection through the cache (see Cache-Based Elliptic CurveSide-Channels).
[1] https://d2cpnw0u24fjm4.cloudfront.net/wp-content/uploads/WLPC_2019_WPA3-OWE-and-DDP_Hemant-Chaskar.pdf
[2] https://www.wi-fi.org/download.php?file=/sites/default/files/private/WPA3_Security_Considerations_201911.pdf
2 Likes
Can someone please share their resulting hostapd conf file with WPA2/WPA3 mixed mode configured that works with iOS13? I'm running hostapd 2.9 on a vanilla linux machine similar to @silentcreek -- but can't seen to get iOS devices connected even with PMKSA caching (and/or OKC) enabled. I must be missing something else...
Yeah, configuring hostapd is a science of it's own. Here's my configuration for 802.11n 2.4GHz wifi:
interface=wlan1
bridge=br-wlan1
driver=nl80211
logger_syslog=-1
logger_syslog_level=2
logger_stdout=-1
logger_stdout_level=2
ssid=### Your SSID here ###
utf8_ssid=1
country_code=DE ### Adjust as appropriate
country3=0x49 ### Adjust as appropriate
ieee80211d=1
hw_mode=g
channel=1 ### Adjust as appropriate
beacon_int=200
dtim_period=2
max_num_sta=36
rts_threshold=-1
fragm_threshold=-1
basic_rates=60 120 240
preamble=1
macaddr_acl=1 ### Adjust as appropriate
accept_mac_file=/etc/hostapd/wlan1.accept ### Adjust as appropriate
auth_algs=1
ignore_broadcast_ssid=0
no_probe_resp_if_max_sta=1
wmm_enabled=1
uapsd_advertisement_enabled=1
wmm_ac_bk_cwmin=4
wmm_ac_bk_cwmax=10
wmm_ac_bk_aifs=7
wmm_ac_bk_txop_limit=0
wmm_ac_bk_acm=0
wmm_ac_be_aifs=3
wmm_ac_be_cwmin=4
wmm_ac_be_cwmax=10
wmm_ac_be_txop_limit=0
wmm_ac_be_acm=0
wmm_ac_vi_aifs=2
wmm_ac_vi_cwmin=3
wmm_ac_vi_cwmax=4
wmm_ac_vi_txop_limit=94
wmm_ac_vi_acm=0
wmm_ac_vo_aifs=2
wmm_ac_vo_cwmin=2
wmm_ac_vo_cwmax=3
wmm_ac_vo_txop_limit=47
wmm_ac_vo_acm=0
disassoc_low_ack=1
ap_isolate=1
bss_load_update_period=50
ieee80211n=1
ht_capab=[HT40-][HT40+][SHORT-GI-40][TX-STBC][RX-STBC1][DSSS_CCK-40] ### Adjust as appropriate
require_ht=1
eapol_key_index_workaround=0
eap_server=0
own_ip_addr=127.0.0.1
wpa=2
wpa_passphrase=### Your PASSPHRASE here ###
wpa_key_mgmt=WPA-PSK WPA-PSK-SHA256 SAE
wpa_pairwise=CCMP
wpa_disable_eapol_key_retries=1
ieee80211w=1
sae_require_mfp=1
tdls_prohibit=1
wnm_sleep_mode=1
wnm_sleep_mode_no_keys=1
The ht capabilities obviously depend on your wireless card (I use a Compex WLE200NX). And the 802.11ac 5GHz wireless configuration looks a bit different, too (mostly related to the vht configuration/capabilities, but also a few additional tx_queue_data* settings).
Now, in terms of what changed over my WPA2-only configuration: That was actually quite simple. I merely added SAE to the list wpa_key_mgmt, added sae_require_mfp=1 and removed disable_pmksa_caching=1.
Yeah, configuring hostapd is a science of it's own.
No kidding. However, with the help of your conf file, I now have this working. The only difference in my hostapd.conf (from the WPA3 perspective) was that I was using wpa_psk_file= to provide my WPA passphrase and as soon as I set the password using wpa_passphrase= instead things work. It seems that the wpa_psk_file= setting isn't read for WPA3. Not sure if it is a bug or not? I suppose using sae_passphrase would work too...
Thanks for the help with this.
I'd assume not. The official hostapd.conf example says:
SAE password
This parameter can be used to set passwords for SAE. By default, the
wpa_passphrase value is used if this separate parameter is not used [...]
So, technically, the behavior seems correct. You either need to provide a sae_password or a wpa_passphrase. Of course, from a user's perspective, one could assume that a wpa_psk_file serves the same purpose, but it seems that hasn't been implemented yet for whatever reason.
@silentcreek's tests showed that it's not necessary to have Opportunistic Key Caching enabled for iOS/iPadOS devices to connect to WPA3 networks. With that in mind, are there any negative consequences associated with having Opportunistic Key Caching enabled? I'm thinking specifically about the impact on security.
@blocktrron, you wrote the patch that enabled auth_cache for WPA3 networks. Could you chime in on this?
It is true, OKC is not needed. However you need PMK caching which is abstracted from the same setting as OKC.
Probably not. To my knowledge OKC is only relevant in two scenarios:
a) Single hostapd instance controlling multiple radios (e.g. a 2.4GHz access point and a 5GHz access point)
In this scenario the cached key can be used when roaming between the different radios. Since OpenWrt uses individual hostapd instances per radio, however, this is not applicable to OpenWrt users.
Edit: As ParanoidZoid pointed out below, this statement isn't true anymore for OpenWrt releases/snapshots after April 2020. As in case b), that should not degrade network security, though.
b) Enterprise wireless networks with multiple access points and authentication based on a radius server or EAP
In this scenario the key may be cached for authentication on all access points. You probably won't find such setups very often in home environments, but you definitely can use EAP with OpenWrt. So, if you do, this setting has an effect, but I wouldn't assume that this would degrade the security of your network in any way or make it easier to attack the network (compared to a setup with only PMK caching enabled)
Fair enough. I always feel a bit wary about having features enabled that are not strictly needed, but in this case it doesn't seem like it would lead to anything bad.
