Tuesday, May 22, 2018

RAdmin version 1.16 is released

We are pleased to announce that RAdmin version 1.16 is now released. RAdmin is our tool for managing RADIUS users. With RAdmin you can check usage summaries, drill down to usage details and much more that is needed when managing your RADIUS traffic and users.

For this revision, we have implemented one key security fix, multiple bug fixes and and other enhancements. With 2-factor authentication, for example, support for using Yubikey 2-factor authentication tokens has now been updated. This release allows our customers to be sure that the software we provide is up-to-date and can be run on the current Windows, Linux and other platforms. 

For detailed list of enhancements, please see RAdmin revision history

New features

In addition of providing new bugfixes, version 1.16 also provides new enhancements for RAdmin UI. One example of these is providing a better way to listing usage of different users and sessions (see picture below). In addition other new usability and UI fixes are now available in order to provide a user-friendly way for managing network users.



Would you like to know more?

We are happy to provide RAdmin, like other Radiator products for evaluation.

RAdmin is designed especially for ISPs, CSPs and other companies or organizations that have the need to manage their RADIUS users. When contacting our sales team at info@radiatorsoftware.com we are happy to provide more info about use cases for Radiator and RAdmin. 

Wednesday, February 28, 2018

Radiator 4.20 now available!

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, see Security Advisory OSC-SEC-2018-01
– 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.

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.

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.

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:
  • 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

Monday, January 15, 2018

Radiator use case: Secure authentication to network devices in corporate network

Radiator AAA Server Software has countless use cases in enterprises. This blog text introduces you a specific use case of real life: authentication of network administrators who configure and maintain corporate network infrastructure. This requires extra security that Radiator is able to provide.



In the example use case, the admins log in to Broadband Network Gateways (BNG) with TACACS+ protocol using their own authentication credentials and passwords. For essential network equipment, a secure two-factor authentication (2FA) is used. Radiator supports a wide range of interfaces for these kinds of authentication use cases. Our customers are free to choose the interfaces and protocols that suit to their own needs.

LDAP user database provides the first factor authentication in the example use case. The second factor is handled by Duo Security.

With AuthBy DUO module, you can configure Radiator to integrate with Duo Security API, which in this case provides the second phase of authentication with Duo Security’s phone application. After the authentication has been confirmed by the application, Radiator will grant access to the network.

Using different 2FA solutions

In addition to TACACS+ protocol, Radiator supports wide range of different authentication protocols that you can use – including RADIUS. It is also possible to use different methods for the first factor authentication and second factor authentication. Radiator supports a number of interfaces suitable for the second factor authentication, and we already have use cases with several different solutions. These interfaces are included in Radiator licences.

If you have any needs for two-factor authentication in your own network, please contact our team at info@radiatorsoftware.com. We are happy to share our experience and help you with your own project.

Updated 6th of February 2018:

You can also learn more about the technical architecture from our earlier post: Secure your network and services with Radiator two-factor authentication.

Tuesday, December 5, 2017

Whatever VNF manager you choose, Radiator VNF is ready for it

Interoperability and flexibility have been Radiator key features for over 20 years. When designing new Radiator VNF, these key features guided our design and implementation. Radiator VNF is designed to operate on multiple virtualisation platforms under its own, generic, or 3rd party orchestration.

Recently we have verified our design by integrating Radiator VNF with a 3rd party VNF manager just in few weeks – together with our operator customer and 3rd party vendor.

Designed for quick and flexible integration


At the very beginning of designing Radiator VNF, it was clear that we could not rely on one orchestration solution alone. Even on telco cloud there were already a multiple options for generic or 3rd party VNF manager and our vision was to be able to run Radiator VNF on top of other cloud infrastructures (Amazon, Google Cloud, etc.) as well. This lead to our decision to separate configuration management from orchestration solution.

Our own proof-of-concept orchestration solution, Radiator VNF Manager, is developed on top of Juju. Juju is also used in ETSI’s Open Source Mano reference orchestration solution. Radiator VNF Manager manages Radiator VNF when there is not a general or 3rd party orchestration solution available. We recommend that Radiator VNF is integrated with customer’s existing orchestration solution. As Radiator VNF is being deployed, we add support for more orchestration solutions according to customer needs. Our point of view is that while having several vendor-specific VNF managers is not a scalable way to orchestrate VNFs, a single well-chosen generic VNF manager is.
In the operator case, the operator chose a 3rd party VNF manager of a major infrastructure vendor, which made the case interesting for us to ensure Radiator VNF was able to integrate with this solution. Because of the Radiator VNF and Radiator VNF Manager architecture we were able to replace Juju with Heat- and Ansible based-vendor VNF manager. This image shows the architecture with Juju.



All we had to do was to ensure that vendor VNF manager managed properly creating and deleting the virtual hosts, and that its configuration management tool Ansible was able to bootstrap the configuration process on each host. The result was successful integration of Radiator VNF with vendor VNF manager within just few weeks. The following image shows the new architecture. This process can be repeated with other VNF managers and cloud infrastructures in the future.




However, technology is only one part of the process. In order to succeed with VNF manager integration, cooperation between the operator and vendors is crucial. In this example case, the operator participated in the integration testing and was able to help us to get into contact with the vendor to get the VNF manager specifications. This kind of cooperation is essential when developing interoperable products and services for NFV infrastructure. We thank all participants for cooperation in this case.

Would you like to know more?


We are happy to tell more about our way of implementing VNF projects and also about integrating Radiator VNF to your telco environment – also with 3rd party VNF managers and infrastructure.

If you would like to know, please contact info@radiatorsoftware.com.