Wireless Deployment Technology and Component Overview

On This Page

Abstract
Wireless LAN Technology Overview
Wireless Support in Windows
RADIUS
EAP
IAS and Remote Access Policies
Certificates
Summary
Related Links

Abstract

Before deploying IEEE 802.11 wireless LAN connectivity in your organization, it is helpful to understand the components of a protected wireless LAN and its authentication infrastructure. This article explains the elements of wireless LANs, the processes of connection and authentication, wireless security technologies, and the components of a wireless LAN authentication infrastructure that are provided with Microsoft® Windows Server® 2003 and Windows® 2000 Server.

Wireless LAN Technology Overview

This section describes the following topics:

• Wireless LAN networking components

• IEEE 802.11

• IEEE 802.11 operating modes

• IEEE 802.11 wireless security

• IEEE 802.1X

• Wi-Fi Protected Access

• Wi-Fi Protected Access 2

Wireless LAN Networking Components

Wireless LAN networking consists of the following components:

• Stations

• Wireless access points

These components are shown in Figure 1.

Figure 1: The components of wireless LAN networking

Stations

A station (STA) is a computing device that is equipped with a wireless LAN network adapter. A personal computer equipped with a wireless LAN network adapter is known as a wireless client. Wireless clients can communicate directly with each other or through a wireless access point.

Wireless clients can be mobile.

A Windows wireless client is a wireless client that has a wireless network adapter and driver installed and is running Windows Vista™, Windows XP, Windows Server Code Name “Longhorn,” or Windows Server 2003.

Wireless access points

A wireless access point (AP) is a networking device equipped with a wireless LAN network adapter that acts as a bridge between STAs and a traditional wired network. An access point contains:

• At least one interface that connects the wireless AP to an existing wired network (such as an Ethernet backbone).

• Radio equipment with which it creates wireless connections with wireless clients.

• IEEE 802.1D bridging software, so that it can act as a transparent bridge between wireless and wired LAN segments.

The wireless AP is similar to a cellular phone network's base station; wireless clients communicate with the wired network and other wireless clients through the wireless AP.

Wireless APs are not mobile and act as peripheral bridge devices to extend a wired network.

The logical connection between a wireless client and a wireless AP is a point-to-point bridged LAN segment, similar to an Ethernet-based network client connected to an Ethernet switch. All frames sent from a wireless client, whether unicast, multicast, or broadcast, are sent on the point-to-point LAN segment between the wireless client and the wireless AP. For frames sent by the wireless AP to wireless clients, unicast frames are sent on the point-to-point LAN segment and multicast and broadcast frames are sent to all connected wireless clients at the same time.

IEEE 802.11

IEEE 802.11 is an industry standard for a shared access, wireless local area network (WLAN) that defines the Physical layer and media access control (MAC) sublayer for wireless communications.

802.11 Physical Layer

At the Physical layer, IEEE 802.11 defines both direct sequence spread spectrum (DSSS) and frequency hopping spread spectrum (FHSS) transmission schemes. The original bit rates for IEEE 802.11 were 2 and 1 megabits per second (Mbps) using the S-Band 2.4-2.5 gigahertz (GHz) Industrial, Scientific, and Medical (ISM) frequency band. The maximum bit rate for IEEE 802.11b is 11 Mbps (using DSSS). The maximum bit rate for IEEE 802.11a is 54 Mbps using the orthogonal frequency-division multiplexing (OFDM) transmission scheme and frequencies in the 5 GHz range, including the 5.725-5.875 gigahertz (GHz) C-Band ISM frequency band. The IEEE 802.11g standard uses OFDM, has a maximum bit rate of 54 Mbps, and uses the S-Band ISM.

802.11 MAC Sublayer

At the MAC sublayer, IEEE 802.11 uses the carrier sense multiple access with collision avoidance (CSMA/CA) media access control (MAC) protocol, which works in the following way:

• A wireless station with a frame to transmit first listens on the wireless channel to determine if another station is currently transmitting (carrier sense). If the medium is being used, the wireless station calculates a random backoff delay. Only after the random backoff delay can the wireless station again listen for a transmitting station. By instituting a random backoff delay, multiple stations that are waiting to transmit do not end up trying to transmit at the same time (collision avoidance).

The CSMA/CA scheme does not ensure that a collision never takes place and it is difficult for a transmitting node to detect that a collision is occurring. Additionally, depending on the placement of the wireless AP and the wireless clients, a radio frequency (RF) barrier can prevent a wireless client from sensing that another wireless node is transmitting. This is known as the hidden station problem.

To provide better detection of collisions and a solution to the hidden station problem, IEEE 802.11 also defines the use of an acknowledgment (ACK) frame to indicate that a wireless frame was successfully received and the use of Request to Send (RTS) and Clear to Send (CTS) messages. When a station wants to transmit a frame, it sends an RTS message indicating the amount of time it needs to send the frame. The wireless AP sends a CTS message to all stations, granting permission to the requesting station and informing all other stations that they are not allowed to transmit for the time reserved by the RTS message. The exchange of RTS and CTS messages eliminates collisions due to hidden stations.

802.11b

The major enhancement to IEEE 802.11 by IEEE 802.11b is the standardization of the Physical layer to support higher bit rates. IEEE 802.11b supports two additional speeds, 5.5 Mbps and 11 Mbps, using the S-Band ISM. IEEE 802.11b uses the DSSS transmission scheme to provide the higher data rates. The bit rate of 11 Mbps is achievable in ideal conditions. In less-than-ideal conditions, 802.11b uses the slower speeds of 5.5 Mbps, 2 Mbps, and 1 Mbps.

802.11a

IEEE 802.11a operates at a data transmission rate as high as 54 Mbps and uses the C-Band ISM. Instead of DSSS, 802.11a uses OFDM. OFDM allows data to be transmitted by subfrequencies in parallel. This provides greater resistance to interference and greater throughput. This higher speed technology allows wireless LAN networking to perform better for video and conferencing applications. Because they are not on the same frequencies as Bluetooth or microwave ovens, OFDM and IEEE 802.11a provides both a higher data rate and a cleaner signal. The bit rate of 54 Mbps is achievable in ideal conditions. In less-than-ideal conditions, 802.11a uses the slower speeds of 48 Mbps, 36 Mbps, 24 Mbps, 18 Mbps, 12 Mbps, and 6 Mbps.

802.11g

IEEE 802.11g, a relatively new standard, operates at a bit rate up to 54 Mbps, but uses the S-Band ISM and OFDM. 802.11g is also backward compatible with 802.11b and can operate at the 802.11b bit rates and use the DSSS transmission scheme. 802.11g wireless network adapters can connect to an 802.11b wireless AP, and 802.11b wireless network adapters can connect to an 802.11g wireless AP. Thus, 802.11g provides a migration path for 802.11b networks to a frequency-compatible standard technology with a higher bit rate. Existing 802.11b wireless network adapters cannot be upgraded to 802.11g by updating the firmware of the adapter and must be replaced. Unlike migrating from 802.11b to 802.11a (in which all the network adapters in both the wireless clients and the wireless APs must be replaced at the same time), migrating from 802.11b to 802.11g can be done incrementally.

Like 802.11a, 802.11g uses 54 Mbps in ideal conditions and the slower speeds of 48 Mbps, 36 Mbps, 24 Mbps, 18 Mbps, 12 Mbps, and 6 Mbps in less-than-ideal conditions.

IEEE 802.11 Operating Modes

IEEE 802.11 defines the following operating modes:

• Ad hoc mode

• Infrastructure mode

Ad Hoc Mode

In ad hoc mode, wireless clients communicate directly with each other without the use of a wireless AP or a wired network, as shown in Figure 2.

Figure 2: Ad hoc mode

Ad hoc mode is also called peer-to-peer mode. Wireless clients in ad hoc mode form an Independent Basic Service Set (IBSS), which is two or more wireless clients who communicate directly without the use of a wireless AP.

Ad hoc mode is used to connect wireless clients together when there is no wireless AP present, when the wireless AP rejects an association due to failed authentication, or when the wireless client is explicitly configured to use ad hoc mode.

Infrastructure Mode

In infrastructure mode, there is at least one wireless AP and one wireless client. The wireless client uses the wireless AP to access the resources of a traditional wired network. The wired network can be an organization intranet or the Internet, depending on the placement of the wireless AP.

A single wireless AP supporting one or multiple wireless clients is known as a Basic Service Set (BSS). A set of two or more wireless APs connected to the same wired network is known as an Extended Service Set (ESS). An ESS is a single logical network segment (also known as a subnet), and is identified by its SSID. An ESS is shown in Figure 3.

Figure 3: Infrastructure mode and an ESS

When a wireless adapter is turned on, it begins to scan across the wireless frequencies for wireless APs and other wireless clients. Scanning is a listening process in which the wireless adapter listens on all the channels for beacon frames sent by wireless APs and other wireless clients. After scanning, a wireless adapter chooses a wireless AP with which to associate. This selection is made automatically by using the Service Set Identifier (SSID) of the wireless network and the wireless AP with the best signal strength (the highest signal-to-noise ratio). Next, the wireless client switches to the assigned channel of the chosen wireless AP and negotiates the use of a logical wireless point-to-point connection. This is known as an association.

Whether the wireless client prefers to associate with wireless APs or individual wireless clients is determined by configuration settings of the wireless client. By default, a Windows wireless client prefers to associate with a wireless AP rather than another wireless client.

If the signal strength of the wireless AP is too low, the error rate too high, or if instructed by the operating system (in the case of Windows, every 60 seconds), the wireless client scans for other wireless APs to determine whether a different wireless AP can provide a stronger signal to the same wireless network. If so, the wireless client switches to the channel of that wireless AP. This is known as reassociation.

Reassociation with a different wireless AP can occur for many different reasons. The signal can weaken because the wireless client moves away from the wireless AP or the wireless AP becomes congested with too much other traffic or interference. The wireless client, by switching to another wireless AP, can distribute the load over other wireless APs, increasing the performance for other wireless clients. By placing wireless APs so that their coverage areas overlap slightly but their channels do not, wireless connectivity for large areas can be achieved. As a wireless client moves its physical location, it can associate and reassociate from one wireless AP to another, maintaining a continuous connection during physical relocation.

If the coverage areas of the wireless APs within an ESS overlap, then a wireless client can roam, or move from one location (with a wireless AP) to another (with a different wireless AP), while maintaining Network layer connectivity.

For example, for TCP/IP, a wireless client is assigned an IP address when it connects to the first wireless AP. When the wireless client roams within the ESS, it creates wireless connections with other wireless APs but keeps the same IP address because all the wireless APs are on the same logical subnet.

