We are happy to announce that Radiator 4.20 is published today!
The new version has dozens of improvements, new features, and bug fixes. Here are some examples:
– OCSP and OCSP stapling support, see the blog post
– Certificate check enhancements
– Better support for asynchronous operations
– Several security improvements
– Security fix for certificate validation for EAP-TLS and TLS-based Stream modules
– Possibility to include extra checks with new ServerTACACSPLUS AuthorizeGroups parameter
– TLS 1.3 awareness
– New module AuthBy RATELIMITSOURCE
– Improved LDAP functionality
– New hooks, such as EAPTLS_CertificateVerifyFailedHook and ForwardHook
For a detailed list of changes, see Radiator revision history page.
Solutions made with Radiator AAA server and other Radiator Software products. Cooking with Radiator for success!
Wednesday, February 28, 2018
Monday, February 26, 2018
Radiator team in Mobile World Conference 2018
Radiator team is present at Mobile World Conference in Barcelona on 26 February – 1 March.
Come to meet us in hall 3 (3B10), Finland Pavilion and discuss newest features of Radiator and Radiator VNF or learn about the latest use cases. We can also arrange a meeting with you, please contact Jaakko Stenhäll (jaakko.stenhall@radiatorsoftware.com) for more details.
Come to meet us in hall 3 (3B10), Finland Pavilion and discuss newest features of Radiator and Radiator VNF or learn about the latest use cases. We can also arrange a meeting with you, please contact Jaakko Stenhäll (jaakko.stenhall@radiatorsoftware.com) for more details.
Labels:
MWC2018,
Radiator VNF
Monday, February 19, 2018
Working together: Radiator AAA Server and Authus Network Security Solution
Our partners use Radiator® widely in their own solutions. Here we introduce you Authus network security solution, provided by our partner company HenZ ICT.
Authus uses Radiator AAA Server for fast, reliable, and stable authentication. Like Authus, Radiator is platform-independent, which makes the combined solution flexible to integrate into different environments. Radiator performs the initial authentication within Authus network security solution.
After the initial authentication, Network Access Engine determines whether a client is permitted access to the network and with which type of profile. The decisions are based on the Authus Validation Rules. The profile defines which VLAN (Virtual LAN) the client gets access.
Furthermore, Authus includes Reporting Engine, which uses a database to store AAA (Authentication, Authorisation, Accounting) information. Based on this data, dashboards show the status and operation of the Authus system. Authus offers also other functionalities for support purposes, such as trace functionality and dashboards on transaction level.
Key benefits for the customer
The combined solution, where Radiator and Authus are interoperating, provides multiple key benefits, such as:
Would you like to know more?
If you are interested to know more about use of Radiator with Authus or the combined solution, please do not hesitate to contact our Radiator sales team at info@radiatorsoftware.com. Also, you can contact Authus team at info@henz.nl.
Authus uses Radiator AAA Server for fast, reliable, and stable authentication. Like Authus, Radiator is platform-independent, which makes the combined solution flexible to integrate into different environments. Radiator performs the initial authentication within Authus network security solution.
Architecture of Radiator and Authus working together |
After the initial authentication, Network Access Engine determines whether a client is permitted access to the network and with which type of profile. The decisions are based on the Authus Validation Rules. The profile defines which VLAN (Virtual LAN) the client gets access.
Furthermore, Authus includes Reporting Engine, which uses a database to store AAA (Authentication, Authorisation, Accounting) information. Based on this data, dashboards show the status and operation of the Authus system. Authus offers also other functionalities for support purposes, such as trace functionality and dashboards on transaction level.
Key benefits for the customer
The combined solution, where Radiator and Authus are interoperating, provides multiple key benefits, such as:
- Better network security
- Low cost of network management
- High degree of flexibility for your infrastructure
- Better reporting for your network
Would you like to know more?
If you are interested to know more about use of Radiator with Authus or the combined solution, please do not hesitate to contact our Radiator sales team at info@radiatorsoftware.com. Also, you can contact Authus team at info@henz.nl.
Wednesday, February 7, 2018
New feature: OCSP and OCSP stapling support for TLS and EAP
New Radiator version 4.20 introduces support for OCSP and OCSP stapling for TLS based EAP methods (such as EAP-TLS, EAP-TTLS, and EAP-PEAP) and RadSec (TLS encryption for RADIUS over TCP).
OCSP (Online Certificate Status Protocol) is a method for checking certificates' revocation status online and is used as an alternative for CRL (Certificate Revocation List) files. Whereas CRL files needs to be updated every now and then, OCSP uses queries sent to CA (Certificate Authority) to obtain the latest revocation status.
Radiator uses OCSP to query and verify that EAP supplicant's or RadSec peer's certificate has not been revoked and can provide OCSP staple to EAP supplicants and RadSec peers to verify that Radiator's own certificate has not been revoked. More info about OCSP and OCSP staple can be found from the references at the end.
In order to use OCSP with Radiator, following conditions needs to be met:
In this blog post, we show two configuration examples how to enable and test OCSP support.
We use demo certificates bundled with Radiator which do support OCSP.
You can check whether your X.509 certificate contains OCSP URL with the commands shown below.
Test client certificate:
Test server certificate:
For testing OCSP, we run OCSP responder provided by OpenSSL library.
Normally, CA who has signed the certificates runs OCSP responder on the Internet.
OCSP responder is run with a command shown below (pass phrase for all demo certificates is "whatever"):
Leave OCSP responder running on http://127.0.0.1:8008/ and waiting for OCSP queries from Radiator.
Radiator configuration which enables OCSP queries and OCSP stapling for EAP-TLS (there is a similar example config in goodies/eap_tls.cfg):
wpa_supplicant / eapol_test configuration for EAP-TLS which requires OCSP staple:
Besides TLS based EAP methods, OCSP can also be used with RadSec peerings, either with or without OCSP stapling.
Radiator configuration for RadSec client enables OCSP stapling (there is a similar example config in goodies/radsec-client.cfg):
Radiator configuration for RadSec server which enables OCSP queries and OCSP stapling (there is a similar example config in goodies/radsec-server.cfg):
Radiator acting as RadSec client (AuthBy RADSEC) will connect to Radiator acting as RadSec server (ServerRADSEC) and will request OCSP staple to be returned during TLS handshake. Server will get OCSP response for its own certificate and return it as OCSP staple to the client and when the client has sent its certificate, the server will query its revocation status with OCSP before accepting it.
OCSP (Online Certificate Status Protocol) is a method for checking certificates' revocation status online and is used as an alternative for CRL (Certificate Revocation List) files. Whereas CRL files needs to be updated every now and then, OCSP uses queries sent to CA (Certificate Authority) to obtain the latest revocation status.
Radiator uses OCSP to query and verify that EAP supplicant's or RadSec peer's certificate has not been revoked and can provide OCSP staple to EAP supplicants and RadSec peers to verify that Radiator's own certificate has not been revoked. More info about OCSP and OCSP staple can be found from the references at the end.
In order to use OCSP with Radiator, following conditions needs to be met:
- Radiator version 4.20 or later
- X.509 certificates and CA used support OCSP
- OpenSSL library version 1.0.0 or later
- Perl Net::SSLeay library version 1.83 or later
- Perl LWP::UserAgent library
- (Optional) Perl HTTP::Async library for asynchronous OCSP queries (supported only with EAP-TLS)
In this blog post, we show two configuration examples how to enable and test OCSP support.
We use demo certificates bundled with Radiator which do support OCSP.
You can check whether your X.509 certificate contains OCSP URL with the commands shown below.
Test client certificate:
% cd path/to/radiator-distribution % openssl x509 -noout -issuer -subject -ocsp_uri -in certificates/cert-clt.pem issuer= /C=AU/ST=Victoria/L=Melbourne/O=OSC Demo Certificates/OU=Test Certificate Section/CN=OSC Test CA (do not use in production)/emailAddress=mikem@open.com.au subject= /C=AU/ST=Victoria/L=Melbourne/O=OSC Demo Certificates/OU=Test Certificate Section/CN=testUser http://127.0.0.1:8008
Test server certificate:
% cd path/to/radiator-distribution % openssl x509 -noout -issuer -subject -ocsp_uri -in certificates/cert-srv.pem issuer= /C=AU/ST=Victoria/L=Melbourne/O=OSC Demo Certificates/OU=Test Certificate Section/CN=OSC Test CA (do not use in production)/emailAddress=mikem@open.com.au subject= /C=AU/ST=Victoria/L=Melbourne/O=OSC Demo Certificates/OU=Test Certificate Section/CN=test.server.some.company.com http://127.0.0.1:8008
For testing OCSP, we run OCSP responder provided by OpenSSL library.
Normally, CA who has signed the certificates runs OCSP responder on the Internet.
OCSP responder is run with a command shown below (pass phrase for all demo certificates is "whatever"):
% cd path/to/radiator-distribution/certificates % openssl ocsp -rsigner root-CA-crt.pem -rkey root-CA-key.pem -index root-CA-idx.txt -port 8008 -CA root-CA-crt.pem -text Enter pass phrase for root-CA-key.pem: Waiting for OCSP client connections...
Leave OCSP responder running on http://127.0.0.1:8008/ and waiting for OCSP queries from Radiator.
EAP-TLS OCSP configuration example
Radiator configuration which enables OCSP queries and OCSP stapling for EAP-TLS (there is a similar example config in goodies/eap_tls.cfg):
Foreground LogStdout LogDir . DbDir . # User a lower trace level in production systems: Trace 4 LogFile %L/radiator.log AuthPort 1812 AcctPort 1813 <Client DEFAULT> Secret radius </Client> <Handler> <AuthBy FILE> # Users must be in this file to get anywhere Filename %D/users EAPType TLS EAPTLS_CAFile %D/certificates/demoCA/cacert.pem EAPTLS_CertificateFile %D/certificates/cert-srv.pem EAPTLS_CertificateType PEM EAPTLS_PrivateKeyFile %D/certificates/cert-srv.pem EAPTLS_PrivateKeyPassword whatever EAPTLS_MaxFragmentSize 1200 # Online Certificate Status Protocol (OCSP) related # configuration parameters # Provide OCSP staple for EAP-TLS clients asking for it. EAPTLS_OCSPStapling # Check OCSP status of EAP-TLS client certificates during TLS handshake EAPTLS_OCSPCheck # Check OCSP status of EAP-TLS client certificates asynchronous after TLS handshake # but before authenticating and authorizing the client. #EAPTLS_OCSPAsyncCheck # Reject EAP-TLS client certificate when OCSP responder is unavailable or OCSP status query fails. # By default, only a valid OCSP status response can reject EAP-TLS client certificate. EAPTLS_OCSPStrict # Use specified OCSP URI for OCSP queries instead of OCSP URI in EAP-TLS client certificate. #EAPTLS_OCSPURI # If OCSP query to OCSP URI fails, mark OCSP responder failed for 10 minutes. EAPTLS_OCSPFailureBackoffTime 600 # Cache OCSP statuses for 1 hour (defaults to 20 minutes) EAPTLS_OCSPCacheTime 3600 # Cache OCSP status for max 2000 different certificates (defaults to 1000 entries) EAPTLS_OCSPCacheSize 2000 AutoMPPEKeys </AuthBy> </Handler>
wpa_supplicant / eapol_test configuration for EAP-TLS which requires OCSP staple:
network={ ssid="my8021xwpa" key_mgmt=WPA-EAP eap=TLS identity="testUser" ca_cert="./certificates/demoCA/cacert.pem" client_cert="./certificates/client-crt.pem" private_key="./certificates/client-key.pem" private_key_passwd="whatever" ocsp=2 }
RadSec OCSP configuration example
Besides TLS based EAP methods, OCSP can also be used with RadSec peerings, either with or without OCSP stapling.
Radiator configuration for RadSec client enables OCSP stapling (there is a similar example config in goodies/radsec-client.cfg):
Foreground LogStdout LogDir . DbDir . # User a lower trace level in production systems: Trace 4 <Client DEFAULT> Secret mysecret </Client> <Handler> <AuthBy RADSEC> ReconnectTimeout 10 NoreplyTimeout 5 KeepaliveTimeout 30 KeepaliveNoreplyTimeout 2 UseStatusServerForFailureDetect UseTLS TLS_CAFile %D/certificates/demoCA/cacert.pem TLS_CertificateFile %D/certificates/cert-clt.pem TLS_CertificateType PEM TLS_PrivateKeyFile %D/certificates/cert-clt.pem TLS_PrivateKeyPassword whatever # Online Certificate Status Protocol (OCSP) related # configuration parameters # Request OCSP staple from RadSec server. TLS_OCSPStapling # Alternatively, check OCSP status of RadSec server certificates during TLS handshake. #TLS_OCSPCheck # Reject RadSec server certificate when OCSP staple or # OCSP responder is unavailable or OCSP status query # fails. By default, only a valid OCSP status # response can reject RadSec server certificate. TLS_OCSPStrict <Host localhost> </Host> </AuthBy> </Handler>
Radiator configuration for RadSec server which enables OCSP queries and OCSP stapling (there is a similar example config in goodies/radsec-server.cfg):
Foreground LogStdout LogDir . DbDir . # User a lower trace level in production systems: Trace 4 # Don't listen on any UDP ports AuthPort AcctPort # Listen for AuthBy RADSEC connections from RadSec clients <ServerRADSEC> UseTLS TLS_CAFile ./certificates/demoCA/cacert.pem TLS_CertificateFile ./certificates/cert-srv.pem TLS_CertificateType PEM TLS_PrivateKeyFile ./certificates/cert-srv.pem TLS_PrivateKeyPassword whatever TLS_RequireClientCert # Accept any peer with valid cert signed by demoCA for demo TLS_ExpectedPeerName .+ # Online Certificate Status Protocol (OCSP) related # configuration parameters # Provide OCSP staple for RadSec client requesting it. TLS_OCSPStapling # Check OCSP status of RadSec client certificates during TLS handshake. TLS_OCSPCheck # Reject RadSec client certificate when OCSP staple or OCSP # responder is unavailable or OCSP status query fails. By # default, only a valid OCSP status response can reject RadSec # client certificate. TLS_OCSPStrict # Use specified OCSP URI for OCSP queries instead of OCSP URI in RadSec client certificate. #TLS_OCSPURI # If OCSP query to OCSP URI fails, mark OCSP responder failed for 10 minutes. TLS_OCSPFailureBackoffTime 600 # Cache OCSP statuses for 1 hour (defaults to 20 minutes) TLS_OCSPCacheTime 3600 # Cache OCSP status for max 2000 different certificates (defaults to 1000 entries) TLS_OCSPCacheSize 2000 </ServerRADSEC> <Handler> <AuthBy FILE> Filename ./users </AuthBy> </Handler>
Radiator acting as RadSec client (AuthBy RADSEC) will connect to Radiator acting as RadSec server (ServerRADSEC) and will request OCSP staple to be returned during TLS handshake. Server will get OCSP response for its own certificate and return it as OCSP staple to the client and when the client has sent its certificate, the server will query its revocation status with OCSP before accepting it.
References
Labels:
certificates,
configuration guide,
EAP,
OCSP,
PKI,
radiator,
RadSec,
security,
stapling,
X.509
Subscribe to:
Posts (Atom)