Request Authenticator value made available to a Perl module

[Brandon Miller]

Attached is my working dictionary file.

My Patch:

diff --git a/src/lib/radius.c b/src/lib/radius.c
index 6aec0f0423..9b857afd53 100644
--- a/src/lib/radius.c
+++ b/src/lib/radius.c
@@ -536,7 +536,7 @@ static void make_secret(uint8_t *digest, uint8_t
const *vector,
  fr_md5_destroy(&context);
 }

-#define MAX_PASS_LEN (128)
+#define MAX_PASS_LEN (256)
 static void make_passwd(uint8_t *output, ssize_t *outlen,
  uint8_t const *input, size_t inlen,
  char const *secret, uint8_t const *vector)
@@ -4825,7 +4825,7 @@ int rad_pwdecode(char *passwd, size_t pwlen,
char const *secret,
  * 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;
+ if (pwlen > MAX_PASS_LEN) pwlen = MAX_PASS_LEN;

  /*
  * Catch idiots.

On Fri, Nov 17, 2023 at 5:10 PM Brandon Miller <webasdf at gmail.com> wrote:
>
> Hi Alan,
>
> That was it!  I got it.  Still lots more to configure on the custom
> build to integrate with our already-built pieces of the system, but
> the decryption was successful.
>
> Thanks again for all your help!
> Brandon
>
> On Fri, Nov 17, 2023 at 5:01 PM Brandon Miller <webasdf at gmail.com> wrote:
> >
> > 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dictionary.aruba
Type: application/octet-stream
Size: 4133 bytes
Desc: not available
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20231117/2a0ad275/attachment-0001.obj>