Radiator Version 4.23 released - security fixes, new features, enhancements and bug fixes

We are pleased to announce the release of Radiator version 4.23. This version contains security fixes for EAP-pwd authentication and certain TLS configurations. Other changes include new features, enhancements and bug fixes.

Selected compatibility notes, enhancements and fixes 

• Improved AcctLogFILE to support JSON. 
• Security fixes for EAP-pwd authentication and certain TLS configurations. OSC recommends all users to review OSC security advisory OSC-SEC-2019-01

Known caveats and other notes

• TLSv1.3 is not enabled by default for TLS based EAP methods.
• TLSv1.3 is not enabled by default for Stream based classes, such as RadSec.

As always, all changes and updates can be found from product history page.

Connect your organization to govroam with Radiator

Recently, we have been implementing solutions for our customers that want to join govroam. With govroam, for example UK public-sector staff can roam in Wi-Fi networks in different locations - in a similar way that eduroam works in academic sector internationally.

As Radiator has strong background in eduroam and in other federated wifi networks, our solutions are a very good fit with govroam as well. We already have good experiences working, for example, with NHS organizations in the UK.

In couple of recent cases, Radiator provides the govroam compliant solution for user authentication and proxying. With Radiator, this has solved a a challenge for customers especially when using Windows AD / Windows NPS in their environment. While working with these cases, we have tailored couple of solutions that helps the organizations to be compliant with govroam specifications.

Also, Radiator can be run on Windows and Linux platforms, and in the cloud as well. In govroam cases, installations have been made to many different environments.

What Radiator Software offers

In our govroam use cases, we have developed two solutions for different types of organizations. The packs include both Radiator licenses as well as the support service for Radiator products:

• Radiator Govroam Federation Support Pack
• Solution for organisations that want to create a regional root service that is connected to govroam
• Radiator Govroam Support Pack
• Solution for individual organisations that will connect to regional root service connected to govroam. In this solution, Radiator is used as a RADIUS proxy providing the needed configuration in order to comply to govroam specifications.

For more info, please contact our sales team at sales@radiatorsoftware.com . We are happy to have a call about your govroam needs in order to provide a suitable solution for your own organization.

Migrating to new Radiator packages

New package formats

Radiator 4.22 is our first release that comes with Windows MSI package and Linux packages for Red Hat Enterprise Linux 7, CentOS 7, Ubuntu 18.04 and 16.04, and Debian 9. The old package formats, tar, zip and generic RPM, are also available. Our plan is to relabel the generic RPM package to legacy RPM and depreate it in favour of distribution specific RPMs.

See our earlier posts for more about new Linux and Windows packages. The topics below refer these posts for background information.

Before going to the topics below, here's what is common with each migration case. See the posts mentioned above for more details:

• Your current Radiator configuration requires no large changes
• Log directory is a prime example of packaging and startup related configuration file option that likely needs an update
• New packages automatically configure Radiator to start at system boot. You may need to remove or disable what you currently use for starting Radiator

 Upgrading from old package format on Windows

Radiator MSI package comes with its own Strawberry Perl. As described in the aforementioned post, Radiator MSI package is designed to be self-contained. This also means that if you already have Radiator installed from a non-MSI package, you can switch to MSI without uninstalling your current Radiator.

We recommend making a copy of your current configuration before installation and checking that old Radiator installation is disabled or removed in Windows services after MSI installation. The blog post mentioned above has a wealth of information about MSI installation and post installation tasks.

Upgrading from generic RPM on Linux

Before starting an upgrade to new el7 RPM, review the Linux post from above to see what updates your current configuration requires. Most likely log directory needs to be updated, but also note the other changes, such as, new configuration file name, and system user and group radiator that are now used to run radiusd.

RPM packages for el7 replace generic RPM, which means you do not have to remove it before installing RPM for el7. We recommend making a backup of your configuration files, dictionaries and edited startup scripts and systemd service files. Although RPM package management tool renames edited files with rpmsave extension when upgrading from generic RPM, backups are recommended.

After the upgrade check that old startup scripts are disabled and Radiator is started with new systemd based unit file. It should run as radiator. See that logging and logrotate work as required.

Upgrading from tar or zip to RPM or deb

When Radiator is installed from RPM or deb package, old tar or zip based installation is not removed. Both RPM and deb packages prefer Radiator files from /opt/radiator directory, but you could consider locating old Radiator files installed from zip or tar package and removing them after the upgrade.

