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

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.

Radiator first setup walkthrough

Radiator is a command line software which is controlled with a simple text file. The Radiator AAA reference manual and goodies directory contain a plethora of examples, but it might be daunting to find a good starting place.

Installing Radiator

Radiator runs on a wide range of platforms and there are platform specific installation packages as well as the full source code package available. Check out the installation instructions from Radiator AAA reference manual.

The manual lists various system requirements, but the absolute minimum that is needed for a simple initial setup are Radiator installation package, Radiator Radius::UtilXS add-on and Perl. Perl is usually included in the most common Unix distributions, and for Windows the Radiator MSI package contains all of these!

Running Radiator for the first time

Once Radiator is installed, it is time to see that Radiator can be run. The deb, RPM and MSI installation packages all install Radiator so that it is controlled by the system. On the Unix side by systemd and on Windows as service. By default the installation also brings a Radiator configuration that can be used to verify the installation, that is the configuration is capable of receiving RADIUS authentication and accounting requests from within the system and always responds with accept.

See how to start Radiator service and run the test from the installation instructions:

• For Linux installations
• For Windows installations

Developing own Radiator configuration

The default configuration available right after Radiator installation is not particularly useful, seeing as it always responds with accept. To develop a proper Radiator configuration, suitable to your needs, check out the goodies directory available in /opt/radiator/radiator/goodies/ on Linux and in \Radiator\Radiator\goodies\ on Windows. Note that on Windows Radiator is automatically installed on the drive that has most space, so the directory can be C:\Radiator\Radiator\goodies\ but it could also be E:\Radiator\Radiator\goodies\

Goodies contains full configuration examples, so when picking suitable starting point to your own configuration you can just copy the whole configuration from goodies as the default Radiator configuration /etc/radiator/radiator.conf on Linux or C:\Program Files\Radiator\radiator.conf on Windows. For example goodies/simple.cfg shows how to authenticate users from a file:

1. Copy the goodies/simple.cfg as /etc/radiator/radiator.conf or as C:\Program Files\Radiator\radiator.conf
2. The simple.cfg refers to users file, which is located to %D (check out more about special characters from this section of the reference manual)
3. There is a default users file available in /opt/radiator/radiator/ on Linux and in \Radiator\Radiator\, which can be copied to /etc/radiator/ directory on Linux or C:\Program Files\Radiator\ on Windows.
Have a look at the contents of the users to see the example users defined therein
4. Now that the new configuration file and the file listing the users are on their place, it is time to restart Radiator so the new configuration is read: sudo systemctl start radiator on Linux and restart Radiator AAA Server service on Windows
5. Whenever Radiator is restarted, it is a good practice to check out the Radiator log file in case there were any errors on the configuration. By default the log files are under /var/log/radiator/ on Linux or C:\Program Files\Radiator\ on Windows. Especially the Radiator process log file radiator.log should be checked as the possible errors could cause unexpected behavior or even leave Radiator unable to start.
6. Test the configuration by running

   perl /opt/radiator/radiator/radpwtst -user mikem -password fred

   on Linux or on Windows:
   1. Click "Radiator Software" -> "Radiator configuration" on the Windows Start menu. This opens a Windows Explorer window that shows the contents of Radiator configuration and log directory under the "Program Files" folder.
   2. Double click "Perl command line" to open a Command Prompt window
   3. Run

      perl radpwtst -user mikem -password fred

7. End result should be 3 OKs, as the radpwtst automatically sends one authentication request, one accounting start request and one accounting stop request.

Working with source code package

Although the recommended approach is to use the distribution specific Radiator packages, sometimes the source code package is the only option. The source code package can be unpackaged to any directory and it doesn’t automatically create any services. The simplest way to test the source code package is to run both Radiator server and radpwtst test from the command line.

1. Take goodies/simple.cfg as starting point and copy it to one level up. Check the DbDir and DictionaryFile defined on the simple.cfg and edit both to point to the location where the source code package was extracted.
2. Run radiusd from the command line:

   perl radiusd -foreground -log_stdout -trace 4 -config_file simple.cfg

