Radiator for Libraries - Enable connection for patrons without extra provisioning

In recent years, libraries have evolved from venues where people come to pick up books into community places for people to read, study, work and much more. As most of these activities require reliable internet access, there is no denying that providing stable connectivity is becoming a requirement for modern libraries.

Hence why more and more libraries are looking at efficient and secure ways to enable connectivity for their patrons, while ensuring that that connection is not used for malicious business. Having an open Wi-Fi broadcasted across the library facilities is not the way to, and provisioning separate credentials for internet connection for all users visiting the library is a big hassle.

Radiator has got you covered. Radiator AAA server seamlessly integrates with existing Library management system (LMS, also known as Integrated library system, ILS) providing patrons connectivity utilising the credentials from LMS, used for lending books.

How does it work?

The key to library Wi-Fi authentication with Radiator lies on 3M™ Standard Interchange Protocol 2.0, known as the SIP2 protocol. The SIP2 protocol provides an interface between a library’s management system and library automation devices. This is the same protocol used for automated self-check devices for loaning and returning library books, and the parameters that can be used for self-lending can also be used for Wi-Fi access.

Radiator authenticates patrons based on their existing patron credential, for example library card number and PIN code. This means libraries do not need to provision and store separate Wi-Fi credentials for patrons. The basic version of this configuration is very simple and Radiator’s scripts handle the communication with the library system. Essentially, in the library system’s view, Radiator is a self-service loaning device among the others.

This integration also enables further functionality. Radiator can be configured to do that if the patron has outstanding fines or fees that exceed an agreed threshold, their Wi-Fi access will be declined upon login. This is done by Radiator’s scripts and is a toggleable option within the Radiator configuration file. The access can be tied to patron status or other patron information, for example age restriction can be applied.

Swift commercial process, flexible testing

Radiator is priced based on the number of servers, which makes a single library deployment very cost-effective. Radiator’s flexible evaluation licences allow you to set up a test system and see the solution working before making any commitments.

If you are interested in deploying a secure, robust and affordable solution for your library connectivity, please contact our sales team at sales@radiatorsoftware.com

Wifi Offloading POC with Radiator

 Recently, we have seen a significant increase in demand for our Wifi Offloading solutions and services. Many mobile operators are aiming for increased use of their own existing wifi infrastructure or the use of wifi infrastructure provided by 3rd party partners. This is done in many cases to expand especially indoor coverage in areas where 5G infrastructure has its limitations.

With Radiator, the essential product is Radiator SIM Pack that provides the integration between key components in wifi network and mobile core for WiFi Offloading. In this blog, we are clarifying how this kind of concept can be easily evaluated in different networks - as we are currently engaged heavily in these kinds of projects.

How Wifi Offloading Proof of Concept can be implemented?

For this kind of Wifi Offloading Proof of Concept (POC), a small number of steps are needed.

1. Firstly, you will need access to relevant wifi controllers / access gateways, in order to configure the RADIUS traffic to be configured towards Radiator SIM Pack. With this, seamless SIM authentication (with EAP-SIM/EAP-AKA/EAP-AKA’ for example) can be implemented.

2. As a next step, you will need to install the evaluation version from relevant Radiator packages: Radiator AAA Server Software, Radiator Carrier Module and Radiator SIM Module, along with the UtilXS component. The packages exist for all recent versions of RedHat based systems, Ubuntu and Debian.

3. After the installation, our team will provide you with the necessary configuration in order to configure traffic towards your subscriber data source. For HSS, Diameter SWx interface is the standard. Radiator can also use Diameter S6d, Cx or Wx interfaces. When using HLR, Radiator connects with GSM MAP with SIGTRAN. If the subscriber data is stored in more than one location, Radiator can authenticate SIMs from multiple backends. SIM authentication uses IMSI, and Radiator can optionally fetch user MSISDN (phone number) for billing purposes. 

4. Lastly, you will need to have access to the carrier profiles for the mobile phones or other end user devices so that automatic wifi authentication can be done. The methods for this differ a bit with Android and iOS devices: for Android, there are developer tools available for your own testing. For iOS, you need assistance from Apple. For both cases, we are happy to provide assistance.

As can be seen, successful WiFi Offload POC requires a bit of cooperation internally in the organization of the mobile operator. However, at the same time the needed configuration is typically something that can be done with limited effort - and with the assistance from us. As we have already deployed tens of successful WiFi offloading and VoWiFi installations, most challenges (and how to overcome them) are familiar to us.

What are the next steps?

If you are interested in WiFi offloading, please do not hesitate to contact us. Please fill out our contact form or contact sales@radiatorsoftware.com, and we are happy to help you with the next steps.

Meet Radiator team at IETF121 in Dublin

Image credit: Bob Linsdell, O'Connell Bridge & River Liffey, Dublin

The Radiator team will be attending IETF 121 meeting at the Convention Centre Dublin 2 - 8 November 2024. 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 catching up with industry people. 

IETF RADIUS working groups 

You can find the Radiator team at these sessions - click the links for the respective meeting materials and agendas. 

• IETF Hackathon on Saturday 
• RADIUS EXTensions (radextra) 
• EAP Method Update (emu) 
• Transport Layer Security (tls) 
• Security Area Open Meeting (saag) 

For other IETF sessions, please see full meeting agenda here: https://datatracker.ietf.org/meeting/121/agenda 

Meet the team 

You can find Radiator developer Heikki Vatiainen and managing director Karri Huhtanen at the working group sessions and around the venue. If you’re in Dublin, come find us and say hi! Everyone else interested in the Radiator roadmap or meeting recaps, please drop us an email.

Radiator Software and Altice Labs announce partnership

Altice Labs, a technology company that is at the forefront of global innovative solutions in telecommunications, networks, and digital services, alongside Radiator Software, a Finnish company which provides AAA (RADIUS/Diameter Authentication, Authorization and Accounting) software products and services for Service Providers and Enterprises, announced a partnership enabling both organizations to jointly deliver end-to-end solutions to Service Providers and Enterprises.

