Last updated: 
1 month 2 weeks ago
Blog Manager
eduroam Service News Follow us on Twitter @eduroamuk - for news, interest, information, photos and fun. Contents - click on item and scroll to bottom of box to read item 12/10/18 - Advisory: Injection of Operator-Name at the NRPSs 23/02/18 - eduroam Seminar pre-Networkshop 2018 - FreeRADIUS 4 etc 14/07/16 - Release of Technical Specification v1.4 10/05/16 - Advisory: Ending of RADIUS Accounting within eduroam(UK) 22/01/15 - eduroam Support Clinic Tues March 1st 14:15-15:30 18/09/15 - Advisory: Impact of change of Certificate Service CA for eduroam Home (IdP) service providers 27/01/15 - eduroam now available at seven hospitals in Cardiff 22/01/15 - eduroam Support Clinic Tues January 27th 10:45-12:00am 23/12/14 - Calling Station Identity 01/12/14 - New DNS Name for eduroam(UK) Support Server 19/12/14 - eduroam Support Clinic Tues January 6th 10:45am 28/11/14 - eduroam Support Clinic Tues December 2nd 10:45am 19/11/14 - Advisory: Microsoft Security Bulletin Affecting NPS and IAS 27/05/14 - eduroam training course June 11-12 Birmingham; Aug 6-7 Aug Bristol 08/04/14 - Advisory: OpenSSL TLS Heartbleed Vulnerability rev 1.1 21/02/14 - Auth Timestamp Feature on eduroam(UK) Support Server 30/10/13 - Release of FreeRADIUS 2.2.2 07/10/13 - Release of FreeRADIUS 3.0.0 17/09/13 - Release of FreeRADIUS 2.2.1 13/06/13 - Release of Technical Specification v1.3 13/06/13 - eduroam training course June 27 Glasgow 23/04/13 - eduroam training courses July 24-25 London 23/04/13 - Chargeable User Identity how-to guide now available in Library 25/03/13 - eduroam training courses May 2-3 Manchester 24/02/13 - Time for a review of your eduroam deployment - Technical Specification v 1.2 Main Changes from v 1.1 30/01/13 - Configuration Assistant Tool (CAT) now available - builds eduroam client installers for user devices 23/01/13 - Advice regarding keeping eduroam credentials secure 09/01/13 - eduroam(UK) Announcement of Change of Name of the Janet Roaming Service to eduroam(UK) 19/11/12 - Uptake of NAPTR record definition in DNS (to enable RadSec DD) is increasing 31/10/12 - eduroam(UK) Support Server Update: Nagios LG and check for NAPTR records 30/10/12 - Cisco ACS 5.4 released: now support Operator-Name 29/10/12 - Unscheduled service outage Friday 26/10/2012 1:02 AM - 9:48 AM 03/10/12 - Advisory: Improving Efficiency of International Authentication through utilisation of RadSec at National Level 11/09/12 - Advisory: FreeRADIUS 2.1.10,11,12 Security

Group administrators:

Advisory: Improving Efficiency of International Authentication through utilisation of RadSec at National Level

Friday, February 3, 2017 - 14:45

October 2012 - 3/10/2012

This advisory is relevant to ALL Home (IdP) service organisations participating in eduroam in the UK. It describes the use of RadSec at national proxy level, how this can benefit the individual user and what eduroam organisations must do in order to gain these benefits.

Originator: Alan Buxey

Abstract

This article is relevant to ALL Home (IdP) service organisations participating in eduroam in the UK. It describes the use of RadSec at national proxy level, how this can benefit the individual user and what eduroam organisations must do in order to gain these benefits. The aim of this RadSec initiative is to improve the efficiency and performance of authentication for roaming users when trying to connect to eduroam in other European countries. All that is needed are some additions to the configuration of the participating organisation's DNS zone file.

This advisory is a recommendation to implement a simple DNS configuration measure in order to support RadSec based authentication transactions at International level. It is not a recommendation to implement RadSec at organisational level. A number of constraints apply to the more widespread deployment of RadSec as described at the end of this article.

Introduction

The UK National RADIUS proxy servers have been operating with RadSec support  (Dynamic Discovery as well as TLS over TCP) for some time and we have been conducting trials across Europe. We think it is now time to take advantage of RadSec and dynamic server discovery so that the number of RADIUS queries that have to traverse the top level international proxies (the European Top Level Radius servers) can be reduced and more efficient routing achieved.

How does it Work?

The efficiency improvement can be achieved because RadSec allows the national RADIUS proxy servers at one NREN confederation member (National RADIUS Operator) to talk to another directly, bypassing the ETLRs. In order to achieve this RadSec checks NAPTR (Network Authority PoinTeR) resource records in DNS to determine where RADIUS packets must be sent using SRV (service records) for your domain/realm zone name.

