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

[Daniel S]

On Wed, Dec 6, 2023 at 4:50 AM Jouni Malinen <j at w1.fi> wrote:
>
> On Mon, Dec 04, 2023 at 04:22:11PM -0500, Daniel S wrote:
> > Is there a way(or why you shouldn't/couldn't) to provide the
> > PMK(perhaps via MS-MPPE-Recv-Key) instead of a cleartext
> > Tunnel-Password as a radius response?
> >
> > It would solve the less-than-ideal situation of storing and
> > transmitting PSKs in cleartext or reversible encryption.
>
> I think there is some terminology issues here in addition to somewhat
> inaccurate implication of RADIUS attribute protection.. I think you are
> actually asking about a PSK to be sent instead of a passphrase (from
> which a PSK can be derived using the SSID and somewhat heavy operation).
> PSK is the raw 256 bit key that is used as-is as the PMK when using
> WPA2-Personal. Passphrase is an ASCII string of 8 to 63 characters from
> which a PSK can be calculated.

Yes, thank you for the clarification -- I remember reading this now
but had spent so much time working just with WPA2-Personal that I
forgot about it.

> None of this is transmitted in cleartext since Tunnel-Password is
> protected (how strong one would consider that protection nowadays is a
> different question, though). Anyway, exposure of the passphrase or PSK
> has the same impact: whoever has either of those can use that to get
> connected to the network. As such, this is more of an optimization
> question instead of more secure transmission or storing question.

I'm trying to mitigate a scenario in an MDU deployment of PPSK/DPSK
where 100's of passphrases are stored. These passphrases may or may
not have been re-used elsewhere, so I'm attempting to avoid storing
and communicating them as cleartext. I understand the psk/passphrase
communication is encrypted, but it is only as strong as the security
of the devices that have the radius secret stored in plaintext on
them. WIFI APs and controllers are not exactly known for their superb
security.

> hostapd does actually support both cases with the Tunnel-Password
> attribute since version 2.6 in 2016. That attribute can contain either

Since you clarified that hostapd does support providing the PSK in
Tunnel-Password, this solves the issue and allows to store and
transmit the keys without a risk of exposing plaintext passphrases. In
the event that a PSK or PSK list is compromised, changing the SSID
invalidates the entire PSK list.

It's a much easier communication to say "We're sorry that there was a
security breach, however, all passwords were stored as salted hashes
and no passwords were revealed. The potential impact has already been
mitigated by changing the SSID." versus  "We're sorry that there was a
security breach, everyone's wifi password is now available on the
darknet. Please never use that password again and change it anywhere
else you may have used it also"

> designs for this. As far as hostapd is concerned, I see no reason to
> change the design that has been there for seven years or support
> multiple different approaches unless an accepted standard were developed

Agreed here -- allowing the PSK in tunnel-password completely resolves
my concern. Thank you for pointing out that it's already supported.

I appreciate your time and response, it was educational and answered
my question.

-Daniel