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-boun...@open.com.au [radiator-boun...@open.com.au] on behalf > of Heikki Vatiainen [h...@open.com.au] > Sent: Wednesday, June 29, 2016 2:20 PM > To: radiator@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 format. > >> 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 <h...@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@open.com.au > http://www.open.com.au/mailman/listinfo/radiator > _______________________________________________ > radiator mailing list > radiator@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. *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"* _______________________________________________ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