When the wireless client roams to a different ESS, the IP address configuration is no longer valid. For a Windows XP and Windows Server 2003 wireless client, a reassociation is interpreted as a media disconnect/connect event. This event causes Windows to perform a DHCP renewal for the TCP/IP protocol. Therefore, for reassociations within the ESS, the DHCP renewal refreshes the current IP address configuration. When the Windows wireless client reassociates with a wireless AP across an ESS boundary, the DHCP renewal process obtains a new IP address configuration that is relevant for the logical IP subnet of the new ESS.

IEEE 802.11 Wireless Security

For authentication, the original 802.11 standard defined open system and shared key authentication types. For data confidentiality (encryption), the original 802.11 standard defined Wired Equivalent Privacy (WEP).

The original 802.11 standard did not define or provide a WEP key management protocol that provides automatic WEP encryption key determination and renewal. This is a limitation to IEEE 802.11 security services; especially for infrastructure mode networks with a large number of wireless clients. The authentication and key management issues of the original 802.11 standard are solved by using the combination of IEEE 802.1X port-based network access control and either Wi-Fi Protected Access™ (WPA™) or Wi-Fi Protected Access 2™ (WPA2™).

802.11 Authentication

The original IEEE 802.11 standard defined the following types of authentication:

• Open System Authentication

• Shared Key Authentication

Open System Authentication

Open system authentication does not provide authentication, only identification using the wireless adapter's MAC address. Open system authentication is used when no authentication is required. Open system authentication is the default authentication algorithm that uses the following process:

1. The authentication-initiating wireless client sends an IEEE 802.11 authentication management frame that contains its identity.

2. The receiving wireless node checks the initiating station's identity and sends back an authentication verification frame.

With some wireless APs, you can configure the MAC addresses of allowed wireless clients using a feature known as MAC filtering. However, MAC filtering does not provide any security because the MAC address of a wireless client can be easily determined and spoofed.

By default, a Windows wireless client that is configured to perform open system authentication sends its MAC address as the identity.

Shared Key Authentication

Shared key authentication verifies that an authentication-initiating station has knowledge of a shared secret. According to the original 802.11 standard, the shared secret is delivered to the participating wireless clients by means of a secure channel that is independent of IEEE 802.11. In practice, the shared secret is manually configured on the wireless AP and the wireless client.

Shared key authentication uses the following process:

1. The authentication-initiating wireless client sends a frame consisting of an identity assertion and a request for authentication.

2. The authenticating wireless node responds to the authentication-initiating wireless node with challenge text.

3. The authentication-initiating wireless node replies to the authenticating wireless node with the challenge text that is encrypted using WEP and an encryption key that is derived from the shared key authentication secret.

4. The authentication result is positive if the authenticating wireless node determines that the decrypted challenge text matches the challenge text originally sent in the second frame. The authenticating wireless node sends the authentication result.

Because the shared key authentication secret must be manually distributed and typed, this method of authentication does not scale appropriately in large infrastructure network mode (for example, corporate campuses and public places). Additionally, shared key authentication is not secure and its use is strongly discouraged.

802.11 Encryption with Wired Equivalent Privacy (WEP)

Due to the nature of wireless LAN networks, securing physical access to the network is difficult. Unlike a wired network where a physical connection is required, anyone within range of a wireless AP can conceivably send and receive frames and listen for other frames being sent, making eavesdropping and remote sniffing of wireless LAN frames very easy. WEP as defined by the original IEEE 802.11 standard was intended to provide a level of data confidentiality equivalent to a wired network.

WEP provides data confidentiality services by encrypting the data sent between wireless nodes. Setting a WEP flag in the MAC header of the 802.11 frame indicates WEP encryption for an 802.11 frame. WEP provides data integrity by including an integrity check value (ICV) in the encrypted portion of the wireless frame.

WEP defines two shared keys:

• A multicast/global key The multicast/global key is an encryption key that protects multicast and broadcast traffic from a wireless AP to all of its connected wireless clients.

• A unicast session key The unicast session key is an encryption key that protects unicast traffic between a wireless client and a wireless AP and multicast and broadcast traffic sent by the wireless client to the wireless AP.

WEP encryption uses the RC4 symmetric stream cipher with 40-bit and 104-bit encryption keys; 104-bit encryption keys are not standard, however, many wireless AP vendors support them.

Note

Some implementations advertising the use of 128-bit keys are just adding a 104-bit encryption key to a 24-bit initialization vector that is used during the encryption process.

WEP Concerns

A big problem with WEP is that the 802.11 standard does not define the determination and distribution of WEP keys. WEP keys must be distributed using a secure channel outside of the 802.11 protocol. For a static WEP key, this is a text string that must be manually configured using a keyboard for both the wireless AP and wireless clients. Obviously, this key distribution system does not scale well to an enterprise organization and is not secure.

Additionally, there is no defined mechanism to change the WEP key either per authentication or periodically for an authenticated connection. All wireless APs and clients use the same manually configured WEP key for multiple sessions. With multiple wireless clients sending a large amount of data, an attacker can remotely capture large amounts of WEP cipher text and use cryptanalysis methods to determine the WEP key.

The lack of a WEP key management protocol is a principal limitation to providing 802.11 security, especially for infrastructure mode networks with a large number of stations. Some examples of this type of network include corporate campuses, and public places such as airports and malls. The lack of automated authentication and key determination services also effects operation in ad hoc mode where users may wish to engage in peer-to-peer collaborative communication; for example, in areas such as conference rooms.

The use of a static WEP key is strongly discouraged because of security weaknesses in the WEP encryption algorithm that allow malicious users to determine the WEP key by analyzing WEP-encrypted frames. With IEEE 802.1X and an authentication type that automatically derives encryption key material from the authentication process, WEP keys can be determined dynamically on a per-wireless client and per-authentication basis. This combination of technologies is known as dynamic WEP.

IEEE 802.1X

The IEEE 802.1X standard defines port-based, network access control used to provide authenticated network access for Ethernet networks. This port-based network access control uses the physical characteristics of the switched LAN infrastructure to authenticate devices attached to a LAN port. Access to the port can be denied if the authentication process fails. Although this standard was designed for wired Ethernet networks, it has been adapted for use on 802.11 wireless LANs.

IEEE 802.1X defines the following terms:

• Port access entity

• Authenticator

• Supplicant

• Authentication server

Figure 4 shows these components for a wireless LAN network.

Figure 4: The components of IEEE 802.1X authentication

Port Access Entity

A LAN port, also known as port access entity (PAE), is the logical entity that supports the IEEE 802.1X protocol that associated with a port. A PAE can adopt the role of the authenticator, the supplicant, or both.

Authenticator

An authenticator is a LAN port that enforces authentication before allowing access to services accessible using that port. For wireless connections, the authenticator is the logical LAN port on a wireless AP through which wireless clients in infrastructure mode gain access to other wireless clients and the wired network.

Supplicant

The supplicant is a LAN port that requests access to services accessible using the authenticator. For wireless connections, the supplicant is the logical LAN port on a wireless LAN network adapter that requests access to the other wireless clients and the wired network by associating with and then authenticating itself to an authenticator.

Whether for wireless connections or wired Ethernet connections, the supplicant and authenticator are connected by a logical or physical point-to-point LAN segment.

Authentication server

To verify the credentials of the supplicant, the authenticator uses an authentication server. The authentication server checks the credentials of the supplicant on behalf of the authenticator, and then responds to the authenticator indicating whether or not the supplicant is authorized to access the authenticator's services. The authentication server may be:

• A component of the access point In this case, the access point must be configured with the sets of user credentials corresponding to the wireless clients that will be attempting to connect. This is typically not implemented for wireless APs.

• A separate entity In this case, the access point forwards the credentials of the wireless connection attempt to a separate authentication server. Typically, the wireless AP uses the Remote Authentication Dial-In User Service (RADIUS) protocol to send the connection attempt parameters to a RADIUS server.

Controlled and Uncontrolled Ports

The authenticator's port-based, access control defines the following different types of logical ports that access the wired LAN via a single, physical LAN port:

• Uncontrolled port The uncontrolled port allows an uncontrolled exchange between the authenticator (the wireless AP) and other networking devices on the wired network-regardless of any wireless client's authorization state. Frames sent by the wireless client are never sent using the uncontrolled port.

• Controlled port The controlled port allows data to be sent between a wireless client and the wired network only if the wireless client is authorized by 802.1X. Before authentication, the switch is open and no frames are forwarded between the wireless client and the wired network. When the wireless client is successfully authenticated using IEEE 802.1X, the switch is closed and frames can be sent between the wireless client and nodes on the wired network.

The different types of ports are shown in Figure 5.

Figure 5: Controlled and uncontrolled ports for IEEE 802.1X

On an authenticating Ethernet switch, the wired Ethernet client can send Ethernet frames to the wired network as soon as authentication is complete. The switch identifies the traffic of a specific wired Ethernet client using the physical port to which the Ethernet client is connected. Typically, only a single Ethernet client is connected to a physical port on the Ethernet switch.

Because multiple wireless clients contend for access to the same channel and send data using the same channel, an extension to the basic IEEE 802.1X protocol is required to allow a wireless AP to identify the secured traffic of a particular wireless client. This is done through the mutual determination of a per-client unicast session key by the wireless client and wireless AP. Only authenticated wireless clients have knowledge of their per-client unicast session key. Without a valid unicast session key tied to a successful authentication, a wireless AP discards the traffic sent from the wireless client.

To provide a standard authentication mechanism for IEEE 802.1X, the Extensible Authentication Protocol (EAP) was chosen. EAP is a Point-to-Point Protocol (PPP)-based authentication mechanism that was adapted for use on point-to-point LAN segments. EAP messages are normally sent as the payload of PPP frames. To adapt EAP messages to be sent over Ethernet or wireless LAN segments, the IEEE 802.1X standard defines EAP over LAN (EAPOL), a standard way to encapsulate EAP messages.

Although dynamic WEP—the combination of WEP, 802.1X, and an EAP type that automatically derives WEP encryption keys—provides additional security for WEP-based networks, its use is discouraged except as a transition security technology to WPA or WPA2.

Wi-Fi Protected Access

Although 802.1X addresses many of the security issues of the original 802.11 standard, issues still exist with regard to weaknesses in the WEP encryption and data integrity methods. The solution to these problems is the IEEE 802.11i standard, which is the standard that specifies improvements to wireless LAN networking security.

While the IEEE 802.11i standard was being ratified, wireless vendors agreed on an interoperable interim standard known as Wi-Fi Protected Access (WPA). The WPA standard defines Enterprise (using IEEE 802.1X authentication) and Personal (using a preshared key) modes of operation.

