This document discusses features of the Radiator RADIUS server software that help ensure compliance and functionality for eduroam and govroam federated authentication. It outlines Radiator's support for status-server, RadSec, EAP context preserving load balancing, advanced username/realm routing and rewriting, loop prevention, and dynamic configuration via database backends. Specific examples are provided for how Radiator has helped organizations in the UK comply with govroam requirements around realm manipulation and routing to Active Directory. Maintaining compliance with standards and addressing challenges like loop prevention are emphasized.

1. TNC19 Radiator technical
workshop
Using Radiator to ensure better SP/IdP connections
to eduroam/govroam

2. Ensuring compliance with Radiator
Radiator has support for several
required or useful functionalities:
● Status-Server (for IdP, SP and
TLR)
● RadSec
● EAP context preserving load
balancing
● Username/realm routing,
rewriting and mangling
● Loop prevention
● Multiple database backends to
help with dynamic
configuration

3. Status-Server (for IdP, SP and TLR)
● Many RADIUS requests in roaming federation do not receive
responses.
● Some reasons for this are: firewalling, configuration errors, TLS
errors, Microsoft NPS…
● When some RADIUS servers do not receive response from their
neighbour, they mark that neighbour dead, which causes outages
for example when top-level RADIUS servers are accidentally
marked dead.

4. Status-Server (for IdP, SP and TLR)
● Status-Server is a standard RADIUS message to test
RADIUS connection without relying to access requests
● Unfortunately Status-Server is supported for certain only in
Radiator, stand-alone FreeRADIUS and radsecproxy.
● Because of this Radiator now has also support for RADIUS
Access Request based availability testing.

5. Transport Layer Security (TLS) Encryption for RADIUS (RFC
6614) also known as RadSec
● Designed by TNC people: S. Winter (Restena), M.
McCauley (OSC/Radiator), S. Venaas (Cisco), K.
Wierenga (Cisco)
● Supported by Radiator since early drafts, supported
also by FreeRADIUS and radsecproxy.
● Secures plain RADIUS traffic with TLS for added privacy

6. ● We work together with eduroam people to develop
RadSec support in Radiator further. Thanks especially
to Paul Dekkers and Stefan Winter for their feedback
and bug reports.
● Please note that in afternoon after Radiator
workshop there will be a presentation in Mobility Day
track about NRO/TLR RADIUS servers adopting
RadSec connections.

7. EAP context preserving load balancing
● Not many load balancers understand RADIUS protocol and
even fewer can preserve EAP context needed for WPA2
enterprise (eduroam/govroam) authentication.
● Extra attention must be focused in configuring load balancing so
that RADIUS packets belonging to same authentication end
up to the same EAP endpoint.

8. EAP context preserving load balancing
● Most common way to solve this is to fix load balancing
decision to the RADIUS client source IP address. This may not
be enough to spread the traffic efficiently.
● Radiator supports load balancing with features like
HASHBALANCE. EAPBALANCE considered harmful nowadays.
● HASHBALANCE can be done based on for example
Called-Station-Id/Calling-Station-Id resulting more even
distribution.

9. Username/realm routing, rewriting and mangling
● Using federated RADIUS roaming requires that
RADIUS server can do sometimes complex username
and realm based RADIUS request routing.
● Often and especially when using backends like Active
Directory, username/realm rewriting and mangling
needs to be done by RADIUS server to ensure
roaming and authentication functionality.

10. Username/realm routing
● Radiator already has advanced username/realm
routing features such as storing realm routing
information into SQL/SQLite databases.
● We are constantly improving Radiator’s
username/realm routing capabilities. Next on our
development list is RealmTable.

11. Govroam(UK) example with Radiator
● Windows domain LOCAL is
not unique => it is not
routable in govroam
● Windows cannot set outer
EAP realm to differ from the
inner realm
● Microsoft NPS RADIUS
cannot manipulate
usernames/realms properly

12. Govroam(UK) example with Radiator
● User terminals are configured to
use unique realm for
organisation => govroam
routing works
● Radiator uses AuthBy LSA to
communicate directly with Active
Directory
● Radiator switches the realm to
local value and authenticates the
user against Active Directory.
● Radiator AuthBy LSA makes
MSCHAP(v2)/PEAP work
whatever the internal AD
domain would be.
Microsoft NPS was
replaced with Radiator
running on top of
Windows. Linux with
Radiator and ntlm_auth
is likely to work as well.

13. Loop prevention
● A loop forms e.g. when organisation proxies back a RADIUS
request, which higher level RADIUS server has sent to it.
● Additional configuration and functionality is needed in the
regional/federation RADIUS proxies to detect and prevent
loops.
● All this adds more complexity to the federation, when there
are ways for IdPs to prevent loops from their end.

14. Loop prevention
● eduroam community has already provided configurations
for example for Radiator to prevent loops and empty
realms to be forwarded:
https://wiki.geant.org/display/H2eduroam/radiator-flr
● Please follow eduroam configuration recommendations
if your RADIUS software supports them -- and consider
using more compliant RADIUS software as a proxy, if your
IdP RADIUS cannot follow or configure them.

15. Dynamic configuration
● Manipulating RADIUS clients and realms within
text configuration is error-prone and requires
usually restarts creating at least short outages.
● Text configuration in Radiator is also slower than
for example having realm information in SQL(ite).

16. Dynamic configuration
● Radiator can retrieve a major part of its configuration
information from for example SQL(ite) databases.
● Those databases can then be managed separately from
Radiator configuration and processes.
● Dynamically retrieved configuration from SQL(ite)
databases, reduces the need for editing configuration
files or restarting processes.

17. Wrap-up -- Radiator advantage
Radiator has support for several
required or useful functionalities:
● Status-Server (for IdP, SP and
TLR)
● RadSec
● EAP context preserving load
balancing
● Username/realm routing,
rewriting and mangling
● Loop prevention
● Multiple database backends to
help with dynamic
configuration

18. Thank you. Questions, comments?
For more information, remember to check out ...
Radiator Cookbook
blog.radiatorsofware.com
And Twitter
@OSCRadiator