Hi Michael, Thanks for the feedback. On Wed, Jun 19, 2024 at 02:32:20PM -0400, Michael Richardson wrote: > Radius already does this, and does it better. > And Radius v1.1 over TLS is a significantly better protocol than the NAT44 > hostile MD5-authenticated thing of yore. Take a page from eduroam. I don't think that RADIUS does this, this does not work for us with Freifunk. Just like we can't offer eduroam on a Freifunk mesh node / AP right now either: The final RADIUS Accept message from the RADIUS server, no matter if using it with or without TLS, will as the final step of its EAP exchange send the pairwise-master-key to the AP. WPA encryption is between the client/supplicant and the AP/authenticator only. The RADIUS TLS encryption is a separate encryption channel and only between the AP/authenticator and remote RADIUS server. It's not end-to-end-encrypting payload between the client/authenticator and a remote host. This whole exchange therefore requires the AP/authenticator to be run by a trusted operator. At Freifunk most of our nodes are run by people that do not know each other. The AP/authenticator would be able to Man-in-the-middle attack there. That was the main idea of this proposal, to create end-to-end-encryption between a client/supplicant and a remote host. Without needing an extra VPN software on the client device. > > L2TP is a disaster, requires IPsec transport mode to be secure. > Just don't. If the frames within L2TP are still WPA encrypted then this shouldn't need an extra layer of encryption around it via IPSec? If this were not secure over the internet then it would not have been secure over the air in the first place either. Regards, Linus _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