This partnership will allow Altice Labs and Radiator Software to combine efforts to improve efficiency by eliminating barriers and accelerating delivery, thereby enhancing the value of products and solutions for both organizations. One of the key use cases that Radiator Software and Altice Labs can provide together includes WiFi offload and Voice-over-WiFi solutions, among others.

Jaakko Stenhäll, Director of Business Development at Radiator Software, highlighted that, “with Altice Labs, we are able to complement our Radiator AAA offering with excellent technical knowledge on different customer needs and also world-class support on various markets - bringing great value to our mutual customers”.

Tiago Pereira, Director of Global Business Development at Altice Labs, commented, “we are looking forward to partnering with Radiator Software, bringing our extensive experience, knowledge and technical expertise on network and service management and control. This is an area where Altice Labs has been present for more than 20 years, with its own products and solutions”.

For Cleverson Novo, Managing Director of Open Labs - Altice Labs branch in Brazil, “this area has gained huge importance in the Latin America market, with Service Providers leveraging their Wi-Fi networks as a complement to traditional cellular networks“.

Together, both companies are paving the way to the future, exploring new marketing opportunities and business growth.

Meet Radiator at WGC EMEA & Network X in Paris!

We are delighted to announce that Radiator Software will be attending the two top connectivity events of the season: WGC EMEA and Network X, co-located in Paris on 7 – 10 October 2024. We are looking forward to meeting our current and prospective partners and customers in Paris.

Wireless Global Congress Americas

WGC is hosted by the Wireless Broadband Alliance and gathers together Wi-Fi industry leaders and experts from all around the world. As usual, the event is divided into two parts: WBA Members-Only Sessions on 7 and 8 October at the Hôtel Mercure Paris Porte de Versailles Expo, followed by the WGC EMEA Open Congress on 9 and 10 October in Porte de Versailles conference centre.

https://www.wirelessglobalcongress.com/emea-2024/

Network X

Network X event runs through 8 - 10 October and brings together Broadband World Forum, 5G World and Telco Cloud. For service providers of all kinds, Radiator provides a flexible AAA solution for fixed broadband, wireless, and WiFi offloading including VoWiFi.

For more information about the Network X event, please see the official website: https://networkxevent.com/

Meet with Radiator team

You can find the Radiator team at the WBA Members-Only Sessions and in the WGC Open Congress throughout the event. For insights on Wi-Fi authentication, Wi-Fi roaming and OpenRoaming, we extend an invitation to all WGC EMEA and Network X attendees to meet with the Radiator team and managing director Karri Huhtanen.

To book a meeting or simply ask a question, please leave a message and we will get back to you. See you in Paris!

Chargeable User Identity - Billing and analytics with privacy

As mobile and wireless networks have evolved, the ability for users to move between different networks while maintaining service, known as roaming, has become essential. WiFi roaming, while convenient for users, introduces several complexities for service providers, particularly in managing billing and user identity securely across network boundaries.

The Chargeable User Identity (CUI) parameter was introduced to address these challenges. While the specification RFC 4372 for CUI has existed for quite awhile, the implementations are now popularising as commercial Wi-Fi is becoming more sought after.

Chargeable User Identity uses and benefits

Chargeable user identity is a parameter used mostly by service providers to identify users for accounting in roaming networks, while ensuring their privacy is not compromised with trackable credentials. The CUI allows service providers to charge users based on their usage, even when users roam across different networks. It is primarily intended for billing purposes, but also provides other benefits to both public and commercial networks.

The main benefit of using Chargeable User Identity parameter is that it solves the business problem of anonymity in commercial networks, while not making any compromises in privacy and security. It provides a robust mechanism for calculating usage, which can be used not only for billing but also analytics purposes. For example, with CUI, roaming network providers can track whether their 100 sessions come from 10 users with 10 sessions each or by 2 users with 50 sessions each. This allows for more accurate analytics, but does not allow the networks to identify the users. This is possible in deployments where the CUI is the same across all of the user’s devices.

The use of Chargeable User Identity also allows public institutions to restrict and ban roaming users who violate their terms. Previously, when administrators decided to take action against users who violate their visiting terms, the user can simply log on with another device. With a CUI parameter that is mutual across user’s all devices, this is not possible.

Chargeable User Identity deployment

Chargeable User Identity is transmitted in RADIUS packets using dedicated RADIUS attribute 89: Chargeable-User-Identity. The implementation is specified in RFC 4372.

Upon sending the authentication Access-Request to the home organisation for a roaming user’s authentication, the visiting organisation should add the Chargeable-User-Identity parameter into the request with a null value. This signals the home organisation that a CUI is requested. The home organisation check’s for an existing valid CUI and sends either a new or existing valid CUI included in the Access-Accept.

The Chargeable-User-Identity parameter will remain the same for the duration of the roaming user’s session and is included in the accounting packets and responses.

Want to know more?

Are you looking to deploy Wi-Fi offloading or other Wi-Fi roaming functionality for your customers or members of your organisation? Or are you setting up a commercial Wi-Fi infrastructure to provide roaming services for operators? For both cases, Radiator AAA is the product for you.

Radiator AAA provides functionality for Wi-Fi roaming host organisations, with dozens of completed deployments for the biggest Wi-Fi roaming networks (eduroam, govroam, OpenRoaming). Combined with the Radiator SIM Pack, Radiator provides seamless authentication for Wi-Fi offloading, roaming between mobile networks and Wi-Fi. Both products and use cases include Chargeable User Identity function for Radiator.

For more information about CUI deployments, please contact our sales team at sales@radiatorsoftware.com

Why 5G drives Wi-Fi offloading for operators?

Latest reports from the industry indicate that globally 5G subscriptions are closing in on 20% of all mobile subscriptions. Mobile operators are deploying 5G networks at an increasing rate and 5G is at an early stage of its life cycle. Global data usage increases year by year and mobile operators’ cellular networks are hard-pressed to withstand all the traffic, requiring investment in more infrastructure.

