FT authentication fails on FT-SAE

Wed Sep 29 01:32:51 PDT 2021

Hi,

I'm wondering on the following aspects of the talk:

- on slide 28, he says full WPA-EAP is slow for roaming. But of the 
472ms shown in the packet trace, 363ms are actually after the EAP 
handshake SUCCESS message and before Key 1/4 message (frame 105499 delta 
value)- and thus cannot be attributed to EAP (nor WPA) but the AP 
internals. Still, FT improves but the baseline should be only 109ms (for 
the authentication).
- on slide 31, the authentication + reply + reassociation + replay OTA 
handshake is 0.002ms (with the AP having to do all the R0<->R1 
communication and key derivation). On slide 34, for over-DS, we have 2ms 
for forwarding the action frame and getting the reply alone and 
additionally the STA waits another 57ms after the over-DS handshake is 
completed before it actually sends its reassocation request, which takes 
<1ms here.

So while it might be true that the tested devices/firmware is slower 
when using over-DS, it looks more like implementation details of the 
specific measured devices/device types to me.

Regards,
M. Braun

Am 29.09.2021 00:53, schrieb James Prestwood:
> 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