TERENA TF-Mobility: Roaming for WLANs Tim Chown University of Southampton TF-Mobility WG & UKERNA Wireless Advisory Group

TF-Mobility objectives Formation Original participants SURFnet, UKERNA, DFN, SWITCH, UNINETT, FUNET Taskforce started on January Key objectives Evaluate AAA techniques in mobile environments. Create an Inter-NREN WLAN roaming architecture and test bed and conduct tests. Evaluate mobile equipment and technology. Evaluate next generation mobile technology for handover and roaming (mobile IPv6).

TF-Mobility status Quickly homed in on the topic of WLAN roaming between university sites Catalogued WLAN access control technologies Web-redirection 802.1x Restricted VPN Roamnode Selecting “best” solution for roaming support Or at least proposing interoperability methods for the leading solutions Operating international test beds

Roaming requirements Any system that enables roaming should: Be scalable Have minimal administrative overhead Avoid the need for additional hardware/systems Have appropriate security for the infrastructure Have user access controlled by their home institution Allow users to use their own security (e.g. VPN/ssh) Have good usability for all needed/used platforms Provide accounting and logging Ensure AUPs and policy requirements are met

Access control mechanisms (Very) basic methods: Hidden SSID MAC-based authentication DHCP control of IP addresses Use of WEP More advanced methods: Web-redirect Restricted VPN 802.1x Roamnode (a homebrew system, more later…)

1: Web-redirection Commonly seen at commercial hotspots Used by BTOpenZone, Telia Homerun, … Popular in UK universities via BlueSocket product User runs web client Access controller detects web request Redirects browser to authentication screen User enters credentials If successful, controller opens access for user Users can be placed into “roles” Allows variable external access restrictions to be applied

Web-redirection Internet Public Access Network Access Control Device AAA Server WWW-browser

Web-redirect advantages May authenticate using different tokens: Username/password, scratch card, SMS Commercial and free systems available e.g. BlueSocket, Vernier, NoCatAuth, … Can interface to RADIUS lookup Important for potential scalable roaming support Can fine tune access policy on firewall Only requires a web browser on user’s device Can use cheaper (non-802.1x) access points Can run a VPN after authenticating

Web-redirect disadvantages Web challenge server could be spoofed Users tend not to check the web server certificate Some such systems do not offer SSL protection Some devices may not support use of SSL Though this is increasingly rare Can be some issues detecting detachment DHCP may be spoofed User traffic may be redirected/relayed/intercepted (Roamnode uses PPPoE for this reason)

2: Restricted VPN User gains local IP access via DHCP (May use RFC1918 addresses locally) Access network only allows VPN out To a restricted set of VPN servers Firewall blocks all other traffic out of network User connects to their home VPN server Requires VPN client Some examples in European networks SWITCHmobile in Swiss academic network There the “restricted set” is all Swiss universities

SWITCHmobile

VPN advantages Ensures data security via VPN connection Most (all?) universities now have a VPN service User appears to be at home university IP address allocated by home site IP-based access mechanisms work For example to access bibliographic resources (Though IP-based authentication is not great!) Most devices now have VPN client software Palm Tungsten C ships with WLAN and VPN

VPN disadvantages For the roaming solution: Need to manage large list of trusted VPN servers Needs to be automatically applied to firewall ACLs (Could “simplify” by using address ranges per NREN) VPN service scalability – need to provision for: High bandwidth/volume of remote users All user traffic routed via home VPN Has an impact on latency for traffic Roamers may be a source of viruses/worms VPNs often have no firewalling into home network

Wbone for VPNs A method deployed in Bremen Each access network at any site uses its own unique RFC1918 address space All sites are connected via permanent IP tunnels over the public academic network Users connect to home VPN gateway using the private address of that gateway Requires heavy coordination

Roamnode A homebrew solution from University of Bristol (UK) Uses PPPoE rather than DHCP Akin to access model for home users through their (broadband) ISP Private IP space used for the roaming node Once admitted, user (can only) run a VPN back to their home institution

Roamnode advantages PPPoE is more secure than DHCP Less potential for spoofing Visited institution does not provide an IP address Arguably makes deployment easier Offers RADIUS support Potential for plug-in to a national RADIUS scheme Clients use VPNs Thus shares the pros and cons of VPN usage