3. Leave the command line running so you can watch the logging, then open a second command line and run the test utility radpwtst:

   perl radpwtst -user mikem -password fred

   1. Have a look at the contents of the file called users to see the example users defined therein
4. End result should be 3 OKs, as the radpwtst automatically sends one authentication request, one accounting start request and one accounting stop request.

All done!

You now have a basic Radiator installation and you are ready to start configuring Radiator your own use case. Check out these resources:

• Radiator AAA reference manual
• Configuration samples in Goodies directory included your distribution
• Radiator Software FAQ

For any questions, please reach out to us at info(a)radiatorsoftware.com. We’re always ready to discuss your use case and how to implement it with Radiator!

Meet the Radiator Team at WGC EMEA and Network X in Paris!

We are delighted to announce that Radiator Software will be exhibiting at the top connectivity events of the season: WGC EMEA and Network X co-located at Porte de Versailles conference centre in Paris on 23 – 26 October 2023.

Wireless Global Congress EMEA 23 – 26 October

The Radiator team will participate in the WBA Members-Only Sessions on 23 and 24 Oct, and the WGC EMEA Open Congress on 25 and 26 Oct. Backed with 20 years of roaming experience, Radiator team can help you deploy RadSec, OpenRoaming, In-Flight Connectivity, and IMSI Privacy with best in class security.

For more information about Wireless Global Congress EMEA 2023, please see the official event website: https://www.wirelessglobalcongress.com/wgc-emea-2023/

Network X 24 – 26 October

Network X event 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

We extend an invitation to all WGC EMEA and Network X attendees to visit Radiator Software booth F19. Here, you can engage Radiator experts for insightful discussions on latest advancements in network authentication, WiFi and mobile convergence and how Radiator unifies RADIUS and Diameter infrastructure.

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

Replacing Juniper SBR in mobile APN authentication with Radiator

Like we have written before in our blog, Radiator AAA Server Software is currently being used in many projects to replace Juniper’s Steel-Belted RADIUS that is now reaching the end of support. Of course at the same time, many FTTH service providers, ISPs and mobile operators are always searching for new options when they prepare their network infrastructure for the future.

One specific use case where we have seen a lot of demand for Radiator is the RADIUS authentication needed in mobile networks. In mobile networks, RADIUS protocol is used when there are private, organization-specific APN (Access Point Name) network paths in use. For example, critical communications such as emergency services often require this kind of network segmentation to secure their operations.

In VoLTE/4G networks, PGW/GGSN components in mobile networks make RADIUS queries to RADIUS server (such as our Radiator), and RADIUS server then authenticates and authorizes the end user to a specific APN network path - that can for example be an enterprise-related private network.

What we have been recently doing with many customers is the replacement of RADIUS servers and the related business logic in mobile networks. These have been done both with Radiator AAA Server Software and with the consultation of our technical team. At the same time, these projects are often combined with different accounting use cases, storing of CDR records etc.

When preparing for the future and taking the course to 5G networks, either RADIUS or Diameter interfaces will be used for similar use cases. Radiator, with extensive support of different TLS-based EAP methods, is of course prepared for this use case with 5G networks as well.

Would you like to know more?

In case you are looking for a future-proof RADIUS and Diameter server for your mobile network, we are happy to provide more info - and discuss your use case. Just reach out to us at sales@radiatorsoftware.com and we can discuss further.

Cutting roaming costs and expanding coverage with Radiator SIM-based authentication.

Modern SIM-based devices, like smartphones and tablets, are able to join and switch between different networks automatically. This is especially valuable to mobile operators who want to offload data from their mobile network to a nearby Wi-Fi network, because Wi-Fi connections are significantly cheaper to operate. It also enables Wi-Fi providers to monetize their Wi-Fi net- works and provide services in partnership with mobile operators. In addition, with use of OpenRoaming or other Wi-Fi roaming services, it also provides a way to expand the coverage of carrier Wi-Fi.

Use cases for the SIM authentication include:

Wi-Fi Offloading:

