This document serves as a technology brief for the WPA Security features available in WS5100 3.0 (WiNG). WPA security implementation relies upon the use of 802.1x, Radius and PKI for most of its functioning. WS5100 3.0 has an onboard Radius server, user database and a Certificate server that can be enabled to do WPA2 authentication without requiring an external Radius or Certificate Server. The purpose of this document is to explain the technical details of the 802.1x/ Radius features, provide configuration steps, sample Radius configuration files and recommend best practices for the design and implementation of WLAN security. This document is intended for use by a Symbol Systems Engineer and Symbol Partners.

As with dial-up ISP networks and the Internet, the role of Radius in a WLAN is to provide authentication. This authentication is key to the operation of 802.1x which uses a Radius server to centralize all authentication decisions. The 802.1x framework defines 3 entities – a supplicant (mobile device), an authenticator (Wireless Switch or Access Point) and an authentication server (Radius server) and requires that the mobile device be authenticated before being allowed access to the Wireless LAN. 802.1x uses EAP. EAP just like Radius was originally designed to work over dial-up networks, hence for WLAN implementations 802.1x uses a slightly modified version of EAP called EAP over LAN or EAPOL. More specifically 802.1x encapsulates authentication messages in EAPOL for communication between the mobile device and the wireless switch.. For communication between the Wireless Switch and the Radius server, 802.1x typically uses the Radius protocol. So its EAPOL between Device à Wireless Switch and RADIUS between the Wireless Switch à Radius Server. WPA is an implementation of 802.1x that specifies the use of certain EAP types. Common WPA implementations are EAP-TLS, EAP-TTLS, PEAP etc. WPA uses these EAP types to authenticate a user/ device before allowing them access to the wireless network. However after an authenticated user has access to the WLAN, their data transmission also needs to be protected using some type of encryption. Typically in the past WLAN environments have used WEP for data encryption relying on the use of a pre-shared WEP key for authentication and encryption. There was no special authentication done in WEP environments – a user’s possession of the WEP key was considered a form of authentications. Another problem with WEP was the manual distribution of the WEP key. This coupled with the lack of authentication and other security weaknesses with WEP led to the development of WPA.  However WPA also can use WEP as one of the encryption types (after the user has been authenticated). TKIP is another encryption type that can be used by WPA after authentication. WPA2 also referred to as 802.11i (a fully ratified IEEE standard) requires the use of AES as the encryption type following the authentication phase. Another concept to understand with WPA relates to key distribution. Unlike stand-alone WEP (without authentication) where encryption keys had to be pre-shared or manually distributed, the encryption keys in WPA are automatically generated and distributed by the Radius server. One of the criticisms for WEP was the symmetric nature of encryption (same key used for encryption and decryption). Note that while TKIP (256 bit key) and AES (256 bit key) use stronger keys – they remain symmetric encryption algorithms. The difference is in the case of WPA/ WPA2 – the underlying encryption used – be it WEP/ TKIP or AES  is done on a per-packet basis meaning the key changes per packet. In the older pre-shared key WEP model – the WEP key remain the same for all packets sent/ received. Hence WEP keys were more easily broken and often had to be rotated i.e. manually changed.

If you have followed through so far then we are almost done except for one last piece of the equation – Certificates and Certificate Servers. (ofcourse if you have not followed any of this then go back and read the WPA book).

So - how do certificates fit into all this, does WPA need certificates, where do you get client and server certificates, and what about setting up PKI –do you need dedicated PKI or does the WS5100 have those capabilities onboard. Again PKI like WPA is a vast topic and hundreds (if not thousands) of books/ papers have been written about it. In this section we will briefly review some of the PKI concepts that are essential for properly deploying WPA2. If you are new to this topic the following URL’s contain some white papers that provide a good overview of this relatively vast and somewhat complex topic.

www.netscape.com

Public Key Infrastructure (PKI) makes use of certificates for the purpose of authentication. A Certificate Authority is a core component of PKI and is used for issuing and revoking certificates. You setup a Certificate Authority by setting up one or more Certificate Servers. Here are some of the characteristics of PKI:

-          Public key encryption is asymmetric. This means PKI uses 2 keys – one for encryption and a different one for decryption

-          These 2 keys include a Public Key and a Private Key. These keys are unique - every user has their own unique Public Key and Private Key

-          The Public Key is made available to everyone. The Private Key is never distributed – it is always kept secret.

-          Typically a sender encrypts the message with their Private Key. The receiver decrypts the received message using the sender’s Public Key. (everyone has everyone else’s public key – as it is widely distributed).

Given the above characteristics of PKI, here’s how it can be used for user authentication

Example 1

-          A->B         hello

-          B->A         Hi, I'm Bob, here is bobs-public-key

-          A->B         prove it

-          B->A         Alice, This Is bob
                  { Hash [Alice, This Is Bob] } signed* with bobs-private-key

In the above example Alice receives Bob’s Public Key, a message saying “Alice, This is Bob” and an encrypted version of the same message. The encrypted message was encrypted using Bob’s Private Key. Although Alice does not have Bob’s Private Key, she can decrypt the message using Bob’s Public Key. This is asymmetric encryption.

