Hi Hadi! No worries at all! Really glad you were able to find what you were looking for - if you want to make life much easier for yourself, I would highly recommend generating the Doxygen documentation included with the source. It makes hunting down functions and structure definitions infinitely easier!! Cheers and all the very best, Jacob [bitNew2.png] On 07/01/2025 19:55:37, Hadi Rezaee <rezaee.hadi@gmail.com> wrote: Hello Jacob, Thanks for your kind reply, your hints helped me a lot. Finally I've found the missing piece (encrypting the generated mppe keys based on rfc2548) in the code-base. There was a good comment for "mppe_chap2_gen_keys128" function (src/modules/rlm_mschap/rlm_mschap.c) that I didn't paid attention to, which says: /* * dictionary.microsoft defines these attributes as * 'encrypt=Tunnel-Password'. The functions in src/lib/radius.c will * take care of encrypting/decrypting them as appropriate, * so that we don't have to. */ So, just like you said after the mppe send/recv keys (16 bytes) generated, "encode_tunnel_password" function (src/protocols/radius/encode.c) then encrypt them based on (rfc2548 section 2.4.2 and 2.4.3). Thanks again to you and Alan for guidance, I appreciate it. Regards, Hadi On Tue, Jan 7, 2025 at 7:04 AM Jacob Lane wrote:
Hi Hadi! Feel free to drop me an email directly if you get really stuck (I've no experience with MS-CHAP, but I can just about make sense of RFCs), but in regards to mppe_add_reply - MS-CHAPv2 uses 128 bit send/receive session keys (16 bytes). When calling mppe_add_reply, Alan is adding a keypair to the VP list that is 16 bytes long for each. See this [ https://datatracker.ietf.org/doc/html/draft-ietf-pppext-mschapv2-keys] IETF Draft from 1998 for session key reference, and RFC 2759 [ https://datatracker.ietf.org/doc/html/rfc2759] for more info about the whole MS-CHAPv2 auth process.
Cheers!
Jacob [bitNew2.png] On 06/01/2025 14:54:07, Hadi Rezaee wrote: Hello Alan and thanks for your response. You're absolutely right, I need to go back for more research and code review :)
Regards, Hadi
On Mon, Jan 6, 2025 at 5:34 PM Alan DeKok wrote:
On Jan 5, 2025, at 2:37 PM, Hadi Rezaee wrote:
I'm trying to figure out how MS-MPPE-Send-Key and MS-MPPE-Recv-Key are getting generated by freeradius-server.
The short answer is "read the RFCs and the code"
Here, it is the sample captured traffic I've for a MS-CHAPv2 (Access-Accept) auth between a radius client and server: MS-MPPE-Recv-Key: a660ce53f31ef08ed6cf209ece137a1dee40aeae5d8e5b9de0f1592324bc92569fc1 MS-MPPE-Send-Key: a81579eb58f0bd25636599778c8689516129db8b25ec2d1e4c15797862efedabb3c
Those are just random values. They don't mean anything.
Correct me if I'm wrong but here I read " mppe_sendkey" and " mppe_recvkey" variables are initialized with 34 bytes (as i expected!), but later by calling mppe_chap2_gen_keys128 only 16 bytes are copied. I was expecting other items (such as 'Salt') to be taken into account too ..
To be honest, I haven't looked at that code in a long time. If it's generating 34-byte keys, then it works. Which means that your reading of the code is wrong.
If you want to know what the code is doing, use a debugger like gdb to step through it.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html