In busy locations with high volumes of mobile traffic like sports stadiums, shopping malls, public transport hubs and underground metros, SIM-based devices can automatically switch from mobile data connections to local Wi-Fi networks. Transferring the data traffic to Wi-Fi networks reduces the load on the mobile network, which improves the coverage and the user experience. In addition, using Wi-Fi roaming services, such as Orion Wi-Fi or OpenRoaming, can further reduce costs when carriers can use these additional services for Wi-Fi offloading.

Voice over Wi-Fi

SIM-based devices can also switch voice calls from mobile networks to Wi-Fi networks, and this kind of call is known as Voice over Wi-Fi. As with data traffic, switching traffic from regular calls to Wi-Fi networks can help carriers and operators to reduce the load on the mobile network, enabling better call quality and continuity.

Wi-Fi Roaming

When a SIM-based device automatically joins a Wi-Fi network or switches to another one, this is called Wi-Fi roaming. Wi-Fi roaming is used to maintain an uninterrupted data connection when the user moves from location to location, or when the current Wi-Fi connection is overloaded or when the signal is weak. In these situations as well, using OpenRoaming and other Wi-Fi roaming services can expand the coverage for mobile carrier.

Wi-Fi SIM-based authentication is essential to making these capabilities work. Before a device is allowed to join a new Wi-Fi network, it must be authenticated using the IMSI*. For this reason, Wi-Fi SIM-based authentication is supported by the latest Android and iOS mobile devices. However, there are still some security issues with this type of authentication. As a result, mobile OS manufacturers are now pushing for even better security on Wi-Fi networks and they require IMSI Privacy Protection with all new OS versions.

How can Radiator help you in this?

The Radiator SIM Pack for Radiator AAA Server Software makes it easy for operators to enable IMSI Privacy Protection. It is the key component needed for secure and seamless switching between mobile and Wi-Fi networks using SIM-based authentication. The Radiator SIM Pack also provides all the functions required for a 3GPP AAA Server.

IMSI privacy is a key feature of the Radiator SIM Pack, and it provides server-side support for permanent identity protection during Wi-Fi SIM-based authentication, Wi-Fi offloading and VoWiFi, resulting in a higher quality user experience. You can read more about Radiator SIM Pack and IMSI Privacy protection from our IMSI Privacy whitepaper.

In addition to this, Radiator provides also all the services and products needed when joining to  Wi-Fi roaming services, such as OpenRoaming, or when connecting to mobile carrier infrastructure by using Diameter interfaces.

Would you like to know more?

If you would like to know more about Radiator, SIM authentication, IMSI Privacy, joining OpenRoaming etc., and how we can help you in your use case, you can always contact our team at info(a)radiatorsoftware.com. Looking forward to hearing from you!

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

Radiator AAA hardware requirements

In many of our new deployment projects, we face the common question “How much CPU, RAM and disk space does Radiator need for x users?” While conservative estimates can be given, there is much more to this question than a simple figure.

The requirements of the system depend on the use case, backend, and implementation. In this blog post we will go over the variables and why it actually is misleading from us to give an answer to this question - but at the same time, we are always happy to help you with the hardware correct sizing.

Use case

There are major differences between the requirements for different authentication methods. The differences can be divided to two: Number of transactions per authentication, and number of interim-accounting transactions per session. One PEAP or EAP-TTLS request can consist of many messages, while a fixed-line authorisation has less transactions.

In reality, AAA servers are usually not the hold-up. Database latency is often the limit for AAA server performance. The database just does not respond in time when the load is high enough. In networking authentication, some use cases are read-heavy and some write-heavy on the database. To allow for better system performance, the database model should be optimised based on the demand for writes over reads or the other way around. What can and should be done is separate VMs for Radiator and the database. It is always better to run AAA server and database on separate servers.

Implementation

Network design plays an important role in ensuring your Radiator setup is sized sufficiently. Radiator can be configured to run as a loadbalancer for other Radiator instances. While there also are other loadbalancer options, a setup loadbalanced with Radiator loadbalancer configuration has better throughput than one without loadbalancing.

The requirements