5G provides higher data rates and other benefits compared to the previous generations, but at the cost of lower signal range. Strong 5G signal for proper coverage requires operators investment in small cell networks and even with one customers might struggle with in-door service quality. At the same time, there are commercial and other WiFi network infrastructure already in place for many of the areas where operators struggle with in-door coverage.

In this blog post, we’ll take a look at underlying reasons driving the demand for Wi-Fi offloading, and how Radiator SIM Pack solution provides the seamless authentication to enable it. In short, with the performance and reliability that Wi-Fi 6 and 7 have brought to the table, it is easy to see the economical and environmental benefits Wi-Fi offloading brings to those who adopt it, all while improving end users’ coverage and quality of service indoors without need for massive infrastructure investments.

Solve coverage issues with existing infrastructure

Even before 5G, operators were struggling with in-door coverage of cellular networks. Upgrading to 5G will not improve the coverage, but rather do the exact opposite. 5G utilises higher signal frequency millimetre waves, which are unable to penetrate obstructions and have short range. This is becoming a key concern when designing 5G networks in congested areas. However, building a network of small cells to reach proper coverage in-doors is fast becoming a challenge for operators in urban areas.

Wi-Fi offloading can significantly enhance coverage and quality of service for network operators by leveraging the ubiquitous presence of Wi-Fi networks to alleviate congestion on cellular networks. By directing data traffic from overloaded cellular networks to available Wi-Fi connections, operators can effectively extend coverage into areas with weak cellular signal and manage high-demand scenarios, such as large public venues. Wi-Fi offloading not only optimises the utilisation of network resources but additionally offloading traffic to Wi-Fi can help operators reduce network congestion and associated operational costs, making it a win-win solution for both service providers and their customers.

As an added benefit for the end user, According to Wireless Broadband Association, smartphones and IoT devices using Wi-Fi 6 have an up to 67% lower power consumption compared to their respective cellular networks. This energy efficiency will be further enhanced with Wi-Fi 7. This does not directly affect the operator, but enhances the end users’ service quality.

Wi-Fi has gotten better. Much better.

This point is not specific to 5G, but rather for all operators who have previously considered Wi-Fi offloading and found Wi-Fi to have high latency, unreliable connections and low data rate, not matching the standard operators want for their networks. This may have been the case once, but not anymore.

Wi-Fi 6, 6E and especially Wi-Fi 7 have brought down latency (below 5ms on most estimations), increased data rate tremendously (up to 46 Gbps) and made connections much more reliable. And as discussed previously, Wi-Fi networks are built with coverage in mind, bringing offloading users optimal quality of service even in areas with dozens of devices online.

Another concern our MNO customers have expressed from time to time is that Wi-Fi security is not up to par with mobile networks. Today’s Wi-Fi offloading solutions use EAP-AKA and EAP-AKA’ authentication, which provides vast improvements to older protocols. IMSI Privacy and standards in MAC address randomisation should be in place in a modern Wi-Fi offloading solution, with which end users details remain private and can not be snooped. Security and privacy concerns are a thing of the past for operators who want to adopt Wi-Fi offloading, so long as the operator chooses a solution that provides these features.

5G and Wi-Fi 7: Better together

We’ve seen many industry blogs and articles discuss the differences of 5G and Wi-Fi, often comparing them as rivals and recommending customers choose one or the other based on their needs. This need not be the case. As leading operators have demonstrated, these networks are not at odds, but rather better utilised together.

Wi-Fi offloading can solve operators’ problem of coverage in congested areas, particularly in-doors and in large venues with high volumes of data traffic. These areas often have Wi-Fi infrastructure in place which operators can utilise, lessening the need for investment in small cell networks.

As an improvement to previous mobile network generations, Wi-Fi offloading has been clearly specified as part of 5G architecture in 3GPP standards (3GPP TS 33.501; Annex S). When viewed as part of the architecture with dedicated authentication interface, rather than a case-by-case solution, Wi-Fi offloading is becoming a more integral part of operators’ connectivity stack.

Looking to deploy Wi-Fi offloading in your network?

Are you looking to adopt Wi-Fi offloading to your cellular network? Radiator SIM Pack is the product for you! Radiator SIM Pack provides seamless authentication for mobile users roaming between cellular and wireless networks.

Radiator SIM Pack provides SIM-based authentication (EAP-SIM, EAP-AKA, EAP-AKA’) with IMSI Privacy and a variety of different integration options for Diameter interfaces and for logging. Often combined with the Radiator Policy and Charging Pack for OCS billing integration, these products provide a one stop shop for operators looking to adopt seamless Wi-Fi offloading for their mobile customers.

If you wish to learn more about our Wi-Fi offloading deployments, please do not hesitate to contact sales@radiatorsoftware.com

Radiator 4.29 released!

We are pleased to announce the release of Radiator version 4.29. The latest release includes a major Radius protocol security fix, and the usual usability and interoperability improvements and bug fixes.

New usability improvements

Tested and supported for Ubuntu 24.04

AuthBy LDAP2 improvements

CEF and JSON logging fixes

Updates to address BlastRADIUS protocol vulnerability

Radiator is actively engaged with IETF’s radext working group and we have been working under embargo to implement the fixes based on the work done in the group.

Add a new flag parameter LimitProxyState to Client clauses. This parameter allows dropping those requests from non-proxy clients that contain Proxy-State but do not contain Message-Authenticator. Ensure that ServeRADSEC drops requests with bad Message-Authenticator instead of just logging them. The upcoming Radius transport update by IETF's radext working group will remove the redundant signatures but keep them for the current transport profile. LimitProxyState addresses CVE-2024-3596.

Update RADIUS Message-Authenticator attribute handling. Message-Authenticator is always added as the first attribute in Radius messages. Message-Authenticator is now added automatically to replies to Access-Request messages and to Access-Request messages when they are proxied.

