[RADIATOR] Questions regarding new release and current roadmap

Nadav Hod nadav.hod at comm-it.co.il
Wed Jun 29 06:32:18 CDT 2016


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?

> 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.

> 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


More information about the radiator mailing list