TERENA TFMobility Roaming for WLANs Tim Chown tjcecs

TERENA TF-Mobility: Roaming for WLANs Tim Chown tjc@ecs. soton. ac. uk University of Southampton TF-Mobility WG & UKERNA Wireless Advisory Group

TF-Mobility objectives l Formation l l l Original participants SURFnet, UKERNA, DFN, SWITCH, UNINETT, FUNET Taskforce started on January 1 2003 Key objectives l l 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 IPv 6).

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

Roaming requirements l Any system that enables roaming should: l l l l l 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 l (Very) basic methods: l l l Hidden SSID MAC-based authentication DHCP control of IP addresses Use of WEP More advanced methods: l l Web-redirect Restricted VPN 802. 1 x Roamnode (a homebrew system, more later…)

1: Web-redirection l Commonly seen at commercial hotspots l l l User runs web client l l l Used by BTOpen. Zone, Telia Homerun, … Popular in UK universities via Blue. Socket product 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” l Allows variable external access restrictions to be applied

Web-redirection Access Control Device 4. AAA Server Internet 3. 5. 1. Public Access Network 2. WWW-browser

Web-redirect advantages l May authenticate using different tokens: l l Commercial and free systems available l l l e. g. Blue. Socket, Vernier, No. Cat. Auth, … Can interface to RADIUS lookup l l Username/password, scratch card, SMS 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. 1 x) access points Can run a VPN after authenticating

Web-redirect disadvantages l Web challenge server could be spoofed l l l 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 l Though this is increasingly rare l Can be some issues detecting detachment l DHCP may be spoofed l l User traffic may be redirected/relayed/intercepted (Roamnode uses PPPo. E for this reason)

2: Restricted VPN l User gains local IP access via DHCP l l Access network only allows VPN out l l l (May use RFC 1918 addresses locally) 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 l l SWITCHmobile in Swiss academic network There the “restricted set” is all Swiss universities

SWITCHmobile

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

VPN disadvantages l For the roaming solution: l l VPN service scalability – need to provision for: l l High bandwidth/volume of remote users All user traffic routed via home VPN l l 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) Has an impact on latency for traffic Roamers may be a source of viruses/worms l VPNs often have no firewalling into home network

Wbone for VPNs l A method deployed in Bremen l l Each access network at any site uses its own unique RFC 1918 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 l l A homebrew solution from University of Bristol (UK) Uses PPPo. E rather than DHCP l l l 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 l PPPo. E is more secure than DHCP l l Visited institution does not provide an IP address l l Arguably makes deployment easier Offers RADIUS support l l Less potential for spoofing Potential for plug-in to a national RADIUS scheme Clients use VPNs l Thus shares the pros and cons of VPN usage

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

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

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

802. 1 x advantages l Growing client (“supplicant”) support l l l Supported by many access points Can interface to RADIUS l l l Mac. OS/X built-in, Win. XP support good EAP-TTLS needs only RADIUS server certificate WEP keys refreshed regularly 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. 1 x disadvantages l Requires special client (“supplicant”) software l l l Participating RADIUS server(s) must support EAP type l l l Any relaying servers must be able to forward EAP Radiator RADIUS server was tested heavily in the pilot 802. 1 x-capable access points expensive l l Not universally available But growing in stature and popularity But prices are falling fast Living a little on the bleeding edge

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

A roaming infrastructure l Explore synergies between the methods l l l Suggests concept of RADIUS referrals l l l Common use of RADIUS back-end Used by Web-redirect, 802. 1 x, Roamnode 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 l RADIUS carries authentication requests l l To scale, do not want n-squared setup l l l So each site “peers” with national RADIUS server Each national server “peers” with EU server Enables “web of trust” between sites l l Needs shared secret configuration between sites Sites use own auth backend, eg. Active Directory Open question: l l What are the security requirements on the peerings? Should certain access control methods be dissuaded?

RADIUS proxy hierarchy testbed (network topology view) Organisation al RADIUS Server FOKUS (Berlin) Organisation al RADIUS Server Currently linked to FCCN, Portugal National RADIUS Proxy Server Currently linked to SURFnet, Netherlands Organisation al RADIUS Server National RADIUS Proxy Server Organisation al RADIUS Server Backup Top-level RADIUS Proxy Server Organisation al RADIUS Server National RADIUS Proxy Server Top-level RADIUS Proxy Server Currently hosted at SURFnet National RADIUS etlr 1. radius. terena. nl (192. 87. 36. 6) Proxy Server etlr 2. radius. terena. nl (195. 169. 131. 2) Organisation al RADIUS Server Currently linked to CARNET, Croatia National RADIUS Proxy Server Currently linked to FUNET, Finland Organisation al RADIUS Server University of Southampton Organisation al RADIUS Server

Future work l Trials & refinement of the RADIUS hierarchy l l l l 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) IPv 6 implications

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

More info l TERENA TF-Mobility l l http: //www. terena. nl/tech/task-forces/tf-mobility/ (Deliverable G in particular) UKERNA WAG l http: //www. ja. net/development/network_access/wireless/wag/ l Including LIN proposal UK Networkshop event presentations l http: //www. ja. net/conferences/networkshop