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
