WPA security configuration is called 802.1x authentication on the WLAN configuration page of the WS5100. This involves several steps but they can broadly be categorized into the following groups:

-          Radius Server Setup

-          User Database Setup

-          PKI/ Certificate Server Setup

There are 3 options for a Radius setup to be used for 802.1x authentication:

-          WS5100 Onboard Radius and built-in User Database.

-          WS5100 Onboard Radius and External User Database (configured using LDAP)*

-          External Radius and External User Database. (Example: Using a Windows Server 2003’s Radius Server - IAS along with the Windows Active Directory User Database).

This document provides a step-by-step procedure for setting up PEAP and EAP TLS authentication. TTLS authentication has not been covered. The setup procedure for TTLS is similar to PEAP as both require a Server Certificate and do not mandate using a User Certificate. TLS authentication has been covered as it involves some additional step for generating and importing User Certificates.

PEAP and TTLS authentication can be fully configured and terminated on the WS5100 without requiring any external Radius Servers/ Certificate Servers. In the example that follows we will setup PEAP authentication using the WS5100 3.0 onboard Radius Server with User Database and the Onboard Certificate Server.

TLS will require a User Certificate and the Certificate Server onboard the WS5100 3.0 does not generate User Certificates. Hence for the TLS example we will use a Windows 2003 Certificate Server for the Server and User Certificate(s).

*For both examples (PEAP and TLS) we will use the WS5100 Onboard Radius and built-in User Database. The LDAP configuration section in this document has the steps for using the WS5100 Onboard Radius with an External User Database like Active Directory. (the external user database is accessed by the WS5100 using the LDAP Interface)

Step 1: As a first step create a WLAN with the following ESSID  “PEAP-TEST”.

Enable 802.1x authentication for this WLAN by clicking on the 802.1x EAP radio button under Authentication. Select WEP128 under Encryption.

Step 2: Click on the Radius Config button at the bottom. Enter the WS5100’s IP address in the Radius Server Address and set the Shared Secret as symbol.

Step 3: Click OK twice to exit from the WLAN Edit menu. Click enable to enable this ESSID.

Step 4: Repeat Steps 1 – 3 to create another ESSID called TLS-TEST

Make sure you have a DHCP server and other configurations like VLAN’s etc setup appropriately.

In this section we look at configuring the onboard Radius server with built-in database for PEAP and EAP-TLS authentication.

Step 1: Click on Security à Radius Server à Configuration à Add

Enter the WS5100 IP address and shared secret. (this step adds the WS5100 as a Radius client to the onboard Radius Server)

Click Ok. Click Yes on the message – Restart the Radius Server)

Step 2: Click on the Authentication tab (under Radius Server) and select All from the EAP and Auth Type dropdown. Click Apply

Step 3: Click on the Groups tab (under Radius Server) and click Add. Give the Group a name – WPA Test. Select the PEAT-TEST and TLS-TEST Essids from the Available WLAN’s list and click on the Add arrow button. Click OK.

Step4: Click on the Users tab (under Radius Server) and click Add. Add the User name demo and password demo. Select the WPA Test group from the available groups list and click the Add arrow. Click ok.

In this example we will configure a Windows XP laptop to connect to the PEAP-TEST essid. Remember we are using the WS5100 onboard Radius server with its built in database (where we created a user demo in the previous step).

PEAP only requires a Server Certificate. The WS5100 3.0 has a default-trustpoint already setup (by default!!).  This default-trustpoint includes a self signed server certificate for the onboard Radius Server, so there is no additional certificate generation steps required. However because the Server Certificate in the default-trustpoint is self signed there is no CA Root Certificate available under the default-trustpoint.

An important part of the PEAP authentication process is the mobile device authenticating the network. This is done by the WS5100/ server presenting its Server Certificate to the mobile device and the device validating this Server Certificate by checking it against the signing CA’s - CA Root Certificate. Since the Server Certificate we are using is a self signed certificate you will need to import the CA Root Certificate into the certificate store of the mobile device for this to work.

Since there is no CA Root Certificate available and because the Server Certificate is self signed – you can import the Server Certificate into the mobile device as the CA Root Certificate (they both have the same Public Key). In order to import the Server Certificate into the mobile device you wil first need to export the Server Certificate from the WS5100. You can export the Server Certificate by clicking on Server Certificates à Transfer Trustpoints (bottom right).

Select From à Wireless Switch and Specify the Ip address of a FTP/ TFTP Server, give the path etc and click Transfer.

Doing this will export 2 files default-trustpoint.crt and default-trustpoint.prv to that FTP/TFTP servers folder. You will need to copy the default-trustpoint.crt file and transfer it to the mobile device using Activesync. Once on the mobile device, this certificate can be installed by double clicking it.

Although it is not recommended - you can configure many supplicants (including WinXP and Fusion 2.x) to bypass this Server Certificate Authentication. Bypassing the Server Certificate validation will save you the process of exporting the CA Root Certificate and importing it on the mobile device. 

Step 1: Double click on the Wireless Network Connection. Find the essid PEAP-TEST. Click on Change Advanced Settings on the Right.

 Step 2: Click on the Wireless Network tab, select the essid PEAP-TEST and click Configure

Step 3: Click on the Association tab. Under Network Authentication, select Open, Data Encryption select WEP. Select the option “The Key is provided to me automatically”.

Step 4: Click on the Authentication tab. Select Protected EAP (PEAP). Click on Properties.

Step 5: Unselect “Validate Server Certificate” (this is not recommended for a real deployment – its being done to avoid importing the CA  Root Certificate). Click Ok.

Step 6: Optional: Integrated Windows Authentication: If you need to use the Windows domain login credentials for PEAP authentication, click on Configure at the bottom instead of Ok. Select the “Automatically use my Windows logon name…” and click Ok. Click Ok again to complete the PEAP profile setup.

 Step 7: Wait a few seconds and then click on the message next to the Wireless Network Connection buttom in the system tray (bottom right) to get the PEAP credentials pop up. Enter User id = demo Password = demo. Click Ok.

Step 8: Verify the laptop’s wireless connection to the PEAP-TEST ESSID.

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.