FT authentication fails on FT-SAE
James Prestwood
prestwoj at gmail.com
Tue Sep 28 15:53:45 PDT 2021
Hi Michael,
On Tue, 2021-09-28 at 17:30 +0000, Michael Yartys wrote:
> 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.
Just a comment on this:
It really depends on how you do FT-over-DS. If you wait to start FT-
over-DS until the time of roam its going to take longer. But if you
instead start the FT-over-DS action sequence to all neighbors early
(like after the initial connection) you can immediately reassociate to
your FT target when needed.
Thanks,
James
>
> 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.
> > > > >
> > > > > 本郵件內容涉及商業或私人秘密，非收件人請勿散佈或使用，收件人亦應遵守保密義務不得散佈或濫用本郵件，否則可能違反相關法令。如
> > > > > 因傳遞錯誤，請立即刪除並回覆通知寄件人。感謝您。
>
> _______________________________________________
> Hostap mailing list
> Hostap at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/hostap
More information about the Hostap
mailing list