In conclusion, there are many factors that affect the system performance, and sizing Radiator depends heavily on the use case and preferred architecture. However, a conservative starting point that we give customers is that each Radiator instance requires 1 vCPU and 0.5 GB RAM and it runs around 1000 TPS. This may heavily vary depending on the use case.

As for disk space, Radiator itself takes around 20 MB of disk space. This does not take into account requirements of the operating system and log data generated by Radiator. However, the Radiator logs can be shipped off to another log host machine to assure the Radiator host’s disk is not filled with log data.

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!

Cisco ACS is reaching end of life - Radiator has got you covered

As announced already some time ago, Cisco will no longer support either the hardware or the software of their Access Control System (Cisco ACS) product line. If your network administration still runs Cisco ACS, it’s time to take action and upgrade it into a product with a clear future for updates and support. Radiator AAA Server software, often referred to as the Swiss Army Knife of AAA Servers, can pick up from there.

As mentioned in a previous Radiator Cookbook post in 2018, Radiator AAA Server Software offers TACACS+ support and can be integrated with existing hardware to replace current solution’s TACACS+ and RADIUS functionalities. This means that Radiator can replace the authentication functions Cisco ACS did in your previous system. All that is required is an external database for user credentials that Radiator integrates to.

Radiator is actively developed, with multiple updates per year, so continuous support for your solution is given. And most importantly, Radiator’s support team consists of experienced professionals who have developed and actively develop Radiator AAA, so your support requests are always handled by capable RADIUS and TACACS+ experts.

These same professionals will be handling the transition work from ACS to Radiator AAA, if you so wish. Our technical team consists of experienced seniors with vast experience in enterprise, ISP, CSP and other AAA solution integrations and have done these transition projects even before the EOL was announced.

Radiator, being a flexible AAA Server with TACACS+ support, can replace ACS’s TACACS+ and RADIUS functions. Radiator does not have the built-in database, but rather integrates to a customer’s existing database. If need be, we are happy this database solution through our partner. The flexibility of Radiator also includes multi-vendor support for NAS devices. This means that changing NAS devices will not be troubled by vendor lock-in.

Want to know more?

If you want to know more about Radiator AAA Server software as the flexible and supported replacement for Cisco ACS, do not hesitate to contact our sales team sales(at)radiatorsoftware.com.

Radiator supports EAP-TLS 1.3

One of the most used authentication methods for Radiator users is EAP-TLS. It is widely supported among wireless vendors and the support for EAP-TLS is needed for different certifications for wireless authentication. Radiator has supported different versions of EAP-TLS from the start. As we want to be in the forefront of industry standards, we are happy to announce that Radiator now supports EAP-TLS 1.3 - our team has also been involved in the standardisation work for EAP-TLS and other TLS-based EAP methods.

What is new in EAP-TLS 1.3?

The key feature in EAP-TLS 1.3 is increased privacy and security. Like the RFC document says “TLS 1.3 is in large part a complete remodeling of the TLS handshake protocol including a different message flow, different handshake messages, different key schedule, different cipher suites, different resumption mechanism, different privacy protection, and different record padding.” This new remodeled TLS handshake protocol ensures faster TLS connections as well as patches previous security errors TLS 1.2 had.

Especially important in this new version for EAP-TLS is that no information about the underlying peer identity is disclosed. In other words this means that with EAP-TLS 1.3 the certificate of the user is delivered encrypted. In previous versions of EAP-TLS the client certificate was delivered without encryption, providing a possibility of tracking the users. This has been an issue for some users of EAP-TLS discouraging its deployment. To increase the security of your organization, Radiator configuration allows you to enable EAP-TLS 1.3 for devices that support it, while the earlier versions of EAP-TLS are still available for older devices. Radiator AAA Server Software and its modules are actively developed and updated to support state-of-the-art AAA security features. With the most recent Radiator SIM Pack patch, Radiator now supports IMSI Privacy as well - as one of the few AAA software vendors. So, in short, Radiator is committed to stay in the frontlines of all AAA security features at all times.

Would you like to know more?

