How to update the new WBA Root CA chain for the Radiator OpenRoaming deployments?

WBA OpenRoaming certificates now issued or renewed using the new WBA Root Certificate Authority chain

At 00:00 UTC (beginning of the day) on 3rd of Febuary 2025 Wireless Broadband Alliance (WBA) switched to issuing OpenRoaming certificates using new WBA Root Certificate Authority (CA) chain. This means that all OpenRoaming certificates, which are renewed or issued on 3rd of February 2025 or later, use the new WBA Root CA chain. 

Although WBA planned and informed OpenRoaming Identity Providers (IdP) and Access Network Providers (ANP) about the planned change, there are OpenRoaming ANPs and IdPs, which have not updated their RADIUS/RadSec server configurations to accept both the old and new WBA root CA certificate chain for RadSec connections.

This means for example that IdP customers of the IdP using the new root chain issued certificate are not able to roam in the ANP networks, which do not accept IdP's new RadSec server certificate if it is issued by the new WBA Root CA chain. If an IdP does not accept the new WBA Root CA verified RadSec client certificates for connections originating from the ANP's Wi-Fi network, that IdP's customers are not able to roam into that ANP's Wi-Fi network.

If ANPs and IdPs do not update their inbound and outbound RADIUS/RadSec connections to accept both the old and new WBA Root CA chain certificates, when new OpenRoaming certificates are issued or old ones are renewed, gradually the roaming connections with those ANPs and IdPs deteriorate.

How to update Radiator OpenRoaming deployment to use the new WBA Root CA chain?

If you have deployed Radiator utilising the Radiator OpenRoaming Configuration Guide, updating your configuration to support the newer WBA Root CA chain certificate (or any other CA certificates) can be done by simply adding new certificates to CA directories in the configuration.

Radiator OpenRoaming Configuration Repository contains a template Radiator configuration tree to use to set up OpenRoaming deployment. These configuration files are intended to be installed to /etc/radiator directory with the sub-directories. 

Both the old and the new WBA Root CAs available from the Wireless Broadband Alliance PKI repository in text (PEM) and binary (DER) format under WBA Root CAs paragraph. The old WBA Root CA is aliased wba-root0 and the new WBA Root CA is aliased wba-root1. Both of these should be installed to the following directories:

• Directory for CA certificates used for verifying inbound OpenRoaming connections from other OpenRoaming ANPs to your server: /etc/radiator/certificates/radsec_inbound_openroaming/ca
• Directory for CA certificates used for verifying the OpenRoaming IdP server certificates for RadSec connections used to authenticate those IdPs users roaming in your network: /etc/radiator/certificates/etc/radiator/certificates/radsec_outbound_openroaming/ca

The retrieval and installation of the new WBA Root CA chain can be done with the following commands on most Linux distributions as a root user or using sudo.

First install the new WBA Root CA to the CA directory for verifying inbound OpenRoaming RadSec connections:

cd /etc/radiator/certificates/radsec_inbound_openroaming/ca
wget https://wballiance.com/wp-content/uploads/2024/05/wba-root1.pem
chown root:radiator wba-root1.pem
chmod 644 wba-root1.pem
openssl rehash -v .

And then install the new WBA Root CA to the CA directory for verifying the IdP servers responding to outbound OpenRoaming RadSec connections:

cd /etc/radiator/certificates/radsec_outbound_openroaming/ca
wget https://wballiance.com/wp-content/uploads/2024/05/wba-root1.pem
chown root:radiator wba-root1.pem
chmod 644 wba-root1.pem
openssl rehash -v .

After installing the certificates, it is recommended to restart the Radiator instances responsible of handling the connections with:

systemctl restart radiator@radsec_inbound_openroaming
systemctl restart radiator@radsec_outbound_openroaming

or all Radiator instances with:

systemctl restart radiator-instances

If you are deploying Radiator OpenRoaming Configuration from scratch, you should also download and install wba-root0.pem from the WBA PKI repository by following the above instructions but replacing the wget command, which retrieves the certificate with:

wget https://wballiance.com/wp-content/uploads/2024/05/wba-root1.pem

All other commands should be executed as described above for both directories.

As a result you now have a Radiator OpenRoaming configuration, which supports both the old and the new WBA Root CA chain. You can read more about Radiator OpenRoaming configuration from the Radiator OpenRoaming Configuration Guide. There are also new useful updates to the Radiator OpenRoaming configuration template files done in January 2025. 

How can I do this with other RADIUS servers?

How and where certificates are set up, depends on the RADIUS server vendor and the configuration, but you should look for ca_dir or CA directory support and instructions if you want to set up similar kind of setup.

Where can I get more help with Radiator OpenRoaming deployment?

Radiator Software provides expert services for Radiator OpenRoaming deployments. Please contact us via email: sales (at) radiatorsoftware.com .

RADIUS news from IETF118

Practically all current Wi-Fi controllers and APs for enterprise and carriers support RADIUS. Mobile network APN and DNN authentication, fixed line fiber-to-the-home gateways and other broadband equipment depend on RADIUS authentication. The industry that uses RADIUS is growing and the standardisation work is active proving RADIUS is in rude health.

The latest Internet Engineering Task Force (IETF) meeting was held earlier this month in Prague, Czechia - with the Radiator team in attendance. RADIUS work is mainly done by the RADIUS EXTensions (radext) working group. The current radext draft documents are related to security enhancements, protocol extensions, maintenance and best practices.

TLS-PSK and RADIUS 1.1

TLS-PSK for RADIUS over TLS and DTLS (also known as RadSec) draft is moving towards the publication phase. The draft has completed its development within the working group. The intended status for the draft is to become an Informational RFC. TLS-PSK greatly eases the configuration of RadSec by using Pre-Shared Keys with TLS instead of certificates.

Closely following the TLS-PSK draft is the draft for RADIUS Version 1.1. This draft is currently in the working group last call phase before it moves on towards publication. With RADIUS Version 1.1, the obsolete methods for RADIUS integrity and authentication are replaced by TLS and DTLS.

RadSec update and depreciation of insecure methods

Other work still in the draft development phase includes an update to RadSec. The update obsoletes the current RFCs for RADIUS over TLS (RFC 6614) and RADIUS over DTLS (RFC 7360) by merging them into a single specification. The draft obsoletes TLS 1.1 and earlier versions, requires TLS-PSK for servers, clarifies the use of DTLS, TLS session resumption, certificate verification and other topics.

Security of RADIUS is updated by a draft that deprecates insecure transport and authentication methods. The draft discusses the problems with unencrypted UDP and TCP transports and common RADIUS authentication methods, such as CHAP. The draft formally deprecates a number of ways these are currently insecurely used. Use of TLS or IPsec transport is now mandated and scope of UDP and TCP transports is reduced.These unsecured transports can be used in secure networks only.

RadSec CoA and Roaming support enhancements

RADIUS dynamic authorisation is updated by a draft that defines how to use existing RadSec connections to send change of authorization (CoA) requests. This allows easier CoA deployments in environments where firewalls, routing or other reasons make it hard to send requests towards a RADIUS client. This specification documents the existing usage that is already implemented by a number of server and client vendors.

Roaming support enhancements are defined in a draft that is currently in working group adoption phase. These enhancements include RADIUS request routing loop detection, remote realm status check and RADIUS request path discovery. This draft is likely approved as a working group draft before the end of the year.

The radext working group is also helping other IETF working groups with draft reviews, liaison work with other organisations, such as Wireless Broadband Alliance (WBA). The working group may continue to work on other documents after the current ones are finished.

What do I gain as a Radiator user?

The new functionality becomes available in Radiator when the drafts are nearing completion. For example TLS-PSK support is made available with the existing RadSec support allowing the Radiator customers to choose between PSK and certificate authentication. As a Radiator user, you will directly benefit from the work we do in the IETF. This will ensure your authentication service stays current and secure and follows the latest standards.

Want to know more?

For status of all current drafts and the working group in general, see https://datatracker.ietf.org/wg/radext/documents/

If you want to know more about Radiator team’s involvement in standardisation or discuss Radiator roadmap items from these drafts, please contact info@radiatorsoftware.com

Connect to OpenRoaming™ with Radiator

Wireless Broadband Alliance (WBA), provides OpenRoaming™, a roaming federation service enabling an automatic and secure Wi-Fi experience globally. It creates a federation of networks and identity providers to enable automatic roaming and user onboarding on Wi-Fi. More information can be found from WBA OpenRoaming™ pages or from the video below.

 

Recently, we have seen developments where carriers and other organisations, such as universities, are embracing OpenRoaming™ for their guest Wi-Fi access. This industry backig and focus on end user experience is one of the key benefits of OpenRoaming™.

As OpenRoaming™ becomes more integrated in the Android and Apple devices, the host organisations do not need to worry about how they will provide guest user credentials for guests. The guests will already authenticate with Apple, Google, participating operators and even in the future with Facebook credentials to guest networks without requiring host organisations to instruct them or provide configuration to their devices. For users, this development would bring significant benefits: secure and easy access to the Wi-Fi network wherever they go.

Radiator Software, being a WBA member and solution provider, can provide your organisation the products and services you need in order to join OpenRoaming™.

Radiator supports OpenRoaming™ requirements

