Request Authenticator value made available to a Perl module

Brandon Miller webasdf at gmail.com
Fri Nov 17 23:01:18 UTC 2023


Hi Alan,

It's been a long day setting up my compile environment.  I just found
the rad_pwdecode function and a line that says:
       /*
         *      The RFC's say that the maximum is 128.
         *      The buffer we're putting it into above is 254, so
         *      we don't need to do any length checking.
         */
        if (pwlen > 128) pwlen = 128;

I'm going to modify this and get back to you, but this looks promising.

Thanks,
Brandon


On Fri, Nov 17, 2023 at 4:57 PM Brandon Miller <webasdf at gmail.com> wrote:
>
> Hi Alan,
>
> I worked on this today, and adjusted the
> freeradius-server/src/lib/radius.c file to reflect MAX_PASS_LEN to
> 192. Unfortunately, it did not work.  I'm still getting garbage after
> 128 characters.  Is the rad_pwencode function responsible for
> decrypting as well as encrypting?  Do I need to work on that function
> to get > 128 bytes decrypted?
>
> This is Aruba btw...attribute 66.
>
> Thanks,
> Brandon
>
> On Thu, Nov 16, 2023 at 5:31 PM Brandon Miller <webasdf at gmail.com> wrote:
> >
> > Thanks Alan,
> >
> > It's funny you quoted that line "go do some RADIUS work", because
> > that's what I heard on our support call today.
> >
> > I will do a custom compile of FreeRADIUS with MAX_PASS_LEN set to 192
> > as suggested.  Then, I should be able to rely on FreeRADIUS to decrypt
> > the value.  I like this idea much better than using an old version of
> > FreeRADIUS.
> >
> > When I get it working, I will forward the VSA file.  Thanks again!
> >
> > Brandon
> >
> > On Thu, Nov 16, 2023 at 4:30 PM Alan DeKok <aland at deployingradius.com> wrote:
> > >
> > > On Nov 16, 2023, at 5:14 PM, Brandon Miller <webasdf at gmail.com> wrote:
> > > > Thanks again for your previous responses.  I have attempted to set the
> > > > encrypt=1 attribute in the vendor dictionary, but it is only
> > > > decrypting the first 128 bytes of the message.  The message I am
> > > > attempting to decrypt is larger than 128 bytes.  After reading the
> > > > RFC2865 section 5.2, I see that password decryption is limited to 128
> > > > bytes.  Unfortunately, our vendor will not change how they are doing
> > > > things, so I'm rather stuck.
> > >
> > >   You should say which vendor it is.
> > >
> > >   I've had a number of run-ins with vendors over the years.  It's always nice to be able to point out that I've written many of the RADIUS RFCs.  And that if I say they're behavior is wrong, then it's likely wrong.
> > >
> > >   The problem is that vendors tend to grab engineers at random, and say "go do some RADIUS work".  They don't really understand the RFCs.  They don't understand how people use RADIUS in the real world.  They just write some garbage code, ship it, and then wonder why people are upset.
> > >
> > >   Even worse, most vendors tend to argue that their team are complete geniuses, and they can't possibly get anything wrong.  They tend to get embarrassed when I point out I've been doing this since their engineers were in kindergarten.
> > >
> > > >  I have all the relevant code written in
> > > > my Perl module to decrypt values larger than 128 bytes, but I simply
> > > > don't have access to the RADIUS authenticator (random nonce value)
> > > > outside of the RAD_REQUEST hash.  Are there any configuration options
> > > > available to change the maximum decryption length to greater than 128
> > > > bytes or any way for me to retrieve the RADIUS authenticator inside my
> > > > Perl script?  I suppose worst case scenario would be to downgrade to
> > > > an older version where I can retrieve the %V expansion parameter
> > > > mentioned earlier.  I'd hate to do that though.
> > >
> > >   If you're going to modify the source code to add %V, then just change the source code so that MAX_PASS_LEN is 192 instead of 128.
> > >
> > >   And send over the vendor dictionaries so that we can include them in the next version of the server.  There's no secret information in them, and you didn't sign an NDA to look at them.
> > >
> > >   Alan DeKok.
> > >
> > > -
> > > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


More information about the Freeradius-Users mailing list