Recently, we have seen a transition with many operators evolving from traditional Internet Service Providers (ISPs) to LTE carriers who provide fixed line, WiFi, and mobile connections. At the same time, their needs for authentication, authorization, and accounting (AAA) become more complex. As an example, on top of a standard RADIUS AAA infrastructure, these carriers may need Diameter interfaces and a 3GPP AAA server.
For Radiator customers, we have made this transition as easy as possible - and with the flexibility of Radiator, it is easy to bring it to different infrastructures as a new solution.
How Radiator can help
As many of our customers have evolved from ISPs to LTE Carriers, their needs for different features have evolved at the same time. For these needs, we have developed Radiator Carrier class product line. In order to ensure cost-effective solutions, we offer a modular approach where you can purchase only the components that you will need in your project.
For example, many of our customers have used Radiator for both fixed and WiFi access for years. When they need to enable VoWiFi calling features, they can just add Radiator SIM Module to their network, and in this way, enable different EAP-SIM / EAP-AKA / EAP-AKA’ authentication methods and have a fully featured 3GPP AAA Server in their network as well.
Another example is our Radiator GBA/BSF Module that provides easy authentication for VoLTE supplementary services. This way you can ensure that VoLTE supplementary services (call forwarding, knocking, call barring) are in use in your LTE infrastructure without resorting to 2G/3G infrastructure.
Would you like to know more?
If you are interested in Radiator features such as Diameter interfaces, online charging, VoWiFi, or 3GPP AAA Server, you can find more details in our website or contact our sales team at sales@radiatorsoftware.com. We will be happy to help you with your project.
Thursday, November 15, 2018
Monday, October 15, 2018
Improved support for Hotspots and subscription quotas!
The release will include following new and updated modules which can be used to implement various service provider use cases:
A new module class called 'ServiceDatabase' which handles differentiated services and subscriptions:
- <ServiceDatabase INTERNAL> stores service definitions and subscription data within in-memory.
- <ServiceDatabase SQL> stores service definitions and subscription data within SQL database.
Existing <SessionDatabase INTERNAL> and <SessionDatabase SQL> modules have been updated to work seamlessly with new <ServiceDatabase> modules for RADIUS accounting based quota control.
A new generic <AuthBy HOTSPOT> module which combines <ServiceDatabase>, <SessionDatabase>, an authenticating <AuthBy>, and possible <AuthBy DYNAUTH> (RADIUS Dynamic Authorization) for sending CoA/DM e.g. after a successful authentication or when a quota has been depleted, into a working solution which can be used with captive portals (for example MikroTik) and network access controllers supporting RADIUS. Beside Hotspot use-case, the same solution can also be used to implement a quota control for fixed-line access or cellular APN.
A new <AuthBy HOTSPOTFIDELIO> module based on <AuthBy HOTSPOT> which uses Radiator Fidelio/Opera PMS integration for authenticating and billing guests. Note that <AuthBy HOTSPOTFIDELIO> obsoletes previous <AuthBy FIDELIOHOTSPOT> module.
 |