For OpenRoaming™, support both for RadSec and DNSRoaming protocol is needed in order to implement the roaming securely and without extra effort to the end user. Radiator AAA Server supports both these protocols as can be seen from our product page. With RadSec, we are proud to tell that Radiator was the first commercial AAA Server where the protocol was implemented.

At the same time, we have 20 years of experience for providing roaming solutions to our Radiator customers - especially for international roaming federations suchs as eduroam and govroam. For these customers, we can of course provide assistance when joining OpenRoaming™.

Interested in joining OpenRoaming™ using Radiator?

For OpenRoaming™, our team can offer you a complete package: providing the software and the installation and the configuration assistance in order to join OpenRoaming™. After this, with Radiator support, you can ask for any later on assistance needed if for example configuration changes are needed.

Please contact our sales team at sales@radiatorsoftware.com

New feature: OCSP and OCSP stapling support for TLS and EAP

New Radiator version 4.20 introduces support for OCSP and OCSP stapling for TLS based EAP methods (such as EAP-TLS, EAP-TTLS, and EAP-PEAP) and RadSec (TLS encryption for RADIUS over TCP).

OCSP (Online Certificate Status Protocol) is a method for checking certificates' revocation status online and is used as an alternative for CRL (Certificate Revocation List) files. Whereas CRL files needs to be updated every now and then, OCSP uses queries sent to CA (Certificate Authority) to obtain the latest revocation status.

Radiator uses OCSP to query and verify that EAP supplicant's or RadSec peer's certificate has not been revoked and can provide OCSP staple to EAP supplicants and RadSec peers to verify that Radiator's own certificate has not been revoked. More info about OCSP and OCSP staple can be found from the references at the end.

In order to use OCSP with Radiator, following conditions needs to be met:

• Radiator version 4.20 or later
• X.509 certificates and CA used support OCSP
• OpenSSL library version 1.0.0 or later
• Perl Net::SSLeay library version 1.83 or later
• Perl LWP::UserAgent library
• (Optional) Perl HTTP::Async library for asynchronous OCSP queries (supported only with EAP-TLS)

In this blog post, we show two configuration examples how to enable and test OCSP support.

We use demo certificates bundled with Radiator which do support OCSP.
You can check whether your X.509 certificate contains OCSP URL with the commands shown below.

Test client certificate:

% cd path/to/radiator-distribution
% openssl x509 -noout -issuer -subject -ocsp_uri -in certificates/cert-clt.pem
issuer= /C=AU/ST=Victoria/L=Melbourne/O=OSC Demo Certificates/OU=Test Certificate Section/CN=OSC Test CA (do not use in production)/emailAddress=mikem@open.com.au
subject= /C=AU/ST=Victoria/L=Melbourne/O=OSC Demo Certificates/OU=Test Certificate Section/CN=testUser
http://127.0.0.1:8008

Test server certificate:

% cd path/to/radiator-distribution
% openssl x509 -noout -issuer -subject -ocsp_uri -in certificates/cert-srv.pem
issuer= /C=AU/ST=Victoria/L=Melbourne/O=OSC Demo Certificates/OU=Test Certificate Section/CN=OSC Test CA (do not use in production)/emailAddress=mikem@open.com.au
subject= /C=AU/ST=Victoria/L=Melbourne/O=OSC Demo Certificates/OU=Test Certificate Section/CN=test.server.some.company.com
http://127.0.0.1:8008

For testing OCSP, we run OCSP responder provided by OpenSSL library.
Normally, CA who has signed the certificates runs OCSP responder on the Internet.

OCSP responder is run with a command shown below (pass phrase for all demo certificates is "whatever"):

% cd path/to/radiator-distribution/certificates
% openssl ocsp -rsigner root-CA-crt.pem -rkey root-CA-key.pem -index root-CA-idx.txt -port 8008 -CA root-CA-crt.pem -text
Enter pass phrase for root-CA-key.pem:
Waiting for OCSP client connections...

Leave OCSP responder running on http://127.0.0.1:8008/ and waiting for OCSP queries from Radiator.

EAP-TLS OCSP configuration example

Radiator configuration which enables OCSP queries and OCSP stapling for EAP-TLS (there is a similar example config in goodies/eap_tls.cfg):

Foreground
LogStdout
LogDir        .
DbDir         .
# User a lower trace level in production systems:
Trace         4
LogFile       %L/radiator.log

AuthPort 1812
AcctPort 1813

<Client DEFAULT>
      Secret radius
</Client>

