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)/
subject= /C=AU/ST=Victoria/L=Melbourne/O=OSC Demo Certificates/OU=Test Certificate Section/CN=testUser

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)/
subject= /C=AU/ST=Victoria/L=Melbourne/O=OSC Demo Certificates/OU=Test Certificate Section/

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 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):
LogDir        .
DbDir         .
# User a lower trace level in production systems:
Trace         4
LogFile       %L/radiator.log

AuthPort 1812
AcctPort 1813

<Client DEFAULT>
      Secret radius

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

            # Check OCSP status of EAP-TLS client certificates during TLS handshake

            # Check OCSP status of EAP-TLS client certificates asynchronous after TLS handshake
            # but before authenticating and authorizing the client.

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

            # Use specified OCSP URI for OCSP queries instead of OCSP URI in EAP-TLS client certificate.

            # 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


wpa_supplicant / eapol_test configuration for EAP-TLS which requires OCSP staple:

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):
LogDir        .
DbDir         .
# User a lower trace level in production systems:
Trace         4

<Client DEFAULT>
      Secret mysecret

      <AuthBy RADSEC>
            ReconnectTimeout        10
            NoreplyTimeout          5
            KeepaliveTimeout        30
            KeepaliveNoreplyTimeout 2

            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.

            # Alternatively, check OCSP status of RadSec server certificates during TLS handshake.

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

            <Host localhost>

Radiator configuration for RadSec server which enables OCSP queries and OCSP stapling (there is a similar example config in goodies/radsec-server.cfg):
LogDir        .
DbDir         .
# User a lower trace level in production systems:
Trace         4

# Don't listen on any UDP ports

# Listen for AuthBy RADSEC connections from RadSec clients
      TLS_CAFile ./certificates/demoCA/cacert.pem
      TLS_CertificateFile ./certificates/cert-srv.pem
      TLS_CertificateType PEM
      TLS_PrivateKeyFile ./certificates/cert-srv.pem
      TLS_PrivateKeyPassword whatever

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

      # Check OCSP status of RadSec client certificates during TLS handshake.

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

      # Use specified OCSP URI for OCSP queries instead of OCSP URI in RadSec client certificate.

      # 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

      <AuthBy FILE>
            Filename ./users

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.


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

Friday, November 3, 2017

Radiator Load Balancer

As a part of our Radiator VNF products, we have recently developed a Radiator Load Balancer for RADIUS and Diameter interfaces. With our own load balancer, Radiator VNF is able to scale workload more efficiently and without need for external load balancer products – which provides a cost-effective solution for all our AAA customers.

Technical overview and key features

To put it short: Radiator Load Balancer’s main function is to distribute the incoming load to the worker components of VNF. It is the primary entry point for the incoming RADIUS and Diameter messages, for which we have independent load balancers.

Loab balancers in Radiator VNF architecture

Our Diameter load balancer supports multicore processor architecture that makes it very effective to use. The load balancer can utilise multiple threads for processing the incoming requests concurrently. The worker thread count is configurable for the best possible performance.

Diameter load balancer has an extensive support for logging. By default, it can produce JSON and plain text log files. The JSON logs can be further integrated to Elasticsearch or other log collecting systems. These systems provide possibilities to create graphical presentations of the system data – both performance counters and log files.

Loadbalancer is very flexible, you can configure several different features, such as routing, initiator support, responder support, TCP and SCTP support, timeout, logging, and many, many more.

You can redirect the messages with Diameter Loadbalancer and use dynamic routing tables. For example, from VNF point of view, HSS can specify which server handles particular traffic. The worker then instructs the load balancer to forward traffic to the indicated server, and the load balancer modifies its dynamic routing tables to perform the forwarding. In addition, to avoid redirect loops, Radiator Loadbalancer has a detector that recognises and prevents them.

The routing decisions are based on matching the dynamic routing table against the Diameter AVPs:
– realm
– application-id
– user-id
– session-id
– hostname

Loadbalancer has a comprehensive support for failover. It prefers the active peers by default and retransmits the messages to alternative peers if one peer does not respond.

Interested to know more about Radiator Load Balancer?

If you are interested to know more about Radiator Load Balancer and Radiator VNF in general, you can contact our sales and support team at . We are happy to provide more detailed information for your infrastructure.