For more information about WPA security features and hardware and software requirements for WPA-based wireless connectivity, see Wi-Fi Protected Access (WPA) Overview.

For information about WPA support for Windows wireless clients, see "Windows Support for WPA" in this article.

Wi-Fi Protected Access 2

The IEEE 802.11i standard formally replaces Wired Equivalent Privacy (WEP) and the other security features of the original IEEE 802.11 standard. WPA2 is a product certification available through the Wi-Fi Alliance that certifies wireless equipment as being compatible with the 802.11i standard. The goal of WPA2 certification is to support the additional mandatory security features of the 802.11i standard that are not already included for products that support WPA. Like WPA, WPA2 offers both Enterprise and Personal modes of operation.

Microsoft has released Wireless Client Update for Windows XP with Service Pack 2, a free download that updates the wireless client components in Windows XP with Service Pack 2 to support WPA2. Windows Vista and Windows Server “Longhorn” also support WPA2.

For more information about WPA2 security features, fast roaming, and hardware and software requirements for WPA2-based wireless connectivity, see Wi-Fi Protected Access 2 (WPA2) Overview.

For information about WPA2 support for Windows wireless clients, see "Windows Support for WPA2" in this article.

Wireless Support in Windows

Windows Vista, Windows XP, Windows Server “Longhorn,” and Windows Server 2003 include support for the following:

• Wireless network adapters

  Microsoft partnered with 802.11 network adapter vendors to improve the roaming experience by automating the process of configuring the network adapter to associate with an available network.

  The wireless network adapter and its Network Driver Interface Specification (NDIS) driver need to do very little beyond supporting some new NDIS Object Identifiers (OIDs) used for the querying and setting of device and driver behavior. The wireless network adapter scans for available wireless networks and passes the SSID information to Windows.

• Wireless Auto Configuration

  Wireless Auto Configuration in Windows Vista, Windows XP, Windows Server 2003, and Windows Server “Longhorn” dynamically selects the wireless network to which to attempt connection, based either on your preferences or on default settings. This includes automatically selecting and connecting to a more preferred wireless network when it becomes available. If none of the preferred wireless networks are found nearby, Wireless Auto Configuration configures the wireless adapter so that there is no accidental connection until the wireless client roams within the range of a preferred network.

  Wireless Auto Configuration is enabled through the Wireless AutoConfig service in Windows Vista and Windows Server “Longhorn,” the Wireless Zero Configuration service in Windows XP, and the Wireless Configuration service in Windows Server 2003.

  For more information about how Wireless Auto Configuration works, see Wireless Auto Configuration.

• Roaming

  When a Windows wireless client associates with a new wireless AP, it performs a DHCP renewal of the IP address configuration for the wireless network adapter. Within the same ESS, the IP address configuration does not change. When a Windows wireless client crosses an ESS boundary (a new subnet), the DHCP renewal obtains a new IP address configuration relevant for that subnet.

  Through Windows Sockets extensions, network-aware applications can be notified of changes in network connectivity and update their behavior based on these changes.

• IEEE 802.1X authentication

  Windows Vista, Windows XP, Windows Server “Longhorn,” and Windows Server 2003 supports IEEE 802.1X authentication for all LAN-based network adapters, including Ethernet and wireless.

Wireless Configuration for Windows XP with SP2

The primary user interface for connecting to wireless networks for Windows XP with SP2 is the Choose a wireless network dialog box, as shown in Figure 6.

Figure 6: The Windows XP with SP2 Choose a wireless network dialog box

You can view the Choose a wireless network dialog box by clicking on the Wireless networks detected message in the Windows XP notification area, or by right-clicking the wireless connection icon in the notification area or in the Network Connections folder, and then clicking View Available Wireless Networks. The Choose a wireless network dialog box in Windows XP with SP2 displays the following for each detected wireless network:

• The type of wireless network

  An antenna icon indicates an infrastructure mode wireless network. The icon with two wireless client computers indicates an ad hoc mode wireless network. An icon for the logo of a wireless Internet service provider indicates that the wireless network uses Wireless Provisioning Services (WPS) to automate and secure registration. For more information about WPS, see Wireless Provisioning Services Overview.

• The wireless network name

• The wireless network signal strength

• Whether the wireless network has security enabled (the lock icon and the "Security-enabled wireless network" label)

• The status of the wireless network to which the wireless client is connected (the "Connected" label)

• Whether the wireless network is a preferred network (the star icon)

From the Choose a wireless network dialog box, you can also do the following:

• Perform another scan of wireless networks within range by clicking the Refresh network list network task

• Start the Wireless Network Setup Wizard by clicking the Set up a wireless network for a home or small office network task

• Display the Wireless Networks tab of the wireless connection to change the order of preferred networks and perform other advanced configuration settings by clicking the Change the order of preferred networks related task

• Display the properties of the wireless connection by clicking the Change advanced settings related task

Windows XP with SP1, Windows Server 2003, and Windows XP with no service packs installed use a similar dialog box to connect to available wireless networks.

The primary user interface for configuring IEEE 802.11 and 801.1X settings on a computer running Windows XP with SP2 consists of the Association and Authentication tabs for the properties of a wireless network, available from the Wireless Networks tab for the properties of a wireless connection in the Network Connections folder.

Wireless Networks Tab

The Wireless Networks tab for the properties of a wireless connection is shown in Figure 7. The Wireless Networks tab only appears for wireless adapters and their drivers that support Wireless Auto Configuration.

Figure 7: The Wireless Networks tab

On the Wireless Networks tab, you can view and configure the following:

• Use Windows to configure my wireless network settings Select this check box when you want Windows to automatically configure your wireless settings (Wireless Auto Configuration). If you have third-party wireless configuration software that you want to use, clear this check box. This option is enabled by default.

• View Wireless Networks Click to display the Choose a wireless network dialog box. In Windows XP with SP1, Windows XP with no service packs installed, and Windows Server 2003, the Available networks section of this tab lists the wireless networks detected in the last scan.

• Preferred networks The list of wireless networks to which the wireless client will attempt to connect and authenticate with, in the order in which they are listed. To add a new wireless LAN network that does not appear in the Available networks list, click Add. To remove a wireless LAN network, click Remove. To configure the settings of a wireless LAN network to which you are connecting, click Properties.

• Advanced To configure advanced wireless settings that are independent of the wireless LAN networks to which you are connecting, click Advanced.

Figure 8 shows the Advanced dialog box.

Figure 8: The Advanced dialog box

In the Advanced dialog box, you can configure the following:

• Networks to access To attempt to connect to wireless LAN networks that are operating in either ad hoc or infrastructure modes while preferring infrastructure mode, select Any available network. To attempt to connect to wireless LAN networks that are only operating in infrastructure mode, select Access point. To attempt to connect to wireless LAN networks that are only operating in ad hoc mode, select Computer-to-computer. By default, Any available network is selected.

• Automatically connect to non-preferred networks This check box specifies whether connection attempts are made to any wireless network within range, regardless of whether they are listed in the Preferred networks list. This option is disabled by default.

When you click Add or Properties for a preferred wireless network, Windows XP with SP2 displays the Wireless network properties dialog box, as shown in Figure 9.

Figure 9: The Association tab on the Wireless network properties dialog box

The properties of a wireless network consist of an Association tab, an Authentication tab, and a Connection tab.

Association Tab

From the Association tab, you can configure the following:

• Network name (SSID) Displays or allows you to type the wireless LAN network name, also known as the Service Set Identifier (SSID). The network name is sent out with beacon frames by wireless APs and is automatically learned by wireless clients during the wireless client scanning process.

• Network Authentication This drop-down box allows you select the following authentication options: Open (for open system authentication), Shared (for shared key authentication), WPA (for WPA authentication), and WPA-PSK (for WPA preshared key authentication). The WPA options are available only if your wireless network adapter and its driver support WPA.

• Data encryption This drop-down box allows you to select the following encryption options: Disabled (no encryption of 802.11 frames), WEP (WEP encryption), TKIP (TKIP encryption), and AES (Advanced Encryption Standard encryption). AES is available only if your wireless network adapter and its driver support the optional AES encryption algorithm.

• Network key and Confirm network key Provides a space to type and confirm either a WEP key or a WPA preshared key.

• Key index (advanced) Allows you to specify the location where the WEP key is stored. Historically, IEEE 802.11 allowed for 4 different keys. The key index is an offset that is used to specify a single key when four keys are used. You can select 1 to 4.

• The key is provided for me automatically This check box specifies whether a WEP or WPA encryption key is provided through some means other than manual configuration, such as through IEEE 802.1X authentication.

• This is a computer-to-computer (ad hoc) network This check box specifies whether this wireless network is operating in ad hoc mode. If disabled, the wireless LAN network is operating in infrastructure mode. This option is disabled by default.

Authentication Tab

The Authentication tab for a wireless network is shown in Figure 10.

Figure 10: The Authentication tab for a wireless network

On the Authentication tab, you can view and configure the following:

• Enable IEEE 802.1x authentication for this network Select this check box when you want to use IEEE 802.1X to perform authentication for this wireless network.

• EAP type Lists the EAP types that correspond to EAP DLLs installed on the computer. The default EAP types are Smart Card or other Certificate and Protected EAP (PEAP). By default the Smart Card or other Certificate EAP type is selected. For more information about EAP types, see "EAP" in this article.

• Properties Click to configure the properties of the selected EAP type.

• Authenticate as computer when computer information is available This check box specifies whether the computer will attempt to authenticate using computer credentials (such as a computer certificate), without the user logging on.

• Authenticate as guest when user or computer information is unavailable This check box specifies whether the computer will attempt to authenticate as a guest when either user or computer credentials are not available.

Figure 11 shows the Smart Card or other Certificate Properties dialog box for Windows XP with SP2, Windows XP with SP1, and Windows Server 2003.

Figure 11: The Smart Card or other Certificate Properties dialog box

For the Smart Card or other Certificate Properties dialog box, you can view and configure the following:

• When connecting To use the certificate on a smart card, click Use my smart card. To use a certificate in the Current User or Local Computer certificate store for authentication, select Use a certificate on this computer. By default, Use a certificate on this computer is selected. When there are multiple user certificates installed, the user is prompted to select a specific user certificate for the first association. The use of that user certificate is cached for reassociations until the Windows user session is ended.

• Use simple certificate selection This check box enables and disables simple certificate selection. When enabled, Windows attempts to simplify the list of certificates with which the user is prompted for selection. The certificates that are usable for EAP-TLS authentication are grouped by the entity that was issued the certificate based on the Subject Alternative Name and Subject fields of the certificates. The most recently issued certificate from each group is used to create the list that is presented to the user. Simple certificate selection is only used when Use a certificate on this computer is selected. When Use a certificate on this computer is selected, simple certificate selection is enabled by default.

