An eduroam federation comes with administrative requirements as well as technical ones. This document uses the eduroam Compliance Statement and the European Configuration definitions and documents; which provide a the baseline for the world-wide eduroam community.
Operating a federation involves managing and supervising eduroam Identity Providers, eduroam Service Providers, as well as keeping authentication logs, fulfilling uptime requirements, etc. Prospect federation operators should read and understand the requirements in DS5.1.1 ("eduroam Service Definition and Implementation Plan") at http://www.eduroam.org/downloads/docs/GN2-07-327v2-DS5_1_1-_eduroam_Service_Definition.pdf, particularly sections 4.1.4 ("Roles and Responsibilities - NROs") and section 6 ("Requirements on Confederation Members").
A prospect NRO also needs to commit to the eduroam policy. The European eduroam policy document can be found at https://www.eduroam.org/wp-content/uploads/2016/05/GN3-12-194_eduroam-policy-for-signing_ver2-4_1_18052012.pdf
The RO may outsource the operation of its technical infrastructure (particularly, the Federation Level RADIUS servers) to a third-party, but will remain responsible for eduroam within its service area.
A Roaming Operator (RO) must maintain a comprehensive overview over eduroam within its service area, and report about its federation's state regularly. The vehicle for such reports is the eduroam database, where information about the RO and all its eduroam SPs and IdPs is stored. The database web interface is open for eduroam operators only; the entry page can be found here: http://monitor.eduroam.org/db_web/
Generic information on how to deliver information to the eduroam database (XML Schema format) can be found here: http://monitor.eduroam.org/database.php
Federation Level RADIUS (FLR) servers are used to connect eduroam Identity Providers and eduroam Service Providers with each other, and also provide an uplink from the federation to all other eduroam federations. They are managed by Roaming Operators (ROs). The RO may outsource the operation to a third-party, but will remain responsible.
Since the concept of an eduroam federation geographically usually maps to a territory or economy, FLRs are central to the deployment of eduroam; there is conceptually only one FLR per RO territory - but for resiliency reasons, it is recommended to provide multiple instances in a failover setup.
An eduroam federation comes with administrative requirements as well as technical ones. The exact requirements may differ between federations. This document uses the European definitions and documents; which provide a baseline for the world-wide eduroam community.
RADIUS is a very lightweight protocol, and does not require expensive hardware setups. Even the busiest eduroam federations operate their server on a single contemporary hardware or Virtual Machine, without experiencing overload conditions.
As with every other professionally-operated service though, you should keep in mind that service uptime is paramount, and plan your procurement accordingly. Examples:
eduroam Europe is in the process of migrating to RADIUS/TLS for its federation servers. In the course of this process, hardware requirements for the servers may change. This section will be updated as necessary.
eduroam does not prescribe any particular RADIUS implementation. The technical requirements for eduroam however narrow the set of usable RADIUS server implementations, and the observed deployment of eduroam federation-level servers shows patterns regarding implementation popularity.
This section will present a few typical implementation setups. Note, however, that a federation is free to use a different implementation so long as the implementation can satisfy the eduroam technical requirements.
The sections for each implementation are accompanied by a skeleton configuration file, which should be usable almost as-is. However, please read and try to understand the entire corresponding section before applying the template - the information presented is valuable for daily operation and troubleshooting.
This section describes how to set up FreeRADIUS to handle RADSEC as a federation-level RADIUS and RADIUS/TLS server. It can then completely replace other RADSEC proxy products on the federation level (i.e. if you already have FreeRADIUS you can simply activate this virtual server and you'll be able to handle RADSEC - RADIUS/TLS over TCP).
More precisely, it will enable a server to:
The prerequisites for this deployment are:
All of the RADSEC configuration for FreeRADIUS 3.x can be in a single virtual server file. A detailed explanation of this configuration file is not yet provided. However, the comments included in the file should make its action almost self- explanatory. This means you can start and experiment with it right after installation.
Simply copy and paste this code into a new virtual server e.g. eduroam-radsec and place into your $RADDB/sites-enabled directory
listen {
ipaddr = *
port = 2083
type = auth
# For now, only TCP transport is allowed.
proto = tcp
clients = radsec
# This is *exactly* the same configuration as used by the EAP-TLS
# module. It's OK for testing, but for production use it's a good
# idea to use different server certificates for EAP and for RADIUS
# transport.
tls {
# These are used to simplify later configurations.
certdir = ${confdir}/radsec
cadir = ${confdir}/radsec
private_key_password = whatever
private_key_file = ${certdir}/server.realm.tld-key.pem
# If Private key & Certificate are located in
# the same file, then private_key_file &
# certificate_file must contain the same file
# name.
#
# If CA_file (below) is not used, then the
# certificate_file below MUST include not
# only the server certificate, but ALSO all
# of the CA certificates used to sign the
# server certificate.
certificate_file = ${certdir}/server.realm.tld-eduPKI.pem
# Trusted Root CA list
#
# ALL of the CA's in this list will be trusted
# to issue client certificates for authentication.
#
# In general, you should use self-signed
# certificates for 802.1x (EAP) authentication.
# In that case, this CA file should contain
# *one* CA certificate.
#
# This parameter is used only for EAP-TLS,
# when you issue client certificates. If you do
# not use client certificates, and you do not want
# to permit EAP-TLS authentication, then delete
# this configuration item.
CA_file = ${cadir}/eduPKI-CA.crt
#
# For DH cipher suites to work, you have to
# run OpenSSL to create the DH file first:
#
# openssl dhparam -out certs/dh 1024
#
dh_file = ${certdir}/dh
random_file = ${certdir}/random
#
# This can never exceed the size of a RADIUS
# packet (4096 bytes), and is preferably half
# that, to accomodate other attributes in
# RADIUS packet. On most APs the MAX packet
# length is configured between 1500 - 1600
# In these cases, fragment size should be
# 1024 or less.
#
fragment_size = 1024
# include_length is a flag which is
# by default set to yes If set to
# yes, Total Length of the message is
# included in EVERY packet we send.
# If set to no, Total Length of the
# message is included ONLY in the
# First packet of a fragment series.
#
include_length = yes
# Check the Certificate Revocation List
#
# 1) Copy CA certificates and CRLs to same directory.
# 2) Execute 'c_rehash <CA certs&CRLs Directory>'.
# 'c_rehash' is OpenSSL's command.
# 3) uncomment the line below.
# 5) Restart radiusd
# check_crl = yes
# CA_path = ${cadir}
#
# If check_cert_issuer is set, the value will
# be checked against the DN of the issuer in
# the client certificate. If the values do not
# match, the cerficate verification will fail,
# rejecting the user.
#
# In 2.1.10 and later, this check can be done
# more generally by checking the value of the
# TLS-Client-Cert-Issuer attribute. This check
# can be done via any mechanism you choose.
#
# this doesnt work yet
# check_cert_issuer = "/DC=org/DC=edupki/CN=eduPKI"
#
# If check_cert_cn is set, the value will
# be xlat'ed and checked against the CN
# in the client certificate. If the values
# do not match, the certificate verification
# will fail rejecting the user.
#
# This check is done only if the previous
# "check_cert_issuer" is not set, or if
# the check succeeds.
#
# In 2.1.10 and later, this check can be done
# more generally by checking the value of the
# TLS-Client-Cert-CN attribute. This check
# can be done via any mechanism you choose.
#
# check_cert_cn = %{User-Name}
#
# Set this option to specify the allowed
# TLS cipher suites. The format is listed
# in "man 1 ciphers".
cipher_list = "DEFAULT"
#
# This configuration entry should be deleted
# once the server is running in a normal
# configuration. It is here ONLY to make
# initial deployments easier.
#
#
# This is enabled in eap.conf, so we don't need it here.
#
# make_cert_command = "${certdir}/bootstrap"
#
# Session resumption / fast reauthentication
# cache.
#
# The cache contains the following information:
#
# session Id - unique identifier, managed by SSL
# User-Name - from the Access-Accept
# Stripped-User-Name - from the Access-Request
# Cached-Session-Policy - from the Access-Accept
#
# The "Cached-Session-Policy" is the name of a
# policy which should be applied to the cached
# session. This policy can be used to assign
# VLANs, IP addresses, etc. It serves as a useful
# way to re-apply the policy from the original
# Access-Accept to the subsequent Access-Accept
# for the cached session.
#
# On session resumption, these attributes are
# copied from the cache, and placed into the
# reply list.
#
# You probably also want "use_tunneled_reply = yes"
# when using fast session resumption.
#
cache {
#
# Enable it. The default is "no".
# Deleting the entire "cache" subsection
# Also disables caching.
#
# You can disallow resumption for a
# particular user by adding the following
# attribute to the control item list:
#
# Allow-Session-Resumption = No
#
# If "enable = no" below, you CANNOT
# enable resumption for just one user
# by setting the above attribute to "yes".
#
enable = yes
#
# Lifetime of the cached entries, in hours.
# The sessions will be deleted after this
# time.
#
lifetime = 24 # hours
#
# The maximum number of entries in the
# cache. Set to "0" for "infinite".
#
# This could be set to the number of users
# who are logged in... which can be a LOT.
#
max_entries = 255
}
#
# Require a client certificate.
#
require_client_cert = yes
#
# As of version 2.1.10, client certificates can be
# validated via an external command. This allows
# dynamic CRLs or OCSP to be used.
#
# This configuration is commented out in the
# default configuration. Uncomment it, and configure
# the correct paths below to enable it.
#
verify {
# A temporary directory where the client
# certificates are stored. This directory
# MUST be owned by the UID of the server,
# and MUST not be accessible by any other
# users. When the server starts, it will do
# "chmod go-rwx" on the directory, for
# security reasons. The directory MUST
# exist when the server starts.
#
# You should also delete all of the files
# in the directory when the server starts.
tmpdir = /etc/raddb/temporary
# The command used to verify the client cert.
# We recommend using the OpenSSL command-line
# tool.
#
# The ${..CA_path} text is a reference to
# the CA_path variable defined above.
#
# The %{TLS-Client-Cert-Filename} is the name
# of the temporary file containing the cert
# in PEM format. This file is automatically
# deleted by the server when the command
# returns.
# this doesnt work yet either
#client = "/usr/bin/openssl verify -CAfile /etc/raddb/radsec/eduPKI-CA.crt -purpose crlsign %{TLS-Client-Cert-Filename}"
}
}
}
# IPv6 listener - config comments cleared for brevity
listen {
ipv6addr = ::
port = 2083
type = auth
proto = tcp
clients = radsec
tls {
certdir = ${confdir}/radsec
cadir = ${confdir}/radsec
private_key_password = whatever
private_key_file = ${certdir}/server.realm.tld-key.pem
certificate_file = ${certdir}/server.realm.tld-eduPKI.pem
CA_file = ${cadir}/eduPKI-CA.crt
dh_file = ${certdir}/dh
random_file = ${certdir}/random
fragment_size = 1024
include_length = yes
# this doesnt work yet
# check_cert_issuer = "/DC=org/DC=edupki/CN=eduPKI"
cipher_list = "DEFAULT"
cache {
enable = yes
max_entries = 255
}
require_client_cert = yes
verify {
tmpdir = /etc/raddb/temporary
# doesnt work yet
#client = "/usr/bin/openssl verify -CAfile /etc/raddb/radsec/eduPKI-CA.crt -purpose crlsign %{TLS-Client-Cert-Filename}"
}
}
}
clients radsec {
client 127.0.0.1 {
ipaddr = 127.0.0.1
proto = tcp
secret = testing123
}
client etlr1.eduroam.org {
ipaddr = 192.87.106.34
proto = tcp
secret = radsec
}
client etlr2.eduroam.org {
ipaddr = 130.225.242.109
proto = tcp
secret = radsec
# IPv6 for ETRL too - unfamiliar with details, so commented out
# client etlr1-v6.eduroam.org {
# ipv6addr = ?????????????????????????????
# proto = tcp
# secret = radsec
# }
# client etlr2-v6.eduroam.org {
# ipv6addr = ?????????????????????????????
# proto = tcp
# secret = radsec
# }
}
# local test listener for debug (present by default)
listen {
ipaddr = 127.0.0.1
port = 4000
type = auth
}
home_server etlr1 {
ipaddr etlr1.eduroam.org
port = 2083
type = auth
secret = radsec
proto = tcp
status_check = status-server
tls {
#
# These are used to simplify later configurations.
#
certdir = ${confdir}/radsec
cadir = ${confdir}/radsec
private_key_password = whatever
private_key_file = ${certdir}/server.realm.tld-key.pem
# If Private key & Certificate are located in
# the same file, then private_key_file &
# certificate_file must contain the same file
# name.
#
# If CA_file (below) is not used, then the
# certificate_file below MUST include not
# only the server certificate, but ALSO all
# of the CA certificates used to sign the
# server certificate.
certificate_file = ${certdir}/server.realm.tld-eduPKI.pem
# Trusted Root CA list
#
# ALL of the CA's in this list will be trusted
# to issue client certificates for authentication.
#
# In general, you should use self-signed
# certificates for 802.1x (EAP) authentication.
# In that case, this CA file should contain
# *one* CA certificate.
#
# This parameter is used only for EAP-TLS,
# when you issue client certificates. If you do
# not use client certificates, and you do not want
# to permit EAP-TLS authentication, then delete
# this configuration item.
CA_file = ${cadir}/eduPKI-CA.crt
#
# For DH cipher suites to work, you have to
# run OpenSSL to create the DH file first:
#
# openssl dhparam -out certs/dh 1024
#
dh_file = ${certdir}/dh
random_file = ${certdir}/random
#
# This can never exceed the size of a RADIUS
# packet (4096 bytes), and is preferably half
# that, to accomodate other attributes in
# RADIUS packet. On most APs the MAX packet
# length is configured between 1500 - 1600
# In these cases, fragment size should be
# 1024 or less.
#
fragment_size = 1024
# include_length is a flag which is
# by default set to yes If set to
# yes, Total Length of the message is
# included in EVERY packet we send.
# If set to no, Total Length of the
# message is included ONLY in the
# First packet of a fragment series.
#
include_length = yes
# Check the Certificate Revocation List
#
# 1) Copy CA certificates and CRLs to same directory.
# 2) Execute 'c_rehash <CA certs&CRLs Directory>'.
# 'c_rehash' is OpenSSL's command.
# 3) uncomment the line below.
# 5) Restart radiusd
# check_crl = yes
# CA_path = ${cadir}
#
# If check_cert_issuer is set, the value will
# be checked against the DN of the issuer in
# the client certificate. If the values do not
# match, the cerficate verification will fail,
# rejecting the user.
#
# In 2.1.10 and later, this check can be done
# more generally by checking the value of the
# TLS-Client-Cert-Issuer attribute. This check
# can be done via any mechanism you choose.
#
# check_cert_issuer = "/C=GB/ST=Berkshire/L=Newbury/O=My Company Ltd"
#
# If check_cert_cn is set, the value will
# be xlat'ed and checked against the CN
# in the client certificate. If the values
# do not match, the certificate verification
# will fail rejecting the user.
#
# This check is done only if the previous
# "check_cert_issuer" is not set, or if
# the check succeeds.
#
# In 2.1.10 and later, this check can be done
# more generally by checking the value of the
# TLS-Client-Cert-CN attribute. This check
# can be done via any mechanism you choose.
#
# check_cert_cn = %{User-Name}
#
# Set this option to specify the allowed
# TLS cipher suites. The format is listed
# in "man 1 ciphers".
cipher_list = "DEFAULT"
}
}
#second home server config cleared to the values required for brevity
home_server etlr2 {
ipaddr etlr2.eduroam.org
port = 2083
type = auth
secret = radsec
proto = tcp
status_check = status-server
tls {
certdir = ${confdir}/radsec
cadir = ${confdir}/radsec
private_key_password = whatever
private_key_file = ${certdir}/server.realm.tld-key.pem
certificate_file = ${certdir}/server.realm.tld-eduPKI.pem
CA_file = ${cadir}/eduPKI-CA.crt
dh_file = ${certdir}/dh
random_file = ${certdir}/random
fragment_size = 1024
include_length = yes
cipher_list = "DEFAULT"
}
}
home_server_pool ETLR {
type = load-balance
home_server = etlr1
home_server = etlr2
}
realm eduroam {
auth_pool = ETLR
}
|
Currently (10th June 2011) there are some bugs with handling unreachable remote proxies which causes the daemon to die. A few of these have already been dealt with via bug reports but some still lurk. Also, the certificate checking/verification code does not currently work - we hope to be able to verify the certificate issuer and OID as we do with RADIATOR and RadSecProxy. Note that this software only does RADSEC/TLS with TCP - DTLS over UDP is not yet an option. Clients are 'radsec' only and the standard naslist or naslist imported from SQL won't operate with radsec.
It is important to constantly monitor your infrastructure on all levels, in order to react to system failure and see upcoming problems. There is a multitude of monitoring solutions on the market, and it is not possible to describe ways to monitor eduroam infrastructure for all of them; but we have provided a selection below.
First, for Europe, some parts of monitoring are done by the eduroam Operation Team which we will describe in the following section; please contact your own regional operator for the corresponding monitoring solution in your area if you are operating outside Europe.
In the then-following sections, we provide general tips for infrastructure monitoring.
When you set up a federation-level RADIUS server, the OT will start monitoring your server availability and will send out email alerts in case of failure. This is done by the OT sending authentication requests for the special realm @eduroam.<TLD> from their monitoring server to your server, and your server is expected to mirror these back to the OT monitoring infrastructure. The technical set-up of this is described in the corresponding HOWTOs for federation-level RADIUS servers.
Server availablitity is tested every hour and the results are summarised on the following web page: http://monitor.eduroam.org/
Note that you can also get more detailed info, including a history, by navigating on the left-hand pane on that website.
There is also a more detailed diagnosis test, where a federation operator can request that a specific path (i.e. from federation A via the European root to federation B) is tested real-time on-demand. The web interface for this testing facility is online at: http://monitor.eduroam.org/inter/test_otm.php (access is restricted to eduroam federation operators only).
There are several dimensions to infrastructure monitoring; most of which are unrelated to eduroam: system utilisation, hardware health, network reachability, a.s.o. There are many market solutions to monitor these aspects. It is beneficial to use a monitoring solution which can use plugins to execute some more eduroam-specific monitoring. Nagios and its fork Icinga have proven to be valuable to many eduroam participants, and the following plugins are considered useful.
The tool "rad_eap_test", which is a frontend to wpa_supplicant's "eapol_test", can be used for scripted authentication checks in Nagios. The added value over eapol_test is that eapol_test requires a configuration file on disk by the time of execution. rad_eap_test is completely command-line driven; it generates a temporary configuration file and deletes it again after eapol_test execution.
You can download rad_eap_test from here: http://www.eduroam.cz/rad_eap_test/
It requires eapol_test, part of wpa_supplicant from here: http://hostap.epitest.fi/
To compile eapol_test, unpack the wpa_supplicant distribution, change into the wpa_supplicant/ subdirectory and create the default config file by executing
cp defconfig .config |
Then, enable compilation of eapol_test by editing the .config file and setting (i.e. uncommenting)
CONFIG_EAPOL_TEST=y |
You can then compile eapol_test with
make eapol_test |
Now, you need to tell the shell script rad_eap_test where to find the eapol_test executable; and tell the eduroam F-Ticks system that these are monitoring-only requests by setting a corresponding MAC address. Edit the rad_eap_test file and replace the lines
EAPOL_PROG=<your path to eapol_test here> MAC="22:44:66:xx:yy:zz" (replace x,y,z with arbitrary values to your liking) |
That's it for the prerequisites - we can now start defining Nagios/Icinga checks.
You would typically execute the Nagios checks by defining your Nagios server as a client to your FLR server, and send requests for known test accounts of your realms to that server.
You can define check commands like the following:
define command{
command_name check_eduroam_login
command_line $USER1$/rad_eap_test -H <your FLR hostname> -P 1812 -S <shared secret for your Nagios client> -A $ARG1$ -u $ARG2$ -p $ARG3$ -e $ARG4$ -m WPA-EAP -t 7
}
|
}
and later use the arguments as follows in your individual checks:
You can also define similar checks for other EAP types; simply execute rad_eap_test without arguments to see which parameters it supports.
Example: You want to test a participating realm foobar.aq which uses PEAP, and for which you have the test credentials "testuser" and "testpass", and you want to test whether anonymous outer identities work properly. The corresponding service check is:
define service{
use generic-service
host_name <your FLR server>
service_description EDUROAM_FOOBAR
contact_groups ...
check_command check_eduroam_login!@foobar.aq!testuser@foobar.aq!testpass!PEAP
}
|
You can use the commodity Nagios plugin "check_ssl_cert" from: https://trac.id.ethz.ch/projects/nagios_plugins/wiki/check_ssl_cert for this purpose. The check command is then:
define command {
command_name = radius_tls
command_line = $USER1$/check_ssl_cert --host $HOSTADDRESS$ --port 2083 --noauth --warning 14 --critical 3
|
and will warn you two weeks in advance that your certificate is about to expire when added to the host as a service check.
It is also important to measure how successful the service is in your area of responsibility. eduroam Operations has set up a statistics system called F-Ticks, which is able to capture all roaming events both on a national as well as an international level. It does not cover local campus usage though.
If your FLR server is configured to support F-Ticks (it is, if configured according to this cookbook), statistics will be generated automatically for that federation. They are accessible at the following website: http://monitor.eduroam.org/f-ticks/
On that web page, you can find historical evolution of roaming service usage in federations, as well as an overview which realms were most active, and from which countries visitors come from. In the future, detailed views per SP and per IdP can be made available if your federation opts to send the data in the extended detail level. Please contact your federation operator to find out which level of statistics your federation provides.