Designing a Secure Wireless LAN with the HP-UX AAA RADIUS Server Version 1 February 2004 A White Paper by the Hewlett-Packard Company Printed in the U.S.A. © Copyright 2004 © Hewlett-Packard Development Company, L.P.
Legal Notices The information in this document is subject to change without notice. Hewlett-Packard makes no warranty of any kind with regard to this manual, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. Hewlett-Packard shall not be held liable for errors contained herein or direct, indirect, special, incidental or consequential damages in connection with the furnishing, performance, or use of this material.
Contents Abstract .............................................................................................................................. 6 Chapter 1 Introduction..................................................................................................... 7 Chapter 2 The Secure WLAN Infrastructure........................................................................ 8 2.1 The Basic Wireless LAN............................................................................................. 8 2.
Integrating VPN and WLAN Protocols ........................................................... 51 Appendix A A.1 VPN (IPSec) Review............................................................................................ 51 A.2 WLAN Security (802.1X – WEP – WPA) Review ..................................................... 51 A.3 VPN Versus WLAN .............................................................................................. 51 Example 1: Public WLAN .........................................
Abstract Wireless Local Area Networks (WLANs) are widely deployed in today's enterprise network— whether they are planned for or not. The progression of security standards, and the transition from network-based security to user-based security, has enabled the deployment of secure WLANs in the enterprise. The HP-UX AAA RADIUS Server is a vital component for mitigating WLAN security risks and can easily integrate into your existing, or new, user-based authentication mechanism.
Chapter 1 Introduction The rapid proliferation of WLANs will ultimately change how employees and organizations accomplish their work.
Chapter 2 The Secure WLAN Infrastructure As with any network topology, a Wireless LAN design can be very simple, with little or no security provisions, or can be increasingly complex, as security policies are addressed and WLAN integration into an existing enterprise network is achieved. A simple WLAN can be purchased for a few hundred dollars and configured in about an hour. A secure WLAN requires additional components and a substantial configuration effort.
network that is referred to as an “ad-hoc” WLAN. When a client communicates with an access point or wired network service, it is known as an “infrastructure” WLAN. All future references to WLAN in this document refer to infrastructure mode. The basic WLAN is easy to set-up and run, but its well-publicized vulnerabilities result in what is essentially a public broadcast of LAN traffic.
described in Chapters 3, 4, and 5) and per-user-session encryption keys can be created, eliminating the need for shared secret keys. User-based security provides enterprise level secure Wireless LAN access and management. In addition, the HP-UX AAA RADIUS Server is not bound to hardware versions or features, so as standards evolve and new security features are added, server updates comply with the latest technology developments.
2.4 The Basic Wireless LAN Components The basic Wireless LAN consists of hardware components and software components. For clarity, these components are defined here: 2.4.1 WLAN Hardware • • • 2.4.2 Client or station: a mobile device or static device equipped with a wireless Network Interface Card. Wireless PCMCIA laptop computer NICs are widely available or wireless NICs can be integrated into newer model laptops or PDAs.
Chapter 3 Making Sense of WLAN Standards One of the challenges of designing and deploying a Wireless LAN is to maintain flexibility when interoperating with equipment and software from multiple vendors. Wireless LAN standards help to address that challenge. The array of WLAN standards can be confusing due to similar naming conventions and continuing updates, resulting in the commonly used term “standards soup.
A key provision of 802.1X is the following 3 term definitions: • • • supplicant: the client that is being authenticated (for WLAN, a laptop or PDA) authenticator: the access point – receiver of client wireless signals authentication server: in this case, the AAA RADIUS Server These terms also describe the structure of the typical secure WLAN. 3.3 Wired Equivalent Privacy - WEP WEP is the Wired Equivalent Privacy protocol that is part of the 802.11 standard.
requiring changes to the underlying network protocols (in this case, 802.1X), and new authentication protocols (EAP methods) as well. EAP itself is an established standard. EAP methods are defined in IETF RFCs, RFC drafts, or can be proprietary, but they can all be carried by EAP.
• • • The server distributes and manages WEP keys for AP-to/from-supplicant encryption TLS solves password and dictionary attacks via certificate authentication TLS requires considerable management effort to distribute and maintain certificates (PKI) to clients and to maintain certificate lists (privileges and access rights) The effective security provisions enabled by certificate usage can be offset in some cases by the management effort for certificate distribution and maintenance.
Authentication Service / User Data Store AAA RADIUS (to Authentication, Directory, etc) VPN IPSec MD5 TLS TTLS LEAP PEAP MISC EAP PPP 1. 2. 3. 4. 5. 802.3 802.11 The bottom layer is the link layer authentication vehicle with 802.11 The next layer is EAP delivering the subordinate EAP-methods. 802.1X defines how to encapsulate EAP in Ethernet frames. When the authentication is finished, EAP goes away, but IPSec/VPN can take over AAA RADIUS can access a variety of user data store formats 3.
Chapter 4 Enterprise WLAN Security Designing and deploying an Enterprise Wireless LAN involves selecting the proper components based upon standards adherence, interoperability with existing and proposed components, security requirements, feature availability, and other factors. These components must then be assembled into an integrated working infrastructure.
end of a connection can be achieved using a key, token, password, or anything that a user, server, or any entity requesting authentication can use to identify themselves. Access Control is provided by WLAN access points, which will deny network access to unauthorized users (typically those that fail authentication).
enable authentication for Wireless LAN or network access in the enterprise IT infrastructure.
4.2.1 Flat File User Database The HP-UX AAA RADIUS Server includes a default flat file user database repository. Users are stored in records on the flat file (see the configuration example in Chapter 5) that include various user attributes for AAA, including the user password. Users can also be grouped by realm in the default user file.
4.2.3 Oracle User Database The HP-UX AAA RADIUS Server can also utilize user data that is stored in an Oracle database.
Chapter 5 Configuration Examples Understanding how Wireless LAN security works, how the standards apply, and how the components fit into an enterprise security infrastructure is essential for the design phase. But eventually, the deployment must begin. The following sections show the deployment evolution of a Wireless LAN through step-by-step configuration examples, resulting in a secure implementation with a AAA RADIUS Server and an LDAP user date store.
5.1 Rogue Access Point: No Security Many wireless LANs start out as a simple rogue access point that is plugged into an existing wired LAN. This holds true for the casual home network or an enterprise secured LAN. LAN laptop client (MACaddr1) Access Point (SSID) PDA client (MACaddr2) LaserJet client (MACaddr3) Because there are no security measures configured, the steps to configure client access are simply to scan for wireless networks on the client (supplicant) and connect.
5.2 Configure WEP and MAC Filtering Enabling WEP on the access point and the client is the easiest way to provide a minimum level of security. WEP enables rudimentary data integrity and privacy. MAC filtering can also be enabled on the access point very easily, and provides rudimentary static client authentication. Configure WEP key on supplicant Configure WEP key on AP.
matches AP The access point WEP key configuration is nearly identical to the client (supplicant), which contributes to the ease-of-use aspect of WEP in general. Simply enable WEP by checking the box, and then specify the 104-bit 13-digit shared key. matches client The client-to-access point transmission is now encrypted for privacy, but authentication is missing. The access point configuration allows for MAC address filtering, which provides a static hardware level authentication.
matches client MAC 26
5.3 Configure AAA RADIUS An enterprise may have various rogue access points configured, with various levels of networkedbased security using WEP and MAC filters. Access points may also be installed on a department level with various levels of network-based security. When it is time to design a WLAN security infrastructure, these various rudimentary custom configurations must be migrated into the enterprise security scheme.
A client profile must be created for the particular authentication attributes. The profile name is SNSLATC. The user name must be entered under the “User Info” tab. This user name will also be entered on the AAA RADIUS server. For this configuration a password will be supplied by the client to authenticate to the AAA server. The password is configured on the supplicant so that the user is not prompted. Next the “Authentication” tab is selected. EAP/TTLS is the Authentication protocol that is configured.
After selecting EAP/TTLS as the authentication protocol, the inner-tunnel password exchange protocol is determined. PAP (Password Exchange Protocol – see Appendix D) is selected. Remember from the previous TTLS discussion that the password exchange occurs inside the secure TTLS tunnel, so the actual exchange protocol is not exposed to WLAN network attacks. Also configured is an anonymous user login for the TTLS tunnel itself.
The initial client supplicant configuration is complete. Later, the client configuration will be updated to include validation of the server certificate to require mutual authentication (so far the configuration only authenticates the client and not the server). 5.3.2 Authenticator (access point) Configuration The MAC address authentication task that the access point processed is now removed, and authentication is forwarded to the HP-UX AAA RADIUS Server.
802.1X and WEP Next, the access point is configured to forward requests to a specific AAA RADIUS server, and the specific port that the radiusd (HP-UX process) is listening on. AAA Server IP /etc/services radius port The access point is now ready. The last component to be configured is the HP-UX AAA RADIUS Server. 5.3.3 Authentication Server (AAA RADIUS Server) Configuration HP-UX AAA RADIUS Server version 6.1.2 is used for this secure Wireless LAN installation. Version 6.1.
Careful attention must be given to software dependencies for the AAA RADIUS Server. Before installing, obtain and read the most current Release Notes and Getting Started Guide. These are available for free at: http://www.docs.hp.com/hpux/internet/index.html After installation and verification, configuring the AAA RADIUS server can progress using the Server Manager web-based Graphical User Interface. Using the left-side navigation tree, scroll down and select “802.1x Advisor.” The HP-UX AAA Server 802.
Load the default configuration from the local host: Start the configuration process by selecting access points. Enter the new access device name. The access point (or access device) shares a secret key with the AAA RADIUS Server. Configure the “Shared Secret Key” parameter to match the “Shared Secret” parameter from the 802.1X Access Point configuration listed above. The Vendor parameter requires special attention for EAP.
The access point configuration data is stored in: • /etc/opt/aaa/clients HPATCWAP1.ROSE.HP.COM secret type = microsoft:nas v1 The access point configuration is now ready. The next task is to configure Local Realms. AAA is configured on a per-realm basis. A realm is a name for a group of users who share a common characteristic, such as belonging to the same organization, Windows domain, or internet service provider.
The atcttls.com realm is configured with a realm type of “TTLS Tunnel.” The hpatc.com is configured with the default realm type of “authentication” because the simple PAP protocol will be used for password exchange. The users are stored in the default configuration file (later this will be changed to LDAP).
The default user file is: • /etc/opt/aaa/users atcuser@hpatc.com Password = “atcpass” In this simple example, the password is stored in clear-text. Passwords can also be stored as hashes. The 802.1x Advisor contains a Password Hashing Compatibility Table that clearly communicates the available options: After the realms have been configured, users are added.
Remember from the supplicant Profile “TTLS Settings” that an “Anonymous name” was added for the TTLS tunnel login. This user belongs to the atcttls.com realm, but an explicit user configuration is not required for Anonymous. A user definition for atcuser@hpatc.com is required. The user name is entered, along with the user password. No authentication type is selected (for PAP), and the Password Hashing Mechanism is “Plain Text” (also for PAP).
o Users hpatc.com: profiles in default file, password authentication atcuser@hpatc.com: no auth type, password, hashing = plain text Do not configure anonymous@atcttls.com (tunnel user) Now go to the AAA Server Manager Navigation Tree and select “Save Configuration”, then stop the server, then start. The new configuration is now loaded and running. On the client, the supplicant software should be running. Choose “Connection” from the left-side navigation window.
client with WEP key distribution. However, mutual authentication has not been configured. Thus, the current setup only provides for the server authenticating the client, but the client has not authenticated the server. In the next step, the client and server will be updated to provide client authentication of the AAA RADIUS server. 5.3.4 Adding Mutual Authentication The HP-UX AAA RADIUS Server version 6.1.
3. A Certificate Import Wizard is started. Click “Next.” 4. The Certificate store window is displayed. Select “Place all certificates in the following store” and then select Browse. 5. The Browse window is displayed. Select “Trusted Root Certificate Authorities” and OK.
6. Click “Next.” 7. The Certificate Import Wizard then completes. 8. When the following dialog-box is displayed, select Yes. 9. The import will be successful – click OK.
10. Start the Funk Odyssey supplicant and select Trusted Servers from the Navigation menu. 11. Add the HP-UX AAA RADIUS Server Certificate cn (Common Name). 12. Select Browse, then the HP-UX AAA RADIUS Server name. Click OK.
13. The Trusted Servers screen acknowledges the new trusted server. 14. Go to the supplicant Profile Properties and choose the Authentication tab, where EAP/TTLS was selected as the Authentication Protocol. Now check “Validate server certificate”, which enables the supplicant authentication of the server. 15. Connect the supplicant to the Wireless Network.
The client has authenticated the HP-UX AAA RADIUS Server using the server self-signed certificate, and the server has authenticated the client using the 802.1X EAP-TTLS protocol with PAP. 5.3.5 Configure AAA RADIUS Summary After the completion of the preceding configuration example, the Wireless LAN network is operating with the following security features: • • • HP-UX AAA RADIUS Server 1. EAP-TTLS authentication protocol over 802.1X 2. PAP – Password Authentication Protocol 3. Distributed WEP keys 4.
5.4 Configure AAA RADIUS with LDAP Configuring the AAA RADIUS server to store user profile data on a directory server has several advantages over the default files storage: • • • • Administration consolidation High performance and scalable Secure user data storage User policy granularity The HP-UX Netscape Directory Server and LDAP are entirely separate and complex topics. A prerequisite to this configuration is the installation of the HP-UX Netscape Directory Server.
LAN Access Point (SSID) laptop client (MACaddr1) HP-UX Netscape Directory Server PDA client (MACaddr2) LaserJet client (MACaddr3) HP-UX AAA RADIUS Server Migrate users from default file to Netscape Directory The migration of user profile storage, retrieval, and management is purely a AAA RADIUS server configuration task. Therefore, no supplicant or access point modifications are necessary. The primary configuration task for LDAP migration is to modify the local realm.
Directory Manager (or authorized user), and the location for where the AAA users will be stored in the directory. Choose “search” as the “Authentication Type.” Note that this Authentication Type is not related to the 802.1X authentication method or the password exchange. Save this configuration, but do not save the AAA server configuration yet. Next, the existing user profiles must be deleted from the default local file.
Save the AAA server configuration, then stop and start the server. The AAA Server is now ready to retrieve user profiles from the LDAP directory server. NOTE: User profile data must be entered into the directory server. For this configuration, the following data was entered: • • Login Name: atcuser Password: atcpass On the client, the supplicant software should be running. Choose Connection from the left-side navigation window.
TTLS.CUP.HP.COM -DEFAULT { EAP-Type TTLS } ldap.atc.hp.com -DEFAULT { EAP "" ProLDAP "" Filter-Type CIS Directory "hpatcux3" { Host hpatcux3.rose.hp.com Port 389 Administrator "cn=Directory Manager" Password "ldapldap" SearchBase "ou=People,ou=ldap-ux,dc=hp,dc=com" Authenticate bind } } 5.
Chapter 6 Conclusion Wireless LAN proliferation, from home networks to enterprise global networks, is as inevitable as wired LANs were in the 80s, or the Worldwide Web in the 90s. The benefits are too compelling to ignore. So the question of WLANs then shifts from “whether to deploy”, to “how to secure.
Appendix A Integrating VPN and WLAN Protocols A common method of securing remote access to an enterprise network is Virtual Private Network (VPN) using IPSec. For years enterprises have utilized VPN over a remote wired network connection to provide effective data encryption from a client outside of the enterprise network to a point within the firewall, thereby supplying secure corporate network access.
At a public wireless LAN hotspot (an airport, trade show, coffee shop, or similar location), a user may want to connect to the internet to read the web edition of a newspaper. The public hot spot has no WLAN security enabled, thus the user’s data can be easily sniffed from the air. But the user is only reading public data, so privacy and security issues are minimal. However, if the user decides to access email from within the corporate network, then privacy and security issues are maximized.
4. Network topology is not affected (like VPN and VPN gateways). 5. Can leverage existing authentication (AAA RADIUS can integrate). Disadvantages are: 1. New client software required (supplicant). 2. New technology means possible interoperability issues (clients and access points). 3. Data only protected from the client to the access point (okay if the internal network is secure). A.7 Summary VPN deployments already exist in many enterprise networks.
Appendix B Case Study Integrating HP-UX AAA RADIUS Into Existing Non-Standard Authentication The prior deployment examples illustrate how to configure a Wireless LAN from a rogue access point to a secure 802.1X environment design with AAA RADIUS. But some business networks may not be using a standard user data repository and authentication system. For these cases, the server must be customizable to provide the flexibility to integrate with an existing nonstandard identity management system.
LAN Access Point (SSID) laptop client (MACaddr1) HP-UX AAA RADIUS Server Requires Windows Domain Controller Windows Domain Controller – User Login Data Store Netscape Directory Server – User Enterprise Data Store The default authentication protocol for the enterprise-wide Windows client platform was the Microsoft proprietary NTLMv1 protocol.
• • • • Include files Make files Configuration files Additional tools The SDK can be used by developers to code their own C libraries that provide programmatic interfaces to non-standard user data stores, authentication methods, and other configuration components. The AAA server has a modular design that allows custom libraries to be easily added to the product.
can now be customized to access a Windows domain controller for a Windows user password combination. This configuration will also utilize the existing Windows client user and password. B.3.1 Supplicant (client) Modifications The supplicant software will require a new user profile, and the profile login will utilize the Windows user and password in the User Info screen. The Authentication screen is unchanged.
The TTLS Settings are unchanged. The new user profile is configured for the network profile. B.3.
This configuration modification affects only the username and user password. The 802.1X EAP method is unchanged, and the distributed WEP keys are unchanged. Therefore, the access point configuration is unaffected. B.3.3 Authentication Server (AAA RADIUS Server) and NTLM Plug-In The resulting output of the development effort for the NTLM plug-in is a compiled binary library named aaa_ntlm.sl.
atcttls.com -DEFAULT { EAP-Type TTLS } hpntatc.com hpatc.com { -DEFAULT -DEFAULT EAP "" NTLM NTLM Authentication ProLDAP "" Filter-Type CIS Directory "hpatcux3" { Host hpatcux3.rose.hp.com Port 389 Administrator "cn=Directory Manager" Password "ldapldap" SearchBase "ou=People,ou=ldap-ux,dc=hp,dc=com" Authenticate bind } } The new hpntatc.com realm is created by adding the single line (in bold above) to the file. Observe the hpatc.com realm with the ProLDAP configuration and the atcttls.
Select the hpntatc.com realm: Observe that the “User Profile Storage” is now NTLM. NTLM is the protocol, and the storage is located on the Windows domain controller. The HP-UX AAA RADIUS Server modifications for NTLM authentication are now complete. B.3.5 NTLM Configuration The NTLM plug-in calls the libsmb library to access the Windows domain controller and run the protocol to retrieve the user and password. As discussed earlier, the libsmb library can be obtained from public domain sources.
##============ Global Settings ================= [global] ## workgroup: NT-Domain-Name or Workgroup-Name workgroup = HPATC ## password server: the netbios names of systems which will ## be used to authenticate logins. password server = HPATCWIN ## wins server: the system used to locate password servers, ## wins server = winserv.mycorp.com The Windows domain name is HPATC – entered by the workgroup parameter. The Windows domain controller is HPATCWIN – entered by the “password server” parameter.
The user is authenticated by the Windows domain controller, and the Wireless LAN connection is established: To verify the correct operation of the NTLM plug-in, go to the HP-UX server, and list the tail of the AAA logfile: 4. tail /var/opt/aaa/logs/logfile Thu Oct 2 08:44:24 2003: Received-Authentication: 57/302 'anonymous@atcttls.com' via HPATCWAP1.ROSE.HP.COM from HPATCWAP1 - Start EAP Thu Oct 2 08:44:34 2003: Created-Authentication: 60/305 'anonymous@atcttls.com' via HPATCWAP1.ROSE.HP.
B.5 Case Study Summary The case study illustrates how the SDK provides the flexibility to customize the HP-UX AAA RADIUS Server for non-standard network and IT environments. For this case, the SDK was used to code a plug-in module for Windows user authentication on the Windows domain controller data store. The earlier LDAP example illustrated a similar built-in configuration using LDAP and the HP-UX Netscape Directory Server. This level of customization requires development resources and testing.