While the support for TLS v1.3 in some operating systems varies, the Radiator implementation of TLS v1.3 and EAP-TLS is currently available in the testing branch of Radiator, but will be included in the next stable release as well. If ou are interested please test and give us feedback about the implementation.

If you want to know more about Radiator and EAP-TLS 1.3, please do not hesitate to contact our sales team at info(a)radiatorsoftware.com. For full list of Radiator technical features, you can also visit the Radiator AAA Server Software product page.

More flexibility to authentication with Ut interface and Radiator GBA/BSF Pack

One of the carrier products in our Radiator product line is the Radiator GBA/BSF Pack. The main use case for this product has been providing the authentication for VoLTE supplementary services in carrier networks and Radiator GBA/BSF Pack has been in this use for many years. 

In addition to self-provisioning VoLTE supplementary services (call forwarding, call barring, knocking, etc.) the same GBA/BSF functionalities can be used for proxying authentication to different services as well - such as Rich Communication Services or different services for IoT devices, for example.

The main functionality in GBA/BSF is that after the initial authentication, end user authentication can be proxied directly to Application Specific servers via Ut interface. The basic architecture is shown on the diagram below.

The Ut interface and authentication proxying can also be used for example in secure IoT authentication for different products, such as IoT devices that need to be authorised and authenticated. In this use case as well, the IoT device is supplied with SIM/eSIM that authenticates with carrier HSS. After the initial authentication, the later authentications can be proxied using the Authentication Proxy provided by Radiator GBA/BSF Pack.  

Radiator provides flexibility when working with Ut interface

For Ut interface, there is a wide range of different vendor specific implementations from device manufacturers. This causes differences in user equipment behaviour across vendors.

This is where Radiator GBA/BSF shows its strengths: wide interoperability accommodating different user equipment within the same systems makes our Radiator GBA/BSF easy to integrate to different network environments. Radiator GBA/BSF’s implementation allows tweaking the configuration when unexpected behaviour is encountered and adjust accordingly.

This focus to accommodate multiple vendor-specific implementations is what we have been doing in recent releases of Radiator GBA/BSF Pack - latest release in April 2022: providing more interoperability based on real observed behaviour of the devices. In this development work, the feedback from our live carrier customer has been extremely valuable.

Would you like to know more?

If you would like to know more about Radiator GBA/BSF and how it can be used in your use case, please contact our team at info(a)radiatorsoftware.com

Radiator Auth.Fi: Self-service, Passwordless Guest Access

 As a part of our Radiator Auth.Fi - Wi-Fi Authentication Service we provide self-service, passwordless guest access for Wi-Fi networks. With this service you can limit the use of your guest network to those users willing to validate their network access with email address or phone number. Compared to unauthenticated guest networks, the authenticated guest networks reduce network abuse  cases and overuse of network resources.

We have designed the guest network access validation to be easy and secure enough for the end-user without any hassle with passwords or need to reauthenticate. As the network access validation is done as a self-service, no vouchers are provided and needed reducing the work needed to support guest users in accessing the network - the authentication and authorization is connected to the user to the MAC address of the user device.

How does it work?

As seen from the picture below, the authentication and access process follows a few steps, after which the guest can join to the Wi-Fi network automatically - but still as an authenticated user. The steps are as follows:

1. Guest user connects to the Wi-Fi network operated by your organization
2. The user device of the guest user notices that authentication is needed before browsing and the user's WWW browser is redirected to the authentication page operated by Radiator Auth.Fi.
3. Guest user chooses the method for authentication and inserts either email address or telephone number for authentication.
4. Radiator Auth.Fi service sends the authentication verification message to the guest user to email or SMS messaging service.
5. Email message (or optionally SMS) containing verification link is sent to the guest user 
6. Following the verification link guest user verifies contact information and network access is authenticated with Radiator Auth.Fi
7. Guest user can now use guest Wi-Fi network and the device joins network automatically
8. Guest user can now use the guest Wi-Fi network for a limited time (for example 24 hours - based on your company policies) without the need for reauthentication. The authorisation of the user device to the network is checked periodically during allowed time.

