[RADIATOR] Questions regarding new release and current roadmap

Hartmaier Alexander alexander.hartmaier at t-systems.at
Fri Jul 1 13:43:14 CDT 2016

On 2016-06-29 13:32, Nadav Hod wrote:
> Hi,
> 2.1)  I haven't dealt with OCSP in the context of RadSec, but rather as a scalable and faster alternative to CTL files in general when dealing with any certificate. Many of our applications already support OCSP, and it would be preferable to use OCSP with stapling than to perform the query from the server each time a certificate needs to be validated.
> 2.2) EAP methods and LDAPS bindings.
> 2.3) I agree that setting up multiple processes isn't a bottleneck, but it is a bit of a hassle. It's a hassle you can automate, though.
> Thanks for the update :)
> ________________________________________
> From: radiator-bounces at open.com.au [radiator-bounces at open.com.au] on behalf of Heikki Vatiainen [hvn at open.com.au]
> Sent: Wednesday, June 29, 2016 2:20 PM
> To: radiator at open.com.au
> Subject: Re: [RADIATOR] Questions regarding new release and current roadmap
> On 29.6.2016 12.16, Nadav Hod wrote:
>> 1) Any news on uploading the roadmap?
> No new news.
>> 2.1) OCSP + OCSP stapling. I've heard this is on the roadmap for the
>> near future.
> Yes, there was recently discussion about this related to RadSec support.
> What would your use case be? If it's for TSL based EAP methods, do you
> know what the stepling support is on the client side?
I'd love to have OCSP support too to not have the requirement for an
external script which downloads the crl files and converts them to pem
>> 2.2) TLS resumption support by Session Tickets (RFC 5077). Another
>> option is to just wait for TLS 1.3 support although it would take
>> several years until most clients in an organization would support
>> TLS 1.3, if at all.
> Noted. For this feature too, would it be for EAP methods too or do you
> have something else in mind?
>> 2.3) Multithreading support for Windows Server (at the moment I'm
>> using a master service and splitting the handling of different
>> authentication methods to different Windows services).
> I don't think multithreading support is the way forward. What we are
> interested in doing is making it easier to run multiple instances that
> work together.
Async would fix all 'the radiator process is waiting for a DB query/LDAP
search/... that is slow or unresponsive and doesn't handle any other
requests for seconds' problem.
It doesn't require complicated multi-threading but some event look like
POE/IO::Async/... (please not AnyEvent!).
>> 2.4) A mature, flexible and robust web GUI, preferably one that can
>> manage distributed Radiator servers. The web GUI I'm using for 4.15
>> isn't much help for maintaining configuration and reading log files,
>> let alone multiple configuration files. Therefore I need to remote
>> desktop into the Radiator server in order to manage anything. This
>> is compounded further if you're using many Radiator servers.
> Centralised logging, and logging enhancements in general, is also
> something we're working on. There's also work done for interfaces that
> can enable building a web GUI, so the GUI does not have to be within
> Radiator itself.
> What comes to credential security, the credentials can be
> encrypted/obfuscated so that they are not in clear text format in the
> configuration file. There's initial support for that in the patches.
> However, we have not looked at separate products for credential storage.
> Thanks,
> Heikki
> --
> Heikki Vatiainen <hvn at open.com.au>
> Radiator: the most portable, flexible and configurable RADIUS server
> anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
> Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
> TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
> DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
> NetWare etc.
> _______________________________________________
> radiator mailing list
> radiator at open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
> _______________________________________________
> radiator mailing list
> radiator at open.com.au
> http://www.open.com.au/mailman/listinfo/radiator

T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
Notice: This e-mail contains information that is confidential and may be privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.

More information about the radiator mailing list