• Validate server certificate Select this check box when you want to validate the computer certificate of the authenticating server (typically, a RADIUS server). This option is enabled by default.

• Connect to these servers You can specify by name the RADIUS servers that are providing authentication and authorization for the connection. If you specify server names, they must exactly match the server name in the Subject field of the RADIUS server's certificate. Use semicolons to specify multiple RADIUS server names. By default, there are no server names.

• Trusted Root Certification Authorities This list box allows you to select multiple trusted root CAs from which the wireless client will accept for the RADIUS server certificate. The list is built from the installed trusted root CAs in the computer and user certificate stores. If no trusted root CAs are selected, the wireless client verifies that the RADIUS server certificate was issued by an installed trusted root CA. If one or multiple trusted root CAs are selected, the wireless client verifies that the RADIUS server computer certificate was issued by a selected trusted root CA.

• View Certificate This allows you to view the properties of the root certificate currently selected in the Trusted Root Certification Authorities list.

• Use a different user name for the connection This check box specifies whether you want to use a user name for authentication that is different from the user name in the certificate. This option is disabled by default. If enabled, the user is prompted with a dialog box to select a user certificate, even if only one user certificate is installed. The selected certificate is used until the Windows user session is ended.

Connection Tab

The Connection tab for a wireless network is shown in Figure 12.

Figure 12: The Connection tab for a wireless network

The Connect when this network is within range check box specifies whether you want the wireless client to automatically connect to this network when it is in range (the default setting) or you want to connect to this network on demand, by double-clicking on it from the Choose a wireless network dialog box.

The Connection tab is not present for the properties of a wireless network in Windows XP with SP1 and Windows Server 2003.

Wireless Features in Windows Server 2003

The following are wireless features that are only supported in Windows Server 2003:

• A new Wireless Monitor snap-in, which can be used to view wireless APs and wireless client event information.

• A new Wireless Network (IEEE 802.11) Policies Group Policy extension that allows you to configure wireless network settings that are part of Computer Configuration Group Policy.

  Wireless network settings include the list of preferred networks, authentication and encryption settings, and IEEE 802.1X settings. These settings are downloaded to computers running Windows XP with SP1, Windows XP with SP2, Windows Server 2003 with no service packs installed, and Windows Server 2003 with Service Pack 1 domain members, making it much easier to deploy a specific configuration for secure wireless connections to wireless client computers. You can configure wireless policies from the Computer Configuration/Windows Settings/Security Settings/Wireless Network (IEEE 802.11) Policies node in the Group Policy snap-in.

  These policy settings are not automatically configured for wireless clients running Windows XP with no service packs installed or Windows 2000.

For more information, see Configuring Wireless Settings Using Windows Server 2003 Group Policy.

Microsoft 802.1X Authentication Client in Windows 2000 SP4

Microsoft 802.1X Authentication Client allows computers running Windows 2000 to use IEEE 802.1X to authenticate network connections (including wireless). Windows 2000 SP4 includes Microsoft 802.1X Authentication Client. To obtain the latest Windows 2000 Service Pack, see Windows 2000 Service Packs.

For the Windows 2000 Server family, Windows 2000 SP4 also provides support for PEAP authentication (both PEAP-MS-CHAP v2 [also known as PEAPv0/EAP-MSCHAPv2] and PEAP-TLS) for the Internet Authentication Service (IAS), the Microsoft implementation of a RADIUS server. A computer running Windows 2000 Server family with SP4 and IAS can act as a RADIUS server that performs authentication and authorization for 802.1X-based wireless clients that use EAP-TLS, PEAP-MS-CHAP v2, or PEAP-TLS authentication types.

Windows 2000 SP4 includes support for PEAP and for the Smart Card or other Certificate Properties dialog box as previously described. However, because Windows 2000 SP4 does not include Wireless Auto Configuration, all configuration of wireless networks must be done using configuration tools provided by the wireless network adapter vendor.

Wireless Features in Windows Vista and Windows Server “Longhorn”

The following are wireless features that are only supported in Windows Vista and Windows Server “Longhorn”:

• User interface improvements for wireless connections

• Wireless Group Policy enhancements

• WPA2 support

• 802.11 wireless diagnostics

• Command-line support for configuring wireless settings

• Single Sign On

For more information about these and additional features, see the “Wireless and 802.1X-based Wired Connections” section of New Networking Features in Windows Server "Longhorn" and Windows Vista and Wireless Networking in Windows Vista.

For information about how to configure wireless networks in Windows Vista, see Connecting to Wireless Networks with Windows Vista.

Windows Support for WPA

Windows Vista, Windows XP with SP2, and Windows Server “Longhorn” include support for WPA. For wireless clients running these versions of Windows and using a wireless network adapter and driver that supports WPA and Wireless Auto Configuration, you can configure WPA encryption and authentication options from the properties of a wireless network in the Network Connections folder.

For wireless clients running Windows XP with SP1 or Windows Server 2003, and using a wireless network adapter that supports Wireless Auto Configuration, you must install the Wireless update rollup package for Windows XP-a free download from Microsoft that includes WPA support and other fixes. The Wireless update rollup package for Windows XP updates the wireless network configuration dialog boxes to support new WPA options.

You must obtain and install a new WPA-compliant configuration tool from your wireless network adapter vendor for wireless clients running the following:

• Windows 2000

• Windows XP with SP1, Windows XP with SP2, or Windows Server 2003, and using a wireless network adapter that does not support Wireless Auto Configuration

Windows Support for WPA2

Windows Vista, Windows Server “Longhorn,” and Windows XP SP2 with the Wireless Client Update for Windows XP with Service Pack 2 (a free download from Microsoft) include support for WPA2. For wireless clients running these versions of Windows and using a wireless network adapter and driver that supports WPA2 and Wireless Auto Configuration, you can select WPA2 encryption and authentication options from the properties of a wireless network in the Network Connections folder.

You must obtain and install a new WPA2-compliant configuration tool from your wireless network adapter vendor for wireless clients running the following:

• Windows 2000

• Windows XP with SP1, Windows XP with SP2, or Windows Server 2003, and using a wireless network adapter that does not support Wireless Auto Configuration

RADIUS

This section describes the following topics:

• RADIUS overview

• Components of a RADIUS infrastructure

• RADIUS protocol

RADIUS Overview

Remote Authentication Dial-In User Service (RADIUS) is a widely deployed protocol enabling centralized authentication, authorization, and accounting for network access. RADIUS is described in RFC 2865, "Remote Authentication Dial-in User Service (RADIUS)," and RFC 2866, "RADIUS Accounting."

Originally developed for dial-up remote access, RADIUS is now supported by wireless APs, authenticating Ethernet switches, virtual private network (VPN) servers, Digital Subscriber Line (DSL) access servers and other network access servers.

Components of a RADIUS Infrastructure

A RADIUS authentication, authorization, and accounting (AAA) infrastructure consists of the following components:

• Access clients

• Access servers (RADIUS clients)

• RADIUS servers

• User account databases

• RADIUS proxies

These components are shown in Figure 13.

Figure 13: Components of a RADIUS infrastructure

Access Clients

An access client is a device that requires some level of access to a larger network. Examples of access clients are dial-up or virtual private network (VPN) clients, wireless clients, or LAN clients connected to a switch.

RADIUS Clients (access servers)

An access server is a device that provides some level of access to a larger network. An access server using a RADIUS infrastructure is also a RADIUS client, sending connection requests and accounting messages to a RADIUS server. Examples of access servers are:

• Wireless APs that provide physical layer access to an organization's network, using wireless-based transmission and reception technologies.

• Switches that provide physical layer access to an organization's network, using traditional LAN technologies such as Ethernet.

• Network access servers (NASs) that provide remote access connectivity to an organization network or the Internet. An example is a computer running Windows Server 2003 and Routing and Remote Access and providing dial-up or virtual private network (VPN) remote access services to an organization's intranet.

RADIUS Servers

A RADIUS server is a device that receives and processes connection requests or accounting messages sent by RADIUS clients or RADIUS proxies. In the case of connection requests, the RADIUS server processes the list of RADIUS attributes in the connection request. Based on a set of rules and the information in the user account database, the RADIUS server either authenticates and authorizes the connection and sends back an Access-Accept message or sends back an Access-Reject message. The Access-Accept message can contain connection restrictions that are implemented by the access server for the duration of the connection.

The Internet Authentication Service (IAS) component of Windows Server 2003 and Windows 2000 Server is an industry-standard compliant RADIUS server.

User Account Databases

The user account database is the list of user accounts and their properties that can be checked by a RADIUS server to verify authentication credentials and obtain user account properties containing authorization and connection parameter information.

The user account databases that IAS can use are the local Security Accounts Manager (SAM), a Microsoft Windows NT® 4.0 domain, or the Active Directory® service. For Active Directory, IAS can provide authentication and authorization for user or computer accounts in the domain in which the IAS server is a member, two-way trusted domains, and trusted forests with domain controllers running Windows Server 2003 or Windows 2000 Server.

If the user accounts for authentication reside in a different type of database, you can use a RADIUS proxy to forward the authentication request to a RADIUS server that does have access to the user account database. Different databases for Active Directory include untrusted forests, untrusted domains, or one-way trusted domains.

RADIUS Proxies

A RADIUS proxy is a device that forwards or routes RADIUS connection requests and accounting messages between RADIUS clients (and RADIUS proxies) and RADIUS servers (or RADIUS proxies). The RADIUS proxy uses information within the RADIUS message to route the RADIUS message to the appropriate RADIUS server.

A RADIUS proxy can be used as a forwarding point for RADIUS messages when the authentication, authorization, and accounting must occur at multiple RADIUS servers in different organizations.

The IAS component of Windows Server 2003 is an industry-standard compliant RADIUS proxy.

RADIUS Protocol

RADIUS messages are sent as User Datagram Protocol (UDP) messages. UDP port 1812 is used for RADIUS authentication messages and UDP port 1813 is used for RADIUS accounting messages. Some access servers might use UDP port 1645 for RADIUS authentication messages and UDP port 1646 for RADIUS accounting messages. Only one RADIUS message is included in the UDP payload of a RADIUS packet.

RFCs 2865 and 2866 define the following RADIUS message types:

• Access-Request Sent by a RADIUS client to request authentication and authorization for a network access connection attempt.

• Access-Accept Sent by a RADIUS server in response to an Access-Request message. This message informs the RADIUS client that the connection attempt is authenticated and authorized.

• Access-Reject Sent by a RADIUS server in response to an Access-Request message. This message informs the RADIUS client that the connection attempt is rejected. A RADIUS server sends this message if either the credentials are not authentic or the connection attempt is not authorized.

• Access-Challenge Sent by a RADIUS server in response to an Access-Request message. This message is a challenge to the RADIUS client that requires a response.

• Accounting-Request Sent by a RADIUS client to specify accounting information for a connection that was accepted.

• Accounting-Response Sent by the RADIUS server in response to the Accounting-Request message. This message acknowledges the successful receipt and processing of the Accounting-Request message.

A RADIUS message consists of a RADIUS header and RADIUS attributes. Each RADIUS attribute specifies a piece of information about the connection attempt. For example, there are RADIUS attributes for the user name, the user password, the type of service requested by the user, and the IP address of the access server. RADIUS attributes are used to convey information between RADIUS clients, RADIUS proxies, and RADIUS servers. For example, the list of attributes in the Access-Request message includes information about the user credentials and the parameters of the connection attempt. In contrast, the list of attributes in the Access-Accept message includes information about the type of connection that can be made, connection constraints, and any vendor-specific attributes (VSAs).

RADIUS attributes are described in RFCs 2865, 2866, 2867, 2868, 2869, and 3162. RFCs and Internet drafts for VSAs define additional RADIUS attributes.

For Point-to-Point Protocol (PPP) authentication protocols such as Password Authentication Protocol (PAP), Challenge-Handshake Authentication Protocol (CHAP), Microsoft Challenge Handshake Authentication Protocol (MS-CHAP), and MS-CHAP version 2 (MS-CHAP v2), the results of the authentication negotiation between the access server and the access client are forwarded to the RADIUS server for verification.

For EAP authentication, the negotiation occurs between the RADIUS server and the access client. The RADIUS server uses Access-Challenge messages to send EAP messages to the access client. The access server forwards EAP messages sent by the access client to the RADIUS server as Access-Request messages. For more information, see "EAP over RADIUS" later in this article.

To provide security for RADIUS messages, the RADIUS client and the RADIUS server are configured with a common shared secret. The shared secret is used to authenticate RADIUS messages and to encrypt sensitive RADIUS attributes. The shared secret is commonly configured as a text string on both the RADIUS client and server.

RADIUS Authentication and Accounting

RADIUS messages are used for authentication, authorization, and accounting of network access connections in the following way:

1. Access servers, such as dial-up network access servers, VPN servers, and wireless APs, receive connection requests from access clients.

2. The access server, configured to use RADIUS as the authentication, authorization, and accounting protocol, creates an Access-Request message and sends it to the RADIUS server.

3. The RADIUS server evaluates the Access-Request message.

4. If required (for example, when the authentication protocol is EAP), the RADIUS server sends an Access-Challenge message to the access server. The access server or access client processes the challenge and sends a new Access-Request to the RADIUS server.

5. The user credentials and the authorization of the connection attempt are verified.

6. If the connection attempt is both authenticated and authorized, the RADIUS server sends an Access-Accept message to the access server.

7. If the connection attempt is either not authenticated or not authorized, the RADIUS server sends an Access-Reject message to the access server.

8. Upon receipt of the Access-Accept message, the access server completes the connection process with the access client and sends an Accounting-Request message to the RADIUS server.

9. After the Accounting-Request message is processed, the RADIUS server sends an Accounting-Response message.

EAP

This section describes the following:

• EAP overview

• EAP types in Windows

• EAP over RADIUS

• EAP-TLS and the IEEE 802.1X authentication process

EAP Overview

The Extensible Authentication Protocol (EAP) was originally created as an extension to PPP that allows for development of arbitrary network access authentication methods. With PPP authentication protocols such as CHAP, MS-CHAP, and MS-CHAP v2, a specific authentication mechanism is chosen during the link establishment phase. During the connection authentication phase, the negotiated authentication protocol is used to validate the connection. The authentication protocol itself is a fixed series of messages sent in a specific order. With EAP, the specific authentication mechanism is not chosen during the link establishment phase of the PPP connection. Instead, each PPP peer negotiates to perform EAP during the connection authentication phase. When the connection authentication phase is reached, the peers negotiate the use of a specific EAP authentication scheme known as an EAP type. EAP is described in RFC 2284.

After the EAP type is agreed upon, EAP allows for an open-ended exchange of messages between the access client and the authenticating server (the RADIUS server) that can vary based on the parameters of the connection. The conversation consists of requests for authentication information and the responses. The length and detail of the authentication conversation is dependent upon the EAP type.

Architecturally, EAP is designed to allow authentication plug-in modules at both the access client and authenticating server ends of a connection. To add support for a new EAP type, install an EAP type library file on both the access client and the authenticating server. This presents vendors with the opportunity to supply a new authentication scheme at any time. EAP provides the highest flexibility to allow for more secure authentication methods.

You can use EAP to support authentication schemes such as Generic Token Card, One Time Password (OTP), MD5-Challenge, Transport Layer Security (TLS) for smart card and certificate support, and any future authentication technologies. EAP is a critical technology component for secure connections.

In addition to support within PPP, EAP is also supported within the IEEE 802 link layer. IEEE 802.1X defines how EAP is used for authentication by IEEE 802 devices, including IEEE 802.11b wireless APs and Ethernet switches. IEEE 802.1X differs from PPP in that only EAP authentication methods are supported.

EAP Types in Windows

The following EAP types for wireless connections are included with Windows:

• EAP-TLS

• Protected EAP

EAP-TLS

EAP-Transport Layer Security (EAP-TLS) is an EAP type that is used in certificate-based security environments. If you are using smart cards for remote access authentication, you must use the EAP-TLS authentication method. The EAP-TLS exchange of messages provides mutual authentication, integrity-protected cipher suite negotiation, and secured private key exchange and determination between the access client and the authenticating server. EAP-TLS provides the strongest authentication method. EAP-TLS is described in RFC 2716.

EAP-TLS using registry-based user and computer certificates is the recommended authentication method for Windows-based wireless connectivity for the following reasons:

• EAP-TLS does not require any dependencies on the user account's password.

• EAP-TLS authentication occurs automatically, usually with no intervention by the user.

• EAP-TLS uses certificates, which is a relatively strong authentication scheme.

• The EAP-TLS exchange is protected with public key cryptography and is not susceptible to offline dictionary attacks.

• The EAP-TLS authentication process results in mutually determined keying material for data encryption and signing.

  Note EAP-TLS authentication with smart cards is not supported for wireless connections in Windows XP with no service packs installed.

Protected EAP

Windows Vista, Windows XP with SP1, Windows XP with SP2, Windows Server 2003, Windows Server “Longhorn,” and Windows 2000 with SP4 support Protected EAP (PEAP) as a new EAP type. For more information about PEAP, see "PEAP Overview" in this article.

EAP Over RADIUS

EAP over RADIUS is not an EAP type, but the passing of EAP messages of any EAP type by the access server to a RADIUS server for authentication. An EAP message sent between the access client and access server is formatted as the EAP-Message RADIUS attribute (RFC 2869, section 5.13), and sent in a RADIUS message between the access server and the RADIUS server. The access server becomes a pass-through device passing EAP messages between the access client and the RADIUS server. Processing of EAP messages occurs at the access client and the RADIUS server, not at the access server. This is shown in Figure 14.

Figure 14: EAP over RADIUS

EAP over RADIUS is used in environments where RADIUS is used as the authentication provider. An advantage of using EAP over RADIUS is that EAP types do not need to be installed at each access server, only at the RADIUS server. However, the access server must support the negotiation of EAP as an authentication protocol and the passing of EAP messages to a RADIUS server.

In a typical use of EAP over RADIUS, the access server is configured to use EAP and to use RADIUS as its authentication provider. When a connection attempt is made, the access client negotiates the use of EAP with the access server. When the client sends an EAP message to the access server, the access server encapsulates the EAP message as the EAP-Message attribute of a RADIUS Access-Request message and sends it to its configured RADIUS server. The RADIUS server processes the EAP message in the EAP-Message attribute and sends an EAP response message as a RADIUS Access-Challenge message with the EAP-Message attribute to the access server. The access server then forwards the EAP message to the access client.

EAP-TLS and the IEEE 802.1X Authentication Process

The following is the EAP-TLS authentication process for a wireless client authenticating to a wireless AP configured to use a RADIUS server as its authentication server:

Step 1: Association and request for identity

If the wireless AP observes a new wireless client associating with it, the wireless AP transmits an EAP-Request/Identity message to the wireless client. Alternately, when a wireless client associates with a new wireless AP, it transmits an EAP-Start message. If the IEEE 802.1X process on the wireless AP receives an EAP-Start message from a wireless client, it transmits an EAP-Request/Identity message to the wireless client.

Step 2: EAP-Response/Identity response

If there is no user logged on to the wireless client, it transmits an EAP-Response/Identity containing the computer name. For Windows wireless clients, the FQDN of the computer account is sent. If there is a user logged on to the wireless client, it transmits an EAP-Response/Identity containing the user name. For Windows wireless clients, the UPN of the user account is sent.

The wireless AP forwards the EAP-Response/Identity message to the RADIUS server in the form of a RADIUS Access-Request message.

Step 3: EAP-Request from RADIUS server (Start TLS)

The RADIUS server sends a RADIUS Access-Challenge message containing an EAP-Request message with the EAP-Type set to EAP-TLS, requesting a start to the TLS authentication process.

The wireless AP forwards the EAP message to the wireless client.

Step 4: EAP-Response from the wireless client (TLS Client Hello)

The wireless client sends an EAP-Response message with the EAP-Type set to EAP-TLS, indicating the TLS client hello.

The wireless AP forwards the EAP message to the RADIUS server in the form of a RADIUS Access-Request message.

