I'll respectfully say that just because something isn't supported by a billion devices doesn't mean that it shouldn't be. And it doesn't have to be to be useful. If that were the case we would still have 802.11b and WEP. I'm not suggesting any sweeping changes, just asking questions. I learned a saying from my father "Just because that's the way you always do it, doesn't mean that's the best way." But I see now that the way everything is done now is the best possible way and no further improvement is possible. Nothing helpful can be added until someone spends years learning everything possible about a project and without daring to ask the very people that know the most about the project. Sorry if I upset anyone here. We're 6 replies deep until a mostly useless exchange. I'll go back to lurking and maybe I can have something to add in a few years. I truly appreciate everyone here and what they do for OSS. I've realized hostapd/wpa_supplicant is practically the backbone of the wirelessly connected world. I hope a new generation can help carry the torch forward and grow into giants themselves. On Mon, Dec 4, 2023 at 9:46 PM Alan DeKok <aland@xxxxxxxxxxxxxxxxxxx> wrote: > > On Dec 4, 2023, at 9:26 PM, Daniel S <timeport0@xxxxxxxxx> wrote: > > I believe it's generally accepted that any sort of authentication key > > should not be stored or transmitted in a reversibly encrypted form, > > Well, no. I think you've read a few checklists on "best practices", and are applying them to situations where they don't work. > > Any idea you have about "should" or "should not" is made irrelevant by the fact that there are a billion devices which implement the current standards. You can't change how these devices work. > > > and deviation from best practices generally is only acceptable when > > suitable alternatives don't exist and risks are effectively mitigated. > > Again, no. The current EAP / RADIUS standards are pretty much best practices. And no suitable alternatives exist. > > I'd suggest understanding the existing systems before proposing sweeping changes, or even before claiming that that those systems don't follow best practices. > > > Alternatives at least should be explored. It seems to me that it would > > be practical to store and transmit a calculated PMK for this > > capability. > > This seems to very much wishful thinking. And ignores current realities. > > > My application is when wpa_psk_radius=3, currently Freeradius runs an > > external authentication method (ran in rlm_perl) has to pull and > > calculate and compare PMK/PTK/KCK/MIC etc.. from a plaintext list of > > vlan/psk. Standard PPSK functionality, from what I've learned. > > The current v3.2.x branch of FreeRADIUS supports DPSK. We've tested interoperability with hostap. > > > I realized as part of this process that I could pre-calculate the PMK > > and store it alongside the vlan, avoiding (relatively)expensive > > calculations in the middle of the EAPOL handshake(As I'm sure others > > have too, but did not find this info published anywhere.) > > Perhaps because it can't be done. > > > Please forgive me if I'm not using the correct words or terminology. > > I've only been working with this for a couple of months and knew > > almost nothing about it prior. > > If you're not using the standard the terminology, then it's difficult for people to understand what you mean. > > The current systems are based on the work of hundreds, if not thousands of peoples, working for decades. I'd suggest being sure that you understand the existing systems very well, before proposing changes. I suspect that any issue of "no one has though of this before" is likely to be really "people have tried it, and it doesn't work". > > But there's not a lot of benefit in discussing concepts based on uncertain terminology. Code is available. If you have a major improvement to EAP / PPSK, etc., then I suggest coding it up and sending patches. Working patches will convince people. Not much else will do that. > > Alan DeKok. > _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