| Implementing a guest network access with Radiator using Fidelio/Opera PMS integration. |
Examples
To demonstrate how new <AuthBy HOTSPOT> and <AuthBy HOTSPOTFIDELIO> combine these new features, see a following configuration examples of new Radiator Hotspot functionality:Example 1. Using in-memory <ServiceDatabase INTERNAL> and <SessionDatabase INTERNAL> with <AuthBy HOTSPOT> and <AuthBy FILE>
# See goodies/hotspot.cfg for a full example config ... ### Service and Session databases ### # ServiceDatabase INTERNAL for Services and Subscriptions <ServiceDatabase INTERNAL> Identifier ServiceDatabase-INTERNAL # Service definitions # Service 1: free, 1 hour, 50M data, no policers Service name:free price:0 prepaidTime:1h prepaidQuota:50M replyItems:"OSC-AVPAIR=Test1,OSC-AVPAIR=Test2" # Service 2: price 1000 cents, 1 day, 100M data, 100M/10M policers Service name:premium price:1000 prepaidTime:24h prepaidQuota:100M prepaidUpRate:10M prepaidDownRate:100M # Service 3: price 2000 cents, 1 day, 1G data, 100M/100M policers Service name:gold price:2000 prepaidTime:24h prepaidQuota:1G prepaidUpRate:100M prepaidDownRate:100M </ServiceDatabase> # SessionDatabase INTERNAL for Sessions <SessionDatabase INTERNAL> Identifier SessionDatabase-INTERNAL </SessionDatabase> ... ### AuthBy Modules ### # Authenticate Hotspot users with AuthBy FILE <AuthBy FILE> Identifier AuthBy-FILE Filename %D/users NoDefault </AuthBy> <AuthBy HOTSPOT> Identifier AuthBy-HOTSPOT # Authenticate Hotspot users with AuthBy FILE AuthBy AuthBy-FILE # Use ServiceDatabase-INTERNAL for services and subscriptions ServiceDatabase ServiceDatabase-INTERNAL # Lookup a subscription based on username (%1) and Calling-Station-Id MAC address SubscriptionId %1-%{Calling-Station-Id} # Use SessionDatabase-INTERNAL for sessions SessionDatabase SessionDatabase-INTERNAL # Lookup a session based on username (%1) and Calling-Station-Id MAC address SessionId %1-%{Calling-Station-Id} # Empty SessionAttribute SessionAttribute # If RADIUS accounting will be used for quota monitoring, # create a new session upon a successful authentication #PreProvisionSession # Alternatively, reply with remaining time quota #UsageMonitoring # and remaining data quota #ReplyWithDataQuota #DataLimitAttribute Mikrotik-Total-Limit #DataLimitGigawordsAttribute Mikrotik-Total-Limit-Gigawords # Use service 'free' as a default service DefaultService free ServiceAttribute OSC-Service-Identifier #ServiceAttributePrefix Service= </AuthBy> # AuthBy DyNAUTH for creating DM/CoA requests for exceeded sessions <AuthBy DYNAUTH> Identifier AuthBy-DYNAUTH SessionDatabase SessionDatabase-INTERNAL # Send Change-Filter-Request (CoA) to NAS UDP port 3799 #RequestType Change-Filter-Request # Send Disconnect-Request (DM) to NAS UDP port 3799 RequestType Disconnect-Request DynAuthPort 3799 # Do not try to lookup a session again NoSessionMapping # Send CoA/DM to IP address within NAS-IP-Address RADIUS attribute NasAddrAttribute NAS-IP-Address # Identify user session by User-Name, Acct-Session-Id and NAS-Port DynAuthAttribute User-Name DynAuthAttribute Acct-Session-Id DynAuthAttribute NAS-Port </AuthBy> # AuthBy RADIUSBYATTR for sending out DM/CoA requests for exceeded sessions <AuthBy RADIUSBYATTR> Identifier AuthBy-RADIUSBYATTR </AuthBy> ### Request Handlers ### # Accounting Handler <Handler Request-Type=Accounting-Request> Identifier Accounting-Handler # Acknowledge Accounting-Request immediately AccountingAccepted AuthByPolicy ContinueUntilRejectOrChallenge # Handle RADIUS accounting AuthBy AuthBy-HOTSPOT # Send DM/CoA request for exceeded session AuthBy AuthBy-DYNAUTH </Handler> # Outgoing DM/CoA Handler <Handler DynAuthRequest=1> Identifier Handler-DYNAUTH AuthBy AuthBy-RADIUSBYATTR </Handler> # Default Handler <Handler> Identifier Default-Handler # Handle RADIUS authentication AuthBy AuthBy-HOTSPOT RejectHasReason </Handler>
# See goodies/hotspot-fidelio.cfg for a full example config
#
# Requires SQL definitions from goodies/hotspot.sql and goodies/hotspot-fidelio.sql
# See goodies/README.hotspot-fidelio for more information
#
...
### Service and Session databases ###
# ServiceDatabase SQL for Services and Subscriptions
<ServiceDatabase SQL>
Identifier ServiceDatabase-SQL
# Details of how to contact the service and subscription database
DBSource dbi:SQLite:dbname=hotspot.db
#DBSource dbi:mysql:hotspot
DBUsername mikem
DBAuth fred
</ServiceDatabase>
# SessionDatabase SQL for Sessions
<SessionDatabase SQL>
Identifier SessionDatabase-SQL
# Details of how to contact the session database
DBSource dbi:SQLite:dbname=hotspot.db
#DBSource dbi:mysql:hotspot
DBUsername mikem
DBAuth fred
# Modified SQL queries/statements for a new session database schema (goodies/hotspot.sql)
CountQuery SELECT nas_id, nas_port, id, ipv4 FROM SESSIONS WHERE user_name=%0
ClearNasQuery DELETE FROM SESSIONS WHERE nas_id='%0'
AddQuery
DeleteQuery
ClearNasSessionQuery
</SessionDatabase>
...
### AuthBy Modules ###
<AuthBy HOTSPOTFIDELIO>
Identifier AuthBy-HOTSPOTFIDELIO
# Use ServiceDatabase-SQL for services and subscriptions
ServiceDatabase ServiceDatabase-SQL
# Lookup a subscription based on username (%1), Fidelio PMS Guest Number (%2) and Calling-Station-Id MAC address
SubscriptionId %1-%2-%{Calling-Station-Id}
# Use SessionDatabase-SQL for sessions
SessionDatabase SessionDatabase-SQL
# Lookup a session based on username (%1), Class (%3) and Calling-Station-Id MAC address
SessionId %1-%3-%{Calling-Station-Id}
# Empty SessionAttribute
SessionAttribute
# If RADIUS accounting will be used for quota monitoring,
# create a new session upon a successful authentication
PreProvisionSession
# Alternatively, reply with remaining time quota
#UsageMonitoring
# and remaining data quota
#ReplyWithDataQuota
#DataLimitAttribute Mikrotik-Total-Limit
#DataLimitGigawordsAttribute Mikrotik-Total-Limit-Gigawords
# Details of how to contact the Fidelio posting database
# See AuthSQL for details
DBSource dbi:SQLite:dbname=hotspot.db
#DBSource dbi:mysql:hotspot
DBUsername mikem
DBAuth fred
# Fidelio PMS interface
Protocol tcp
Port 5010
Host localhost
# Validity time in seconds of plan purchased
# Default 86400 seconds (1 day)
BlockDuration 86400
# Default price for plan
# Price in database overrides this value
BlockPrice 900
# ServiceAttribute defines the RADIUS attribute that is
# used select the desired prepaid service or plan. On
# Mikrotik login page you can create a menu as shown
# below to display the different purchase
# options. Note: "name=radius0-9048" is OSC-AVPAIR.
# <tr><td>Service:</td><td>
# <select name="radius0-9048">
# <option value="Mikrotik-Service=free">best effort (free) </option>
# <option value="Mikrotik-Service=premium">premium ($5)</option>
# </select></td></tr>
ServiceAttribute OSC-AVPAIR
# If it is possible that there are multiple instances
# of the ServiceAttribute in the request, you can use
# an optional prefix to choose the correct instance.
ServiceAttributePrefix Mikrotik-Service=
# By default upgrade or renewal of the current plan is
# automatically processed and charged. With this option
# you can ask the guest to confirm the charge first.
# With Mikrotik you can show the message to the guest
# by including
# $(if error)<br /><div style="color: #FF8080; font-size: 14px">$(error)</div><br>$(endif)
# on the Mikrotik login page
#ConfirmUpgradeOrRenew
#ConfirmationMessage "You are going to upgrade or renew your plan, please login again to confirm the charge"
# This one uses the last part of the guest name (case sensitive) as the
# password. This is usually the guest surname
UserPasswordHook sub {my @n = split(/\s/, $_[1]->{'GN'}); return $n[$#n];}
# Need this to ensure the Guest Number is included in the postings
# Required when there are multiple guests per room
#PostingExtraFields G#,%4
# You can add extra attributes in the reply here if you wish
# to set limits or controls over access
#AddToReply Mikrotik-Recv-Limit-Gigawords=1,Mikrotik-Xmit-Limit-Gigawords=1
</AuthBy>
# AuthBy DyNAUTH for creating DM/CoA requests for exceeded sessions
<AuthBy DYNAUTH>
Identifier AuthBy-DYNAUTH
SessionDatabase SessionDatabase-SQL
# Send Change-Filter-Request (CoA) to NAS UDP port 1700
#RequestType Change-Filter-Request
# Send Disconnect-Request (DM) to NAS UDP port 1700
RequestType Disconnect-Request
DynAuthPort 1700
# Do not try to lookup a session again
NoSessionMapping
# Send CoA/DM to IP address within NAS-IP-Address RADIUS attribute
NasAddrAttribute NAS-IP-Address
# Identify user session by User-Name, Acct-Session-Id and NAS-Port
DynAuthAttribute User-Name
DynAuthAttribute Acct-Session-Id
DynAuthAttribute NAS-Port
</AuthBy>
# AuthBy RADIUSBYATTR for sending out DM/CoA requests for exceeded sessions
<AuthBy RADIUSBYATTR>
Identifier AuthBy-RADIUSBYATTR
</AuthBy>
### Request Handlers ###
# Accounting Handler
<Handler Request-Type=Accounting-Request>
Identifier Accounting-Handler
# Acknowledge Accounting-Request immediately
AccountingAccepted
AuthByPolicy ContinueUntilRejectOrChallenge
# Handle RADIUS accounting
AuthBy AuthBy-HOTSPOTFIDELIO
# Send DM/CoA request for exceeded session
AuthBy AuthBy-DYNAUTH
</Handler>
# Outgoing DM/CoA Handler
<Handler DynAuthRequest=1>
Identifier Handler-DYNAUTH
AuthBy AuthBy-RADIUSBYATTR
</Handler>
# Default Handler
<Handler>
Identifier Default-Handler
# Use SessionDatabase-SQL
SessionDatabase SessionDatabase-SQL
# Don't try to delete a session before authentication
SessionDatabaseOptions NoDeleteBeforeAuthentication
# Handle RADIUS authentication
AuthBy AuthBy-HOTSPOTFIDELIO
RejectHasReason
</Handler>
Tuesday, September 18, 2018
Radiator as a Cisco ACS replacement
Since Cisco announced the end of sale of their Secure Access Control System (Cisco ACS), customers have contacted Radiator Software looking for a replacement solution, and they have found Radiator AAA Server Software to be just the alternative they need. Radiator is a cost-effective, flexible solution that is known in the market as the “Swiss Army of AAA Servers”.
Radiator AAA Server Software is actively developed and it runs with a variety of platforms, including Linux, Windows, and others. You can be sure that you will have a supported, continuously developed AAA solution that is always kept up to date for years to come. Radiator has at least two releases per year, with interim patches made for security and other urgent needs.
Making it a flexible solution with multi-vendor support, key features of Radiator include:
- Supports authentication by over 60 different types of methods
- Interoperates with a huge range of devices, databases, billing packages, and tokens
- Includes RadSec - secure, reliable RADIUS proxying
- Includes Diameter - the RADIUS successor protocol used already by mobile operators
- Includes TACACS+ - for infrastructure management
- Integration with AD, LDAP, SQL databases among others
- Accounting logs in variety of formats to be integrated with external systems
- See also full feature list
How migration to Radiator works?
When doing the migration to Radiator, you do not need to have new appliances; Radiator can be cost-efficiently fitted into your current infrastructure.
All you need is to install Radiator into your preferred platform, implement the initial configuration, and integrate Radiator to your preferred database. The use of a separate database enables your organization a secure way to store user credentials and data. Additionally, it is possible to include management and logging systems, which you may already have in use. When doing the migration, our team can provide you with assistance and experience from a wide range of use cases.
 |
| Typical Radiator set-up in a Wi-Fi authentication use case using RADIUS and TACACS+. |
You do not need to worry about complicated licensing; all you need is a Radiator AAA Server Software license pack, available from one server license, two server license for high-availability, and unlimited server count license for large scale deployments. If you need an additional AAA server for a different use case within your organization, you can use a remaining available license, or upgrade your existing pack.
Would you like to know more?
With Radiator, you get direct professional technical support for configuration, deployment, and custom development. Our support packages range from basic email support to 24x7 telephone support.
Our consulting services are available to assist with migration projects. As we have had a wide range of customers with different needs migrating to Radiator, we can easily tailor a cost-effective consulting package for your needs. Thanks to our experience with similar projects, Radiator configuration can be adjusted to new environments without any extra hassle. Our customers include ISPs, enterprises, carriers, universities, public organizations, and utility companies.
If you would like to know more about Radiator, licensing options, and support, please contact our team at sales@radiatorsoftware.com
Blog post revised Feb 2nd 2022.
Thursday, September 6, 2018
Radiator GBA/BSF Module: Seamless authentication to VoLTE Supplementary services
VoLTE (Voice over LTE) calling is now being used by mobile carriers in their networks all over the world.
With VoLTE calling, there is no dependency on the legacy circuit-switched voice network to be maintained, which has many benefits for the carrier infrastructure. As a part of this, the carrier network will need an easy way to authenticate also to VoLTE supplementary services, such as call forwarding, knocking and call barring.
For this need, we have created Radiator GBA/BSF Module on top of our Radiator. Radiator GBA/BSF Module makes authentication for VoLTE supplementary services easy by using General Bootstrapping Architecture (GBA). In addition to this GBA enables also extending SIM authentication to any operator WWW services. In addition, SIM authentication itself has authentication federation support, which can be used to produce services across virtual and other operators.
Our product, Radiator GBA/BSF Support Module works as an authentication proxy between the end-user UE and HSS. It authenticates user requests, and also separates the authentication procedure and the Application Specific server (AS) specific application logic to different logical entities.
Main technical product features
Radiator GBA/BSF Module is already being used in live networks in multiple countries. The main technical features include:
With VoLTE calling, there is no dependency on the legacy circuit-switched voice network to be maintained, which has many benefits for the carrier infrastructure. As a part of this, the carrier network will need an easy way to authenticate also to VoLTE supplementary services, such as call forwarding, knocking and call barring.
For this need, we have created Radiator GBA/BSF Module on top of our Radiator. Radiator GBA/BSF Module makes authentication for VoLTE supplementary services easy by using General Bootstrapping Architecture (GBA). In addition to this GBA enables also extending SIM authentication to any operator WWW services. In addition, SIM authentication itself has authentication federation support, which can be used to produce services across virtual and other operators.
Our product, Radiator GBA/BSF Support Module works as an authentication proxy between the end-user UE and HSS. It authenticates user requests, and also separates the authentication procedure and the Application Specific server (AS) specific application logic to different logical entities.
 |
| Radiator GBA/BSF Architecture |
Main technical product features
Radiator GBA/BSF Module is already being used in live networks in multiple countries. The main technical features include:
- Authenticating LTE subscribers for VoLTE supplementary services such as multimedia telephony service (MMTel) and multimedia telephony application server (MTAS)
- BSF server (Ub interface)
- Authenticating Proxy (NAF/AP, Ut/Ua interface)
- Interoperable with all major EPC vendors (Nokia, Ericsson, Huawei)
- Interoperable with all major handset vendors (Samsung/Android, Apple, Nokia, Microsoft)
Recently we introduced release 1.5.0 of Radiator GBA/BSF Module, with more focus on configuration examples and installation process - making it even easier product to implement in different carrier infrastructures. Our team at info@radiatorsoftware.com is happy to share with more info about our Radiator GBA/BSF Module product.
Friday, August 31, 2018
Radiator interacting with Microsoft Azure Multi-Factor Authentication
One of Radiator’s key strengths is flexibility in different environments and authentication use cases.
Recently, a customer had a new case for authenticating network device administrators with Microsoft Azure Multi-Factor Authentication (MFA). The devices use TACACS+ and a solution was required to integrate with Azure MFA Radius. Thanks to the flexibility of Radiator, this can be done without any extra hassle.
When a user logs in, the device sends the username, static password and one-time passcode with TACACS+ authentication request to Radiator. Radiator processes the TACACS+ request and starts MFA authentication by first sending the password as RADIUS Access-Request. Azure MFA responds by replying with Access-Challenge prompting for the passcode. In turn, Radiator responds with password reminder (passcode of 6 numbers) to complete the authentication.
After this, authentication REPLY is delivered to the TACACS+ client and access is granted.
Would you like to know more?
In many recent customer cases, we have implemented various authentication solutions to interact with Microsoft Azure, including the Multi-Factor Authentication use case mentioned above. We are happy to tell more about this and other use cases. If you would like to know more, please contact info@radiatorsoftware.com
Recently, a customer had a new case for authenticating network device administrators with Microsoft Azure Multi-Factor Authentication (MFA). The devices use TACACS+ and a solution was required to integrate with Azure MFA Radius. Thanks to the flexibility of Radiator, this can be done without any extra hassle.
When a user logs in, the device sends the username, static password and one-time passcode with TACACS+ authentication request to Radiator. Radiator processes the TACACS+ request and starts MFA authentication by first sending the password as RADIUS Access-Request. Azure MFA responds by replying with Access-Challenge prompting for the passcode. In turn, Radiator responds with password reminder (passcode of 6 numbers) to complete the authentication.
After this, authentication REPLY is delivered to the TACACS+ client and access is granted.
Would you like to know more?
In many recent customer cases, we have implemented various authentication solutions to interact with Microsoft Azure, including the Multi-Factor Authentication use case mentioned above. We are happy to tell more about this and other use cases. If you would like to know more, please contact info@radiatorsoftware.com
Thursday, June 28, 2018
Radiator 4.21 now available
We are happy to announce that Radiator 4.21 has been released. This release covers a number of enhancements, bug fixes, and some new features. Here are some examples:
- Fixed nested and cascaded AuthBy GROUPs that stopped working in Radiator 4.20.
- Unified AuthBy HANDLER functionality and reverted some of its changes done in Radiator 4.20.
- JSON authentication and accounting log now formats time as numeric type instead of string.
- ServerTACACSPLUS connection handling had major updates.
For a detailed list of changes, visit the Radiator revision history page.
Tuesday, May 22, 2018
RAdmin version 1.16 is released
We are pleased to announce that RAdmin version 1.16 is now released. RAdmin is our tool for managing RADIUS users. With RAdmin you can check usage summaries, drill down to usage details and much more that is needed when managing your RADIUS traffic and users.
For this revision, we have implemented one key security fix, multiple bug fixes and and other enhancements. With 2-factor authentication, for example, support for using Yubikey 2-factor authentication tokens has now been updated. This release allows our customers to be sure that the software we provide is up-to-date and can be run on the current Windows, Linux and other platforms.
For detailed list of enhancements, please see RAdmin revision history.
New features
In addition of providing new bugfixes, version 1.16 also provides new enhancements for RAdmin UI. One example of these is providing a better way to listing usage of different users and sessions (see picture below). In addition other new usability and UI fixes are now available in order to provide a user-friendly way for managing network users.
Would you like to know more?
We are happy to provide RAdmin, like other Radiator products for evaluation.
RAdmin is designed especially for ISPs, CSPs and other companies or organizations that have the need to manage their RADIUS users. When contacting our sales team at info@radiatorsoftware.com we are happy to provide more info about use cases for Radiator and RAdmin.
For this revision, we have implemented one key security fix, multiple bug fixes and and other enhancements. With 2-factor authentication, for example, support for using Yubikey 2-factor authentication tokens has now been updated. This release allows our customers to be sure that the software we provide is up-to-date and can be run on the current Windows, Linux and other platforms.
For detailed list of enhancements, please see RAdmin revision history.
New features
In addition of providing new bugfixes, version 1.16 also provides new enhancements for RAdmin UI. One example of these is providing a better way to listing usage of different users and sessions (see picture below). In addition other new usability and UI fixes are now available in order to provide a user-friendly way for managing network users.
Would you like to know more?
We are happy to provide RAdmin, like other Radiator products for evaluation.
RAdmin is designed especially for ISPs, CSPs and other companies or organizations that have the need to manage their RADIUS users. When contacting our sales team at info@radiatorsoftware.com we are happy to provide more info about use cases for Radiator and RAdmin.
Wednesday, February 28, 2018
Radiator 4.20 now available!
We are happy to announce that Radiator 4.20 is published today!
The new version has dozens of improvements, new features, and bug fixes. Here are some examples:
– OCSP and OCSP stapling support, see the blog post
– Certificate check enhancements
– Better support for asynchronous operations
– Several security improvements
– Security fix for certificate validation for EAP-TLS and TLS-based Stream modules
– Possibility to include extra checks with new ServerTACACSPLUS AuthorizeGroups parameter
– TLS 1.3 awareness
– New module AuthBy RATELIMITSOURCE
– Improved LDAP functionality
– New hooks, such as EAPTLS_CertificateVerifyFailedHook and ForwardHook
For a detailed list of changes, see Radiator revision history page.
The new version has dozens of improvements, new features, and bug fixes. Here are some examples:
– OCSP and OCSP stapling support, see the blog post
– Certificate check enhancements
– Better support for asynchronous operations
– Several security improvements
– Security fix for certificate validation for EAP-TLS and TLS-based Stream modules
– Possibility to include extra checks with new ServerTACACSPLUS AuthorizeGroups parameter
– TLS 1.3 awareness
– New module AuthBy RATELIMITSOURCE
– Improved LDAP functionality
– New hooks, such as EAPTLS_CertificateVerifyFailedHook and ForwardHook
For a detailed list of changes, see Radiator revision history page.
Monday, February 26, 2018
Radiator team in Mobile World Conference 2018
Radiator team is present at Mobile World Conference in Barcelona on 26 February – 1 March.
Come to meet us in hall 3 (3B10), Finland Pavilion and discuss newest features of Radiator and Radiator VNF or learn about the latest use cases. We can also arrange a meeting with you, please contact Jaakko Stenhäll (jaakko.stenhall@radiatorsoftware.com) for more details.
Come to meet us in hall 3 (3B10), Finland Pavilion and discuss newest features of Radiator and Radiator VNF or learn about the latest use cases. We can also arrange a meeting with you, please contact Jaakko Stenhäll (jaakko.stenhall@radiatorsoftware.com) for more details.
Monday, February 19, 2018
Working together: Radiator AAA Server and Authus Network Security Solution
Our partners use Radiator® widely in their own solutions. Here we introduce you Authus network security solution, provided by our partner company HenZ ICT.
Authus uses Radiator AAA Server for fast, reliable, and stable authentication. Like Authus, Radiator is platform-independent, which makes the combined solution flexible to integrate into different environments. Radiator performs the initial authentication within Authus network security solution.
After the initial authentication, Network Access Engine determines whether a client is permitted access to the network and with which type of profile. The decisions are based on the Authus Validation Rules. The profile defines which VLAN (Virtual LAN) the client gets access.
Furthermore, Authus includes Reporting Engine, which uses a database to store AAA (Authentication, Authorisation, Accounting) information. Based on this data, dashboards show the status and operation of the Authus system. Authus offers also other functionalities for support purposes, such as trace functionality and dashboards on transaction level.
Key benefits for the customer
The combined solution, where Radiator and Authus are interoperating, provides multiple key benefits, such as:
Would you like to know more?
If you are interested to know more about use of Radiator with Authus or the combined solution, please do not hesitate to contact our Radiator sales team at info@radiatorsoftware.com. Also, you can contact Authus team at info@henz.nl.
Authus uses Radiator AAA Server for fast, reliable, and stable authentication. Like Authus, Radiator is platform-independent, which makes the combined solution flexible to integrate into different environments. Radiator performs the initial authentication within Authus network security solution.
 |
| Architecture of Radiator and Authus working together |
After the initial authentication, Network Access Engine determines whether a client is permitted access to the network and with which type of profile. The decisions are based on the Authus Validation Rules. The profile defines which VLAN (Virtual LAN) the client gets access.
Furthermore, Authus includes Reporting Engine, which uses a database to store AAA (Authentication, Authorisation, Accounting) information. Based on this data, dashboards show the status and operation of the Authus system. Authus offers also other functionalities for support purposes, such as trace functionality and dashboards on transaction level.
Key benefits for the customer
The combined solution, where Radiator and Authus are interoperating, provides multiple key benefits, such as:
- Better network security
- Low cost of network management
- High degree of flexibility for your infrastructure
- Better reporting for your network
Would you like to know more?
If you are interested to know more about use of Radiator with Authus or the combined solution, please do not hesitate to contact our Radiator sales team at info@radiatorsoftware.com. Also, you can contact Authus team at info@henz.nl.
Wednesday, February 7, 2018
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:
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:
Test server certificate:
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"):
Leave OCSP responder running on http://127.0.0.1:8008/ and waiting for OCSP queries from Radiator.
Radiator configuration which enables OCSP queries and OCSP stapling for EAP-TLS (there is a similar example config in goodies/eap_tls.cfg):
wpa_supplicant / eapol_test configuration for EAP-TLS which requires OCSP staple:
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):
Radiator configuration for RadSec server which enables OCSP queries and OCSP stapling (there is a similar example config in goodies/radsec-server.cfg):
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.
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
Monday, January 15, 2018
Radiator use case: Secure authentication to network devices in corporate network
Radiator AAA Server Software has countless use cases in enterprises. This blog text introduces you a specific use case of real life: authentication of network administrators who configure and maintain corporate network infrastructure. This requires extra security that Radiator is able to provide.
In the example use case, the admins log in to Broadband Network Gateways (BNG) with TACACS+ protocol using their own authentication credentials and passwords. For essential network equipment, a secure two-factor authentication (2FA) is used. Radiator supports a wide range of interfaces for these kinds of authentication use cases. Our customers are free to choose the interfaces and protocols that suit to their own needs.
LDAP user database provides the first factor authentication in the example use case. The second factor is handled by Duo Security.
With AuthBy DUO module, you can configure Radiator to integrate with Duo Security API, which in this case provides the second phase of authentication with Duo Security’s phone application. After the authentication has been confirmed by the application, Radiator will grant access to the network.
Using different 2FA solutions
In addition to TACACS+ protocol, Radiator supports wide range of different authentication protocols that you can use – including RADIUS. It is also possible to use different methods for the first factor authentication and second factor authentication. Radiator supports a number of interfaces suitable for the second factor authentication, and we already have use cases with several different solutions. These interfaces are included in Radiator licences.
If you have any needs for two-factor authentication in your own network, please contact our team at info@radiatorsoftware.com. We are happy to share our experience and help you with your own project.
Updated 6th of February 2018:
You can also learn more about the technical architecture from our earlier post: Secure your network and services with Radiator two-factor authentication.
In the example use case, the admins log in to Broadband Network Gateways (BNG) with TACACS+ protocol using their own authentication credentials and passwords. For essential network equipment, a secure two-factor authentication (2FA) is used. Radiator supports a wide range of interfaces for these kinds of authentication use cases. Our customers are free to choose the interfaces and protocols that suit to their own needs.
LDAP user database provides the first factor authentication in the example use case. The second factor is handled by Duo Security.
With AuthBy DUO module, you can configure Radiator to integrate with Duo Security API, which in this case provides the second phase of authentication with Duo Security’s phone application. After the authentication has been confirmed by the application, Radiator will grant access to the network.
Using different 2FA solutions
In addition to TACACS+ protocol, Radiator supports wide range of different authentication protocols that you can use – including RADIUS. It is also possible to use different methods for the first factor authentication and second factor authentication. Radiator supports a number of interfaces suitable for the second factor authentication, and we already have use cases with several different solutions. These interfaces are included in Radiator licences.
If you have any needs for two-factor authentication in your own network, please contact our team at info@radiatorsoftware.com. We are happy to share our experience and help you with your own project.
Updated 6th of February 2018:
You can also learn more about the technical architecture from our earlier post: Secure your network and services with Radiator two-factor authentication.
Subscribe to:
Posts (Atom)