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

[Daniel S]

Mr. Dekok,

Thank you for the response and for your lifetime of contributions to
OSS -- See comments below

On Mon, Dec 4, 2023 at 6:43 PM Alan DeKok <aland at deployingradius.com> wrote:
>
> On Dec 4, 2023, at 4:22 PM, Daniel S <timeport0 at gmail.com> 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?
>
>   MS-MPPE-Recv-Key already has a defined meaning.  You can't change that meaning without changing all pieces of software which use it.

I see vendors (1) and others using this option to return a PMK, and it
seems in most EAP implementations the same is done. So I thought I
would try and see if hostapd would take that attribute instead of
Tunnel-Password. I'm not a C programmer and don't have the skill(yet)
to look through the hostap code myself to learn this, and there isn't
much documentation available for my wpa_psk_radius=3 case.

>
> > It would solve the less-than-ideal situation of storing and
> > transmitting PSKs in cleartext or reversible encryption.
>
>   I'm not sure what you're getting at.  MS-MPPE-Recv-Key and Tunnel-Password are both protected with reversible encryption.  Neither of them send data in clear text.

I apologize for the misunderstanding. I did not intend to imply that
the keys were transmitted in cleartext, more on the storing part
below. It's storing the PSKs locally (on the radius server or
database) in cleartext, as well as transmitting them with reversible
encryption that I was looking to avoid. Reversible encryption
is...well...reversible.

I believe it's generally accepted that any sort of authentication key
should not be stored or transmitted in a reversibly encrypted form,
and deviation from best practices generally is only acceptable when
suitable alternatives don't exist and risks are effectively mitigated.
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. Of course this is WPA2 which I think most development has
pretty much halted for focus on WPA3, so I was more asking if this was
something that already existed and I simply didn't know how to use it.

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.

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.) Then I
realized technically the PSK didn't need to be stored at all once you
had the PMK calculated, *if* hostapd would accept that instead. Which
then would eliminate any realistic possibility that a compromise or
breach of any part of the system could expose PSKs.

So I asked if this had been considered and/or coded for as it seemed
simple enough that I wondered if someone else had already done this.

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.

>
> > 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.
>
>   Of course.  If you put IPv6 addresses into an IPv4 field it won't work, either.
>
>   The protocols and attributes have defined meaning.  You can't just put different data into an attribute and expect the systems to understand what you intend.
>
>   Alan DeKok.
>

(1) https://docs.commscope.com/bundle/zd-10.5.1-userguide/page/GUID-98007EBD-43CA-4C41-9F99-626A0295D75F.html

-Daniel