Re: PAP: adding support for OpenLDAP and 389ds PBKDF2 passwords
Hi, I have noticed that our radius server doesn't recognize PBKDF2 passwords from our freeipa/389ds ldap server. Picking up from this message last year https://lists.freeradius.org/pipermail/freeradius-devel/2024-June/014382.htm... and seeing that pr #5329 https://github.com/FreeRADIUS/freeradius-server/pull/5329 was closed as stale, I have looked into it and put together something myself: https://github.com/gvde/freeradius-server/compare/master...pbkdf-389ds It's currently against the master branch and I basically only used the pap module tests to verify it's working. It took me a while to understand the control flow. I went a slightly different path then outlined in #5329 but I think it's closer to the other types. All pap module tests succeed thus I guess it's correct. Tested with Password.PBKDF2 (which I have implemented for additional support) as well as Password.With-Header. We are running 3.2 at the moment thus I would also have to backport it to 3.2, but as it took a couple of hours to get a working and useful development environment set up, I don't want to waste any more time on it if there isn't any interest... Cheers, Gerald
It seems fine on a quick look. If you send a PR we'll review it and merge it in. The previous PR wasn't merged because it had buffer overflows, and the author didn't fix them.
On Apr 25, 2025, at 7:33 AM, Gerald Vogt <vogt@spamcop.net> wrote:
Hi,
I have noticed that our radius server doesn't recognize PBKDF2 passwords from our freeipa/389ds ldap server.
Picking up from this message last year
https://lists.freeradius.org/pipermail/freeradius-devel/2024-June/014382.htm...
and seeing that pr #5329
https://github.com/FreeRADIUS/freeradius-server/pull/5329
was closed as stale, I have looked into it and put together something myself:
https://github.com/gvde/freeradius-server/compare/master...pbkdf-389ds
It's currently against the master branch and I basically only used the pap module tests to verify it's working. It took me a while to understand the control flow. I went a slightly different path then outlined in #5329 but I think it's closer to the other types.
All pap module tests succeed thus I guess it's correct. Tested with Password.PBKDF2 (which I have implemented for additional support) as well as Password.With-Header.
We are running 3.2 at the moment thus I would also have to backport it to 3.2, but as it took a couple of hours to get a working and useful development environment set up, I don't want to waste any more time on it if there isn't any interest...
Cheers,
Gerald - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
On 25.04.25 14:36, Alan DeKok wrote:
It seems fine on a quick look. If you send a PR we'll review it and merge it in.
I would have if I could but I can't which is why I have imported and not forked the repository... -Gerald
The previous PR wasn't merged because it had buffer overflows, and the author didn't fix them.
On Apr 25, 2025, at 7:33 AM, Gerald Vogt <vogt@spamcop.net> wrote:
Hi,
I have noticed that our radius server doesn't recognize PBKDF2 passwords from our freeipa/389ds ldap server.
Picking up from this message last year
https://lists.freeradius.org/pipermail/freeradius-devel/2024-June/014382.htm...
and seeing that pr #5329
https://github.com/FreeRADIUS/freeradius-server/pull/5329
was closed as stale, I have looked into it and put together something myself:
https://github.com/gvde/freeradius-server/compare/master...pbkdf-389ds
It's currently against the master branch and I basically only used the pap module tests to verify it's working. It took me a while to understand the control flow. I went a slightly different path then outlined in #5329 but I think it's closer to the other types.
All pap module tests succeed thus I guess it's correct. Tested with Password.PBKDF2 (which I have implemented for additional support) as well as Password.With-Header.
We are running 3.2 at the moment thus I would also have to backport it to 3.2, but as it took a couple of hours to get a working and useful development environment set up, I don't want to waste any more time on it if there isn't any interest...
Cheers,
Gerald - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
On Apr 25, 2025, at 1:03 PM, Gerald Vogt <vogt@spamcop.net> wrote:
On 25.04.25 14:36, Alan DeKok wrote:
It seems fine on a quick look. If you send a PR we'll review it and merge it in.
I would have if I could but I can't which is why I have imported and not forked the repository... -Gerald
I'm not sure I understand the problem. GitHub makes it trivial to fork the repo and create a pull request. Anyways, it's easy enough to download a patch file. Alan DeKok.
On 27.04.25 12:58, Alan DeKok via Freeradius-Devel wrote:
On Apr 25, 2025, at 1:03 PM, Gerald Vogt <vogt@spamcop.net> wrote:
On 25.04.25 14:36, Alan DeKok wrote:
It seems fine on a quick look. If you send a PR we'll review it and merge it in.
I would have if I could but I can't which is why I have imported and not forked the repository... -Gerald
I'm not sure I understand the problem. GitHub makes it trivial to fork the repo and create a pull request.
If I fork from https://github.com/FreeRADIUS/freeradius-server I'll end up back on https://github.com/FreeRADIUS/freeradius-server again. No errors shown. Just like other freeradius repositories. I have no problems forking from other projects. As far as I understand from github community posts this is probably because you have blocked me from forking. -Gerald
Anyways, it's easy enough to download a patch file.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
On Apr 27, 2025, at 9:56 AM, Gerald Vogt <vogt@spamcop.net> wrote:
As far as I understand from github community posts this is probably because you have blocked me from forking.
Looking back, you were blocked in May 2023 for unhelpful discussions. I can unblock you, which will allow you to fork. Alan DeKok.
As you have probably noticed, I have created pull request #5564 for the master branch. I have pushed some more commits today to implement the legacy pbkdf2 hashes using the scheme "{PBKDF2_SHA256}" (underscore instead of dash). https://github.com/FreeRADIUS/freeradius-server/pull/5564 -Gerald On 28.04.25 01:56, Alan DeKok wrote:
On Apr 27, 2025, at 9:56 AM, Gerald Vogt <vogt@spamcop.net> wrote:
As far as I understand from github community posts this is probably because you have blocked me from forking.
Looking back, you were blocked in May 2023 for unhelpful discussions. I can unblock you, which will allow you to fork.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Hi, PR#5564 and PR#5576 have been merged. Thanks. And thank you for your patience. It took a little to familiarize with git and github again. Out of curiosity I have also checked the v3.0.x branch. The internal dictionary and rlm_pap.c are almost identical to v3.2.x. I have cherry-picked the v3.2.x PR commit 7e0f4fa27156b3fa74ef095703251adc8f371cd0 and it works just as well as in v3.0.x. I know v3.0.x is bug fixes only and the pbkdf2 hashes are not really a bug fix although some may disagree. So I leave it to the developers to decide whether the lacking support of pbkdf2 support in v3.0.x is a bug or just a missing feature. If you want me to set up a PR for v3.0.x just let me know. Another question on customs about updating (commenting) closed issues: do you usually comment in older, closed github issues (or pull requests) on the same topic posting a pointer to the latest update? For example point issue #2649 to the PRs as solution? Let me know if I should do. Lastly, I think it might be helpful to be able to join freeradius-users again in case someone has problems with the added pbkdf2 support, so that I could answer them... Thanks, Gerald On 04.05.25 16:49, Gerald Vogt wrote:
As you have probably noticed, I have created pull request #5564 for the master branch.
I have pushed some more commits today to implement the legacy pbkdf2 hashes using the scheme "{PBKDF2_SHA256}" (underscore instead of dash).
https://github.com/FreeRADIUS/freeradius-server/pull/5564
-Gerald
On 28.04.25 01:56, Alan DeKok wrote:
On Apr 27, 2025, at 9:56 AM, Gerald Vogt <vogt@spamcop.net> wrote:
As far as I understand from github community posts this is probably because you have blocked me from forking.
Looking back, you were blocked in May 2023 for unhelpful discussions. I can unblock you, which will allow you to fork.
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
participants (2)
-
Alan DeKok -
Gerald Vogt