RequireMessageAuthenticator is now available for AuthBy RADIUS and its subclasses. It can be set for all hosts in an AuthBy or host-by-host basis. This parameter requires a valid Message-Authenticator in proxy replies.

A new configuration flag -no_message_authenticator is available in radpwtst to skip Message-Authenticator in Access-Requests.

Please see the security notice for more information on CVE-2024-3596 and our security recommendations.

New attributes ensuring interoperability

Vendor specific attributes updated in the Radiator dictionary for Arista, Dell, ELTEK, Force10, Mojo, and Teldat.

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?

As always, you can contact Radiator team at info(a)radiatorsoftware.com - we are happy to learn more about your use case and assist you!

Security Notice: BlastRADIUS protocol vulnerability (CVE-2024-3596) fixed in Radiator v4.29

In February 2024 University of California San Diego researchers and their partners reported a vulnerability discovered in the RADIUS protocol to the CERT and IETF. The RADIUS protocol vulnerability was later named BlastRADIUS. The vulnerability allows the attacker to alter RADIUS messages between the RADIUS server and client so that for example a rejected authentication can be turned into accepted authentication. Utilising the vulnerability requires that the attacker is able replace the original requests and replies between RADIUS client and server with the attacker’s content. Only the RADIUS messages, which do not contain message authenticator, or where the RADIUS client or server is not verifying message authenticator properly, are vulnerable.

Radiator Software has been working since February together with the researchers and other RADIUS server implementers to implement the identified fixes for RADIUS protocol in Radiator. This work and fixes have been under embargo until July 9th 2024 12:00am UTC. The fixes for RADIUS protocol have been implemented in the Radiator v4.29 released now after the embargo has ended.

Affected Radiator versions

Since this is a recently discovered RADIUS protocol vulnerability, all Radiator versions up until version 4.29 are affected.

Affected Radiator configurations and deployments

The RADIUS server deployments, which send and receive RADIUS requests without message authenticator or RadSec (RADIUS over TLS) over untrusted networks, are the most vulnerable for abuse. Enterprise Wi-Fi (EAP) authentication is using message authenticator in all messages by default so in those networks, the effect of the vulnerability depends if the RADIUS client implementation (e.g. in a Wi-Fi controller) is verifying the message authenticator properly. In addition to the RADIUS server updates, also RADIUS clients and client software may need to be updated.

As Radiator implements the RADIUS protocol all Radiator configurations and deployments using RADIUS protocol without requiring Message Authenticator or RadSec (RADIUS over TLS) are affected by this vulnerability.

Mitigation

Radiator Software strongly recommends upgrading Radiator to the latest version to get all the improvements and fixes to the vulnerability. In addition to upgrading Radiator, the Message-Authenticator requirement instructions should also be followed.

Configuring Message-Authenticator requirement

Requiring Message-Authenticator from RADIUS clients

Radiator version 4.10 (2012) or newer can be configured to require a Message-Authenticator from a RADIUS client by adding RequireMessageAuthenticator to the Client configuration. For example:

<Client 192.0.2.42>
     Identifier CLIENT-IPV4-192.0.2.42
     Secret 6m9TXQTjLdH5BbgT
     RequireMessageAuthenticator
</Client>

Please note that configuring RequireMessageAuthenticator will require the Message-Authenticator to be present in the request and does not accept requests without it.

A legacy RADIUS client, which is not able, or configured, to send Message-Authenticator is not able to connect with Radiator after this requirement. The RADIUS client should be configured to send Message-Authenticator in its requests and require Message-Authenticator in the replies. If only Radiator is configured to use Message-Authenticator but RADIUS client does not require it, an attacker can drop the Message-Authenticator from the reply to Access-Request and modify the contents of the reply.

By default Radiator proxies and responds with Message-Authenticator to all messages with Message-Authenticator already present in them, but accepts also requests without the Message-Authenticator for compatibility and interoperability reasons.

If your configuration uses SQL database to specify clients in addition to (or instead of) the Radiator configuration by utilising the ClientListSQL, please see ClientListSQL part of Radiator AAA reference manual. See documentation subsections GetClientQuery and ClientColumnDef for more detailed instructions.

Requiring Message-Authenticator from RADIUS proxies or servers

Radiator v4.29 (2024) adds RequireMessageAuthenticator configuration directive for RADIUS based AuthBys such as AuthBy RADIUS, ROUNDROBIN and HASHBALANCE. With RequireMessageAuthenticator enabled, the AuthBy only accepts requests with Message-Authenticator in the RADIUS replies. Radiator by default adds Message-Authenticator to outgoing messages.

<AuthBy RADIUS>
     Identifier AUTHBY-RADIUS-PROXIES
     Secret 9iLeKAnBP8e8oMhb
     Asynchronous
     Retries 1
     RetryTimeout 3
     FailureBackoffTime 5
     # Requires Message-Authenticator from all RADIUS proxies/servers in this AuthBy
     RequireMessageAuthenticator
     <Host 192.0.2.111>
          # RequireMessageAuthenticator can also be required per host
          #RequireMessageAuthenticator
          AuthPort 1812
          AcctPort 1813
     </Host<
     <Host 192.0.2.112>
          # RequireMessageAuthenticator can also be required per host
          #RequireMessageAuthenticator
          AuthPort 1812
          AcctPort 1813
     </Host>       
</AuthBy>

Requiring Message-Authenticator in requests with Proxy-State attribute

Radiator v4.29 introduces an additional configuration directive, LimitProxyState, which can be added to NAS RADIUS client definitions to require a valid Message-Authenticator in all requests, which contain the Proxy-State attribute used in the BlastRADIUS attack. This allows requests without Message-Authenticator (e.g. RADIUS client does not support it) to be received, but prevents the BlastRADIUS attack by not accepting requests with Proxy-State included in them. This configuration directive should only be used for NAS RADIUS clients, e.g network equipment such as switches, Wi-Fi controllers etc. It should not be used for clients, which are RADIUS servers or proxies. An example of the configuration is below:

<Client 192.0.2.42>
     Identifier CLIENT-IPV4-192.0.2.42
     Secret 6m9TXQTjLdH5BbgT
     LimitProxyState
</Client>

Please note that RequireMessageAuthenticator should not be set together with LimitProxyState because RequireMessageAuthenticator will prevent requests without Message-Authenticator altogether. LimitProxyState is intended for use cases where client can not be configured to send Message-Authenticator.

If your configuration uses SQL database to specify clients in addition to (or instead of) the Radiator configuration by utilising the ClientListSQL, please see ClientListSQL part of Radiator AAA reference manual. See documentation subsections GetClientQuery and ClientColumnDef for more detailed instructions.

Limiting unencrypted RADIUS use only to management networks

To utilise the vulnerability the attacker needs to get in between RADIUS servers or between RADIUS server and RADIUS client. Separating unencrypted RADIUS traffic into a management network and reducing the routing distance between the server and clients makes it more difficult to perform the actual attack.

Unencrypted RADIUS over public networks exposes the RADIUS requests for the well-resourced attackers to abuse and should be avoided.

Securing RADIUS messages with TLS or VPN

The BlastRADIUS attack only works on unencrypted RADIUS traffic over UDP or TCP. The RADIUS traffic can already be secured with RADIUS over TLS (RadSec, RFC 6614) or with VPN solutions if RadSec support is not available.

Radiator is the first RADIUS server ever (v3.12, 2005) to implement RADIUS over TLS neve(RadSec, RFC 6614), which was an IETF draft originally developed in cooperation between eduroam and Radiator implementers. Radiator Software continues to participate in developing the RADIUS over TLS specification in the IETF as well as implementing the latest features into the Radiator itself.

Radiator Software strongly recommends migrating from unencrypted RADIUS to RADIUS over TLS. While requiring Message-Authenticator from RADIUS client and servers mitigates the vulnerability, the effort needed to configure these and test the changes, clients and servers for interoperability may be greater than configuring and deploying RADIUS over TLS to secure both the protocol and privacy of the information transferred in RADIUS request attributes.

Questions and answers

Is my multi-factor authentication (MFA/2FA) affected?

If your multi-factor authentication is using RADIUS, it is likely to be affected. The exposure for the vulnerability depends on the RADIUS clients, servers and the attacker’s access to the network in between them. If your systems are for example doing MFA authentication with unencrypted RADIUS over the public Internet to a multi-factor authentication service provider your authentication is exposed and vulnerable. Is my enterprise Wi-Fi (WPA2/WPA3 Enterprise) affected?

No. Enterprise Wi-Fi utilises EAP authentication over RADIUS. The EAP authentication already mandates Message-Authenticator in all requests.

Is eduroam or OpenRoaming affected?

No. Both eduroam and OpenRoaming are utilising EAP authentication like enterprise Wi-Fi (WPA2/WPA3) networks. OpenRoaming additionally mandates RadSec (RADIUS over TLS) and it is also supported in eduroam.

Is my VPN solution affected?

Similarly as with multi-factor authentication if your VPN endpoint is using unencrypted RADIUS for authenticating the VPN connection credentials from the RADIUS server or service, this vulnerability could be used in the worst case to allow an attacker to get a successful VPN connection to your network. Those VPN solutions which are using EAP authentication with RADIUS servers are not affected.

Is roam.fi roaming service affected?

The roam.fi roaming service is similar to eduroam and OpenRoaming utilising Enterprise Wi-Fi EAP authentication so it is not affected. Additionally roam.fi roaming service also supports RadSec (RADIUS over TLS) and it is strongly recommended that the roam.fi member organisations would migrate in using RadSec, when they have the RadSec connection capability themselves. The service will be updated to utilise Radiator v4.29 as soon as it becomes generally available.

Is Radiator Auth.Fi RADIUS as a service affected?

The Radiator Auth.Fi EAP authentication including both username-password and client certificate authentication is not affected.

The captive portal and MAC address authentication used for guest network functionality is affected if unencrypted RADIUS connections are used. The Radiator Auth.Fi already supports RadSec client connections for securing the RADIUS traffic and it is strongly recommended that customers who have the ability to use RadSec, will switch to using RadSec instead of unencrypted RADIUS.

The Radiator Auth.Fi Radiator will also be updated to utilise Radiator v4.29 as soon as it is released and that will enable additional options for adjusting Message-Authenticator settings for unencrypted RADIUS.

Is my ISP, fixed line subscriber configuration provisioning or IP address allocation RADIUS solution affected?

As these solutions are usually based on unencrypted RADIUS they are affected, but usually the RADIUS traffic is in these cases separated into management networks. If an attacker has access to a management network, the attacker is more likely to focus on more interesting targets than fabricating RADIUS requests and replies. The mitigation options work also in these networks, but extra attention should be given to testing, because the mitigation requires interoperable functionality from both RADIUS servers and clients.

How can I update Radiator?

If you have an active support contract for Radiator, you can get Radiator updates including the new Radiator v4.29 release from the Radiator download and repository page at https://radiatorsoftware.com/downloads/. If you are not sure or have an older license without a support contract, please contact sales@radiatorsoftware.com to renew your support.

Is my RADIUS configuration affected?

Radiator Software email support is able to answer questions and support you in case you want to evaluate the vulnerability’s effect on your deployment and use case. If you have active support, you can contact Radiator support at support@radiatorsoftware.com. If you are not sure or have an older license without a support contract or want to engage in larger scale configuration evaluation or upgrade, please contact sales@radiatorsoftware.com to renew your support or discuss the scope for Radiator expert services.

For more information about the vulnerability

BlastRADIUS WWW site: https://www.blastradius.fail/

BlastRADIUS paper: https://www.blastradius.fail/pdf/radius.pdf

