It has been in my plans to write this article for a while now, but now finally Easter holidays gave the opportunity to finalise the configuration and some free time to write these configuration instructions. This blog post describes how you can build a mobile eduroam access point by utilising RadSec and a popular open source access point firmware called OpenWRT. The network architecture is presented in the Figure 1 above and the rest of the instructions follow below.
The first thing to do is of course install OpenWRT on your access point. There are several different OpenWRT supported access point models and the installation instruction vary between models and manufacturers. In this case I assume that you have alredy OpenWRT based access point installed and continue from the actual eduroam and RadSec configuration.
The base OpenWRT distribution does not come with all the software we will require so we need a working Internet connection to install some additional packages. The most important of these are the tools for time synchronisation (for certificate validity verification) and radsecproxy for RadSec functionality.
From the OpenWRT command line you can install the needed packages by giving the following commands:
# opkg update # opkg upgrade # opkg install radsecproxy # opkg install ntpclient
I recommend rebooting the access point and verifying the correct time with date command. The default OpenWRT timezone is UTC so the time is likely to be hours off from your local time. You can change the timezone, hostname and remote logging address from /etc/config/system displayed below:
config system
option hostname mobile-ap
option timezone UTC
# remote syslog server, we used the syslog configured to radsec server
option log_ip 10.10.10.10
The wireless settings for eduroam are configured in /etc/config/wireless. The important thing to notice is that the RADIUS server (radsecproxy) will be run on the OpenWRT access point.
config wifi-device wl0
option type broadcom
option channel 5
option country FI
# REMOVE THIS LINE TO ENABLE WIFI:
# option disabled 1
config wifi-iface
option device wl0
option network lan
option mode ap
# in case you are already running eduroam in your organisation you might
# want to consider different ssid to prevent causing denial of service for
# your users
option ssid eduroam
option encryption mixed-wpa
# as we use radsecproxy on localhost for converting RADIUS to RADSEC
# the RADIUS server is the radsexproxy on localhost
option server 127.0.0.1
option port 1812
option key RadiusSecretHere
option nasid nas.id.here
option wpa_group_key 600
option ieee80211d 1
Radsecproxy is an open source implementation of the RadSec protocol. The RadSec protocol is essentially TLS-secured RADIUS over TCP making it more reliable and more secure for setting up connections over unreliable or unsecure networks (such as most Internet connections).
There are however few pre-requirements for configuring RadSec and eduroam:
- Home organisation must be part of the national eduroam federation and international confederation to have an access to eduroam infrastructure
- a RadSec capable server (either radsecproxy (also on server side) or commercial RadSec capable server such as Radiator)
- existing Certificate Authority (CA) for signing certificates for RadSec server and clients
In our company we already had Radiator RADIUS server and own CA configured so making certificates and server configuration was not very difficult. The client side (OpenWRT) configuration was done in the /etc/radsecproxy.conf file.:
listenUDP 127.0.0.1:1812
ListenAccountingUDP 127.0.0.1:1813
# Optional log level. 3 is default, 1 is less, 4 is more
LogLevel 3
#Optional LogDestinatinon, else stderr used for logging
# Logging to file
#LogDestination file:///tmp/rp.log
# Or logging with Syslog. LOG_DAEMON used if facility not specified
# The supported facilities are LOG_DAEMON, LOG_MAIL, LOG_USER and
# LOG_LOCAL0, ..., LOG_LOCAL7
# Syslog is nice as you can direct it to external host via OpenWRT's
# system configuration
LogDestination x-syslog:///log_daemon
tls mobile-ap-to-radsec-server {
# In Arch Red we have multiple levels of CA servers with root CA and server CA
# so the CACertificateFile is a bundle of root CA and server CA. The server CA
# is the actual CA certifying both the server and mobile-ap certificates.
CACertificateFile /etc/certs/ca-servers-bundle-cert.pem
CertificateFile /etc/certs/mobile-ap-cert.pem
CertificateKeyFile /etc/certs/mobile-ap-key.pem
# Optionally enable CRL checking
# CRLCheck on
# Optionally specify how long CAs and CRLs are cached, default forever
# CacheExpiry 3600
}
# configuration for OpenWRT's local RADIUS
client 127.0.0.1 {
type udp
# the secret between OpenWRT nas/hostapd and radsecproxy
secret RadiusSecretHere
}
# in the real configuration the IP address of the RadSec server
server 10.10.10.10 {
type TLS
# the RADIUS shared secret between mobile-ap and RadSec server
secret SecretBetweenMobileAPandRadServer
port 2083
tls mobile-ap-to-radsec-server
certificateNameCheck off
matchCertificateAttribute CN:/^radsecserver\.hostname\.here$/
retryCount 3
retryInterval 5
}
# The realm below is equivalent to /.*
realm * {
# the IP addresses of the RadSec server
server 10.10.10.10
accountingServer 10.10.10.10
}
I copied the necessary (CA and client) certificates manually to a directory /etc/certs I had created on the wireless access point file system. A larger deployment of RadSec access points would of course require either a scalable way to deploy and install client certificates or utilising only one client certificate for all mobile access points. Solving this issue can however be a topic for paper or some future blog post, when actual need arises. I did not yet configure the certificate revokation list (CRL) retrieval, but it is in my plans to document also this aspect.
Right, so now we have the actual configuration pretty much set up and we can start testing. Before running radsecproxy as a service I did a prelimanry testing by running it on OpenWRT console with the following command:
# radsecproxy -c /etc/radsecproxy.conf -d 3 -f
I was now able to check if the radsecproxy was able to connect to the home organisation RADIUS server and thus verify the radsecproxy configuration. After this was verified I enabled the radsecproxy permanently with the following command:
# /etc/init.d/radsecproxy enable
Then I rebooted the access point and verified once again that time was correct, radsecproxy was running as a daemon and wireless settings were correct before proceeding to eduroam authentication tests using my own TUT user account.
Like you have probably guessed, the testing was successful and I was able to now have my own mobile eduroam access point to be deployed wherever I may roam. :) Of the difficulties I ran into while doing this, I think the most difficult was once again setupping and configuring the X.509 certificates properly. The radsecproxy default was to check if the certificate CN contained the IP address mentioned in the server block and I had to check from the documentation how this check could be replaced with hostname check without having to use DNS hostname in the configuration block. The result is documented above there in the radsecproxy configuration.
RadSec as a technology felt very solid and functional for connecting devices and services to eduroam and the radsecproxy open source implementation was so well implemented and documented that I think it could be used as an official open source implementation to join to the eduroam federation with RadSec and this way as a roaming proxy replacing for example FreeRADIUS. Even the current radsecproxy implementation has better functionality set (for example dead realm marking) for eduroam proxy usage than the current FreeRADIUS has.<commercial>Or then again, you can get a Radiator RADIUS+RADSEC server from us, Open System Consultants or some other reseller.</commercial>
No comments:
Post a Comment