<Handler>
      <AuthBy FILE>
            # Users must be in this file to get anywhere
            Filename %D/users
            
            EAPType                   TLS
            EAPTLS_CAFile             %D/certificates/demoCA/cacert.pem
            EAPTLS_CertificateFile    %D/certificates/cert-srv.pem
            EAPTLS_CertificateType    PEM
            EAPTLS_PrivateKeyFile     %D/certificates/cert-srv.pem
            EAPTLS_PrivateKeyPassword whatever
            EAPTLS_MaxFragmentSize    1200
            
            # Online Certificate Status Protocol (OCSP) related
            # configuration parameters

            # Provide OCSP staple for EAP-TLS clients asking for it.
            EAPTLS_OCSPStapling

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

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

            # Reject EAP-TLS client certificate when OCSP responder is unavailable or OCSP status query fails.
            # By default, only a valid OCSP status response can reject EAP-TLS client certificate.
            EAPTLS_OCSPStrict

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

            # If OCSP query to OCSP URI fails, mark OCSP responder failed for 10 minutes.
            EAPTLS_OCSPFailureBackoffTime 600

            # Cache OCSP statuses for 1 hour (defaults to 20 minutes)
            EAPTLS_OCSPCacheTime 3600

            # Cache OCSP status for max 2000 different certificates (defaults to 1000 entries)
            EAPTLS_OCSPCacheSize 2000

            AutoMPPEKeys
      </AuthBy>
</Handler>

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

network={
      ssid="my8021xwpa"
      key_mgmt=WPA-EAP
      eap=TLS
      identity="testUser"
      ca_cert="./certificates/demoCA/cacert.pem"
      client_cert="./certificates/client-crt.pem"
      private_key="./certificates/client-key.pem"
      private_key_passwd="whatever"
      ocsp=2
}

RadSec OCSP configuration example

Besides TLS based EAP methods, OCSP can also be used with RadSec peerings, either with or without OCSP stapling.

Radiator configuration for RadSec client enables OCSP stapling (there is a similar example config in goodies/radsec-client.cfg):

Foreground
LogStdout
LogDir        .
DbDir         .
# User a lower trace level in production systems:
Trace         4

<Client DEFAULT>
      Secret mysecret
</Client>

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

            UseTLS
            TLS_CAFile             %D/certificates/demoCA/cacert.pem
            TLS_CertificateFile    %D/certificates/cert-clt.pem
            TLS_CertificateType    PEM
            TLS_PrivateKeyFile     %D/certificates/cert-clt.pem
            TLS_PrivateKeyPassword whatever

            # Online Certificate Status Protocol (OCSP) related
            # configuration parameters

            # Request OCSP staple from RadSec server.
            TLS_OCSPStapling

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

            # Reject RadSec server certificate when OCSP staple or
            # OCSP responder is unavailable or OCSP status query
            # fails. By default, only a valid OCSP status
            # response can reject RadSec server certificate.
            TLS_OCSPStrict

            <Host localhost>
            </Host>
      </AuthBy>
</Handler>

Radiator configuration for RadSec server which enables OCSP queries and OCSP stapling (there is a similar example config in goodies/radsec-server.cfg):

Foreground
LogStdout
LogDir        .
DbDir         .
# User a lower trace level in production systems:
Trace         4

# Don't listen on any UDP ports
AuthPort
AcctPort

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

      TLS_RequireClientCert
      # Accept any peer with valid cert signed by demoCA for demo
      TLS_ExpectedPeerName .+

      # Online Certificate Status Protocol (OCSP) related
      # configuration parameters

      # Provide OCSP staple for RadSec client requesting it.
      TLS_OCSPStapling

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

      # Reject RadSec client certificate when OCSP staple or OCSP
      # responder is unavailable or OCSP status query fails. By
      # default, only a valid OCSP status response can reject RadSec
      # client certificate.
      TLS_OCSPStrict

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

      # If OCSP query to OCSP URI fails, mark OCSP responder failed for 10 minutes.
      TLS_OCSPFailureBackoffTime 600

      # Cache OCSP statuses for 1 hour (defaults to 20 minutes)
      TLS_OCSPCacheTime 3600

      # Cache OCSP status for max 2000 different certificates (defaults to 1000 entries)
      TLS_OCSPCacheSize 2000
</ServerRADSEC>

<Handler>
      <AuthBy FILE>
            Filename ./users
      </AuthBy>
</Handler>

Radiator acting as RadSec client (AuthBy RADSEC) will connect to Radiator acting as RadSec server (ServerRADSEC) and will request OCSP staple to be returned during TLS handshake. Server will get OCSP response for its own certificate and return it as OCSP staple to the client and when the client has sent its certificate, the server will query its revocation status with OCSP before accepting it.

References

• https://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol
• https://en.wikipedia.org/wiki/OCSP_stapling
• http://www.open.com.au/radiator/history.html
• https://metacpan.org/changes/distribution/Net-SSLeay