FT authentication fails on FT-SAE

[Michael Yartys]

Hi

Thanks a lot for the detailed write-up!

In case you're interested, I remember seeing a talk from WLPC 2019 Prague about how over-the-DS performed worse than over-the-air: https://www.youtube.com/watch?v=4Ua2lI6HBhE&t=1178s

This is only based on one type of test, and the performance might be better in other situations, but it looks like you don't save on anything (the roam takes longer actually) with over-the-DS.

Michael

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On Monday, September 27th, 2021 at 22:59, michael-dev <michael-dev at fami-braun.de> wrote:

> Hi,
>
> DHCP does not matter here, as it is provided independently from the way
>
> wifi authentication works.
>
> With FT, there is for each connected station the AP called "R0" - the
>
> AP, that the station completed its first FT-SAE handshake with (for the
>
> current session). The current connected AP is called "R1". After
>
> connecting first, the current AP is both R0 and R1.
>
> So when connecting to a new AP reusing its existing FT session, that new
>
> AP also behaves as an R1 AP and contacts the R0 AP. Which of your APs
>
> becomes R0 or R1 depends on which is the first the STA connects to - so
>
> both need to be able to act as R0 and R1 and learn of each other in both
>
> R0 and R1 role.
>
> R0 <-> R1 communication takes place using the MAC addresses configured
>
> with r0kh/r1kh config setting using a hostapd-specific protocol. With
>
> ft_psk_generate_local=1, (only) this communication is skipped with
>
> FT-PSK and the R1 just does the required computations itself to make up
>
> the results.
>
> In order for the STA to save an RTT of being effectively disconnected
>
> when roaming, it can complete its handshake with the new R1 by sending
>
> the packets to its current R1, which the forwards it to the new R1
>
> (normally over wire). This is called over-DS and is independed from
>
> R0<->R1 communication. If over-DS is not used (either because the STA
>
> does not want to or the AP has ft_over_ds=0), this STA <-> new AP
>
> handshake is done over WiFi (as would any non-FT handshake). This packet
>
> forwarding does not depend on r0kh/r1kh configuration, as the target MAC
>
> adress is provided by the STA.
>
> Regards,
>
> M. Braun
>
> Am 26.09.2021 22:41, schrieb Michael Yartys:
>
> > Hi
> >
> > I suspected that would be the case.
> >
> > So the APs need to communicate for FT-SAE to work, but how does that
> >
> > communication take place? In my setup one R7800 acts as the "main"
> >
> > router and provides IP addresses through DHCP while the other one is
> >
> > connected to it via Ethernet and is simply a dumb AP. Do the APs
> >
> > communicate via Ethernet or via WiFi?
> >
> > Michael
> >
> > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> >
> > On Sunday, September 26th, 2021 at 22:32, michael-dev
> >
> > michael-dev at fami-braun.de wrote:
> >
> > > Hi,
> > >
> > > this is not possible by the way the EAP authentication backing FT-SAE
> > >
> > > works.
> > >
> > > Regards,
> > >
> > > M. Braun
> > >
> > > Am 23.09.2021 11:08, schrieb S330錢小偉qianxiaowei:
> > >
> > > > Dear Braun,
> > > >
> > > > Do we have plans to support functions similar to ft_psk_generate_local
> > > >
> > > > on FT-SAE?
> > > >
> > > > As we know, before ft_psk_generate_local is not supported, we also
> > > >
> > > > need to manually configure r0kh and r1kh.
> > > >
> > > > This is not very friendly for home users who have APs from different
> > > >
> > > > manufacturers.
> > > >
> > > > Thanks to the emergence of ft_psk_generate_local, which makes FT-PSK
> > > >
> > > > very simple Well!
> > > >
> > > > If FT-SAE can also support such a function, it would be great!!!
> > > >
> > > > Thanks.
> > > >
> > > > Best Regards!
> > > >
> > > > > On Sep 23, 2021, at 4:13 PM, michael-dev michael-dev at fami-braun.de
> > > > >
> > > > > wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > you're missing most of the required settings in section IEEE 802.11r
> > > > >
> > > > > configuration of
> > > > >
> > > > > https://w1.fi/cgit/hostap/plain/hostapd/hostapd.conf .
> > > > >
> > > > > You don't need r0kh/r1kh only if only using FT-PSK with
> > > > >
> > > > > ft_psk_generate_local, because otherwise both hostapd instances need
> > > > >
> > > > > to communicate to faciliate roaming (exchange keys etc.) - which
> > > > >
> > > > > they cannot unless r0kh/r1kh is configured.
> > > > >
> > > > > Regards,
> > > > >
> > > > > M. Braun
> > > > >
> > > > > Am 13.08.2021 09:34, schrieb Michael Yartys:
> > > > >
> > > > > > --- LAPTOP 1 ---
> > > > > >
> > > > > > interface=wlp18s0
> > > > > >
> > > > > > driver=nl80211
> > > > > >
> > > > > > ssid=test1
> > > > > >
> > > > > > hw_mode=g
> > > > > >
> > > > > > channel=1
> > > > > >
> > > > > > auth_algs=3
> > > > > >
> > > > > > wmm_enabled=1
> > > > > >
> > > > > > nas_identifier=first_example
> > > > > >
> > > > > > wpa=2
> > > > > >
> > > > > > wpa_passphrase=testingstuff123
> > > > > >
> > > > > > wpa_key_mgmt=SAE FT-SAE
> > > > > >
> > > > > > wpa_pairwise=CCMP
> > > > > >
> > > > > > ieee80211w=2
> > > > > >
> > > > > > sae_pwe=2
> > > > > >
> > > > > > mobility_domain=a1b2
> > > > > >
> > > > > > ft_over_ds=0
> > > > > >
> > > > > > ft_psk_generate_local=0
> > > > > >
> > > > > > --- LAPTOP 2 ---
> > > > > >
> > > > > > interface=wlp18s0
> > > > > >
> > > > > > driver=nl80211
> > > > > >
> > > > > > ssid=test1
> > > > > >
> > > > > > hw_mode=g
> > > > > >
> > > > > > channel=6
> > > > > >
> > > > > > auth_algs=3
> > > > > >
> > > > > > wmm_enabled=1
> > > > > >
> > > > > > nas_identifier=second_example
> > > > > >
> > > > > > wpa=2
> > > > > >
> > > > > > wpa_passphrase=testingstuff123
> > > > > >
> > > > > > wpa_key_mgmt=SAE FT-SAE
> > > > > >
> > > > > > wpa_pairwise=CCMP
> > > > > >
> > > > > > ieee80211w=2
> > > > > >
> > > > > > sae_pwe=2
> > > > > >
> > > > > > mobility_domain=a1b2
> > > > > >
> > > > > > ft_over_ds=0
> > > > > >
> > > > > > ft_psk_generate_local=0
> > > > >
> > > > > Hostap mailing list
> > > > >
> > > > > Hostap at lists.infradead.org
> > > > >
> > > > > http://lists.infradead.org/mailman/listinfo/hostap
> > > >
> > > > This message including any attachment is intended only for the use of
> > > >
> > > > the addressee(s) and may contain privileged and confidential
> > > >
> > > > information. If you are not the intended recipient, you are hereby
> > > >
> > > > notified that any dissemination of this message is strictly
> > > >
> > > > prohibited. Disclosure, copying, distribution, or use of the contents
> > > >
> > > > of this e-mail by persons other than the intended recipient may
> > > >
> > > > violate applicable laws. Abuse or dissemination by the intended
> > > >
> > > > recipient is also forbidden. Please kindly return the e-mail and
> > > >
> > > > delete it if you have received this message in error. Thank you.
> > > >
> > > > 本郵件內容涉及商業或私人秘密，非收件人請勿散佈或使用，收件人亦應遵守保密義務不得散佈或濫用本郵件，否則可能違反相關法令。如因傳遞錯誤，請立即刪除並回覆通知寄件人。感謝您。