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

[Jouni Malinen]

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.

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.

hostapd does actually support both cases with the Tunnel-Password
attribute since version 2.6 in 2016. That attribute can contain either
the passphrase (8..63 characters of ASCII) or the raw PSK (64 hex
characters). When the former is used, the CPU-intensive PBKDF2 operation
is needed; when the latter is used, PBKDF2 is not needed and the raw PSK
is extracted with trivial hex-to-binary conversion.

> I tried as a test just sending the PMK or PTK back as MS-MPPE-Recv-Key
> as in EAP but seems that didn't do the trick.

The derivation from PMK (i.e., PSK in this case) to PTK is not an
expensive operation, so I don't see much value in trying to change that
part even though it would be theoretically possible if one were prepared
to go through a new RADIUS exchange every single time there is need for
performing 4-way handshake. In practice, I would expect this to
introduce much worse issues than benefits.

As far as PMK (i.e., PSK) instead of passphrase is concerned, you can
already do that with the Tunnel-Password attribute as noted above. Sure,
one could do this with some other RADIUS attribute as well, so
MS-MPPE-Recv-Key could be used for same purpose. However, there is no
standard way of doing this and vendors have ended up using different
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
for this or if there were a commonly used RADIUS server that would
support one mechanism without the one supported in hostapd.

-- 
Jouni Malinen                                            PGP id EFC895FA