Authentication and Access Control

Connecting to wireless networks is designed to be easy. In fact, ease of connection is one of the major advantages to many newer wireless technologies. 802.11 networks announce themselves to anybody willing to listen for the Beacon frames. To protect networks against the threat of unauthorized access, strong access control must be applied. When a wireless station connects to a wireless LAN, there are four ways in which access control can be applied:

Station authentication

The first step in connecting to a wireless LAN is to perform 802.11 station authentication. Station authentication is either open system authentication, in which only trivial authentication is performed, or shared key authentication, which depends on the use of a WEP key. (For more details, see Chapter 9.) Many products offer the ability to perform MAC address filtering at the authentication phase to screen out "unauthorized" clients by MAC address.

Association

After authentication completes, stations attempt to associate with the access point. Generally, this process does not have any security components, though MAC address filtering could also be applied at this step.

Link layer

Once association has established the virtual network "port" on the access point for the wireless station, link-layer security protocols based on 802.1X can be applied. Authorized users can be connected to resources they are allowed to use, and unauthorized users will be kicked off the network. Wireless networks are open to eavesdropping, so it is necessary to choose an authentication protocol based on strong cryptographic fundamentals.

Network-or transport-layer

IP-based networks have an unfortunate history of security failings, and a number of higher-layer security products can be applied to critical points in the network. Firewalls can be used to isolate untrusted networks and authenticate users, and VPN termination devices can supply encryption over untrusted networks.

Different authentication protocols work at different layers in the OSI stack. Initially, the native link-layer security mechanisms were quite weak, and network administrators were forced to work at higher layers in the stack. Much of the engineering and design effort in wireless LAN security over the past few years has focused on developing strong link-layer security mechanisms. At this point, network administrators have a choice of protocols to secure the network. In order from weakest to strongest, they are:

WEP shared key authentication

In shared key authentication, systems seeking network access respond to a challenge from the AP. Shared key authentication is so horribly constructed that it was deprecated (its use was recommended against) by 802.11i.

MAC address filtering

Every AP in the network is programmed with a list of MAC addresses allowed network access. MAC addresses are easily forged and duplicated, but some older devices may offer nothing better.

WPA preshared key (WPA-PSK or WPA Personal)

One of WPA's major additions was a preshared key mode that allows stations to authenticate to a network while in possession of only a passphrase. It is significantly stronger than either of the previous approaches, but even stronger methods exist.

802.1X-based protocols

802.1X was designed to identify and authenticate users before granting network access. Because it is based on the Extensible Authentication Protocol (EAP), "802.1X" is often used to refer to any one of the extended authentication methods that runs over EAP. Some software may refer to this as WPA Enterprise.

Network-layer authentication

Insecurity of IP-based networks is hardly a new phenomenon. Many past products have attempted to address authentication of network users in one form or another, and there is a plethora of systems and protocols that can be used once the network (IP) layer is established. Most of the appropriate methods for use with wireless networks will tie in with VPN technology that can also be used to secure the network traffic.

Station Authentication and Association

Applying security at the station authentication phase or the association phase is quite weak. Security mechanisms available at first stages of connection are not strong at all.

An early "security" feature began life as the so-called closed network.[*] In the early days of 802.11, stations had to be configured with the network name (SSID) used by an access point. Client software was so primitive that it searched Beacons in the air for a given network name before associating. The closed network consisted of two components. Access points would send Beacons as required by the standard, but without the SSID information element. Without the SSID in the Beacon frames, there was a minor gain in privacy because some client software would not display an available network. To associate, clients were required to send a Probe Request that includes the SSID, making it function as a hidden "key." APs using the SSID hiding features would only accept Probe Requests from stations that already are configured with the hidden SSID. However, Probe Requests are not encrypted; any station that observes a successful exchange of probe frames can see the SSID and use it in a subsequent association attempt. Attackers who need to know the SSID immediately can even disassociate authorized stations to force transmission of the SSID in the probe exchange when the station reconnects.

[*] This feature may go by several names, including cloaked network, SSID broadcast suppression, private network name, and several further variations.