Would you like to know more?

For more info about Radiator Auth.fi Wi-Fi Authentication Service, please contact our sales team at sales(a)radiatorsoftware.com or via contact form.

We are happy to discuss your use case and how Radiator Auth.fi may suit your needs. Commercially, Radiator Auth.fi is based on a flexible, pay-as-you-go subscription model that allows you scale the commercial model of the service based on your business needs. At the same time, we provide several feature options for the Radiator Auth.fi - this use case of providing guest access being one of them.

In-flight Connectivity with Radiator

For many of our customers we have been implementing WiFi roaming for different use cases: for example, carriers offloading traffic from their mobile network to WiFi hotspots or for providing VoWiFi (Voice over WiFi) calling to their customers.

One case for Radiator is to implement in-flight connectivity for airline carriers, providing authentication to onboard WiFi that is connected by other means (such as satellite connection) to the internet.

In this scenario, Radiator provides the necessary interfaces for WiFi roaming when subscribers of mobile operators are using their phones during the flight. With smooth WiFi roaming provided by Radiator AAA Server Software, end user devices can connect automatically to the in-flight WiFi network, and continue their use based on the roaming policy agreements between mobile operators and in-flight network operators.

Some of the benefits for this kind of solution are:

• For the airline carrier: More value for service as a provider of smoothly connected onboard WiFi as a part of their in-flight services.
• For the end user: Better user experience when connecting to onboard WiFi.
• For the mobile operator: New product opportunities for mobile operator roaming with airline onboard WiFi.
• For the onboard Wi-Fi technology provider: A flexible product with Radiator that provides connectivity to carrier networks via different interfaces.
  

At the same time, the solution with Radiator AAA server can of course be used in cruise ships and platforms where a smoothly run, commercial onboard WiFi is needed. 

How does it work?

On the technical side, Radiator AAA Server, combined with Radiator SIM Pack, is used to provide EAP-SIM, EAP-AKA and EAP-AKA’ authentication and connectivity to different HSS / HLR systems used by different roaming partner carriers and mobile operators. In these cases, the flexibility of Radiator helps to connect to various different systems needed via multiple interfaces.

With this configuration, in addition to handling the authentication traffic, Radiator AAA Server also proxies the accounting traffic to policy enforcement or traffic monitoring solutions that can then use it to provide access to end users, based on their data plan or subscriber profile. The following diagram shows Radiator as part of the architecture for in-flight connectivity.

Radiator provides EAP-SIM / EAP-AKA / EAP-AKA’ authentication and connecting to roaming partners HSS / HLR.

 

 

Would you like to know more?

For commercial contact and more in-depth technical discussion, please do not hesitate to contact our sales team at sales(a)radiatorsotware.com . We are happy to discuss about your requirements, suitable license and configuration assistance needed for your service.

Radiator provides IMSI privacy for EAP-SIM, EAP-AKA and EAP-AKA’ authentication

In many high traffic areas such as sports stadiums, shopping venues, or public transport hubs, mobile carriers may partner with the local Wi-Fi providers to improve coverage and user experience: mobile devices can be automatically connected to Wi-Fi instead of congested cellular network. Internationally, Wi-Fi roaming agreements also allow carriers to lower the cellular roaming costs. 

EAP-SIM, EAP-AKA and EAP-AKA’ are SIM-based Wi-Fi authentication methods used to achieve seamless offloading to carrier and partner Wi-Fi, with International Mobile Subscriber Identifier (IMSI) derived from the SIM card acting as a unique identifier for each user. 

On the first ever connection to such a Wi-Fi network, the mobile device communicates its permanent subscriber identity information (IMSI), which is then sent to the home operator for authentication. This identity is sent in the clear. A potential 3rd party adversary installing a Wi-Fi sniffer in the vicinity of such networks can harvest permanent identities and track users. This tracking can also be done by the venue or network owner when connecting to the Wi-Fi network. 

Because of this, mobile operating systems such as iOS15 will show the following warning when joining a Wi-Fi network without IMSI encryption: “your mobile subscriber identity will be exposed”. The similar situation can be seen from the pictures below. 

