IEEE 802.1X specifies a method for authenticating and authorizing a device attached to a LAN port. It is used on both wired switches and on wireless access points (where the “attachment” is not physical). 802.1X provides optional support for use of an authentica- tion server, such as a RADIUS server, which is recommended for larger installations.
Chapter 8: Developing Network Security Strategies 257
802.1X is extensible and supports a variety of authentication algorithms. The most com- mon are varieties of EAP, which is an IETF standard, documented in RFC 2284. With 802.1X and EAP, devices take on one of three roles:
■ The supplicant resides on the wireless LAN client.
■ The authenticator resides on the access point.
■ An authentication server resides on a RADIUS server.
When 802.1X and EAP are implemented, a client that associates with an access point cannot use the network until the user is authenticated. After association, the client and the network (access point or RADIUS server) exchange EAP messages to perform authen- tication. An EAP supplicant on the client obtains credentials from the user, which could be a user ID and password, a user ID and one-time password, or a digital certificate. The credentials are passed to the authenticator or server and a session key is developed. With 802.1X and EAP, session timeouts force a client to reauthenticate to maintain net- work connectivity. Although reauthentication is transparent to the client, the process of reauthentication generates new WEP keys at every reauthentication interval. This is important for mitigating statistical key derivation attacks and is a critical WEP enhance- ment. One disadvantage of 802.1X with EAP, however, is that reauthentication can cause some delay, when compared to using a static WEP key. This might cause a problem for users that roam with delay-sensitive devices, such as 802.11 phones.
Note that EAP authenticates users. Whereas 802.11 authentication is device-based, EAP is based on authenticating a user rather than a wireless LAN device. This avoids the prob- lems caused by theft of a laptop computer using a static WEP key, which would allow the thief access to the network and would probably result in a network administrator needing to change the WEP key on the affected access points and all clients. EAP generates unique keying material for each user. This relieves network administrators from the bur- den of managing static keys. EAP also supports mutual authentication, which allows a client to be certain that it is communicating with the intended authentication server. Selecting the right EAP implementation can be a challenging process due to the large num- ber of options. The funny-sounding names, such as LEAP and PEAP, don’t help matters. You must get this right though. The supplicant, authenticator, and authentication server must all support the same variety of EAP, which is mostly likely one of the following:
■ Lightweight EAP (LEAP): Developed by Cisco and is sometimes called EAP-Cisco. Cisco licenses LEAP to other vendors, including Apple Computer and Intel. LEAP supports user-based authentication and dynamic WEP keys that are generated after authentication and when session timeouts occur. User authentication is based on a user’s Windows logon, which means the user does not have to supply additional lo- gon information to access the wireless network, which makes LEAP easy to use. LEAP supports mutual authentication, which means that the client authenticates the server and the server authenticates the client. This is important for ensuring that the client talks to an authorized server and not a hacker posing as a server.
258 Top-Down Network Design
■ EAP-Transport Layer Security (EAP-TLS): Developed by Microsoft and is docu- mented in RFC 2716. Microsoft supports EAP-TLS in all versions of Windows XP and has released a free Windows 2000 client. Like LEAP, EAP-TLS supports mutual authentication, dynamic keys, and session timeouts. EAP-TLS requires certificates for clients and servers. Because of this, some users consider Microsoft’s EAP to be more secure than other EAPs. However, the certificate requirement also means EAP- TLS needs certificate management, such as the use of a trusted certificate authority and the ability to quickly revoke certificates.
■ EAP-Tunneled TLS (EAP-TTLS): Developed by Funk and Certicom and then turned over to the IETF, where it is currently (as of this writing) a standards-based Internet draft. EAP-TTLS is an enhancement of EAP-TLS, with support for advanced authen- tication methods such as token cards. A variety of vendors have signed on to support EAP-TTLS.
■ Protected EAP (PEAP): Supported by Cisco, Microsoft, and RSA Security. Like LEAP and EAP-TLS, PEAP supports mutual authentication, dynamic keys, and ses- sion timeouts. PEAP uses a certificate for the client to authenticate the RADIUS server. The server uses a one-time password or a username and password to authenti- cate the client. When the client validates the server’s certificate, it builds an encrypt- ed tunnel and then uses EAP in the tunnel to authenticate. PEAP is more manageable and scalable than EAP-TLS. Organizations can avoid installing digital certificates on every client machine, as required by EAP-TLS, and select the method of client authentication that best suits them.
■ EAP-MD5: Has no key management features or dynamic key generation. Although EAP-MD5 is supported on many platforms, it will probably be phased out of most wireless networks because it has few benefits over WEP.