Because zip or tar based installation does not create any system user or group, log directories or require any other settings that come with new el7 RPM and deb packages, you need to review and updated your current Radiator configuration. See the Linux packaging blog post mentioned above for the details of paths, users and other information.

Also note that you need to manually disable old startup scripts. After the upgrade check that Radiator is started with new systemd based unit file. It should run as radiator. See that logging and logrotate work as required.

Radiator SIM support 2.4 released

We are pleased to announce release 2.4 of Radiator SIM support. This release includes support for SCTP multihoming and has a number of smaller enhancements and bug fixes.

Revision 2.4 detailed updates and fixes

• 3GPPAutHSS now supports Peer-Auth-Application-Id as DiaPeerDef selector. Requires Carrier module 1.5 or later and Radiator 4.20 or later.
• Added configuration parameter HSSRealm to 3GPPAuthHSS. This value for this parameter is typically the realm where HSS resides. If not set, messages’ realm is set from DestinationRealm parameter of DiaPeerDef used to forwarding messages to the HSS. Defaults to not set.
• Subscription-Id AVP is now added to SWm DEA messages to relay MSISDN to ePDG.
• Updated EAP-SIM, EAP-AKA and EAP-AKA’ permanent, pseudonym (TMSI) and fast re-authentication identity leading characters to match RFC 4186, 4187 and 5448, and 3GPP TS 23.003 suggestions and requirements. Because of historical reasons, EAP-SIM fast re-authentication and EAP-AKA TMSI leading characters were swapped. EAP-AKA’ non-permanent identifiers are now fully separate from the respective EAP-AKA identifiers.
• Removed obsolete configuration parameters TestNoMAP and GetReauthQueryEAP. Support for TestClient and TestVectorFile were removed from AuthAKA.pm and related files because they are obsolete. Use AuthAKATEST or ServerWXMAP based configurations for testing.
• A number of code clean up and maintenance changes were done based on Perl::Critic and other tools.
• SCTP multihoming is now supported. Requires Radiator 4.22 and Radiator Radius::UtilXS package.

Also, for more information, please do not hesitate to contact us at info@radiatorsoftware.com . See also Radiator SIM Pack product page.

Radiator Carrier Pack revision 1.5 released!

We are pleased to announce that Radiator Carrier revision 1.5 has been released. The many upgrades and enhancements in the new revision provide even better support for different carrier infrastructures than before.

Detailed changes and upgrades in revision 1.5

• Added StreamServerUnix which allows to use UNIX domain sockets to connect to Radiator process. Integrator.pm in goodies shows an example how to create an integration interface which uses StreamServerUnix.
• Updated ServerDIAMETERTelco and DiaPeerDef to fully support TLS_* configuration parameters.
• DiaPeerDef now supports ReconnectTimeout parameter.
• AuthBy DiaRelay now supports newly added DiaPeerDef selector Peer-Auth-Application-Id which allows selecting next hop Diameter peer based on the Auth-Application-Id advertised in the peer's CER or CEA. Requires Radiator 4.20 or later.
• ReconnectTimeout and TLS support in DiaPeerDef requires Radiator 4.21 or later.
• DiaPeerDef and ServerDiameterTelco now support SCTP multihoming when Radius::SCTP bindings for libsctp are available. Multiple local IP addresses are bound when BindAddress or LocalAddress are configured for ServerDIAMETERTelco or DiaPeerDef, respectively. DiaPeerDef now accepts one or more SCTPPeer configuration parameter for connecting to multiple destination IP addresses. Requires Radiator 4.22 and Radiator Radius::UtilXS package.
• A number of code clean up and maintenance changes were done based on Perl::Critic and other tools.
• Information about Diameter connection establishment, termination and DiaPeer selection is now logged on INFO level.

Now available as new Linux packages

Similar to Radiator 4.22, Radiator Carrier Pack is now available as packages suitable for Red Hat, CentOS and Ubuntu. These packages are based on the best practices we have used in our deployments and they comply with the current Linux distribution packaging practices. For more info regarding the new Radiator packages, please see our recent blog. 

These new packages are now available at:

https://radiatorsoftware.com/products/radiator-carrier-pack/downloads/ 

As these are new packages, we are interested in any feedback you may have on the package design and installation. If you have any ideas, suggestions, feedback or questions of the new  packages, please do send them via this package feedback form or via email to support (a) radiatorsoftware.com.

Radiator Carrier Pack is now known as Radiator Service Provider Pack.