Privacy warning when authenticating to Wi-Fi network without IMSI encryption

 

Operators risk decreased user satisfaction for Wi-Fi offloading if transmitting IMSI in the open - it may cause users to feel their privacy is being compromised.

Radiator SIM Pack provides IMSI privacy protection 

The solution is to protect user privacy by implementing IMSI encryption for EAP-SIM, EAP-AKA and EAP-AKA’ authentication. As an operator, you can enable IMSI privacy easily: Radiator 3GPP AAA Server handles both encrypted and clear authentication requests. This means IMSI privacy can be offered to devices supporting it without affecting other users. 

Starting already from revision 2.5, Radiator SIM Pack supports IMSI encryption as specified in 3GPP S3-170116 document “Privacy Protection for EAP-AKA” (zip), and WBA’s IMSI Privacy Protection for Wi-Fi – Technical Specification. The feature is already implemented by some of our operator customers to cover their AAA server encryption. 

The latest release of Radiator SIM Pack is available for new licensees and for licensed customers with valid download access. To find out if Radiator SIM Pack suits your needs, you can contact us at sales@radiatorsoftware.com and a member of our sales team will be happy to assist you. 

You can also contact us to renew your support contract and get access to the newest release. A full history of Radiator SIM Pack releases is available on our website.

Radiator and NCINGA - working together towards customer success

 

 

 

While Radiator has hundreds of operator customers all over the world, we also have an extensive network of integrator partners providing turn-key solutions for our customers. One of these trusted integrators is NCINGA.  As NCINGA is known to provide technology transformations in frontier markets, they also provide Radiator AAA solutions to operators and carriers especially in the APAC area.

This collaboration has provided solutions to customers both for fixed and wireless AAA. In
different use cases, the main focus in the cooperation has involved integrating Radiator
solutions with different vendor environments and network elements. Radiator is used for
example when applying policy and control functionalities for end user data plans.

    “With Radiator, we were able to quickly deliver complex AAA implementations. It was easy
    to configure and extend to the customers need. The Radiator Technical Support team made
    it even easier to implement & support with prompt responses and guidance.” 

    -Kokum Randeni, VP Sales, Ncinga

One of the key elements in the working model has been the flexibility in Radiator licensing:
the components needed by the customer can be tailored to the use case and number of
subscribers. This way the ROI for the customer can be ensured as they can add new
features of Radiator to use when needed.

For the customer, the operating model is quite easy and straightforward: NCINGA and their
team of experts provide the first level support and integration consultation, and the Radiator
team provides the product-related 2nd level support and consultation related to Radiator
specific configuration and other needs.

Would you like to know more about Radiator and NCINGA?

If you are looking for a carrier-grade AAA server with flexible options for different use cases,
please do not hesitate to contact our sales team at sales(a)radiatorsoftware.com. For
NCINGA, please contact their sales team at www.ncinga.net.

Examples of Radiator use include carrier-grade AAA, Wi-Fi offloading, integrating Diameter
online and offline charging with RADIUS-based infrastructure, integrating RADIUS
accounting with Diameter online and offline charging and much more. On top of that, our
support team has wide experience of various carrier use cases in different environments.

TNC19 Radiator technical workshop presentations available!

Terena Networking Conference 2019 (TNC19) is over as is our Radiator technical workshop, which was part of the conference. Here are all of Radiator Software presentations presented in the Radiator technical workshop. You are able to find these also on our SlideShare account, where we will upload also future public presentations about Radiator.

1) TNC19 Radiator Technical Workshop -- Introduction, what's new with Radiator (Software)

2) TNC19 Radiator Technical Workshop -- Using Radiator to ensure better SP/IdP connections to eduroam/govroam

3) TNC19 Radiator Technical Workshop -- Meet Radiator developers

Thank you to all Radiator technical workshop participants, we hope to see you again. We also will look into possibilities of repeating our technical workshop as a webinar together with TNC19 organisers for those who were not able to attend live.

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.

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.