CERT CVE: https://www.cve.org/CVERecord?id=CVE-2024-3596

CERT Coordination Center: https://kb.cert.org/vuls/id/456537 (vendor status for vulnerability fixes)

Radiator revision history (v4.29): https://radiatorsoftware.com/products/radiator/history/

How to speed up RADIUS authentication processing during peak hours with Radiator

From time to time, our customers reach out to us and ask guidance on how to speed up RADIUS authentication processing during peak hours. Performance of this core functionality of Radiator is stable and predictable, and with increasing traffic load, most of the bottlenecks often emerge from the performance of the backend services that Radiator is utilising. In this blog, we give some helpful information to make improvements.

What causes bottlenecks?

In many cases,  authentication backends that Radiator is configured to use may be too slow to process the number of requests that are arriving. For example SQL databases may be slow to respond, LDAP lookups can take time, or HTTP requests be delayed. Writing accounting data or logging to a slow database can slow down Radiator.

When this happens, the host system's UDP traffic buffer on the listening port fills up to the point that it overflows and new RADIUS request packets arriving at the server get dropped. Because the requests are dropped by the host operating system, they cannot even be logged as failed requests by Radiator.

To get a better understanding of what is happening during peak hours, set `Trace 4` debug log level with `LogMicroseconds` in the configuration file (see [How to enable debug logging?]. The debug log will show how long each processing step is taking, and from there you can determine how many requests per second the configuration can handle.

How to tune Radiator to speed up authentication processing?

There are several ways to tune Radiator to speed up processing:

• Split configuration into two separate files, one for authentication and one for accounting, and run Radiator as two separate running instances. This way there are two processes handling traffic with their own UDP buffers and backend dependencies that may even out the congestion. On Linux systems with systemd there are mechanisms readily available to help with that. More information: [How do I manage Radiator instances on a single host?].
• Use a proxy instance to forward authentication and/or accounting requests to multiple worker instances (see first bullet). The requests can be spread out to worker instances so that request state is preserved (see [methods for load distribution and balancing] in documentation).
• Within instances, use [FarmSize] to create a farm of server processes to add parallel processing of requests. Note: This is not compatible with many EAP protocols, such as EAP-TLS, EAP-TTLS, PEAP etc. This is because such protocols rely on authentication state being held within each server process, and it is necessary for all the requests for such protocols to go to the same Radiator process.
• Incoming requests can be distributed from one or two proxying or load-balancing hosts to multiple hosts for processing.
• Depending on use case, any combination of FarmSize, multiple instances per host and multiple hosts can be used together to enable more throughput. Separating processing on the Radiator side will create more separate connections to backends that may help even out backend load.

Additionally, the bottleneck might be the available resources

• If the host is running other processes, make sure it has enough resources available for Radiator. The best would be to use dedicated hosts for each function.
• If a virtualisation platform is used, make sure that it can provide the configured resources to Radiator virtual machines even during the peak hours when other vm's are running their peak loads.
• Logging to external servers may cause some unneeded delays for Radiator. This can be mitigated by configuring Radiator to log locally, and then process and ship logs with a separate agent.
• Outside of Radiator, performance of backends may be tuned depending on the backend itself. For example a database can be scaled up or replicated to multiple-server cluster. On the other hand, speeding up the database might be possible even without adding more hardware if queries can be optimised or suitable indexes created. For optimising backends, please refer to their respective documentation.
• Running configuration or Radiator may contain some parts that can be optimised. At the end of this blog post, we tell a bit about our consultation services. 

How can we help?

 

In case you would like our assistance when tuning your Radiator and related infrastructure, please contact sales@radiatorsoftware.com. Our team of experts have a long experience on configuring Radiator, and also assisting with the best practices when integrating Radiator with existing or new infrastructure. 

Radiator as a CISCO CPAR replacement

Recently we have received a lot of queries on whether Radiator AAA would be a good solution for replacing Cisco CPAR (Cisco Prime Access Registrar). As it is known, Cisco CPAR has a released end of support date in October 2024, after which it will not receive software maintenance updates. Therefore many operators are looking to replace their existing CPAR setups with alternative established robust AAA solutions. If you are among these companies, Radiator AAA is the solution for you.

Why choose Radiator AAA as a Cisco CPAR replacement?

 

Known for its reliability and flexibility, Radiator AAA has been in the market for decades. Radiator is an actively developed and supported AAA server with RADIUS and TACACS+ functionalities. With modules focused on carriers, Radiator AAA can also be complemented with Diameter functionalities, SIM-based authentication with IMSI Privacy and other mobile network functionalities.

At the same time, Radiator AAA Server offers support for both Linux and Windows installations - and Radiator AAA has multi-vendor support and can be installed flexibly on different platforms on physical or virtual machines. Radiator has extensive support for different databases and authentication backends (SQL-based, LDAP, AD etc.) as well as support for MFA solutions with TOTP capable authenticators and tokens (Google and MS authenticator, Yubikey, DIGIPASS etc.)

The Radiator technical team consists of experts with vast experience in migration from other AAA solutions. We offer migration support and configuration assistance so you do not need to worry about meeting project schedules before the end of support for CPAR - we have already done these kinds of transitions. Radiator can integrate with existing databases and in most cases no changes to schema are needed.

With Radiator, you can compile your AAA use cases under one product: RADIUS, Diameter, TACACS+, SIGTRAN, you name it, we have it!

Want to know more?

For any questions or other inquiries about Radiator as Cisco CPAR replacement, please contact sales@radiatorsoftware.com. We always provide also simple, transparent and cost-effective licensing models, so there will be no surprises in the cost of ownership during the whole time your company is using Radiator.

Meet Radiator team at WGC Americas in Dallas!

We are delighted to announce that Radiator Software will be attending the top connectivity event of the summer: WGC Americas in Dallas on 10 – 13 June 2024. We are looking forward to meeting our current and prospective partners and customers in Texas.

Wireless Global Congress Americas

WGC is hosted by the Wireless Broadband Alliance and gathers together Wi-Fi industry leaders and experts from all around the world. As usual, the event is divided into two parts: WBA Members-Only Sessions and plugfest on 10 and 11 June hosted by AT&T, and WGC Americas Open Congress on 12 and 13 June held in Dallas Marriott Downtown.

Meet with Radiator team

We extend an invitation to all WGC Americas attendees to meet with Radiator managing director Karri Huhtanen, who is part of our conference delegation. You can find the Radiator team at the WBA Members-Only Sessions and in the Open Congress throughout the event.

To schedule a meeting or simply ask a question, please leave a message and we will get back to you. See you in Texas!

Radiator Simple WiFi Authentication – Introduction to Radiator Cloud

We are pleased to announce an expansion to the Radiator product offering – Radiator Cloud for Azure. We have ever so often been approached by companies and organisations that require a fast to set up, easy to use hosted WiFi authentication solution.

Often the trouble with Software-as-a-Service type WiFi solutions is the concern for privacy, who has access to customer data and how it is handled. To address the demand for a hosted solution with complete privacy to customer data, we’ve developed an Azure-native cloud solution – Radiator Cloud for Azure

Radiator Cloud for Azure is a managed application that is deployed, hosted, operated and monitored all in Azure. User data and logs stay within your Azure tenant with no external access. User and NAS client provisioning is done with enhanced Azure UI and the solution can be monitored with premade Azure Monitoring queries.

Radiator Simple WiFi authentication, powered by Radiator Cloud

The first application that is now live in Azure Marketplace is Radiator Simple WiFi authentication. It is a simple username-password authentication solution that allows organisations to take control of their wireless network with minimum requirements. The only prerequisites to deploying the solution are an active Azure subscription and access to one’s network device configuration.

Deployment is done within minutes from the Azure Marketplace. A user with at least Contributor permissions for their tenant can deploy the application. Provisioning and monitoring is made straightforward with Azure UI and billing is done together with the organisation's other Azure applications.

Radiator Simple WiFi authentication – Easy, Fast and Affordable

The main customer groups that benefit from the application are organisations who do not yet have any WiFi authentication solution in use, as well as organisations with multiple locations who want to centralise their WiFi authentication operations. Radiator Simple WiFi authentication provides an easy way for centralised user and device management with minimum prerequisites.

Radiator Simple WiFi authentication is easy, fast and affordable. The simple structure of the application, backed with comprehensive deployment guide and user manual, make the application easy to deploy and operate. Deployment process is automated and does not need any vendor approval. Provisioning is very straightforward. In a typical deployment, you have a working system within the same day.

The costs of the application consists of two parts: fixed monthly software cost and Azure running costs for hosting the application. All costs are transparent and easy to estimate. You are only billed by Azure, along with your other Azure applications.

The future of Radiator Cloud

While Radiator Simple WiFi authentication is already available for purchase in Azure Marketplace, we are also actively looking to expand the Radiator Cloud product family both horizontally with other use cases and vertically to other platforms.

Our two big roadmap items for Radiator Cloud are enterprise-grade WiFi authentication application and an application for WiFi authentication utilising Microsoft Entra IDs. Both of these address a direct need not only from new but also existing customers who are looking to move from their existing Active Directory on to Azure.

While these development news are all about Radiator Cloud, this is by no means a sign that we would have shifted focus from our on-site products. Radiator is committed to active development and latest standards and these efforts are made to make Radiator products more accessible to all organisations across different platforms and deployment models.

Want to know more?

If you have any questions about Radiator Simple WiFi Authentication or Radiator Cloud roadmap items, please do not hesitate to contact us at sales(a)radiatorsoftware.com

WiFi offloading vs VoWiFi

In recent years we have encountered a lot of customers wanting to utilize their networks more efficiently, and provide premium service for their subscribers. WiFi offloading and VoWiFi are popular ways to to extend the mobile operator’s network coverage into wifi, free bandwidth from congested cellular networks and improve user experience with better connectivity. The technologies share many similarities and both use a 3GPP AAA server for SIM based authentication.

WiFi offloading offers some flexibility in the supported authentication backends and the SIM authentication can be done through various HSS and HLR interfaces depending on what the mobile operator has available. This is especially important in roaming scenarios where the WiFi provider has agreements with multiple MNOs to offload their subscribers.

WiFi calling is more strictly standardised to support high QoS for the voice call, and also the handover between VoWiFi and VoLTE. This allows users to move outside the range of the WiFi hotspot and seamlessly continue the call over VoLTE, and vice versa.

Let’s take a look at the key differences between the two related technologies:

Comparison	WiFi offloading	VoWiFi
Purpose	Ease network congestion, Network CAPEX savings, Roaming cost savings, Secure authentication to private wireless networks: carrier, industrial, in-flight, underground, IoT	Ease network congestion, Indoor coverage extension, Combat OTT apps, Roaming cost savings
Relationship between MNO and access network provider	Agreement required between MNO and wifi provider	No relationship between MNO and wifi provider
Access network	Carrier or partner wifi	Any public or private wifi
Traffic	Data only	Voice and video calls
SIM authentication protocol	EAP-SIM, EAP-AKA, or EAP-AKA’	EAP-AKA
Supported HSS interfaces	SWx, Wx, Cx, S6a	SWx required
Supported HLR interfaces	MAP, SIGTRAN	Not supported
ePDG	Not applicable	ePDG mandatory
Security	WPA Enterprise	IPSec tunnel between UE and ePDG
IMSI Privacy	Yes, supported by Radiator	Yes, supported by Radiator

What is different?

The main difference between WiFi offloading and VoWiFi is the relationship between the mobile operator and the wifi provider: operator controlled data offloading always requires a prior agreement between the MNO and the WISP. WiFi offloading is often done in high traffic areas such as airports, sports stadiums and concert venues, since offloading users to WiFi is cheaper than adding microcells to boost the mobile signal. MNOs can invest in carrier wifi hotspots themselves, or make offloading agreements with wireless ISPs.

VoWiFi requires the mobile device to be connected to a wifi before attempting a VoWiFi call, but any type of wifi can be used for WiFi calling, including consumer home wifi. Therefore no relationship between the mobile operator and WiFi provider is required. However VoWiFi has specific technical requirements for the MNO: a HSS with SWx interface and ePDG are required.

Private network authentication

WiFi offloading technology is also applicable to private network offerings, such as industrial and IoT networks. SIM authentication provides a secure method to authenticate users into a private network using their SIM credentials and eliminates the human element of reusing and sharing passwords. In high security deployments the SIM authentication can be further combined with device IMEI check, to make sure that only authorised users and devices are able to access the private wifi network. VoWiFi is also possible in private networks, and can enable voice calls in challenging environments such as underground.

Interested in WiFi offloading or VoWiFi?

Radiator SIM Pack provides a fully featured 3GPP AAA server solution, with superb flexibility to connect with your environment. Please contact the Radiator team at sales (at) radiatorsoftware.com to get a quote.

Meet Radiator team in Brisbane at IETF119

Radiator team continues the active engagement with RADIUS working groups at IETF and will be attending IETF 119 meeting in person at the Brisbane Convention and Exhibition Center 16 - 22 March 2024.

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.

IETF RADIUS working groups

You can find the Radiator team at these sessions - click the links for the respective meeting materials and agendas.

RADIUS EXTensions (radextra)

EAP Method Update (emu)

MAC Address Device Identification for Network and Application Services (madinas)

Radext working group will be discussing reverse CoA and deprecating insecure practices in RADIUS. EMU group has Forward Secrecy for EAP-AKA on the agenda, and madinas group is addressing the current status of MAC randomisation. We also welcome Wireless Broadband Alliance presenting a document describing OpenRoaming protocols - for Radiator, we have released the Radiator OpenRoaming configuration guide on Github.

For other IETF sessions, please see full meeting agenda here: https://datatracker.ietf.org/meeting/119/agenda

Meet the team

The point of contact is Radiator developer Heikki Vatiainen, whom you can find at the RADIUS working group sessions and around the venue. If you’re in Brisbane, come find us and say hi! Everyone else interested in Radiator development, please drop us an email!

Meet Radiator Software at Mobile World Congress 2024

Like everyone else in the telecom industry, we’re busy preparing for the world’s largest connectivity event of the year: Mobile World Congress held at Fira Gran Via in Barcelona on 26th – 29th February 2024. We’re looking to catch up with old and new partners and customers in Barcelona!

For MWC24, Radiator Software is showcasing Radiator solutions, which deliver a superb combo of flexibility, interoperability and performance to complex operator AAA deployments. We invite you to engage with our team of network authentication experts to discuss all things AAA: FTTH authentication, WiFi roaming, VoWiFi, IMSI Privacy, OpenRoaming, and more.

Book a meeting here: Google Form

Radiator SIM Pack 2.9 released

Recently, we have met increased demand for SIM authentication in different use cases and services. Radiator development is driven by the actual customer cases and we are now pleased to announce the release of Radiator SIM Pack version 2.9!

Here are selected highlights from the new release:

Cx support for EAP-SIM, EAP-AKA and EAP-AKA’ authentication

Diameter Cx interface provides an alternative way of fetching the SIM authentication vectors when the standard SWx interface is not available from the MNO. Cx is an HSS interface that is typically used to authenticate users from the IMS side of the network, but Radiator can now also use it for SIM based Wi-Fi authentication.

SIGTRAN location update features

Support for MAP UpdateLocation, MAP UpdateGprsLocation and MAP CancelLocation have been implemented in SIGTRAN. Location update features make it possible to resolve the user MSISDN (i.e. mobile number) and use IMSI related profile for authorisation. As a result, different authorisation rules can be enforced based on the MSISDN, or mobile numbers can be included in logging, accounting and other customer specific requirements.

Improved temporary identity generation

Temporary Mobile Subscriber Identity or TMSI is a pseudonym for the subscriber’s actual identity, IMSI. Plain or encrypted IMSI is always used for the initial SIM authentication, but a temporary identity can be generated for the subsequent requests to make re-authentication faster and increase security. Radiator TMSI implementation has now been updated per recent 3GPP specification: the improved implementation no longer requires a SQL session database further enhancing the speed of re-authentication. Historical data is also retained better.

For a full list of new features and changes, please see Radiator SIM Pack revision history.

Trends in operator AAA cases

In our recent projects with customers ranging from small private operators to major tier 1 carriers, we have seen these significant trends:

• Demand for Wifi offloading and VoWiFi remains high for various reasons: coverage and capacity expansion, ease of congestion in high density areas, and cost saving, especially for saving international roaming costs.
• Non-fixed backhaul connectivity cases (in-flight, train, maritime) cases are emerging.
• New private LTE/5G operators need SIM authentication to add Wi-Fi networks to their offerings. Radiator is an integral part in different MVNE solutions in connecting the MVNO and MNO network elements.

In addition, security requirements have increased. Demand for IMSI Privacy is driven by Android and iOS, and support for IMSI encryption is now a must for new offloading projects. RadSec is required for various roaming scenarios, including OpenRoaming. Both are supported by the Radiator SIM Pack - with a long track record of field proven production implementations.

Would you like to know more?

Radiator pre-sales team includes experienced engineers who can provide expertise for advanced Diameter and roaming use cases, including non-standard and custom cases.

In addition to top tier technical support, we also provide a flexible licensing model to match your business case. Whether you have your own subscribers, IoT devices or roaming guests, you can grow your license at the same pace where your business grows - you can just buy add-on licensing as you are onboarding more SIM authentication or VoWiFi end users, for example.

We always know that every customer case is different - so please do not hesitate to contact us at info@radiatorosoftware.com.