However in the above example anyone can be Bob – all you would need is a Public Key and a Private Key. Then send an unencrypted message to someone, attach your Public Key and finally an encrypted version of the same message (encrypted using your Private Key). There receiver will successfully decrypt the message and assume they are talking to Bob.

This is the where a Certificate comes into the picture. A certificate typically includes the following:

-          The Certificate Authority’s name (Verisign, etc)

-          The name of the subject to whom the certificate is being issued. (usually involves a manual verification that you are who you say you are)

-          The public key of the subject.

-          Expiration date etc.

The certificate is signed (read encrypted) by the CA using its own Private Key. Everyone has the CA’s Public Key (i.e. the CA itself has a certificate. A certificate contains the Public Key for a subject and is signed by a well known CA

So here’s a more secure transaction using a digital certificate:

Example 2

-          A->B         hello

-          B->A         Hi, I'm Bob, here is bobs-certificate

-          A->B         prove it

-          B->A         Alice, This Is bob
                  { Hash [Alice, This Is Bob] } signed* with bobs-private-key

Alice now also needs the CA Certificate (contains Public Key of the CA) with her. CA Certificates for most leading CA’s usually are embedded in the browser already. So Alice can examine Bob’s certificate, see it was signed by a trusted CA, confirm the subject name to be Bob and then get Bob’s Public Key from Bob’s Certificate.

So why does Bob still have to send the last 2 messages an unencrypted and another encrypted with Bob’s Private Key. Well anyone could have stolen Bob’s certificate and could present it to Alice. But they would not be able to create a message that can be successfully decrypted. Only Bob can do that because only Bob has Bob’s Private Key,

The examples above illustrate the functioning of a protocol originally developed by Netscape called SSL. Today SSL is commonly used for secure Internet Transactions. A more standardized implementation of SSL has evolved into a IETF protocol called TLS. TLS with EAP (TLS over EAP) along with Radius is the basis for WPA authentication.

Examples 1 and 2 above have been referenced from a Netscape document with slight modifications. The original Netscape document is called “How SSL Works” and can be found at http://developer.netscape.com/tech/security/ssl/howitworks.html

The WS5100 has an onboard Radius server and a built-in User Database that can be used for 802.1x EAP Authentication, Hotspot Authentication and VPN’s. The focus for this paper is using the onboard radius server to enable 802.1x EAP authentication for wireless LAN’s. (Hotspot and VPN Authentication are covered in other tech notes). Following EAP authentication types are supported by the onboard Radius server:

-          TLS*

-          TTLS and MD5

-          TTLS and PAP

-          TTLS and MSCHAPv2

-          PEAP and GTC

-          PEAP and MSCHAPv2

* TLS using the onboard Radius server is a new feature in WS5100 3.0

In addition to the EAP authentication WS5100 3.0 Radius capabilities also allow the enforcement of User based policies. User based policies include dynamic VLAN assignment, QOS policy, access based on time of day, etc. While the WS5100 can set these User policies based on the Radius server response – these policies (other than dynamic VLAN assignment) are currently not supported by the onboard Radius server. This requires an external Radius server like Free Radius or Microsoft IAS. The onboard Radius server can however do dynamic VLAN assignment.

VLAN assignment is done at the WLAN level –when a WLAN is configured you also map the WLAN to a VLAN. Dynamic VLAN assignment is done based on the Radius server response. A user who associates to WLAN1 (mapped to VLAN1) can be assigned to a different VLAN after authentication with the Radius server. This dynamic VLAN assignment overrides the WLAN’s VLAN ID to which the User associates.

The WS5100 3.0 has an onboard certificate server. This means you can now generate a self signed server certificate onboard the WS5100 and not have to send a certificate signing request to an external certificate authority (CA). This is a new feature in the 3.0 release.

As reviewed earlier WPA2 uses certificates for authentication. There are 3 types of certificates and depending on the EAP type you may have the following:

-          Server Certificate

-          User Certificate

-          CA Certificate

As the names indicate a server certificate would reside on the authentication server (WS5100 in this case since we are using the onboard Radius server, hence the authenticator and the authentication server are the same system – the WS5100), and the User certificate would be resident on the mobile device. In an authentication mechanism like EAP TLS the WS5100 would present its server certificate to the device and the device in turn would present its user certificate to the WS5100. This is called mutual authentication where the client authenticates the network and vice versa.

The CA Certificate refers to the certificate (public key) of the Certificate Authoirity that signed the User and Server Certificates. If it’s the same CA that issued/ signed the Server and User certificates then you will import a copy of the CA Certificate onto the WS5100 and another copy of the same CA Certificate into the mobile device. This is done to allow the WS5100 and the Mobile Device to verify each others certificates against this Root CA Certificate during the mutual authentication. (as it was the Root CA that signed them)

The W5100 Certificate Server does not generate User Certificates. It can only generate self signed Server Certificates or a Server Certificate signing request. Hence for TLS authentication you will have to generate the User Certificates on an external Certificate Authority and import the CA Root Certificate into the appropriate trustpoint.