On Wed, Dec 6, 2023 at 4:50 AM Jouni Malinen <j@xxxxx> 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 _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
