220 likes | 315 Views
Overview of eduroam developments in Europe. Klaas Wierenga Klaas.Wierenga@surfnet.nl APAN Singapore, July 20 2006. Content. Current status of eduroam in Europe The European eduroam federation eduroam-ng Summary. Current status. eduroam members.
E N D
Overview of eduroam developments in Europe Klaas Wierenga Klaas.Wierenga@surfnet.nl APAN Singapore, July 20 2006
Content • Current status of eduroam in Europe • The European eduroam federation • eduroam-ng • Summary
eduroam members • Reaching 100% coverage in terms of countries • Reaching 500 connected institutions • Moving to a full service means: • Management and monitoring • Formal agreements • Scalability Green= member, Blue = in process of joining
The European eduroam policy • Mutual access • Home institutions are/remain responsible for their users abroad • Members are European NRENs • Members guarantee required security levels by their participants • Members promote eduroam in their countries • European eduroam may peer with other regions
National policy • Mutual access • Members are connected institutions • Home institution is/remains responsible for its users behaviour. • Home institution is responsible for proper user management • Home and visited institution must keep sufficient logdata • Appropriate security levels
eduroam-NG: Requirements • GEANT2 roaming facility = eduroam-ng • Downward compatible with existing eduroam (RADIUS, 802.1X) • Intended key improvements of eduroam-ng • More formally defined form of federation • More reliable • More scalable (dynamic trust establishment) Requirements as taken from GEANT2 deliverable DJ5.1.2: “Documentation on the GEANT2 Roaming Requirements”
Dynamic Trust Establishment • Dynamic Trust Establishment and Scalability requirements typically translate into • Direct connections between parties (peers) involved in handling an authentication / authorization request • No RADIUS tree traversing as with current eduroam setup • But, peers do not have a direct formal relationship • Connection setup between peers consists of two steps • Peer discovery (Which server handles authentication / authorization requests for the user’s realm?) • Confirm that peer (or user realm) is part of roaming domain (Is the user part of the community that shares resources?)
‘Peer Discovery’ and ‘Roaming Domain Participation’ Common setup for protocols • Peer discovery • DNS based • Confirmation of participation in roaming domain • Public Key Infrastructure (PKI) based • DNS based (using secure extensions)
Protocol architectures for roaming • 3 architectures have been analysed: • Diameter. IETF defined this as successor for RADIUS • P2P Radius • Trust based on dnssec (radius-dnssec) • Trust based on PKI (RadSec) • Diameter: no widely available implementation • DNSsec: idem • RadSec: not widely deployed but: • Supported by Radiator • Strong interest in FreeRADIUS community
RadSec / DNSROAM • RADIUS extension ‘borrrowing’ the goodies from Diameter • Usage of TCP • Usage of TLS • Trust based on preconfigured set of roaming CA’s (PKI) • Supports migration scenarios • Either static links: RadSec • Or dynamic through DNS: DNSROAM
Deployment scenarios in Geant2 • We tested the RadSec approach • Multiple deployment scenarios have been studied. We describe the three that are tested: • Fully hierarchical • Meshed top-level • Fully meshed
Test and evaluation results • Test setup • 6 NRENs and a number of institutions participated (SURFnet, CESNET, ISTF, TELIN, ARNES, ACAD, UNINETT, RESTENA) • Each scenario was tried-out between a couple of sites, and subsequently extended to a larger group • Tested a number of cases • Authentication related (known/unknown user, wrong credentials) • PKI related (unknown CA, multiple CA, Revocation, mismatch between peer name and CN) • DNS related (NAPTR/SRV lookup failure, fallback ) • Configuration related (CA cert not installed, loops) • Connectivity related (peer unreachable) • Performance related (DNS overhead)
Test results • Hierarchical scenario • TCP/TLS was preferred over current RADIUS (better failure detection) • Most appreciated scenario! (Rating: 8.2 of 10) • Meshed top-level (institutions were statically configured) • Test used a centralized zone (test.eduroam.org) • 2/3 say ‘DNS-based roaming is a GOOD thing’ • 1/3: Buggy DNS-servers, DNS not secure • Rating: 6.2 of 10 • Fully meshed (no toplevel CA!) • PKI management wasn’t easy (re-distribution issues and problems with revocation lists) • Main issue: Auth Server has to be opened to the whole world (even though certificates are checked) • Score: 6.8 out of 10
Summary • eduroam is widely deployed (at the country level) • Now moving to a ‘real’ European federation • We have to work out the relation with other regions (like yours!) • It is possible to replace the static Radius hierarchy with a similar one, using RadSec. RadSec proved to be sufficiently stable. • Dynamic peer discovery needs more testing and consideration. • So eduroam is here, is here to stay, so the motto remains: