«Meetinghouse Data Communications 802.1x AEGIS Client Version 1.3.0 802.1X AEGIS Client User Guide THE SPECIFICATIONS AND INFORMATION REGARDING THE ...»
802.1x AEGIS Client
AEGIS Client User Guide
THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL
ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND
RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE
PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST
TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.
This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (http://www.openssl.org/) This product includes cryptographic software written by Eric Young (firstname.lastname@example.org).
This product includes software written by Tim Hudson (email@example.com).
MEETINGHOUSE DATA COMMUNICATIONS AND ITS SUPPLIERS SHALL NOT UNDER ANY
CIRCUMSTANCES BE LIABLE FOR ANY DAMAGE, OF ANY KIND OR LIMIT, RESULTING
FROM THE USE OF THIS MANUAL.
802.1X AEGIS Client User Guide Copyright © 2001, 2002 Meetinghouse Data Communications All rights reserved.
Table of Contents 1 INTRODUCTION
1.1 HOW IT WORKS
1.1.1 Typical message exchange using MD5 or TLS
1.1.2 Typical message exchange using TTLS
1.2.1 Central User Administration
1.2.2 Dynamic session specific wireless encryption keys
1.2.3 Additional advantages of TTLS
2 INSTALLING AND REMOVING THE AEGIS CLIENT
3 SPECIAL CONSIDERATIONS RUNNING UNDER WINDOWS XP
4 SPECIAL CONSIDERATIONS RUNNING UNDER WINDOWS 98 AND ME..........11 5 AEGIS CLIENT PROGRAMS
6 RUNNING THE AEGIS CLIENT SERVICE
6.1 WINDOWS 98/98SE AND ME
6.2 WINDOWS NT 4.0, 2000 AND XP
7.1 USER SETTINGS
7.2 SYSTEM SETTINGS
7.3 SERVER IDENTITY
7.4 PORT SETTINGS
7.5 DISABLING AND ENABLING 802.1X ON A GIVEN PORT
8 RUNNING THE AEGIS CLIENT MANAGER
9 RUNNING MULTIPLE INSTANCES
10 STATE INDICATION
11 EVENT LOG
11.1 WINDOWS XP, 2000 AND NT 4.0
11.2 WINDOWS 98/98SE AND ME
12.1 OBTAINING A PERSONAL LICENSE
12.2 OBTAINING AN ENTERPRISE LICENSE
1 Introduction Meetinghouse Data Communications’ AEGIS ClientTM is an implementation of the client side of the IEEE 802.1X - Port Based Network Access Control protocol. 802.1X access control provides improved security for both wired and wireless networks. It solves the problem of key distribution in wireless LANs by enabling public key authentication and encryption between Wireless Access Points and roaming stations. It also allows network managers to control 802.1X user profiles from centralized RADIUS or in the case of TTLS, from a RADIUS, Diameter or other AAA servers.
Figure 1-1 shows the network elements involved in a typical wireless LAN. When 802.1X is running, a wireless device must authenticate itself with the access point in order to get access to the Existing LAN. With respect to the terms used in the 802.1X standard, Access Points (APs) function as authenticators and wireless devices function as supplicants. The authenticator keeps a control port status for each AEGIS Client it is serving. If an AEGIS Client has been authenticated, its control port status is said to be Authorized, and the AEGIS Client can send application data to the LAN through the AP.
Otherwise, the control port status is said to be Unauthorized, and application data cannot traverse the AP.
1.1.1 Typical message exchange using MD5 or TLS Figure 1-3 shows the typical message exchange when the device and the AP support
802.1X. When an AP acting as an authenticator detects a wireless station on the LAN, it sends an EAP-Request for the user's identity to the device. (EAP, or the Extensible Authentication Protocol, is an authentication protocol that runs before network layer protocols transmit data over the link.) In turn, the device responds with its identity, and the AP relays this identity to an authentication server, which is typically an external RADIUS server as shown in Figure 1-1.
This allows the RADIUS server to act as a central repository of user profile information.
Such use of a centralized authentication server allows the user to access wireless LANs at many different points, but still be authenticated against the same server. In response to the Access-Request, the RADIUS server sends an Access-Challenge to the AP, which is then relayed in the form of an EAP-Request to the device. The device sends its credentials to the AP, which in turn relays them to the RADIUS server. The RADIUS server determines whether or not access to the network is accepted or denied based on the AEGIS Client's credentials.
1.1.2 Typical message exchange using TTLS Figure 1-5 shows a typical message flow for a TTLS transaction. TTLS negotiation comprises two phases. In the first phase of authentication, TLS is used to authenticate the TTLS server to the client.* The TLS handshake is negotiated between the client and the TTLS server. Following the TLS handshake, phase two may proceed using a secure channel (tunnel) provided by the TLS record layer. The secure tunnel is then used to exchange information for the negotiation of the legacy protocol, either EAPMD5, PAP, CHAP, MS-CHAP, or MS-CHAPV2 (subject to support by the AAA/H server).
A TTLS server may perform the authentication, or the information may be detunneled and passed on to an AAA/H server. The AAA/H server is the server in the user’s home domain where authentication and authorization are administered.
*Note: The TTLS server may optionally request authentication of the client’s certificate, but the default verification is only for the client to authenticate the server’s certificate.
1.2.1 Central User Administration The AEGIS ClientTM allows network administrators to continue to use RADIUS or another AAA server as their centralized authentication server. In 802.11b, where authentication took place between the access point and the station, there was no concept of passing credentials from the access point to an authentication server. For local area networks this was fine, but as users began to use their devices in remote locations the security provided became inadequate. 802.1X solves this problem by allowing access points to pass client credentials to the appropriate authentication server.
RADIUS Server (ISP)
Figure 1-6. Central user administration For example, Figure 1-6 shows the authentication flow for a mobile user who wishes to create a virtual private network with his home office. By using the AEGIS ClientTM, the user can associate with a wireless network provided by a third party, in this case the ISP. We assume that the company and the ISP have established a service relationship beforehand. When the ISP receives the user's credentials, the ISP proxies the credentials to the company's AAA server, which returns a message telling the ISP to either accept or deny the user access. This response is then propagated to the remote user.
1.2.2 Dynamic session specific wireless encryption keys There have been many published reports recently about the lack of security provided by the Wired Equivalent Privacy (WEP) protocol. One of the problems with WEP is that the shared key used by the station and the access point is inherently static. That is, this shared key will only change if it is manually reconfigured on both devices. The AEGIS ClientTM remedies this by supporting the Transport Layer Security (TLS) protocol. TLS ensures that a new shared key is generated each time a station associates itself with an access point. TLS has proven itself to be an excellent authentication and encryption protocol in commercial environments. The AEGIS ClientTM also supports the MD5 and TTLS security protocols.
1.2.3 Additional advantages of TTLS The AEGIS ClientTM provides the advantage of Tunneled TLS (TTLS) support. TTLS provides the security of TLS with greatly reduced administrative load. Security is enhanced by never passing user id and password in the clear. No “real” userid or
Administration is eased by greatly reduced certificate requirements in comparison to TLS. In TLS each Client must have a client certificate to pass to the server, and a CA certificate with which to verify a server certificate, while the server must have a client certificate from each user and CA certificates for each possible CA chain and it’s own server certificate. TTLS requires only that a single server certificate be created for the server to present to the client, and the client needs a CA certificate to verify the server.
Because these are the same for each client on the network, they are easily managed, unlike TLS, where every client certificate is unique. TTLS thus provides the security of a TLS channel without the need for managers to distribute and manage client certificates.
Lastly, TTLS allows for the use of existing legacy authentication protocols.
Administrators may continue to use established authentication databases.
1.2.4 Features • 802.1X supplicant protocol support
• Support for the Extensible Authentication Protocol (EAP) - RFC 2284
• Supported Authentication Methods:
o CHAP/MD5 - RFC 1994 o EAP TLS Authentication Protocol - RFC 2716 o EAP Tunneled TLS (TTLS) – Internet Draft August 2001
• Supports both wireless (802.11b) and Ethernet interfaces.
• Support Agere Wireless LAN PC card, miniPCI card, integrated PC card, and USB wireless LAN adapter.
• Supports Cisco 340 and 350 Aironet cards
• Supports most wireless cards implementing the NDIS 5.1 interface standard.
• Tested against Microsoft's Internet Access Server (IAS) - Microsoft's RADIUS server - supports the EAP attribute defined for extended RADIUS.
• Tested against Funk Odyssey Server using TLS and TTLS
• Tested against AEGIS Server using MD5, TLS, and TTLS
• Tested against Cisco 350 Aironet access point, Enterasys RoamAbout access point, Agere 2000 access point, HP Procurve Ethernet switches, and Nortel Baystack 450 Ethernet switch 1.2.5 Platforms
• Windows XP/2000/NT/ME/98SE/98
The AEGIS Client is distributed as a.msi file, which uses the Microsoft Windows Installer. Put the.msi file in a known directory and double-click the file icon to begin installation. Follow the instructions. You will be prompted to restart the machine at the end of the installation.
NOTE: Versions of the Windows Installer prior to 2.0 will not work. If you have installation problems, download the latest version of the Windows Installer from www.microsoft.com. Be sure to download the file specific to your particular operating system.
To remove the AEGIS Client, use the Add/Remove Programs dialog, which is reached from the Control Panel. If you still have the.msi file, you may execute it and choose the uninstall option.
To disable the XP supplicant, go to Network Connections, and under “LAN or HighSpeed Internet”, right click on the wireless card and select properties. Click on the Authentication tab. Make sure that the checkbox for “Enable network access control using IEEE 802.1X” is not checked. This will disable the remainder of this dialog page.
The AEGIS Client service starts the protocol at boot time to provide early network access. Boot time access will be necessary under some circumstances, such as if the machine is using DHCP to obtain an IP address. In this case the network access is required for the DHCP requests before a user has logged in. If boot time access is not needed, the service may be disabled.
The AEGIS Client manager also runs the protocol. When started it takes over from the service. It will typically start automatically when a user logs in. In addition the manager allows the user to monitor the protocol and to configure both the service and the manager. The manager, mgr8021x.exe, can be started from the command line but more typically is run from an icon in the system tray, or from a startup group. In Windows 2000 and XP, the shortcut to the AEGIS Client manager is installed in the Startup folder of the current user. In Windows NT 4.0, 98 and ME, the shortcut is installed in the All User’s Startup folder. When run from the command line, the AEGIS Client manager takes one parameter, the “start” keyword. If invoked without “start”, the AEGIS Client manager’s user interface is brought up as a monitor without actually starting the protocol. The manager in this case does not take over the protocol from the service.
However the Client may be configured and/or started manually from the interface. It will also show the state of any ports upon which the protocol is already running (having been started at boot by the service).
Windows 2000/XP/NT uses the mgr8021x.exe start command as a default. Typically on this platform, the service is started at boot time. A new instance of the protocol is started by the manager when a new user logs in. The new instance will use that user’s credentials. Please note that the service must have a user account assigned to it, and that account must be configured, in order for the service to be useful at boot. This will be discussed in detail later.
Windows 98/ME uses the mgr8021x.exe command without the start parameter as the default. The manager will not take over from the service unless it is explicitly started.