One common approach, supported by nearly every product, is MAC address filtering. Access points maintain a list of authorized MAC addresses, and deny connection requests from stations not on the list. Screening MAC addresses is better than nothing, but certainly leaves a great deal to be desired. Like wired Ethernet cards, 802.11 cards may change the transmitter MAC address, which undermines the use of the MAC address as an access control token. Attackers equipped with packet sniffers can easily monitor successful associations to acquire a list of allowed MAC addresses.

Practical headaches often compound the use of MAC address filtering. Maintaining the address list is an administrative headache, especially if users are prone to using multiple devices or changing the cards they use. Many products were not designed for large-scale management and require the same information to be entered in to each device individually. Many products that have centralized distribution of address lists require the use of TFTP. TFTP has no place on a secure network.

A second approach to authentication is WEP shared key authentication. Access points issue a challenge to a device seeking network access. As discussed in Chapter 5, shared key authentication is broken, and cannot provide any protection from malicious users seeking to authenticate to the network. It is possible to fake a legitimate response to a WEP challenge without any knowledge of the WEP key. (It would, however, be impossible to send traffic without first recovering the WEP key.)

In some products, address filtering and shared key authentication may be combined. However, both are easily defeated. Only consider these two rudimentary methods if you are stuck with wireless client devices that cannot support stronger protocols, and an upgrade is out of the question. Devices that are stuck with crude authentication mechanisms are usually quite old. Logistics applications of 802.11 were an early win for the technology, and the handheld inventory and tracking scanners used in the logistics field typically have limited computing power. Some cannot even do WEP, and quite a few run MS-DOS!

Address filtering and shared key authentication are awful security, and should only be used when absolutely necessary, such as with devices that do not support anything better.

 

Link-Layer Authentication

Link-layer authentication, in the form of 802.1X and WPA, is a significant step up from simple filtering approaches. Authenticating users has several advantages. Typical link-layer authentication schemes allow very restricted network access for the purpose of authentication. Full network access is only granted once the user is positively identified. In the wireless LAN world, obtaining user identity early in the network attachment process allows the network to provide much finer access controls because users can be classified and restricted before obtaining network access. Link-layer authentication is transparent to network protocols, and will work for any network protocol you choose. Networks are increasingly homogenous and based on IP, although there may be pockets of older protocols such as IPX. Link-layer authentication can be used to secure both IP and IPX. In many cases, link-layer authentication is also relatively fast because it can happen as the network interface is brought up. Rather than using protocols designed to work across wide-area networks, link-layer authentication can start immediately when the link is established.

WPA Personal (preshared key)

WPA has two modes. The simpler of the two is based on distributing a preshared key (WPA-PSK) to all wireless clients. Key derivation for the wireless link is based on random numbers exchanged along with the preshared key. As with any protocol that uses a preshared key, WPA is vulnerable to dictionary attacks by determined attackers.[*] In essence, WPA PSK is a shortcut. Rather than depending on a computationally intensive multimessage TLS exchange to derive keys, WPA-PSK derives the preshared master key from a passphrase and the SSID.

[*] An attack tool, called coWPAtty, is available from http://remote-exploit.org.

In most cases, a single preshared key is used for all stations in an SSID. In such networks, all stations share the same master key. With the preshared key, an attacker can monitor the four-way handshake described in Chapter 7 and derive the unique keys for any other station which shares the same preshared key. Attackers can also forge messages that force reauthentication, which enables them to capture the four-way handshake.

Security of WPA-PSK depends a great deal on the quality of the passphrase. 802.11i Annex H discusses passphrase quality, and notes that a passphrase usually only has 2.5 bits of security per character. Very short passphrases are subject to dictionary attack.

The best defense against weak passphrases is to use either the binary preshared key mode and enter the 256-bit preshared key, or to use a strong passphrase. (Not all products support entering the preshared key directly.) The best passphrases will have more than 20 characters, and avoid common phrases and dictionary attacks. Further advice on passphrases and discussion of passphrase quality can be found in the Passphrase FAQ.[*]

[*] The Passphrase FAQ is available from http://www.stack.nl/~galactus/remailers/passphrase-faq.html. It was written for PGP, but much of the advice applies to any passphrase-based technology, including WPA-PSK.

WPA's preshared key mode makes sense for smaller networks that are not stuffed with valuable data. Security is essentially risk management, and many networks may not need anything stronger than WPA PSK because they do not have much of value.

Use WPA with preshared keys only for small, low-risk networks, or networks which have guest users that do not need maximum protection. Otherwise, use one of the following authentication protocols.

 

802.1X-based EAP authentication

802.1X is an extensible framework, not a protocol in and of itself. Network administrators can select from a menu of protocols, each with its own strengths and weaknesses. To whittle down the choices to a set of candidates, consider the practical requirements imposed by wireless networks. By transmitting over the air, wireless networks are inherently subject to eavesdropping. Strong encryption to protect credentials is a must. Beyond simply transmitting encrypted user credentials, it is desirable to provide mutual authentication. Obviously, users must be authenticated. In the absence of a physical connection, however, some cryptographic operation is necessary so that users can be sure they are connecting to the legitimate, sanctioned wireless LAN deployment. Finally, automatic WEP key distribution is a no-brainer. Randomly generated keys are more secure than static keys, especially if the random key can be refreshed at regular intervals. Three protocols meet these practical requirements, although a fourth is often considered as well.

Cisco's Lightweight LEAP (LEAP) is an older, prestandard protocol that Cisco designed to address some of the initial security flaws discovered in wireless LANs. It is notable for being the first protocol to dynamically derive keys for each user, but its design fails the other practical requirements. LEAP transmits scrambled credentials using MS-CHAP version 1. Although MS-CHAP version 1 does not transmit credentials in the clear, it is a fundamentally broken protocol that cannot provide signficant cryptographic protection.[*] (It remains in use on some embedded devices because of the relatively small amount of CPU power reuqired.) Furthermore, LEAP provides mutual authentication only by running two MS-CHAP exchanges (one in each direction). As a final straw, LEAP is proprietary to Cisco. While there are other options for some of the components in the system, it requires either additional client software or Cisco cards on the client end, and may require Cisco access points in the authenticator role. I have worked with more than one organization that is attempting to move away from LEAP because of its proprietary nature. Client systems must have LEAP software, which can be part of the Cisco driver load or a third-party client; it is not uncommon to see organizations that adopted LEAP heavily to purchase Cisco cards for the LEAP client and put them in portable devices that have built-in wireless cards. LEAP's weaknesses have led to an effort to standardize a replacement protocol, EAP-FAST. At the time this book was written, EAP-FAST was not widely implemented.

[*] See http://asleap.sourceforge.net/, a tool used to recover LEAP passwords. It works by forcing users to authenticate, and then brute-forcing their password hash.

The three widely considered standards-based protocols are EAP-Transport Layer Security (EAP-TLS), Protected EAP (PEAP), and Tunneled Transport Layer Security (TTLS). All three use TLS to provide strong cryptographic protection of user credentials, and use the TLS key exchange to provide the seed for link-layer keys. Furthermore, all can provide mutual authentication. Each of them establishes a TLS tunnel with the authentication server, and uses the certificate supplied by the authentication server as the basis for the network-to-user half of mutual authentication.

EAP-TLS uses certificates in both directions for authentication. As part of the TLS tunnel establishment, the network supplies a certificate to the user, which the user will check for validity. Provided the user can validate the server certificate, the client system will transmit the user's certificate for similar validation by the authentication server. EAP-TLS is strong, secure, and easy to understand, but it does have an Achilles heel. The client authentication is provided by a client certificate, which requires the existence of a PKI to generate, sign, and distribute certificates. If you do not already have a certificate system in place, EAP-TLS is probably not for you.

The two remaining protocols, PEAP and TTLS, are quite similar. Both use the server certificate in the TLS tunnel to provide the first-stage network-to-user authentication, and use the TLS tunnel to encrypt the user credentials used for the user-to-network authentication in the second stage. PEAP and TTLS do not depend on extensive use of certificates, but they do require a certificate for each authenticator on the wireless network. Choosing between PEAP and TTLS is more a matter of fitting a protocol to your requirements. TTLS is more flexible in the way it passes data for the user-to-network authentication in the tunnel, and it can be used with nearly any form of second-stage authentication. PEAP is more limited because it requires that the second stage be performed using an EAP method. In practice, the most commonly used PEAP supplicant is the built-in supplicant in Windows XP/2000, and it only supports one second stage protocol that does not require certificates: MS-CHAP, version 2. For networks that have a large number of Windows clients, PEAP is a good choice because it obviates the need to license and load additional software.

