Rhodes University Wireless Network Like many organisations, Rhodes aims to secure its wireless network against unauthorised use. This document explains how this is achieved. Network Overview The University s wireless network consists of a number of different components that interoperate to provide secure, authenticated access to the network and Internet. The diagram below shows how the components of the network are interconnected. All components of the network must be functional for a user to successfully authenticate and connect. Rhodes Wireless Network Components Rhodes Network & the Internet Supplicant Wireless Access Points WPA-Enterprise Wireless Security Switch EAP RADIUS SSL edirectory The three dashed lines show the various secure (encrypted) tunnels that are established during the authentication process. The client initially establishes a tunnel to the University s RADIUS servers (blue, EAP) via a proxy on the wireless security switch. The RADIUS server then establishes a second tunnel (orange, SSL) to the University s edirectory (LDAP) servers. Together these two tunnels secure the user s credentials as they re transmitted over both the University s wireless and wired networks. Once authenticated, the client establishes a tunnel to the wireless security switch (green, WPA-Enterprise). This tunnel is then used for network traffic, and thus secures the user s communication over the wireless network. In practice many of the above components are redundant. Each wireless access point can automatically connect to either of two wireless security switches. These switches connect to a cluster of five RADIUS servers, any one of which is capable of handling authentication requests. The RADIUS servers load balance authentication requests between three edirectory replicas, with automatic failover. These wireless security protocols implemented by each of these components are explained in further detail in the sections below. 2009/02/07 1
Wireless Security Access to the wireless network is controlled by individual wireless access points in consultation with the wireless security switches they re connected to. These check that a particular device is authorised to use the network before allowing it to connect. We make use of devices that are certified under the WiFi-Protected Access (WPA) program, and utilise this standard for network authentication. Our access points will support the following protocols: Network Authentication: Data Encryption: WPA or WPA2 TKIP or AES The combination of WPA & TKIP is collectively known as WPA-Enterprise whilst WPA2 & AES combined form WPA2-Enterprise. Of these two, WPA2-Enterprise is the preferred method for doing network authentication as it is a newer standard and is known to be more secure than WPA-Enterprise. The other two combinations (WPA+AES & WPA2+TKIP) will work with Rhodes s wireless network infrastructure but they are not standards-based. The older, insecure Wired-Equivalency Protocol (WEP) is not supported in any form. Authentication Both versions of WPA-Enterprise make use of the Extensible Authentication Protocol (EAP) to authenticate and authorize particular users. As its name suggests, EAP provides for a number of different authentication methods. The following are supported at Rhodes: EAP-type: PEAP/MSCHAPv2 or TTLS/PAP or TTLS/MSCHAPv2 There s no preferred EAP type. Both PEAP and TTLS provide excellent security, and can be used interchangeably on our network. Each has their own pros and cons which might make them preferable in certain situations. TTLS/PAP is non-standard but is widely used and supported (for example by EDUROAM). WPA-Enterprise supports several other EAP authentication methods, most notably EAP-TLS (client certificates) and EAP-GTC (smart cards). Whilst some operating systems provide support for these EAP types, they re not widely used. Rhodes does not support any of these EAP types. The client part of EAP authentication (i.e. what s on the user s laptop) is called a supplicant. User Credentials EAP authentication is handled by the University s RADIUS servers, which in turn pass user credentials to the Novell edirectory (LDAP) servers for validation. These are the same servers that authenticate Rhodes users when they read e-mail, browse the Internet, etc. Users should therefore make use of their normal Rhodes username and password when connecting to the network. 2009/02/07 2
EAP and RADIUS support the concept of realms. A realm is used to provide routing information in environments where the same RADIUS servers handle authentication for several different organisations. Realms are often specified by appending an @ sign and the realm to the person s username (e.g. username@ru.ac.za). Realms are unnecessary on the staff and student wireless networks, so users can leave any realm or domain field in their supplicant blank. If, however, they want to specify a realm, the correct one for staff and guests is ru.ac.za and the correct one for students is campus.ru.ac.za (i.e. the same as the domain in their e-mail address and the SSID of the wireless network they use). The TTLS EAP type requires an outer identity which it uses to route EAP messages correctly. When making use of TTLS, users should specify anonymous@ru.ac.za as their outer identity. In this context the realm is important; it cannot be left out. Operating System Support For reference, the following table shows which combinations of network authentication, data encryption and EAP type (as implemented by Rhodes network infrastructure) various operating systems are known to support: Security Options Operating System Windows XP (SP2 or later) Windows Vista Apple OSX Leopard Linux, *BSD, etc (wpa_supplicant 1 ) WPA + TKIP + PEAP WPA + TKIP + TTLS WPA + AES + PEAP? WPA + AES + TTLS? WPA2 + TKIP + PEAP? WPA2 + TKIP + TTLS? WPA2 + AES + PEAP WPA2 + AES + TTLS just works no yes yes no Key: Native operating system support Supported, but requires a third-party supplicant such as SecureW2 2 Not supported (conclusively known not to work)? Should be supported, but not able to test properly 1 http://hostap.epitest.fi/wpa_supplicant/ 2 http://www.securew2.com/ 2009/02/07 3
The just works row of the table indicates how well the operating system concerned detects Rhodes wireless network and configures itself to make use of it. Operating systems with a yes here automatically detect a valid combination and thus work out-the-box with no specific user configuration (other than entering a username and password when prompted). Those with a no here require some level of user configuration before they ll connect. This could be as simple as selecting the right options, or could involve the installation of extra software such as a supplicant, drivers or a frontend. For example, installing KNetworkManager 3 in KDE 4 makes wpa_supplicant just work. Security Certificates The EAP methods Rhodes supports make use of X.509 certificates to secure user credentials as they re transmitted over the network. In order to work correctly, the wireless client needs to trust the certificate authorities that issue the certificates we use. Rhodes makes use of two different certificate authorities, and users of the wireless network should make sure that they trust both authorities. These are: Rhodes University CA (SHA1 fingerprint: 2b 47 db 5c a0 e4 c5 26 42 4b b9 c4 00 35 d1 b4 ca a6 bd 5b) Thawte Premium Server CA (SHA1 fingerprint: 62 7f 8d 78 27 65 63 99 d2 7d 7f 90 44 c9 fe b3 f3 3e fa 9a) Rhodes CA certificate is available from https://www.ru.ac.za/certs/. Thawte s CA certificate is built into most operating systems and web browsers. Clients should not validate the certificate s CN (server name) because it s likely to change. 3 http://en.opensuse.org/projects/knetworkmanager 4 http://www.kde.org/ 2009/02/07 4
Appendix: PEAP on Windows XP Manually add a new wireless network with the following settings: On the Association tab: Network Name (SSID): ru.ac.za Network Authentication: WPA2 Data Encryption: AES On the Authentication tab: EAP type: Protected EAP (PEAP) Authenticate as computer: unticked (is ticked by default) Authenticate as guest: unticked Then click Properties to change the PEAP properties On the PEAP properties dialog: Validate server certificate: ticked Connect to these servers: unticked Do not prompt user to authorize...: unticked Authentication Method: EAP-MSCHAPv2 Fast reconnect: ticked (actually, untick if you have problems) Then click Configure... to change the MSCHAPv2 properties On the EAP-MSCHAPv2 properties dialog: Automatically use my Windows logon...: unticked (this can be left ticked if the user logs into Windows with exactly the same username and password as they use for e-mail, etc. the danger is that if the password is wrong they'll get intruder locked out when Windows re-trys authentication) 2009/02/07 5
Appendix: wpa_supplicant on Linux/FreeBSD Option 1: TTLS Put the following into your /etc/wpa_supplicant.conf network={ ssid="campus.ru.ac.za" key_mgmt=wpa-eap proto=rsn WPA eap=ttls anonymous_identity="anonymous@ru.ac.za" identity="username@campus.ru.ac.za" password="xxxxxxxxxxxx" ca_cert="/path/to/thawte.cer" } replacing ssid with the correct SSID, username@campus.ru.ac.za with the correct username and realm and XXXXXXXXXXXX with your normal Rhodes password. (Leave the anonymous_identity as-is, it is important). You'll also need to download and save the Thawte Premium Server CA certificate, and then fix the path in the ca_cert line. Option 2: PEAP Use this instead of the network section above as an alternative. The CA certificate is not required. network={ ssid="ru.ac.za" key_mgmt=wpa-eap eap=peap identity="username" password="xxxxxxxxxxxxx" phase2="auth=pap" } replacing ssid with the correct SSID, username with the correct username (no realm) and XXXXXXXXXXXX with your normal Rhodes password. 2009/02/07 6