Re: New Features Development Question
On May 11, 2020, at 8:26 AM, Alan DeKok <aland@deployingradius.com> wrote:
On May 11, 2020, at 8:38 AM, Oleg Pekar <oleg.pekar.2017@gmail.com> wrote:
Dear FreeRADIUS developers, I'm evaluating of implementation of the following features in my local copy of FreeRADIUS for the PoC that I'm building locally:
Which version is this for?
We're trying to do major new features only in v4. However, that's taking longer than expected. So we're OK with minor code changes to v3. But that work cannot involve major code changes. We just don't have the bandwidth to support multiple releases.
That's perfectly clear. What is the current schedule for releasing v4? Are you also planning releasing some beta-version on feature complete milestone before the official release? If I take v4 today as a base for my PoC - what is the current stability level of v4?
* Support of unloading RADIUS/EAP/TLS state to external DB (e.g. Redis) at the end of every RADIUS request processing and locating and loading the state back from the external DB to the application when the next request RADIUS of the same RADIUS session comes. This would be extremely helpful for building scalable clusters of stateless FreeRADIUS servers (I need it for my PoC)
IIRC, that's already supported in v4. I'll check with Arran, as he added that feature.
It's unclear, he may be talking about spreading TLS based EAP methods across multiple FreeRADIUS instances instead of doing session resumption.
If it's session resumption that's already supported in v4.
* Support of external generic CA and CTL for certificate based user authentications
I'm not sure what that means. "generic CAs" ?
Yeah no idea either.
I meant generic ability to work with external CA server that provides Certificate Trusted List services instead of working with the local certificate storage. I don't have any specific API in mind, just need to think about such functionality.
* Support of configurable debug and audit log to external loggers
We have a plan for that in v4. But even there, it involves some fairly serious changes, even if they are largely of the form "change A to B".
See rlm_logtee in v4. It's already there.
-Arran
Few more questions: * Is RadSec over TLS working in v4? My colleague has it working in v3, but not in v4. TCP on the other hand is working fine in v4. * Is it possible to have dynamic authorization messages and responses go over the same RadSec tunnel used for authentication and accounting? In v3? In v4? * Does v4 has backward compatibility for configuration? If we start with v3 - what will be the effort to move to v4 (not including any code changes we can do)? Thank you, Oleg
On May 11, 2020, at 8:26 AM, Alan DeKok <aland@deployingradius.com> wrote:
On May 11, 2020, at 8:38 AM, Oleg Pekar <oleg.pekar.2017@gmail.com> wrote:
Dear FreeRADIUS developers, I'm evaluating of implementation of the following features in my local copy of FreeRADIUS for the PoC that I'm building locally:
Which version is this for?
We're trying to do major new features only in v4. However, that's taking longer than expected. So we're OK with minor code changes to v3. But that work cannot involve major code changes. We just don't have the bandwidth to support multiple releases.
That's perfectly clear. What is the current schedule for releasing v4? Are you also planning to release some beta-version on a feature complete milestone before the official release? If I take v4 today as a base for my PoC - what is the current stability level of v4?
* Support of unloading RADIUS/EAP/TLS state to external DB (e.g. Redis) at the end of every RADIUS request processing and locating and loading the state back from the external DB to the application when the next request RADIUS of the same RADIUS session comes. This would be extremely helpful for building scalable clusters of stateless FreeRADIUS servers (I need it for my PoC)
IIRC, that's already supported in v4. I'll check with Arran, as he added that feature.
It's unclear, he may be talking about spreading TLS based EAP methods across multiple FreeRADIUS instances instead of doing session resumption.
If it's session resumption that's already supported in v4.
* Support of external generic CA and CTL for certificate based user authentications
I'm not sure what that means. "generic CAs" ?
Yeah no idea either.
I meant a generic ability to work with an external CA server that provides Certificate Trusted List services instead of working with the local certificate storage.These services include revocation configuration (OCSP/CRL) per CA certificate. I don't have any specific API in mind, just need to think about such functionality.
The better method though, is sending back all the encoded session-state attributes in the ticket, then there's no need for the central database. That's not done currently unfortunately because of limitations in the OpenSSL API.
Agree, usage of client-side caching is very efficient in EAP-TLS session tickets and EAP-FAST PAC.
The better method though, is sending back all the encoded session-state attributes in the ticket, then there's no need for the central database. That's not done currently unfortunately because of limitations in the OpenSSL API. What are those limitations?
Few more questions: * Is RadSec over TLS working in v4? My colleague has it working in v3, but not in v4. TCP on the other hand is working fine in v4. * Is it possible to have dynamic authorization messages and responses go over the same RadSec tunnel used for authentication and accounting? In v3? In v4? * Does v4 have backward compatibility for configuration? If we start with v3 - what will be the effort to move to v4 (not including any code changes we can do)? Thank you, Oleg
On Jul 7, 2020, at 6:04 AM, Oleg Pekar <oleg.pekar.2017@gmail.com> wrote:
That's perfectly clear. What is the current schedule for releasing v4?
It will be released when it's ready. Sadly, paying work gets in the way of fixing v4.
Are you also planning to release some beta-version on a feature complete milestone before the official release? If I take v4 today as a base for my PoC - what is the current stability level of v4?
v4 is stable, mostly. We run a suite of tests on it for every build. We ensure that the tests pass. But as with software undergoing large changes, there may be issues from time to time.
I meant a generic ability to work with an external CA server that provides Certificate Trusted List services instead of working with the local certificate storage.These services include revocation configuration (OCSP/CRL) per CA certificate. I don't have any specific API in mind, just need to think about such functionality.
OpenSSL already supports OCSP. That's supported in v3, too.
The better method though, is sending back all the encoded session-state attributes in the ticket, then there's no need for the central database. That's not done currently unfortunately because of limitations in the OpenSSL API. What are those limitations?
I don't recall. Maybe Arran can offer opinions.
Few more questions: * Is RadSec over TLS working in v4? My colleague has it working in v3, but not in v4. TCP on the other hand is working fine in v4.
Radsec isn't in v4 yet, mostly due to time.
* Is it possible to have dynamic authorization messages and responses go over the same RadSec tunnel used for authentication and accounting? In v3? In v4?
No. There is no IETF standard for this, and no RADIUS server supports it. We're looking at adding it in v4 for a large WiFi project which is underway. But even that may take 8 months.
* Does v4 have backward compatibility for configuration? If we start with v3 - what will be the effort to move to v4 (not including any code changes we can do)?
It's not 100% compatible with v3. That's why it's a major version change. But, most things are pretty similar. The unlang syntax is 99% the same (some new things are added). The module configurations are 99% the same. The server comes with an "upgrade" guide which details the differences. See doc/antora/modules/installation/pages/upgrade.adoc It should take less than a day to move a complex v3 configuration to v4. It's mostly just renaming and testing. Alan DeKok.
participants (2)
-
Alan DeKok -
Oleg Pekar