PMK or PTK instead of PSK in radius response when wpa_psk_radius=2 or wpa_psk_radius=3

[Daniel S]

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 at deployingradius.com> wrote:
>
> On Dec 4, 2023, at 9:26 PM, Daniel S <timeport0 at gmail.com> 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.
>