New Features Development Question

[Oleg Pekar]

> > On May 11, 2020, at 8:26 AM, Alan DeKok <aland at deployingradius.com> wrote:
> >
> > On May 11, 2020, at 8:38 AM, Oleg Pekar <oleg.pekar.2017 at 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