Avoid LEAP because it is proprietary and relatively weak. Instead, use an authentication protocol based on TLS because it can provide mutual authentication and key distribution.

Three candidates are based on TLS: EAP-TLS, PEAP, and TTLS. EAP-TLS requires client certificates for authentication, and is not likely to be an option unless a PKI already exists. PEAP and TTLS are quite similar, and either makes a fine choice. The former is more useful in monolithic Windows environments, while the latter is more useful with older authentication systems.

 

Network Layer Authentication

Many early wireless networks were built as separate networks from the existing wired infrastructure, and recycled existing authentication and access control mechanisms. For example, in the single subnet topology in Figure 20-1 in the previous chapter, there is a natural choke point. Firewalls are often deployed at choke points, and may provide some access control functionality. If the choke point device is also capable of terminating VPNs, the VPN software will certainly provide user authentication in addition to traffic encryption.

Firewalls are well-known for providing a number of strong authentication mechanisms, and they have a proven ability to integrate with one-time password systems such as RSA's SecurID tokens. Many IPsec VPN devices also have this capability, although it requires the use of protocol extensions such as eXtended Authentication (XAUTH), Hybrid Mode IKE, or Challenge/Reponse for Authenticated Control Keys (CRACK). XAUTH is quite popular, but it suffers from the compound binding problems discussed in this chapter. High-security networks may wish to avoid some of the problems with protocol extensions by deploying IPsec with user certificates for authentication. Instead of IPsec termination, the VPN device may be an SSL VPN device. Rather than using client software, SSL-based VPN devices may be substantially easier to use because they require only a web browser.

Instead of using a full-blown (and expensive) firewall, many organizations started using web-based authentication systems. The wireless network itself is run with minimal authentication and encryption to enable unrestricted access from potential users. Many networks are run using open 802.11 authentication and no encryption. (Some security-conscious networks are beginning to use WPA-PSK for web-authenticated networks, but it is a relatively new practice.) The first request to a web site is trapped by a proxy and redirected to a secure login page. Before authentication completes, the web system drops any packets from the client. Once authentication succeeds, the client systems packets are allowed through. It is important to note that many web authentication systems do encrypt the login, but have no way of providing strong link-layer encryption.

When wireless LAN security first became a burning issue, several vendors began selling "wireless access controller" devices, which typically combine packet filtering, authentication, authorization, and accounting services (AAA), and a DHCP server; many devices also include a DNS server, VPN termination, and packet shaping or rate limiting. AAA features are typically provided by an interface to an existing corporate infrastructure such as RADIUS, which has already often been configured for remote access purposes. Some products may also include dynamic DNS so that a domain name is assigned to a user, but the IP number can be assigned with DHCP.

Integrating User Authentication Through RADIUS

RADIUS is often used as the authentication back end, no matter where authentication is performed in the protocol stack. Both wireless devices and VPNs can reference external RADIUS servers. Most organizations have a centralized user account system somewhere, and placing a RADIUS server in front of it is a common way to provide access to many network devices. RADIUS servers can also be used to tie together multiple user account systems to present a single integrated view of user accounts in an organization.

Although RADIUS servers have the ability to define local users, the user management tools are not particularly powerful or sophisticated. Most RADIUS servers are deployed in such a way that they refer to other sources of data for user accounts, leaving the RADIUS server to act as protocol translators. Some of the most common forms of external user databases are:

Windows domains

Most organizations have at least some users in a Windows domain or Active Directory. Integrating a RADIUS server with Windows passwords is easy for users because the Windows password is often the main user credential. End users hate remembering passwords. Referring to a Windows domain allows users to keep using the same credential for a variety of purposes. Windows prevalence varies from the odd departmental network at major universities all the way to huge multinational corporate networks, many of which are built around Windows network technology.

Token cards (such as RSA SecurID, Secure Computing SafeWord)

