Request Authenticator value made available to a Perl module
Hi Everyone, I am working on a Perl module that requires access to the Request Authenticator value for each Access-Request. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Request Authenticator <----------- I need this value passed to my Perl module | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attributes ... +-+-+-+-+-+-+-+-+-+-+-+-+- I combed through the docs and found the Request-Authenticator Runtime variable (https://wiki.freeradius.org/config/run_time_variables). I tried to dynamically assign this variable (%V) to a Radius-Request variable in my site definition file, but the server won't start with error: /etc/raddb/sites-enabled/myPerlSite[17]: Failed parsing expanded string: /etc/raddb/sites-enabled/myPerlSite[17]: %V /etc/raddb/sites-enabled/myPerlSite[17]: ^ Invalid variable expansion It seems this variable has been deprecated in v3. Is there any way to get at this variable in another way? I am running v3.0.13. Thanks in advance, Brandon
On Nov 14, 2023, at 6:14 PM, Brandon Miller <webasdf@gmail.com> wrote:
I am working on a Perl module that requires access to the Request Authenticator value for each Access-Request.
Why? The Request Authenticator is only used to sign packets. It has zero value once the packet is received.
I combed through the docs and found the Request-Authenticator Runtime variable (https://wiki.freeradius.org/config/run_time_variables). I tried to dynamically assign this variable (%V) to a Radius-Request variable in my site definition file, but the server won't start with error:
I think %V was removed a long time ago.
/etc/raddb/sites-enabled/myPerlSite[17]: Failed parsing expanded string: /etc/raddb/sites-enabled/myPerlSite[17]: %V /etc/raddb/sites-enabled/myPerlSite[17]: ^ Invalid variable expansion
It seems this variable has been deprecated in v3. Is there any way to get at this variable in another way? I am running v3.0.13.
You don't need access to the Request Authenticator. If you think you do, then something very weird is going on, i.e. the only reason to look at the Request Authenticator is for (a) packet validation, and (b) attribute decryption. For (a), the server core takes are of that. Don't do it in Perl. For (b), update the dictionaries, and the server will automatically decrypt attributes. If you need something else, then explain what you need, and why you need it. Just saying "I need access to the Request Authenticator" doesn't help. There are very very few reasons why that's necessary. And 3.0.13 is very old. You should use a more recent version of the server. Alan DeKok.
Hi Alan, Thanks for the reply. I am in need of the request authenticator because of the way a VSA is coming across. When you said that FreeRADIUS should decrypt any encrypted attributes, it got me thinking. I remembered that our vendor said they use rfc2865 to encrypt this attribute. I am about to go to bed for the night and just connected the dots. I checked the dictionary file and I do not see the encrypt=1 clause in there for this attribute. I'll give that a try tomorrow. Upgrading FreeRADIUS is also in order. Thanks! Brandon On Tue, Nov 14, 2023, 6:34 PM Alan DeKok <aland@deployingradius.com> wrote:
On Nov 14, 2023, at 6:14 PM, Brandon Miller <webasdf@gmail.com> wrote:
I am working on a Perl module that requires access to the Request Authenticator value for each Access-Request.
Why?
The Request Authenticator is only used to sign packets. It has zero value once the packet is received.
I combed through the docs and found the Request-Authenticator Runtime variable (https://wiki.freeradius.org/config/run_time_variables). I tried to dynamically assign this variable (%V) to a Radius-Request variable in my site definition file, but the server won't start with error:
I think %V was removed a long time ago.
/etc/raddb/sites-enabled/myPerlSite[17]: Failed parsing expanded string: /etc/raddb/sites-enabled/myPerlSite[17]: %V /etc/raddb/sites-enabled/myPerlSite[17]: ^ Invalid variable expansion
It seems this variable has been deprecated in v3. Is there any way to get at this variable in another way? I am running v3.0.13.
You don't need access to the Request Authenticator. If you think you do, then something very weird is going on,
i.e. the only reason to look at the Request Authenticator is for (a) packet validation, and (b) attribute decryption. For (a), the server core takes are of that. Don't do it in Perl.
For (b), update the dictionaries, and the server will automatically decrypt attributes.
If you need something else, then explain what you need, and why you need it. Just saying "I need access to the Request Authenticator" doesn't help. There are very very few reasons why that's necessary.
And 3.0.13 is very old. You should use a more recent version of the server.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Nov 15, 2023, at 12:58 AM, Brandon Miller <webasdf@gmail.com> wrote:
Thanks for the reply. I am in need of the request authenticator because of the way a VSA is coming across. When you said that FreeRADIUS should decrypt any encrypted attributes, it got me thinking. I remembered that our vendor said they use rfc2865 to encrypt this attribute. I am about to go to bed for the night and just connected the dots. I checked the dictionary file and I do not see the encrypt=1 clause in there for this attribute. I'll give that a try tomorrow.
Exactly. Please also send over updates to any dictionaries, so that other people don't run into the same problem. Alan DeKok.
Hello Alan, 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. 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. Thanks for any help, Brandon On Wed, Nov 15, 2023 at 6:12 AM Alan DeKok <aland@deployingradius.com> wrote:
On Nov 15, 2023, at 12:58 AM, Brandon Miller <webasdf@gmail.com> wrote:
Thanks for the reply. I am in need of the request authenticator because of the way a VSA is coming across. When you said that FreeRADIUS should decrypt any encrypted attributes, it got me thinking. I remembered that our vendor said they use rfc2865 to encrypt this attribute. I am about to go to bed for the night and just connected the dots. I checked the dictionary file and I do not see the encrypt=1 clause in there for this attribute. I'll give that a try tomorrow.
Exactly.
Please also send over updates to any dictionaries, so that other people don't run into the same problem.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Nov 16, 2023, at 5:14 PM, Brandon Miller <webasdf@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.
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@deployingradius.com> wrote:
On Nov 16, 2023, at 5:14 PM, Brandon Miller <webasdf@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
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@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@deployingradius.com> wrote:
On Nov 16, 2023, at 5:14 PM, Brandon Miller <webasdf@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
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@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@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@deployingradius.com> wrote:
On Nov 16, 2023, at 5:14 PM, Brandon Miller <webasdf@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
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@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@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@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@deployingradius.com> wrote:
On Nov 16, 2023, at 5:14 PM, Brandon Miller <webasdf@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
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@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@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@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@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@deployingradius.com> wrote:
On Nov 16, 2023, at 5:14 PM, Brandon Miller <webasdf@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
On Nov 17, 2023, at 6:26 PM, Brandon Miller <webasdf@gmail.com> wrote:
Attached is my working dictionary file.
With all of the "Aruba-" prefixes removed. :( That's not good. The dictionaries don't have "namespaces". So if two vendors define an attribute "Foo", then the only way to tell the attributes apart is by name. One attribute is "Vendor1-Foo", and the other attribute is "Vendor2-Foo" But that's minor. For the Aruba-MPSK-Lookup-Info attribute, why is it marked "octets" instead of "string"? When the attribute is decoded, are the contents ASCII text, or some kind of hex structure? Do you have a reference for the definition of the attribute?
My Patch:
I'll push a slightly different patch. There's no real reason to limit password attributes to be 128 characters. Alan DeKok.
Hi Alan, Thank you again for all your hard work on the FreeRADIUS project, the related RFCs, and taking the time to help on the mailing list. It is much appreciated. I see you updated the VSA in the source on github already. I personally agree with you that the attributes should have the Aruba prefix. I'm not sure what it would take to make that happen? I honestly don't recall where exactly I found that dictionary file. Looking at the github code, I do see the ALIAS directive at the bottom. Does this alias directive force the prefix "Aruba"? I was having issues with the older version of FreeRADIUS not accepting the VSA because of conflicting attributes, and the older version didn't accept the ALIAS directive in the dictionary files. This is likely why I manually changed several of the attributes...just to get it "working". I chose octets for the Aruba-MPSK-Lookup-Info datatype with a length of 178 for 2 reasons. 1) The Aruba-MPSK-Lookup-Info attribute is encoded WPA2 EAPOL request data as part of the WPA2 handshake. The returned data is a binary structure that makes more sense when reading as a string of hex values. 2) When doing a packet capture, wireshark indicated a length of 178 bytes for that attribute. I hope this helps. Thanks, Brandon On Sat, Nov 18, 2023 at 8:01 AM Alan DeKok <aland@deployingradius.com> wrote:
On Nov 17, 2023, at 6:26 PM, Brandon Miller <webasdf@gmail.com> wrote:
Attached is my working dictionary file.
With all of the "Aruba-" prefixes removed. :( That's not good.
The dictionaries don't have "namespaces". So if two vendors define an attribute "Foo", then the only way to tell the attributes apart is by name. One attribute is "Vendor1-Foo", and the other attribute is "Vendor2-Foo" But that's minor.
For the Aruba-MPSK-Lookup-Info attribute, why is it marked "octets" instead of "string"? When the attribute is decoded, are the contents ASCII text, or some kind of hex structure?
Do you have a reference for the definition of the attribute?
My Patch:
I'll push a slightly different patch. There's no real reason to limit password attributes to be 128 characters.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Nov 21, 2023, at 1:45 PM, Brandon Miller <webasdf@gmail.com> wrote:
Thank you again for all your hard work on the FreeRADIUS project, the related RFCs, and taking the time to help on the mailing list. It is much appreciated.
You're welcome.
I see you updated the VSA in the source on github already. I personally agree with you that the attributes should have the Aruba prefix. I'm not sure what it would take to make that happen?
Edit the dictionary files.
I honestly don't recall where exactly I found that dictionary file. Looking at the github code, I do see the ALIAS directive at the bottom. Does this alias directive force the prefix "Aruba"?
No. You likely copied the dictionary file from the git "master" branch (v4), and then tried to use it in v3. That's not a good idea. v3 comes with an aruba dictionary. You can just edit it there. There's no need to use a new dictionary file.
I was having issues with the older version of FreeRADIUS not accepting the VSA because of conflicting attributes, and the older version didn't accept the ALIAS directive in the dictionary files. This is likely why I manually changed several of the attributes...just to get it "working".
Or, use the dictionary.aruba file that comes with v3? It's text, you can edit it.
I chose octets for the Aruba-MPSK-Lookup-Info datatype with a length of 178 for 2 reasons. 1) The Aruba-MPSK-Lookup-Info attribute is encoded WPA2 EAPOL request data as part of the WPA2 handshake. The returned data is a binary structure that makes more sense when reading as a string of hex values. 2) When doing a packet capture, wireshark indicated a length of 178 bytes for that attribute.
That's the encoded size. It's rounded up to a multiple of 16, because of the encryption. Anyways, I've updated the dictionary.aruba file. It should be fine. Alan DeKok.
participants (2)
-
Alan DeKok -
Brandon Miller