Computing MS-MPPE-Recv-Key and MS-MPPE-Send-Key in MS-CHAPv2 auth
Hadi Rezaee
rezaee.hadi at gmail.com
Tue Jan 7 19:54:29 UTC 2025
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 <admin at bitcomputing.io> 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 <rezaee.hadi at gmail.com> 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
>
More information about the Freeradius-Devel
mailing list