Monday, March 27, 2023

Radiator team take part in IETF 116 in Yokohama

We at Radiator take pride in applying the latest industry standards into Radiator. Part of these efforts include actively engaging with the relevant IETF working groups. Following up on the widely supported reboot of the RADIUS Extensions working group at IETF 115 in London, Radiator team is flying out to Japan to participate in IETF 116 in person. We’re especially looking forward to these two sessions:

  • RADIUS EXTensions (radextra)
  • EAP Method Update (emu)

    Meet the team

    Staying at the forefront of industry developments is a top priority for Radiator development. As always, we are looking forward to working on RADIUS drafts and standards and implementing them in Radiator. If you’re in Yokohama, come find us at the and say hi! The point of contact is Radiator developer Heikki Vatiainen, who is available to meet at Pacifico venue. Everyone else, please drop us an email!

    Want to know more?

  • IETF 116 Yokohama
  • IETF 116 RADIUS EXTensions meeting
  • IETF EAP Method Update meeting
  • Our blog from IETF 115 highlights
  • Monday, March 13, 2023

    Radiator SIM Pack 2.8 released! Major scalability improvement and other enhanced features

    We are pleased to announce the release of Radiator SIM Pack version 2.8. This new release contains major scalability improvement and many enhanced features.

    Scalability improvement and other enhanced features

    To make it easier to manage large installations and improve performance, Radiator 3GPP AAA Server now supports configuration with multiple parallel workers that use the same Diameter identity. This update was also reflected in earlier Radiator Service Provider Pack release. 

    In addition, Radiator SIM Pack has supported IMSI Privacy since release 2.5 and 2.8 release now adds support for certificate revocation and expiration notifications. For more info about IMSI Privacy features in Radiator SIM Pack, please see our new whitepaper.

    Also, customers using SIGTRAN will be pleased to learn that SIGTRAN stack upper layers have been rearranged to better support additional MAP dialogues. For more detailed changes, please see the Radiator SIM Pack revision history.

    Would you like to know more?

    If you like to know more about Radiator, the new release and how it can help you in your use case, you can always contact our team at info(a) - or fill out the contact form.

    Thursday, February 23, 2023

    New whitepaper: Introduction to IMSI Privacy Protection for Wi-Fi with Radiator SIM Pack


    Great news! We are proud to present our new whitepaper “Introduction to IMSI Privacy Protection for Wi-Fi with Radiator SIM Pack”. You can download the whitepaper from our website.

    What is IMSI Privacy about and why is it important?

    One of the key use cases for SIM authentication, Wi-Fi offloading enables SIM-based devices to automatically switch data and voice traffic from mobile networks to Wi-Fi networks. This lets mobile carriers and operators reduce their operating costs, and provide better network coverage and customer service, in locations with high amounts of mobile traffic. However, without IMSI Privacy Protection for Wi-Fi the mobile user’s identity will be exposed on the Wi-Fi network when the device is authenticated and the latest Android and iOS mobile devices will also give the user a security warning and may refuse to connect automatically.

    Since many of the SIM-based Wi-Fi authentication use cases, such as Wi-Fi offloading, Voice over Wi-Fi and Wi-Fi roaming capabilities are growing in importance, mobile OS manufacturers are putting pressure on the industry to improve Wi-Fi security, leading to a clear need for reliable IMSI Privacy Protection.

    In our white paper, we give an overview of the security issues with Wi-Fi SIM-based device authentication and introduce the Radiator SIM Pack, which is a proven solution for IMSI Privacy Protection for Wi-Fi.

    For more information, please download the whitepaper from our website.

    *) In SIM-based mobile devices, like smart phones and tablets, the user’s unique identifier is stored on the SIM card in a standard format known as the International Mobile Subscriber Identifier, or IMSI for short.

    Wednesday, January 18, 2023

    Meet Radiator Team at Mobile World Congress Barcelona 2023!

    Radiator Software is exhibiting at MWC23 Barcelona! 

    We are delighted to announce that Radiator team will once again be exhibiting at the world’s largest connectivity event of the year: Mobile World Congress 2023 held at Fira Gran Via in Barcelona on 27 February – 2 March.

    Our theme for this event is the capabilities of Radiator SIM Pack; a standalone support SIM-based authentication methods with use cases like WiFi offloading, in-flight connectivity and OpenRoaming. To prepare for the event next month we are hosting a webinar about SIM Authentication with Radiator next week on 24th and 26th of January. More information and sign up at our webinars page.

    Where can you find the Radiator team?

    Finland country pavillion, booth 7G41.

    We are exhibiting with fellow Finns in hall 7. The event team will consist of both commercial and technical Radiator experts so whichever Radiator topic you have in mind, we have got you covered. So whether you are familiar with Radiator or considering options for your AAA needs, or just exploring the world of network authentication come stop by and have a chat with us.

    If you want to schedule a meeting or simply ask a question, please fill out this form and we will get back to you.

    See you in Barcelona!

    Thursday, December 22, 2022

    Radiator 4.27 now available!

    We are pleased to announce the release of Radiator version 4.27!

    The main new feature in the release is support for EAP-TLS v. 1.3 - as specified in the RFC 9190. TLS v. 1.3 is available also for RadSec and for all TLS-based EAP methods. TLSv1.3 is disabled by default, but can be turned on by the customer when needed. TLSv1.3 will be enabled by default in future Radiator releases.

    At the same time, we continue to monitor TLSv1.3 interoperability with EAP-TTLS and PEAP. At the moment TLSv1.3 session resumption is disabled because of interoperability problems. To help with this, we are participating in IETF work that aims to solve the pending issues.

    In addition, significant update work for LDAP connection and TLS debugging has been made - as well as support for different Linux distributions.
    For other new features, enhancements, interoperability, and bug fixes, please see below.
    Selected compatibility notes, enhancements and fixes

    • Significant LDAP updates to connection and TLS handling.
    • Red Hat Enterprise Linux 9 and its derivatives are now supported.
    • Ubuntu 22.04 is now supported.
    • Session resumption is enabled for EAP-TLS with TLSv1.3 but remains disabled for the other TLS based EAP methods.
    • TLSv1.3 is supported by EAP-TLS, EAP-TTLS and PEAP but remains disabled by default.
    • TLSv1.3 is tested with RadSec and other Stream modules but remains disabled by default.
    • Radiator can log TLS key material to a file to allow fully decrypting EAP and Stream SSL/TLS sessions.
    • TLS handshake and state trace logging is now enabled for EAP and Stream modules, such as PEAP and RadSec, when Trace 4 (debugging) or PacketTrace is configured.
    • Radiator SIM Pack 2.7 and Carrier Pack 1.7, or later, are strongly recommended.


    Known caveats and other notes

    • TLSv1.3 remains disabled by default for TLS based EAP methods and Stream based classes, such as RadSec. TLSv1.3 testing reports are welcome.
    • Fix and enhance EAP-FAST. Requires Net::SSLeay 1.94 or later with OpenSSL 1.1.1 and later.

    More detailed changes can be found in the revision history.

    Radiator packages are available to download for current licensees from the downloads page and the Radiator repository.

    Would you like to know more?

    If you like to know more about Radiator, the new release and how it can help you in your use case, you can always contact our team at info(a)

    Monday, December 12, 2022

    Offline TOTP implementation with Radiator AAA Server and Windows Server

    Recently, we have had multiple customer cases in the need of offline TOTP (time-based one-time password) implementations. Both private enterprises and public institutions working on different fields have discovered an increasing need for offline multi-factor authentication to protect their critical infrastructure. These use cases include for example power companies, transport infrastructure and other use cases that are used in private networks, and where secure authentication is essential at all times.

    Many of these customers use Windows Server and Microsoft SQL server in their implementations, so we wanted to share how Radiator AAA Server Software can be used with them when implementing an offline TOTP solution. And as clarified below, given the flexibility of Radiator, other platforms can be used as well⁠—do not hesitate to contact us with your own specific use case in your own infrastructure.

    How it is done

    We have had a working example in the Radiator goodies directory that can be leveraged to individual needs:

    totp.cfg and totp.sql
    Sample configuration file for Radiator, showing how to authenticate using TOTP (RFC 6238) one-time-passwords. The sample MySQL database schema provides test users, with and without a PIN.
    Supporting script for generating secret values for TOTP and printing them in different text formats and as QR code images.

    The existing example is using SQL definitions specific to MySQL and MariaDB database servers. As Radiator is flexible, the same functionality can be achieved on any supported OS and with any database. Here we show how to set up a similar system with Windows Server 2012 to 2022 and Microsoft SQL Server 2012 to 2022, with Radiator AAA Server Software (current version 4.26). The new Windows-specific configuration shown here will also be included in the goodies of the oncoming release of Radiator soon.

    To start with, we expect the system with Windows Server is already installed and hardened as needed. Also, installing Microsoft SQL Server and Microsoft SQL Server Management Studio is out of scope of this post. You can try this TOTP setup out also on a standard desktop Windows version and free SQL Server Express (

    After the prerequisites are met, the next step is to download and install the rest of the needed software packages:

    ODBC Driver for SQL Server

    Radiator AAA Server Software, Radiator Windows MSI installer

    After creating a new ODBC data source (be sure to select a 64-bit driver on 64-bit environments), you can test if the DSN is available to Radiator by running a small test script. Start the command shell with correct environment settings by selecting Radiator configuration from the Start menu and then clicking Perl command line. Save and run the following script on the server. The script lists all DSNs it finds, and if you see the newly created DSN, everything is OK.

    # List available data sources
    # Example run:
    # C:\> perl
    # - dbi:ODBC:<datasourcename1>
    # - dbi:ODBC:<datasourcename2>
    use strict;
    use DBI;
    my @dsns = DBI->data_sources('ODBC');
    foreach my $d (@dsns)
      print "- $d\n";

    If you want to generate TOTP secrets with you also need to install the following new modules. The command cpanm makes it easy if you're connected to the internet:

    cpanm MIME::Base32
    cpanm Imager::QRCode

    You can also download the modules manually (check for the latest versions), for example:
    and install them from local files like:

    cpanm MIME-Base32-1.303.tar.gz
    cpanm Imager-QRCode-0.035.tar.gz
    Create the database and grant the needed privileges to the user (SELECT and UPDATE). Here's the table definition with SQL Server specific field types. The definition is stripped from comments for brevity, and some fields are optional. Please see goodies for full details.
    CREATE TABLE totpkeys
      id              INT NOT NULL IDENTITY(1,1),
      active          BIT DEFAULT 0,
      created         DATETIME NOT NULL,
      accessed        DATETIME NOT NULL,
      username        VARCHAR(100) UNIQUE NOT NULL,
      tokenId         TEXT,
      pin             TEXT,
      secret          VARCHAR(130) UNIQUE NOT NULL,
      digits          INT DEFAULT 6,
      bad_logins      INT DEFAULT 0,
      last_timestep   INT,
      algorithm       TEXT NOT NULL,
      timestep        INT DEFAULT 30,
      timestep_origin INT DEFAULT 0,
      PRIMARY KEY (id)
    Insert some example data ( we use 6-digit codes for broader compatibility, and here's only some of the records):
        '3132333435363738393031323334353637383930', 6, 0, NULL, 'SHA1', 30, 0);
        6, 0, NULL, 'SHA512', 30, 0);
    INSERT INTO totpkeys VALUES (1, GETUTCDATE(), GETUTCDATE(), 'fred', NULL, 'fred',
        '1111111111111111111111111111111111111111', 6, 0, NULL, 'SHA1', 30, 0);
    Then we make modifications to the example TOTP configuration. Change the DBSource name (DSN) and credentials as needed in the <AuthBy SQLTOTP> block. Also, AuthSelect and UpdateQuery are modified with SQL Server syntax:
    <AuthBy SQLTOTP>
      DBSource    dbi:ODBC:totp
      DBUsername  totp
      DBAuth      fred
      AuthSelect SELECT secret, active, pin, digits, bad_logins, DATEDIFF(s, '1970-01-01', accessed), \
                        last_timestep, algorithm, timestep, timestep_origin FROM totpkeys WHERE username=?
      AuthSelectParam %0
      UpdateQuery UPDATE totpkeys SET accessed=GETUTCDATE(), bad_logins=?, last_timestep=? WHERE username=?
      UpdateQueryParam %0
      UpdateQueryParam %2
      UpdateQueryParam %1
    Update the configuration otherwise as needed (ie. make sure paths are correct to your setup, etc.), and set Trace 4 to see the interesting information during testing. (Re)start the Radiator server process to make sure the new configuration will be used, and then you can try your new setup. Importing the keys to your TOTP application can be done with the help of script. If you use the predefined examples, you can get the QR codes by running it like
    C:\Radiator>perl -accountname "mikem" -issuer "Organisation" \
        -algorithm SHA1 -hex_secret "3132333435363738393031323334353637383930" -digits 6 \
        -image_format gif -qrcode_file \temp\mikem.gif
    TOTP key to insert into Radiator database: 3132333435363738393031323334353637383930
    Writing QR code file \temp\mikem.gif

    You can also create new keys by leaving out the -hex_secret parameter and insert the generated hex string into the database.

    Then use your preferred method to display the generated QR code image (MS Paint or web browser are fine) and scan the key into your TOTP application. Microsoft and Google have their authenticators available for mobile devices, and Apple's mobile devices have the feature built-in. There's also a free alternative FreeOTP with an open source codebase:

    After getting your authenticator app set up you're ready for your first TOTP authentication using radpwtst on command line. Replace the password with your time-based response:

    perl radpwtst -noacct -user mikem -password 751352
    Or if static PIN is used, here PIN "fred" is prefixed to TOTP one-time-password:
    perl radpwtst -noacct -user fred -password fred755224

    If everything goes as expected you'll see the Access-Accept response on radpwtst's output, and also on the Radiator server's log. And if something fails, the log can be used to pin-point the problem.
    This example is just basic password authentication (PAP). You can now change and expand the configuration to enable more elaborate TOTP RADIUS authentication to your devices or software as needed.

    Would you like to know more?

    If you want to know more how offline TOTP can be implemented for your use case and solution with Radiator, please do not hesitate to contact us. We can always be reached via email at

    Wednesday, November 16, 2022

    Radiator team take part in RADIUS extensions working group reboot

    With the Remote Authentication Dial-In User Service (RADIUS) standard in its early 30s, it continues to be the go-to protocol for network authentication use cases. With the IETF drafting RADIUS protocol’s standard RFC 2058 in the year 1997, RADIUS has seen continuous development even though Diameter (RFC 6733) was developed to be its intended successor. Since then, RADIUS has held a strong ground in networking authentication and Diameter has become de facto standard in the TELCO field.

    RADIUS is still alive and the way to keep it current with the latest security requirements such as TLS 1.3 is by cooperation of many players in the field in joint standardisation of the protocol. Last week our technical team took part in the reboot of the RADIUS extensions working group at IETF 115 meeting in London.

    Some highlights from the proposed future agenda for standardisation are updating RFC 6614 RADIUS over TLS (RadSec) and developing RADIUS protocol and extensions further towards current security requirements: for example SRadius draft, Extended ID and Reverse Change of Authorisation over RadSec.

    What is SRadius?

    SRadius is essentially a RADIUS packet transport profile, which would mandate TLS transport and remove the previous reliance on MD5 attribute obfuscation and packet signing. This is an important change as MD5 has been proven insecure (RFC 6151) and should no longer be used. SRadius implementation would then be FIPS-140 compliant while old RADIUS is not.

    Why RADIUS should be secured with TLS?

    Even with the use of current EAP authentication methods, RADIUS accounting messages can and are still sent in plain text format. This accounting information can include sensitive information such as user location attributes, which are open to eavesdropping by man-in-the-middle attacks without any encryption in-between. RADIUS over TLS protocol (RadSec, RFC 6614) tunnels this information with TLS. Both RadSec and SRadius secure the transport with TLS.

    The working group reboot received interest and positive feedback from many stakeholders in the field working on both commercial and non-commercial RADIUS projects. There is unanimous support across the field that rebooting the RADIUS extensions working group is necessary for the future development of RADIUS. We are looking forward to working on RADIUS drafts and standards and implementing them in Radiator.

    Want to know more?