On Fri, Apr 16, 2021 at 01:18:24PM +0200, michael-dev@xxxxxxxxxxxxx wrote: > If no matching sae_password is configured in hostapd, use the RADIUS > supplied Tunnel-Password as SAE password. Though, that is still subject to > the length constraint of WPA passphrase (8..63 chars) to avoid ambiguation. > > The SAE password identifier can be optionally supplied using > Tunnel-Client-Auth-ID. The cover letter in patch 0/2 noted about "while at it" change to optimize iteration efficiency, but that is not mentioned here in patch 1/2 that is the only one that actually does changes.. Furthermore, this patch seems to be combining a large number of independent changes into a single large patch which makes this inconvenient to review. Ideally, this would be split into separate patches for each such individual change. For example, all the radius_attrs[] and debug printing changes could be in their own patch and the optimizations that are not specific to the new SAE related support in another one. This would hopefully leave the actual addition of SAE support easier to understand in its own patch. As far as use of RADIUS with SAE is concerned, I guess there could be uses for this type of mapping from a station to some external storage of passwords, but I would expect it to be significantly more useful if the mapping at the RADIUS authentication server could be done based on the SAE password identifier provided by the station in the Authentication frame instead of MAC address. That would allow large number of different passwords (per-user password) to be used even in cases where random MAC addresses are used. Have you happened to thought about that type of approach with this or are you only interested in use cases where there is a relatively small number of passwords in use? -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