Token cards often have RADIUS frontends; many RADIUS servers can also pass credentials directly to a token card server for approval. Integration with token card servers enables administrators to require strong token authentication with wireless networks.

LDAP directories

Directories are highly extensible, and valued by organizations that desire a single user data store for everything. Passwords, access privileges, policies, and contact information can all be stored in a directory. When used to access LDAP directories, RADIUS servers can perform authorization based on information learned from LDAP. For example, universities may identify users as either faculty or students, with students having restricted network privileges.

Kerberos realms

Many universities also have a large investment in Kerberos authentication. RADIUS servers accept credentials from the end user and use them to obtain a Kerberos ticket. If the authentication is succesful, access is granted. Kerberos integration is relatively loose right now. The tickets granted to users are dummy tickets that are not used in authorization, but many universities would like to extend existing Kerberos infrastructure to new wireless networks. I expect to see additional protocol development that uses Kerberos ticket data for authentication in the future.

Unix password systems

Unix password systems include Pluggable Authentication Modules (PAM) and Network Information System (NIS). Organizations with a significant investment in Unix may be able to create single-sign-on by recycling their existing authentication system. RADIUS servers that use these authentication schemes are installed on Unix systems, and attempt to validate user credentials with a system call.

RADIUS proxy

RADIUS servers may pass authentication requests to other RADIUS servers. In environments with distributed user enrollment and account creation, such as most large research universities, it is hopeless to try to create a centralized database. The best solution is to accept the distributed nature of user accounts, and ensure that RADIUS servers can refer authentication requests to other RADIUS servers for processing.

TACACS

TACACS is an alternative access control service. It is used widely by network devices, but is not often used to store accounts for anybody other than network administration staff.

RADIUS authentication and Microsoft Windows databases

There are two ways of looking up Windows user accounts. Operating system API calls can look up user accounts on domain controllers. Network protocols between servers can also be used to look up user accounts. In older Windows NT4-based networks, the domain controllers used an inter-server protocol that has been reverse engineered by the open source community. External RADIUS servers can run software that pretends to be a domain controller, and can therefore look up Windows accounts across the network. In fact, most RADIUS servers developed on Unix systems can use the reverse engineering to perform authentication against NT Domain user accounts. Windows-based RADIUS servers must be installed on a domain controller to look up user accounts.

Networks built around Windows 2000 are largely built with Active Directory. In addition to its many features, Active Directory introduced newer inter-server protocols that have remained proprietary to Microsoft. Internet Authentication Server (IAS), Microsoft's RADIUS server, can use Active Directory communications to look up user accounts stored on any other member server in Active Directory. These protocols have not yet been reverse engineered, and are not available to third-party RADIUS servers. They must instead rely on the system call API on a domain controller. Once an request for user credentials is dispatched to the domain controller via its API, the domain controller may proceed to use Active Directory protocols to look up the user account remotely.[*]

[*] The indirect nature of the credential lookup and the domain controller requirement is a subtle advantage for Microsoft's RADIUS server, which is bundled with Windows server operating systems. Third-party RADIUS servers must be installed on a domain controller, and hence, a server installation. Network administrators must therefore justify the additional cost of the third-party RADIUS server over the inexpensive Microsoft RADIUS server.

Active Directory can be installed in a native mode, in which the member servers use only the newer Active Directory protocols, or a compatibility mode in which the older, less-secure NT Domain protocols are used as well. Most current installations of Active Directory are now based on the native mode without compatibility options.

The bottom line presents network administrators with a choice: run Microsoft's RADIUS server, run a third-party RADIUS server on a domain controller, or run Active Directory in compatibility mode. The last option is fraught with security problems, and is generally not workable because it also limits the functionality of Active Directory. If you need to authenticate against Active Directory user accounts, the choice is either to use Microsoft's IAS or find a domain controller for a third-party RADIUS server. (Note that not all third-party RADIUS servers can be installed on Windows; most third-party RADIUS applicances, for example, do not run Windows.) In many organizations, both tasks can be quite challenging simply because a large network of domain controllers generally cannot be disturbed without extensive change control procedures.

Most RADIUS server software cannot access Windows user credentials unless installed on a domain controller. If you need to authenticate Windows user accounts, be prepared to set aside a domain controller for that purpose.