In order to benefit from the efficiency gains made possible by the new national level RadSec implementation, the joy is that eduroam organisations do not have to support RadSec natively on the ORPS! This possible because although the inter-NREN authentication transaction will use RadSec Dynamic Discovery, the transactions between ORPS and NRPS will use standard RADIUS as a present. The RADIUS request is proxied from the visited country's national proxy server using RadSec and dynamic server discovery straight to the UK NRPS, which then accepts it (based on certificates in the RadSec transaction) and then passes it on to the ORPS directly using good old fashioned RADIUS.

In this way, users visiting e.g. Germany will get their requests sent from the German organisation's ORPS to the German NRPS and sent then directly to the UK - that results in 2 hops in each direction dropped from the path for every one of the packets transfered. Currently (updated Jan 2015) Belgium, Germany, Ireland, Luxembourg, Netherlands, Norway, Poland, Spain, Switzerland and the UK have deployed RadSec Dynamic Discovery, with Denmark and Sweden and others soon to follow suit.

For a little more information about RadSec, NAPTR, SRVs etc see https://wiki.geant.org/display/H2eduroam/DNS-NAPTR

Instructions

How do you join the party? You simply need to define a NAPTR record that points (indirectly) to the required SRV records (which define the required UK NRPS).

a) Recommended method.

1) Define a NAPTR record for your zone that points to the Janet roaming  _radsec._tcp. record by appending the following line in the main zone header section, alongside the usual MX, TXT, SPF etc entries (e.g. to  camford.ac.uk.  43200  IN )   

NAPTR 100 10 "s" "x-eduroam:radius.tls" "" _radsec._tcp.roaming.ja.net.

Nb. Be careful - the above is case sensitive!

(in the main zone header section, alongside the usual MX, TXT, SPF etc entries)

2) You can verify all is well by then running DIG against your records e.g.

$ dig +short -t naptr camford.ac.uk

Result:
100 10 "s" "x-eduroam:radius.tls" "" _radsec._tcp.roaming.ja.net.

That's it! (The _tcp records section of the ja.net zone file includes the required SRV records for the 3 NRPSs.)

Nb. If you have multiple realm names defined for eduroam, you must add a NAPTR records for all of your realms! That includes sub-realms too.

Nbb. If you run DNSSEC might want to prove that the SRVs are real and verified.

Organisations running DNSSEC can then have the happy feeling that all of this is 100% validated - but in this case it doesn't really matter as we are using a closed club (eduroam RadSec currently uses a special CA that only members can use to create the transaction)

NB. Some DNS Servers do not support NAPTR:

Windows Server 2003 DNS Server and Windows 2008 non-R2 DNS Server  CANNOT do NAPTR

djbdns CANNOT do NAPTR either (without a patch applied...which is unlikely to be in a distro release)

DNS Servers which do support NAPTR:

Windows Server 2008 R2, BIND, CNR, PowerDNS, NSD, MaraDNS unxsbind and DNSmasq all CAN do it

Resources: NAPTR Record Creation using MS Windows 2008R2   

Test Systems to Verify and Monitor Site Records

As of May 2013 a check for NAPTR records is part of the eduroam(UK) Nagios test system running on the Support server. An alert appears on the Nagios LG page and also on your main configuration page.

Constraints Limiting Wider RadSec Deployment

This advisory is a recommendation to implement a simple DNS configuration measure in order to support RadSec based authentication transactions at International level. It is not a recommendation to implement RadSec at organisational level for ORPS - NRPS communication. A major constraint is that RadSec, both TLS over TCP and Dynamic Server Discovery, is only supported at present in Radiator and RadSecProxy RADIUS implementations. RadSec TLS over TCP will be included in FreeRADIUS 3 and DD will become available in future releases.

If a RADIUS platform that supports RadSec has been deployed as the ORPS, participating organisations may implement (and we would recommend implemention of) RadSec TLS over TCP for communication with the national proxies. The NRPS are based on Radiator and so support TLS over TCP. Nb. Implementation requires the use of special eduroam-signed certificates - guidance on this is outside the scope of this advisory.

RadSec Dynamic Server Discovery is NOT permitted since an important and long standing tennet of the eduroam trust model (dating from the inception of the service) is that all RADIUS transactions pass  through the NRPS. Only when a robust central logging system has been developed can direct organisation - organisation authentication be considered. On a practial level, there are ongoing issues with DD on ALL of the platforms which currently support it (Radiator and radsecproxy).