Step 5: EAP Request from RADIUS server (RADIUS Server's Certificate)

The RADIUS server sends a RADIUS Access-Challenge message containing an EAP-Request message with the EAP-Type set to EAP-TLS, and includes the RADIUS server's certificate chain.

The wireless AP forwards the EAP message to the wireless client.

Step 6: EAP-Response from the wireless client (Wireless Client's Certificate)

The wireless client sends an EAP-Response message with the EAP-Type set to EAP-TLS, and includes the wireless client's certificate chain.

The wireless AP forwards the EAP message to the RADIUS server in the form of a RADIUS Access-Request message.

Step 7: EAP-Request from RADIUS server (Cipher suite, TLS complete)

The RADIUS server sends an EAP-Request message with the EAP-Type set to EAP-TLS, and includes the cipher suite and an indication that TLS authentication message exchanges are complete.

The wireless AP forwards the EAP message to the wireless client.

Step 8: EAP-Response from the wireless client

The wireless client sends an EAP-Response message with the EAP-Type set to EAP-TLS.

The wireless AP forwards the EAP message to the RADIUS server in the form of a RADIUS Access-Request message.

Step 9: EAP-Success from RADIUS server

The RADIUS server derives the per-client unicast session key and the signing key from the keying material that is a result of the EAP-TLS authentication process. Next, the RADIUS server sends a RADIUS Access-Accept message containing an EAP-Success message and the MPPE-Send-Key and MPPE-Recv-Key attributes to the wireless AP.

The wireless AP uses the key encrypted in the MS-MPPE-Send-Key attribute as the per-client unicast session key for data transmissions to the wireless client (truncated to the appropriate WEP key length). The wireless AP uses the key encrypted in the MS-MPPE-Recv-Key attribute as a signing key for data transmissions to the wireless client that require signing (truncated to the appropriate WEP key length).

The wireless client derives the per-client unicast session key (the same value as the decrypted MS-MPPE-Send-Key attribute in the RADIUS message sent to the wireless AP) and the signing key (the same as value as the decrypted MS-MPPE-Recv-Key attribute in the RADIUS message sent to the wireless AP) from the keying material that is a result of the EAP-TLS authentication process. Therefore, both the wireless AP and the wireless client are using the same keys for both the encryption and signing of unicast data.

The wireless AP on receiving the RADIUS server message forwards the EAP-Success message to the wireless client. The EAP message does not contain the per-station unicast session or signing keys.

Step 10: Multicast/global encryption key to the wireless client

The wireless AP derives the multicast/global encryption key by generating a random number or by selecting it from a previously set value. Next, the wireless AP sends an EAP over LAN (EAPOL)-Key message to the wireless client containing the multicast/global key that is encrypted using the per-client unicast session key.

The Key field of the IEEE 802.1X EAPOL-Key message is RC4-encrypted using the per-client unicast session key and portions of the message are signed with HMAC-MD5 using the per-client unicast signing key.

Upon receiving the EAPOL-Key message, the wireless client uses the per-client unicast session key to verify the signed portions of the EAPOL-Key message and decrypt the multicast/global key. Next, the wireless LAN network adapter driver indicates the per-client unicast session key, the per-client unicast signing key, and the multicast/global key to the wireless LAN network adapter. After the keys have been indicated, the wireless client begins protocol configuration using the wireless adapter (such as using DHCP to obtain an IP address configuration).

When the wireless AP changes the multicast/global key, it generates and sends EAPOL-Key messages to its connected wireless clients. Each EAPOL-Key message contains the new multicast/global key encrypted with the particular wireless client's per-client unicast session key.

This process is summarized in Figure 15.

Figure 15: EAP-TLS and the IEEE 802.1X authentication process

PEAP Overview

Although EAP provides authentication flexibility through the use of EAP types, the entire EAP conversation might be sent as clear text (unencrypted). A malicious user with access to the media can inject packets into the conversation or capture the EAP messages from a successful authentication for analysis. This is especially problematic for wireless connections, in which the malicious user can be located outside of your business. EAP occurs during the IEEE 802.1X authentication process, before wireless frames are encrypted with WEP.

PEAP is an EAP type that addresses this security issue by first creating a secure channel that is both encrypted and integrity-protected with TLS. Then, a new EAP negotiation with another EAP type occurs, authenticating the network access attempt of the client. Because the TLS channel protects EAP negotiation and authentication for the network access attempt, password-based authentication protocols that are normally susceptible to an offline dictionary attack can be used for authentication in wireless environments.

MS-CHAP v2 Overview

MS-CHAP v2 is a password-based, challenge-response, mutual authentication protocol that uses the industry-standard Message Digest 4 (MD4) and Data Encryption Standard (DES) algorithms to encrypt responses. The authenticating server challenges the access client and the access client challenges the authenticating server. If either challenge is not correctly answered, the connection is rejected. MS-CHAP v2 was originally designed by Microsoft as a PPP authentication protocol to provide better protection for dial-up and virtual private network (VPN) connections.

Although MS-CHAP v2 provides better protection than previous PPP-based challenge-response authentication protocols, it is still susceptible to an offline dictionary attack. A malicious user can capture a successful MS-CHAP v2 exchange and methodically guess passwords until the correct one is determined. Using the combination of PEAP with MS-CHAP v2, the MS-CHAP v2 exchange is protected with the strong security of the TLS channel.

PEAP with MS-CHAP v2 Operation

The PEAP authentication process occurs in two parts. The first part is the use of EAP and the PEAP EAP type to create an encrypted TLS channel. The second part is the use of EAP and a different EAP type to authenticate network access. This section examines PEAP with MS-CHAP v2 operation, using as an example, a wireless client that attempts to authenticate to a wireless AP that uses a RADIUS server for authentication and authorization.

The following steps are used to create the PEAP TLS channel:

1. After creating the logical link, the wireless AP sends an EAP-Request/Identity message to the wireless client.

2. The wireless client responds with an EAP-Response/Identity message that contains the identity (user or computer name) of the wireless client.

3. The EAP-Response/Identity message is sent by the wireless AP to the RADIUS server. From this point on, the logical communication occurs between the RADIUS server and the wireless client, using the wireless AP as a pass-through device.

4. The RADIUS server sends an EAP-Request/Start PEAP message to the wireless client.

5. The wireless client and the RADIUS server exchange a series of TLS messages through which the cipher suite for the TLS channel is negotiated and the RADIUS server sends a certificate chain to the wireless client for authentication.

At the end of the PEAP negotiation, the RADIUS server has authenticated itself to the wireless client. Both nodes have determined mutual encryption and signing keys (using public key cryptography, not passwords) for the TLS channel.

After the PEAP TLS channel is created, the following steps are used to authenticate the wireless client credentials with MS-CHAP v2:

1. The RADIUS server sends an EAP-Request/Identity message.

2. The wireless client responds with an EAP-Response/Identity message that contains the identity (user or computer name) of the wireless client.

3. The RADIUS server sends an EAP-Request/EAP-MS-CHAP-V2 Challenge message that contains a challenge string.

4. The wireless client responds with an EAP-Response/EAP-MS-CHAP-V2 Response message that contains both the response to the RADIUS server challenge string and a challenge string for the RADIUS server.

5. The RADIUS server sends an EAP-Request/EAP-MS-CHAP-V2 Success message, which indicates that the wireless client response was correct and contains the response to the wireless client challenge string.

6. The wireless client responds with an EAP-Response/EAP-MS-CHAP-V2 Ack message, indicating that the RADIUS server response was correct.

7. The RADIUS server sends an EAP-Success message.

At the end of this mutual authentication exchange, the wireless client has provided proof of knowledge of the correct password (the response to the RADIUS server challenge string), and the RADIUS server has provided proof of knowledge of the correct password (the response to the wireless client challenge string). The entire exchange is encrypted through the TLS channel created in the first part of the PEAP authentication.

For additional information about the PEAP-MS-CHAP v2 authentication process, see IEEE 802.11 Wireless LAN Security with Microsoft Windows.

If PEAP-TLS is used, a TLS authentication process occurs in the same way as EAP-TLS, except that the EAP messages are encrypted using the TLS channel created in the first part of the PEAP authentication.

PEAP Fast Reconnect

You can also use PEAP to quickly resume a TLS session. If PEAP Part 2 is successful, the RADIUS server can cache the TLS session created during PEAP Part 1. Because the cache entry was created through a successful PEAP Part 2 authentication process, the session can be resumed without having to go through a complete authentication again. In this case, an EAP-Success message is sent almost immediately for a reauthentication attempt. This is known as fast reconnect. Fast reconnect minimizes the connection delay in wireless environments when a wireless client roams from one wireless AP to another.

Fast reconnect is an optional feature of PEAP. If you intend to use it, fast reconnect must be enabled on both the wireless client and the RADIUS server. Fast reconnect is supported in Windows Vista, Windows XP with SP1, Windows XP with SP2, Windows Server 2003, Windows Server “Longhorn,” and Windows 2000 with SP4. IAS for Windows Server 2003 also supports fast reconnect. In all cases, fast reconnect is disabled by default. IAS for Windows 2000 Server with SP4 does not support fast reconnect.

PEAP Support in Windows

Windows Vista, Windows XP with SP1, Windows XP with SP2, Windows Server 2003, Windows Server “Longhorn,” and Windows 2000 with SP4 wireless clients support PEAP-MS-CHAP v2 and PEAP-TLS. This allows these Windows wireless clients to use PEAP with MS-CHAP v2 for protected wireless access with passwords rather than certificates.

For authentication servers, IAS for Windows Server 2003 and Windows 2000 Server when SP4 is installed support PEAP-MS-CHAP v2 and PEAP-TLS.

PEAP with MS-CHAP v2 requires certificates on the IAS servers but not on the wireless clients. IAS servers must have a certificate installed in their Local Computer certificate store. Instead of deploying a PKI, you can purchase individual certificates from a third-party CA to install on your IAS servers. To ensure that wireless clients can validate the IAS server certificate chain, the root CA certificate of the CA that issued the IAS server certificates must be installed on each wireless client.

Windows wireless clients include the root CA certificates of many third-party CAs. If you purchase your IAS server certificates from a third-party CA that corresponds to an included root CA certificate, no additional wireless client configuration is required. If you purchase your IAS server certificates from a third party CA for which your Windows wireless clients do not include a corresponding root CA certificate, you must install the root CA certificate on each wireless client.

IAS and Remote Access Policies

This section describes the following topics:

• IAS overview

• IAS as a RADIUS server

• Remote access policies

• Remote access policy conditions and restrictions

• Dial-in properties of a user or computer account

• Authorizing access

IAS Overview

Internet Authentication Service (IAS) in Windows Server 2003 and Windows 2000 Server is the Microsoft implementation of a RADIUS server and for Windows Server 2003, the Microsoft implementation of a RADIUS proxy. IAS performs centralized connection authentication, authorization, and accounting for many types of network access, including wireless, authenticating switch, dial-up and virtual private network (VPN) remote access, and router-to-router connections. IAS supports RFCs 2865 and 2866, as well as additional RADIUS extension RFCs and Internet drafts.

IAS enables the use of a heterogeneous set of wireless, switch, remote access, or VPN equipment, and can be used with the Windows Server 2003 or Windows 2000 Server Routing and Remote Access service.

When an IAS server is a member of an Active Directory-based domain, IAS uses Active Directory as its user account database and is part of a single sign-on solution. The same set of credentials is used for network access control (authenticating and authorizing access to a network) and to log on to an Active Directory-based domain.

Different IAS configurations can be created for the following solutions:

• Wireless access

• Organization dial-up or virtual private network (VPN) remote access

• Outsourced dial-up or wireless access

• Internet access

• Authenticated access to extranet resources for business partners

IAS as a RADIUS Server

IAS can be used as a RADIUS server to perform authentication, authorization, and accounting for RADIUS clients. A RADIUS client can be either an access server or a RADIUS proxy. IAS as a RADIUS server is shown in Figure 16.

Figure 16: IAS as a RADIUS server

When IAS is used as a RADIUS server, it provides the following:

• A central authentication and authorization service for all access requests that are sent by RADIUS clients IAS uses a Windows NT Server 4.0 domain, an Active Directory-based domain, or the local Security Accounts Manager (SAM) to authenticate user credentials for a connection attempt. IAS uses the dial-in properties of the user account and remote access policies to authorize a connection.

• A central accounting recording service for all accounting requests that are sent by RADIUS clients Accounting requests are stored in a local log file for analysis.

You can use IAS as a RADIUS server when:

• You are using a Windows NT Server 4.0 domain, an Active Directory-based domain, or the local Security Accounts Manager (SAM) as your user account database for access clients.

• You are using the Routing and Remote Access service on multiple dial-up servers, VPN servers, or demand-dial routers and you want to centralize both the configuration of remote access policies and connection logging for accounting.

• You are outsourcing your dial-in, VPN, or wireless access to a service provider. The access servers use RADIUS to authenticate and authorize connections that are made by members of your organization.

• You want to centralize authentication, authorization, and accounting for a heterogeneous set of access servers.

IAS as a RADIUS Proxy

Internet Authentication Service (IAS) can be used as a RADIUS proxy to provide the routing of RADIUS messages between RADIUS clients (access servers) and RADIUS servers that perform user authentication, authorization, and accounting for the connection attempt. When used as a RADIUS proxy, IAS is a central switching or routing point through which RADIUS access and accounting messages flow. IAS records information in an accounting log about the messages that are forwarded.

Figure 17 shows IAS as a RADIUS proxy between RADIUS clients (access servers) and either RADIUS servers or another RADIUS proxy.

Figure 17: IAS as a RADIUS proxy

You can use IAS as a RADIUS proxy when:

• You are a service provider that offers outsourced dial, virtual private network (VPN), or wireless network access services to multiple customers.

• You want to provide authentication and authorization for user accounts that are not members of either the domain in which the IAS server is a member or another domain that has a two-way trust with the domain in which the IAS server is a member.

• You want to perform authentication and authorization by using a database that is not a Windows account database.

• You want to process a large number of connection requests. The IAS RADIUS proxy dynamically balances the load of connection and accounting requests across multiple RADIUS servers and increases the processing of large numbers of RADIUS clients and authentications per second.

• You want to provide RADIUS authentication and authorization for outsourced service providers and minimize intranet firewall configuration.

For more information about using IAS as a RADIUS proxy, see Windows Server 2003 Help and Support.

Remote Access Policies

For IAS, network access authorization is granted on the basis of user account dial-in properties and remote access policies. Remote access policies are an ordered set of rules that define how connections are either authorized or rejected. For each rule, there are one or more conditions, a set of profile settings, and a remote access permission setting.

If a connection is authorized, the remote access policy profile specifies a set of connection restrictions. The dial-in properties of the user account also provide a set of restrictions. Where applicable, user account connection restrictions override the remote access policy profile connection restrictions.

Remote Access Policy Conditions and Restrictions

Remote access policies validate a number of connection settings before authorizing the connection, including the following:

• Group membership

• Type of connection

• Time of day

Advanced conditions include the following:

• Access server identity

• Access client phone number or MAC address

• Whether unauthenticated access is allowed

After the connection is authorized, remote access policies can also be used to specify connection restrictions, including the following:

• Idle timeout time

• Maximum session time

• Encryption strength

• Authentication method

• IP packet filters

• Advanced restrictions:

  • IP address for PPP connections

  • Static routes

Additionally, you can vary connection restrictions based on the following settings:

• Group membership

• Type of connection

• Time of day

• Authentication methods

• Identity of the access server

• Access client phone number or MAC address

• Whether unauthenticated access is allowed

For example, you can have policies that specify different maximum session times for different types of connections or groups. Additionally, you can specify restricted access for business partners or unauthenticated connections.

Dial-in Properties of a User or Computer Account

User and computer accounts for an Active Directory-based server contains a set of dial-in properties that are used when allowing or denying a connection attempt. On an Active Directory-based server, you can set the dial-in properties on the Dial-in tab for the user and computer account in the Active Directory Users and Computers snap-in. Figure 18 shows the Dial-in tab.

Figure 18: The Dial-in tab of a user account

The dial-in properties for a user and computer account are:

• Remote Access Permission (Dial-in or VPN)

  You can use this property to set remote access permission to be explicitly allowed, denied, or determined through remote access policies. In all cases, remote access policies are also used to authorize the connection attempt. If access is explicitly allowed, remote access policy conditions, user account properties, or profile properties can still deny the connection attempt. The Control access through Remote Access Policy option is only available on user and computer accounts in a native-mode domain.

  New accounts that are created for a native-mode domain are set to Control access through Remote Access Policy. New accounts that are created in a mixed-mode domain are set to Deny access.

• Verify Caller ID

  If this property is enabled, the server verifies the caller's phone number. If the caller's phone number does not match the configured phone number, the connection attempt is denied.

  The caller, the phone system between the caller and the remote access server, and the remote access server, must support caller ID. On a computer running the Routing and Remote Access service, caller ID support consists of call answering equipment that provides caller ID information and the appropriate driver to pass the caller ID information to the Routing and Remote Access service.

  If you configure a caller ID phone number for a user, and you do not have support for the passing of caller ID information from the caller to the Routing and Remote Access service, the connection attempt is denied.

• Callback Options

  If this property is enabled, the server calls the caller back during the connection process. Either the caller or the network administrator sets the phone number that is used by the server.

• Assign a Static IP Address

  You can use this property to assign a specific IP address to a user when a connection is made.

• Apply Static Routes

  You can use this property to define a series of static IP routes that are added to the routing table of the server running the Routing and Remote Access service when a connection is made. This setting is designed for user accounts that Routing and Remote Access routers use for demand-dial routing.

  Note Dial-in properties for computer accounts in a Windows 2000-based domain are available only after Windows 2000 Service Pack 3 or Windows 2000 Service Pack 4 is installed on domain controllers.

Authorization Administration Models

There are two ways to use remote access policies to grant authorization:

1. By user

2. By group

Authorization by user

If you are managing authorization by user, set the remote access permission on the user or computer account to either Grant access or Deny access and, optionally, create different remote access policies based on different types of connections. For example, you might want to have one remote access policy that is used for dial-up connections and a different remote access policy that is used for wireless connections. Managing authorization by user is recommended only when you have a small number of user or computer accounts to manage.

If you are managing authorization by user, the basic process for authorizing a connection attempt occurs as follows:

1. If the connection attempt matches all policy conditions, check the remote access permission setting of the account.

2. If the remote access permission is set to Grant access, apply the connection settings of the policy profile and user account.

3. If the remote access permission is set to Deny access, reject the connection attempt.

4. If the connection attempt does not match all policy conditions, process the next remote access policy.

5. If the connection attempt does not match all conditions of any remote access policy, reject the connection attempt.

Authorization by group

If you are managing authorization by group, set the remote access permission on the account to Control access through Remote Access Policy and create remote access policies that are based on different types of connections and group membership. For example, you might want to have one remote access policy for dial-up connections for employees (members of the Employees group) and a different remote access policy for dial-up connections for contractors (members of the Contractors group).

If you are managing authorization by group, the basic process for authorizing a connection attempt occurs as follows:

1. If the connection attempt matches all policy conditions, check the remote access permission of the remote access policy.

2. If the remote access permission is set to Grant remote access permission, apply the connection settings of the policy profile and user account.

3. If the remote access permission is set to Deny remote access permission, reject the connection attempt.

4. If the connection attempt does not match all policy conditions, process the next remote access policy.

5. If the connection attempt does not match all conditions of any remote access policy, reject the connection attempt.

   Notes The Control access through Remote Access Policy remote access permission setting is only available on accounts of a native-mode domain.

• Setting the remote access permission to Control access through Remote Access Policy and not using groups to manage network access is not recommended.

Certificates

This section describes the following topics:

• Computer authentication and user authentication

• Obtaining a certificate for IEEE 802.1X authentication

• Group policy and IEEE 802.1X authentication

Computer Authentication and User Authentication

To successfully authenticate a Windows wireless client with a wireless AP, you must have a computer certificate, a user certificate, or both installed. Wireless clients running Windows Vista, Windows XP, Windows Server 2003, Windows Server “Longhorn,” and Windows 2000 can use EAP-TLS to authenticate the computer or the user logged on to the computer.

To authenticate the computer, the Windows wireless client submits a computer certificate (along with its chain) stored in the Local Computer certificate store during EAP-TLS authentication. The Local Computer certificate store is always available, regardless of whether a user has logged on to the computer or who is logged on to the computer. More importantly, the Local Computer certificate store is available during the computer's startup process.

To authenticate the user logged on to the computer, the Windows wireless client submits a user certificate stored in the Current User certificate store during EAP-TLS authentication. The user's certificate store is only available after the user has successfully logged on to the computer using the proper credentials. Each individual user that logs on to the computer has a separate user certificate store. The user certificate is not available during the startup process.

Without an installed computer certificate, a Windows wireless client computer that starts up within range of a wireless AP associates with it but authentication fails. A user can log on to a computer that does not have wireless LAN network connectivity using cached credentials. Once successfully logged on, the user's certificate store becomes available and the subsequent authentication with the wireless AP succeeds using the installed user certificate.

The following registry setting controls the computer and user authentication behavior of Windows XP and Windows Server 2003:

AuthMode

Key: HKEY_LOCAL_MACHINE\Software\Microsoft\EAPOL\Parameters\General\Global 
Value Type: REG_DWORD 
Valid Range: 0-2 
Default value: 0 
Present by default: No

Values:

• 0 - Computer authentication mode If computer authentication is successful, no user authentication is attempted. If the user logon is successful before computer authentication, then user authentication is performed. This is the default setting for Windows XP with no service packs installed.

• 1 - Computer authentication with re-authentication If computer authentication completes successfully, a subsequent user logon results in a re-authentication with the user certificate. The user logon has to complete in 60 seconds or the existing network connectivity is terminated. The user certificate is used for subsequent authentication or re-authentication. Computer authentication is not attempted again until the user logs off the computer. This is the default setting for Windows XP with SP1, Windows XP with SP2, and Windows Server 2003.

• 2 - Computer authentication only When a user logs on, it has no effect on the connection. 802.1X authentication is performed using the computer certificate only.

For changes to this setting to take effect, restart the Wireless Zero Configuration service for Windows XP and the Wireless Configuration service for Windows Server 2003.

Obtaining a Certificate for IEEE 802.1X Authentication

The following methods can be used to obtain certificates for Windows wireless clients and IAS server computers:

• Autoenrollment

• Request a certificate via the Web

• Request a certificate using the Certificates snap-in

• Import a certificate using the Certificates snap-in

• Create a program or script using CAPICOM

Autoenrollment

Autoenrollment is the automatic requesting and issuing of certificates based on Group Policy. There are two types of autoenrollment:

• Autoenrollment of computer certificates.

  Supported by Windows Server 2003 and Windows 2000 Server CAs and Windows Vista, Windows XP, Windows Server 2003, Windows Server “Longhorn,” and Windows 2000 with SP4 wireless clients.

• Autoenrollment of user certificates

  Supported by Windows Server 2003, Enterprise Edition CAs and Windows Vista, Windows XP, Windows Server “Longhorn,” and Windows Server 2003 wireless clients.

Autoenrollment of computer certificates is done through Computer Configuration Group Policy. By configuring the Automatic Certificate Request Settings Group Policy setting (found under Computer Configuration\Windows Settings\Security Settings\Public Key Policies), you can have the computers who are members of the domain system container for which the settings are configured automatically request a certificate of specified types when Computer Group Policy settings are refreshed.

For wireless client access and for the IAS server, configure the Automatic Certificate Request Settings Group Policy setting to automatically request the "Computer" certificate. The "Computer" certificate (as named in the Certificate Template dialog box of the Automatic Certificate Request Setup Wizard), is stored in the Local Computer certificate store of the member computer and contains both the User Authentication and Server Authentication certificate purpose. The certificate purpose is also known as an Enhanced Key Usage (EKU). An EKU is identified using an object identifier (OID). The OID for Server Authentication is "1.3.6.1.5.5.7.3.1" and the OID for Client Authentication is "1.3.6.1.5.5.7.3.2".

EAP-TLS in Windows requires that the certificate offered for validation by the authenticating client contain the Client Authentication certificate purpose and that the certificate offered for validation by the authenticating server contain the Server Authentication certificate purpose. If both of these conditions are not met, the authentication fails.

Because the autoenrolled "Computer" certificate contains both the Client Authentication and Server Authentication certificate purposes, it can be used by both a Windows wireless client to perform computer authentication and by the IAS server as the authenticating server.

Autoenrollment of user certificates is done through User Configuration Group Policy. By configuring the Autoenrollment Settings Group Policy setting (found under User Configuration\Windows Settings\Security Settings\Public Key Policies), you can have the users who are members of the domain system container for which the settings are configured automatically request a certificate of specified types when User Group Policy settings are refreshed.

For wireless client access, configure the Autoenrollment Settings Group Policy setting to automatically request a user certificate template that is created using the Certificate Templates snap-in. For more information about configuring the certificate template and configuring autoenrollment of user certificates for a Windows Server 2003, Enterprise Edition CA, see the topic titled "Checklist: Configuring certificate autoenrollment" in Windows Server 2003 Help and Support.

Request a certificate via the Web

Requesting a certificate via the Web, also known as Web enrollment, is done with Internet Explorer. For the address, type http://servername/certsrv, where servername is the computer name of Windows-based CA. A Web-based wizard takes you through the steps of requesting a certificate. Note that the location where the certificate is stored (whether it is the Current User store or the Local Computer store) is determined by the Use local machine store check box when performing an advanced certificate request. By default, this option is disabled, and certificates are stored in the Current User store. You must have local administrator privileges to store a certificate in the Local Computer store.

Request a certificate using the Certificates snap-in

Another way to request a certificate is using the Certificates snap-in. To request a certificate to store in the Current User store, open the Certificates-Current User\Personal\Certificates folder, right-click the Certificates folder, point to All tasks, then click Request New Certificate. A Certificate Request Wizard guides you through the steps of requesting a certificate. For wireless access, the certificate requested for the Current User store must have the Client Authentication certificate purpose.

To request a certificate to store in the Local Computer store, open the Certificates (Local Computer)\Personal\Certificates folder, right-click the Certificates folder, point to All tasks, then click Request New Certificate. A Certificate Request Wizard will guide you through the steps of requesting a certificate. For wireless access, the certificate requested for the Local Computer store must have the Client Authentication certificate purpose. For the certificate for the IAS server, the certificate requested for the Local Computer store must have the Server Authentication certificate purpose.

Import a certificate using the Certificates snap-in

All of the preceding ways of requesting a certificate assume that network connectivity already exists, such as using the Ethernet port on a laptop. For those configurations where the only network connectivity is wireless, which cannot be obtained without certificates, you can also import a certificate file from a floppy disk, CD-ROM, or other recordable media using the Certificates snap-in.

To import a certificate to store in the Current User store, open the Certificates-Current User\Personal\Certificates folder, right-click the Certificates folder, point to All tasks, then click Import. A Certificate Import Wizard will guide you through the steps of importing a certificate from a certificate file. For wireless access, the certificate imported into the Current User store must have the Client Authentication certificate purpose.

To import a certificate to store in the Local Computer store, open the Certificates (Local Computer)\Personal\Certificates folder, right-click the Certificates folder, point to All tasks, then click Import. A Certificate Import Wizard will guide you through the steps of importing a certificate from a certificate file. For wireless access, the certificate imported into the Local Computer store must have the Client Authentication certificate purpose. For the certificate for the IAS server, the certificate imported into the Local Computer store must have the Server Authentication certificate purpose.

If you use PEAP-MS-CHAP v2, you might have to install the root CA certificate of the CA that issued the computer certificates that are installed on your IAS servers. To obtain the root CA certificate, first export the root CA certificate to a file (*.P7B) from the Certificates (Local Computer)\Trusted Root Certification Authorities\Certificates folder on the IAS server. Then, import the root CA certificate file into the Certificates (Local Computer)\Trusted Root Certification Authorities\Certificates folder on the wireless client.

Note It is also possible to import a certificate by double-clicking a certificate file that is stored in a folder or sent in an e-mail message. Although this works for certificates created with Windows-based CAs, this method does not work for third-party CAs. The recommended method of importing certificates is to use the Certificates snap-in.

Create a program or script using CAPICOM

Requesting a certificate using Web enrollment or the Certificates snap-in requires user intervention. To automate the certificate distribution process, a network administrator can write an executable program or script using CAPICOM. CAPICOM is a COM client, supporting Automation, that performs cryptographic functions (the CryptoAPI) using Microsoft® ActiveX® and COM objects.

The CAPICOM interface can be used to perform fundamental cryptographic tasks including signing data, verifying signatures, enveloping messages, decrypting enveloped messages, encrypting and decrypting data, and checking the validity of digital certificates. CAPICOM can be used via Visual Basic®, Visual Basic Scripting Edition, and C++.

To perform an enterprise deployment of user and computer certificates, a CAPICOM program or script can be distributed through email for execution or users can be directed to a Web site containing a link to a CAPICOM program or script. Alternately, the CAPICOM program or script can be placed in the user's logon script file for automatic execution. The storage location of the user or computer certificate can be specified using the CAPICOM APIs.

For information about CAPICOM, search for "CAPICOM" at https://msdn.microsoft.com.

Group Policy and EAP-TLS-based IEEE 802.1X Authentication

Group Policy settings define the various components of the user's desktop environment that a system administrator needs to manage; for example, the programs that are available to users, the programs that appear on the user's desktop, and Start menu options. Group Policy settings you specify are contained in a Group Policy object, which is in turn associated with selected Active Directory container objects-sites, domains, or organizational units. Group Policy includes settings for User Configuration, which affect users, and Computer Configuration, which affect computers.

IEEE 802.1X and Computer Configuration Group Policy

Updates to Computer Configuration Group Policy occur when the computer starts, achieves network connectivity, and locates a domain controller. The computer attempts to download the latest Computer Configuration Group Policy based on the computer's membership in a domain system container.

If a Windows wireless client configured to use EAP-TLS authentication does not have a computer certificate installed, it cannot authenticate to a wireless AP to obtain wireless LAN network connectivity. Therefore, the attempt to locate a domain controller and download the latest Computer Configuration Group Policy fails. This event is recorded in the event log.

The solution to this problem is to install a computer certificate on the Windows wireless client so that wireless LAN network connectivity is present during the location of the domain controller and the download of the Computer Configuration Group Policy.

IEEE 802.1X and User Configuration Group Policy

Updates to User Configuration Group Policy occur when a user supplies correct credentials and logs on to the domain. If a computer certificate is not installed (and the computer has not authenticated itself against the wireless AP), the logon uses cached credentials. After the user certificate in the user's certificate store becomes available, the Windows wireless client configured to use EAP-TLS authentication attempts to authenticate against the wireless AP. Depending on how long the wireless authentication takes, the download of the User Configuration Group Policy might also fail. This event is recorded in the event log.

The solution to this problem is to install a computer certificate on the Windows wireless client. With an installed computer certificate, the Windows wireless client has wireless LAN network connectivity during the entire logon process, and therefore should always be able to download the latest User Configuration Group Policy.

Note Computer authentication with PEAP-MS-CHAP v2 is done using the account name and password associated with the computer account for the computer, which is automatically assigned when the computer account is created. The credentials for computer authentication are always available and are used during the computer startup process to obtain access to the wireless network. User authentication with PEAP-MS-CHAP v2 is done using an account name and password associated with the user of the computer. By default, the user's logon credentials (username and password) are automatically used to perform user authentication after the client successfully logs on to the computer. The automatic use of the user logon credentials can be configured from the properties of the MS-CHAP v2 PEAP type.

Summary

The components of an infrastructure mode wireless LAN consist of wireless clients, wireless APs, a wired network, and an authentication infrastructure. The elements provided with Windows Vista, Windows XP, Windows Server 2003, Windows Server “Longhorn,” and Windows 2000 are wireless clients (computers running Windows with a supported wireless LAN adapter) and the authentication infrastructure consisting of RADIUS servers, domain controllers, and CAs. With this combination of components, you have all the required elements to deploy a protected wireless LAN infrastructure that uses either EAP-TLS with certificates or PEAP-MS-CHAP v2 with passwords for strong authentication and per-session encryption key management.

Related Links

See the following resources for additional information:

• Wireless Networking Web page at https://www.microsoft.com/technet/network/wifi/default.mspx

• Internet Authentication Service Web page at https://www.microsoft.com/network/ias/default.mspx

• Security Services Web site at https://www.microsoft.com/windowsserver2003/technologies/security/default.mspx

• Windows 2000 Service Pack 4 at https://www.microsoft.com/windows2000/downloads/servicepacks/default.asp