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@xxxxxxxxxxxxxxxxxxx> wrote: > > On Dec 4, 2023, at 4:22 PM, Daniel S <timeport0@xxxxxxxxx> 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 _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