Thursday, August 17, 2017

Going Cloud-Native with Radiator VNF

Cloud-native packet core architecture

Nowadays, many telcos target their packet core architecture at a cloud-native implementation, which is deployed in their own virtual infrastructure environment. In this environment, all different network functions, such as AAA, are virtualised.

This infrastructure supports all services (data, voice, IoT, and so on) and all wireless access technologies including WiFi, LTE, and 5G. Also the data plane and control plane are fully separated. They are likely to follow different deployment models, such as centralised control plane and session management or distributed data plane.

Radiator - cloud-native AAA solution

Radiator VNF is an ideal solution for this kind of approach and migration to cloud-native infrastructure. Radiator VNF components and virtual hosts are configured automatically through a centralised configuration system. In addition to this, all VNF components interact using the redundant message queue. Cloud-native approach is also seen in load balancers, that ensure that you always have the right amount of AAA capacity in your cloud-native network.


Radiator VNF is cloud-native from architecture point of view as well

Two ways: cloud-native from the start or step-by-step approach

For transition to Radiator VNF for your AAA solution, you can run it on your cloud-native infrastructure, such as Openstack. The other alternative is that you run Radiator VNF with a static configuration on VMs. In that case, you can have all the components, such as load balancers, developed for Radiator VNF, but options in scaling and automatic configuration are more limited. They emerge when your infrastructure is transformed to be cloud-native. Our licensing options and Radiator deployments support both approaches.

If you want to get more information, please see Radiator VNF technical documentation, or contact our team at

Tuesday, July 25, 2017

Recent logging and management updates in Radiator

In recent Radiator releases 4.18 and 4.19 we have implemented numerous logging and management updates. These enhancements provide more tools for diagnostics and management of your network and possible authentication issues. In Radiator release 4.19, the enhancements include:
  • Unfinished EAP authentications are now logged and available for AuthLog logging
  • Ignored authentications are now available for AuthLog logging
Also, in release 4.18 we have added support for new type of clause "AcctLog xxxxx". With this enhancement, it is easier to configurate the handling of accounting messages than before. An AcctLog clause logs RADIUS accounting requests to a file, Windows Event Log, SQL or syslog. An AcctLog is configured similar to AuthLog: you configure one more AcctLog clauses for a Handler or Realm. Currently supported AcctLog clauses are: 
  • AcctLog EVENTLOG 
  • AcctLog FILE
  • AcctLog SQL
  • AcctLogSYSLOG. 
In Radiator documentation, you can see logformat.cfg and sql.cfg for configuration samples. All enhancements in releases 4.18 and 4.19 can be found from Radiator product history.

Would you like to know more?

If you would like to know more how these enhancements and Radiator in general can help you with your authentication, accounting and logging needs, please do not hesitate to contact our team at

Wednesday, June 7, 2017

Radiator VNF – meeting the standards

Radiator – interoperability in NFV world

Radiator is known for its interoperability and flexibility and from the very beginning, Radiator VNF is meant to be similar. In order to make it so, we have built Radiator VNF to meet the industry standards, such as NFV release 1 by the European Telecommunications Standards Institute (ETSI). Radiator VNF follows the ETSI standard architecture as shown below.

Radiator VNF architecture

Of course, meeting the NFV release 1 standard is not enough for us. There are new releases coming, such as ETSI NFV release 2 published in autumn 2016. Our development team has been working to make Radiator VNF to meet this standard and the development goes on. The NFV release 2 added several new specifications to the previous release: various requirements and instructions for resilience, service quality metrics, management, orchestration, security, and many, many more.

Meeting these standards and constant development means that Radiator VNF customers can trust their solution to be interoperable now and in the future. This helps both our integrator partners and customers in their mission to have the best components for different needs in their infrastructure.

Meeting standards – more benefits for markets

When the vendors ensure that their software follows the NFV standards, the market will run better, too. The customers, such as telcos, can choose the components from the wide range of products without a fear for a vendor lock-in. This makes the NFV markets to mature more rapidly. Additionally, the technology itself matures and can deliver the promised benefits. More information about this is available in the industry report by SDx Central.

We in Radiator team are committed to deliver the NFV promise and Radiator’s well-known interoperability in the new Radiator VNF. Contact our sales team at to get more information about our Radiator VNF solution.