Roamnode disadvantages PPPoE client availability Not yet available for Pocket PC PDA platform And because the client uses a VPN: The usual drawbacks of VPN approach

802.1x Port-based (layer 2) access control Run 802.1x client on user device Communicates with authenticator (in access point) User supplies credential (e.g. Carried over EAP, e.g. EAP-TLS or EAP-TTLS Access point relays request to RADIUS server RADIUS response processed by access point May add user to a given VLAN Runs at Layer 2 (Ethernet admission)

802.1x with RADIUS referral Authentication Server (RADIUS server) Institution A Authentication Server (RADIUS server) Institution A Internet Central RADIUS Proxy server Central RADIUS Proxy server Authenticator (access point) Supplicant (client) DB Authentication Server (RADIUS server) Institution B Authentication Server (RADIUS server) Institution B

802.1x advantages Growing client (“supplicant”) support MacOS/X built-in, WinXP support good EAP-TTLS needs only RADIUS server certificate WEP keys refreshed regularly Supported by many access points Can interface to RADIUS Thus has potential for a scalable roaming method Can be used on wired docking points too User can run a VPN after being admitted

802.1x disadvantages Requires special client (“supplicant”) software Not universally available But growing in stature and popularity Participating RADIUS server(s) must support EAP type Any relaying servers must be able to forward EAP Radiator RADIUS server was tested heavily in the pilot 802.1x-capable access points expensive But prices are falling fast Living a little on the bleeding edge

Interoperability Interoperability will be very important E.g. in the transition to deploy new technology, like 802.1x May require special AP functions Ability to offer multiple SSIDs or VLANs Run different methods on different SSIDs/VLANs 802.1x on “trusted” VLAN and SSID Perhaps run a more basic method on another VLAN and SSID as a fallback mechanism during transition 802.1x + multi-SSID + multi-VLAN access points Still quite rare, but available

A roaming infrastructure Explore synergies between the methods Common use of RADIUS back-end Used by Web-redirect, 802.1x, Roamnode Suggests concept of RADIUS referrals Unknown credentials passed up hierarchy Relayed by proxy to home institution Response relayed back to querying site Differential access based on local/remote user In parallel explore scalability of VPN method

RADIUS relationships RADIUS carries authentication requests Needs shared secret configuration between sites To scale, do not want n-squared setup So each site “peers” with national RADIUS server Each national server “peers” with EU server Enables “web of trust” between sites Sites use own auth backend, eg. Active Directory Open question: What are the security requirements on the peerings? Should certain access control methods be dissuaded?

Organisational RADIUS Server Top-level RADIUS Proxy Server Top-level RADIUS Proxy Server Organisational RADIUS Server National RADIUS Proxy Server National RADIUS Proxy Server National RADIUS Proxy Server National RADIUS Proxy Server University of Southampton Currently hosted at SURFnet Currently linked to FCCN, Portugal Currently linked to CARNET, Croatia Backup Top-level RADIUS Proxy Server Backup Top-level RADIUS Proxy Server etlr1.radius.terena.nl ( ) etlr2.radius.terena.nl ( ) Organisational RADIUS Server National RADIUS Proxy Server National RADIUS Proxy Server Organisational RADIUS Server Currently linked to SURFnet, Netherlands National RADIUS Proxy Server National RADIUS Proxy Server Organisational RADIUS Server Currently linked to FUNET, Finland RADIUS proxy hierarchy testbed (network topology view) National RADIUS Proxy Server National RADIUS Proxy Server Organisational RADIUS Server FOKUS (Berlin) National RADIUS Proxy Server National RADIUS Proxy Server

Future work Trials & refinement of the RADIUS hierarchy Location Independent Networking (LIN) architecture Consider RADIUS credential formats and semantics Understand interoperability of methods Study methods to scale VPN roaming Define policy issues Security analysis of all aspects of the LIN model Wider trials of Bristol’s Roamnode Consider and deploy (Mobile) IPv6 implications

Internet 2 interest? US universities have significant WLANs Often much bigger than European deployments Is there a desire for a roaming infrastructure? Are mobility requirements different in the US? What is Internet 2 doing in this area now? Perhaps join the TF-Mobility trial? If any university is interested Shibboleth integration/interoperability Many issues to consider, but should be feasible

More info TERENA TF-Mobility (Deliverable G in particular) UKERNA WAG Including LIN proposal UK Networkshop event presentations