Chapter 5 - EAP

Chapter 5

EAP

The Extensible Authentication Protocol (EAP) was originally created as an extension to the Point-to-Point Protocol (PPP) that allows for development of arbitrary network access authentication methods. With PPP authentication protocols such as Challenge Handshake Authentication Protocol (CHAP), Microsoft Challenge Handshake Authentication Protocol (MS-CHAP), and MS-CHAP version 2 (MS-CHAP v2), a specific authentication mechanism is chosen during the link establishment phase. During the authentication phase, the connection is validated by using the negotiated authentication protocol. 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 (for wireless, the RADIUS server) that can vary based on the parameters of the connection. The conversation consists of requests and responses for authentication information. The EAP type determines the length and detail of the authentication conversation.

Architecturally, EAP allows 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 capability to extend EAP provides vendors with the opportunity to create new authentication schemes. 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), Message Digest 5 (MD5)-Challenge, Transport Layer Security (TLS) for smart card and certificate authentication, and future authentication technologies. EAP is a critical technology component for establishing secure connections.

In addition to support within PPP, EAP is 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, 802.11a, and 802.11g wireless access points (APs) and Ethernet switches. IEEE 802.1X differs from PPP in that only EAP authentication methods are supported.

EAP-MD5 CHAP

EAP-Message Digest 5 Challenge Handshake Authentication Protocol (EAP-MD5 CHAP) is an EAP type that uses the same challenge handshake protocol as PPP-based CHAP, but the challenges and responses are sent as EAP messages. EAP-MD5 CHAP is described in RFC 2284.

You can use EAP-MD5 CHAP to authenticate the credentials of remote access clients by using username and password security systems and to test EAP interoperability.

EAP-MD5 CHAP is not a suitable authentication method for Windows-based wireless connections for the following reasons:

• CHAP requires the availability of a reversibly encrypted form of the account password to verify the CHAP challenge response. This property of accounts is not enabled for local computer or domain accounts by default.

• CHAP authentication for wireless connectivity results in multiple user logons: one to obtain wireless connectivity and another to log on to a domain.

• CHAP is a password-based authentication method in which the user chooses passwords that could result in a relatively weak authentication scheme.

• CHAP is susceptible to offline dictionary attacks in which a malicious user captures the CHAP exchange and then attempts to determine the password.

• CHAP authentication does not result in mutually determined keying material for data encryption and data signing.

There are no configuration properties for EAP-MD5 CHAP on either the wireless client or IAS. Windows XP (SP1 and later), Windows 2000 with Microsoft 802.1X Authentication Client, and Windows Server 2003 no longer allow the use of EAP-MD5 CHAP as a wireless authentication method.

EAP-TLS

EAP-Transport Layer Security (EAP-TLS) is an EAP type that is used in certificate-based security environments and provides the strongest authentication method. If you use 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 encryption key determination. These parameters are negotiated between the access client and the authenticating server and are described in RFC 2716.

EAP-TLS using user and computer certificates is the preferred 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 provide a relatively strong authentication scheme.

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

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

NOTE
EAP-TLS authentication with smart cards is supported for wireless connections with Windows XP (SP1 and later), Microsoft 802.1X Authentication Client, and Windows Server 2003. Windows XP (prior to SP1) does not support the use of smart cards for wireless authentication.

The EAP-TLS type authentication for wireless connections in Windows has client-side and server-side configuration requirements. The client-side configuration is done on the wireless client; the server-side configuration is done on the IAS server.

Configuring EAP-TLS on the Wireless Client

Figure 5-3 shows the client-side Smart Card Or Other Certificate Properties dialog box for Windows XP (prior to SP1). This dialog box can be accessed from the Authentication tab on the properties of a wireless network adapter.

Figure 5-3. Client-side Smart Card Or Other Certificate Properties dialog box.

From the Smart Card Or Other Certificate Properties dialog box, you can view and configure the following:

• When Connecting

  To use a certificate in the Current User or Local Computer certificate stores for authentication, select Use A Certificate On This Computer, which is the default. When there are multiple user certificates installed, you are prompted to select a specific user certificate for the first association. Its use is cached for reassociations until the Windows user session is ended. To use the certificate on a smart card, select Use My Smart Card.

• Validate Server Certificate

  This option, which is enabled by default, allows you to validate the computer certificate of the authenticating server (typically a RADIUS server for wireless clients).

• Connect Only If Server Name Ends With

  This option, which is disabled by default, determines whether you want to specify a string that must match the last part of the name in the authenticating server s computer certificate. If you enable this option and type the wrong string, the authentication fails. For example, if you want to connect only if the fully qualified domain names in the Subject field of the server certificates end in corpnet.example.com , type corpnet.example.com.

• Trusted Root Certificate Authority

  This option allows you to select the specific root certification authority (CA) of the RADIUS server s computer certificate. (By default, there is no specific trusted root CA selected.) If you select the wrong trusted root CA, you are asked during authentication whether you want to accept the connection using the root CA of the RADIUS server s certificate. If you click OK, your selection of the trusted root CA is automatically set to the root CA of the RADIUS server certificate.

• Use A Different User Name For The Connection

  This option, which is disabled by default, specifies whether you want to use a username for authentication that is different from the username in the certificate. If enabled, you are prompted to select a user certificate, even if only one user certificate is installed. The selected certificate is used until the user session is ended.

For Windows XP (SP1 and later), Windows 2000 with Microsoft 802.1X Authentication Client, and Windows Server 2003, the properties of the Smart Card Or Other Certificate dialog box have changed. Figure 5-4 shows the new Smart Card Or Other Certificate Properties dialog box, which you can access from the Authentication tab on the properties of a wireless network or wireless network adapter.

Figure 5-4. The new client-side Smart Card Or Other Certificate Properties dialog box.

The new Smart Card Or Other Certificate Properties dialog box contains the following new configuration items:

• Use Simple Certificate Selection

  This option 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 used only when Use A Certificate On This Computer is selected (the option is enabled by default).

  To determine the certificates that are usable for EAP-TLS authentication, the certificates in the Current User or Local Computer certificates stores are filtered. This filtering, which occurs whether simple certificate selection is enabled or not, eliminates certificates that have expired, those that do not have the Client Authentication enhanced key usage, those that do not have an associated private key, and those whose private key is not available without requiring user interaction (for example, prompting the user for a personal identifier [PIN] to unlock the private key corresponding to the certificate).

• Connect To These Servers

  This option allows you to specify RADIUS servers providing authentication and authorization for the connection by name. The server names must exactly match those 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 listed.)

• Trusted Root Certification Authorities

  This option allows you to select multiple trusted root CAs when authenticating the certificate of the RADIUS server.

• View Certificate

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

Configuring EAP-TLS on the IAS Server

Figure 5-5 shows the server-side Smart Card Or Other Certificate Properties dialog box for Windows 2000 Server and Windows Server 2003 IAS. This dialog box can be accessed from the Authentication tab of the profile properties of a remote access policy.

Figure 5-5. Certificate selection in Windows 2000 Server and Windows Server 2003 IAS.

The server-side Smart Card Or Other Certificate Properties dialog box contains the following elements:

• Certificate Issued To

  This option allows you to select the computer certificate to send to the wireless client during EAP-TLS authentication. The certificates in this list correspond to the list of certificates in the Local Computer certificate store. If a certificate is installed on the computer in the Local Computer certificate store but does not appear in this list, the certificate does not support the SChannel cryptographic provider and therefore cannot be used for EAP-TLS authentication.

• Friendly Name

  This field displays the friendly name for the certificate (it might not be configured by default). You can configure a friendly name for the certificate from the properties of the certificate by using the Certificates snap-in. Locate the computer certificates in Certificates (Local Computer)\Personal\Certificates. Right-click the certificate and select Properties. On the General tab, type a friendly name in the Friendly Name text box.

• Issuer

  This field displays the name of the CA that issued the certificate.

• Expiration Date

  This field displays the expiration date and time for the certificate.

To view all the fields of the certificate, use the Certificates snap-in.

Protected EAP (PEAP)

Windows XP (SP1 and later), Windows Server 2003, and Microsoft 802.1X Authentication Client support Protected EAP (PEAP) as a new EAP type. For more information, see the section on PEAP later in this chapter.

NOTE
The Security Dynamics ACE/Agent for Windows 2000 is an additional EAP type for Security Dynamics-based authentication methods for hard tokens, soft tokens, and smart cards. It is included on the Windows 2000 Server product CD-ROM in the Valueadd\3rdparty\Security\Sdti folder. This EAP type is not supported for wireless connections.

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:

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.

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 username. For Windows wireless clients, the user principal name (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.

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.

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.

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.

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.

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

   The RADIUS server sends a RADIUS Access-Challenge message containing an EAP-Request message with the EAP-Type set to EAP-TLS, which 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.

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.

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 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, the wireless AP and the wireless client are using the same keys for both the encryption and signing of unicast data.

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

10. Multicast/global encryption key to the wireless client.

    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 by using the per-client unicast session key, and portions of the message are signed with HMAC-MD5 by using the per-client unicast signing key.

After receiving the EAPOL-Key message, the wireless client uses the per-client unicast session and signing keys 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 are indicated, the wireless client begins the protocol configuration by using the wireless adapter (such as using Dynamic Host Configuration Protocol [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 5-7.

Figure 5-7. EAP-TLS and the IEEE 802.1X authentication process.

Configuring PEAP on the Wireless Client

Figure 5-8 shows the client-side Protected EAP Properties dialog box for Windows XP (SP 1 and later), Windows 2000 with Microsoft 802.1X Authentication Client, and Windows Server 2003. This dialog box can be accessed from the Authentication tab on the properties of a wireless network or wireless network adapter.

Figure 5-8. Client-side Protected EAP Properties dialog box.

From the Protected EAP Properties dialog box, you can view and configure the following:

• Validate Server Certificate

  This option, which is enabled by default, allows you to validate the computer certificate of the RADIUS server.

• Connect To These Servers

  This option allows you to specify by name the RADIUS servers that provide authentication and authorization for the connection. If you specify a server name, it must exactly match the server name in the Subject field of the RADIUS server s certificate. Use semicolons to specify multiple RADIUS server names.

• Trusted Root Certification Authorities

  This option allows you to select multiple trusted root CAs that the wireless client will accept to verify the certificate of the RADIUS server.

• Select Authentication Method

  This option allows you to select the specific PEAP type to use for authentication. Only Secured Password (EAP-MS CHAP v2) and Smart Card Or Other Certificate are selectable by default.

• Enable Fast Reconnect

  This option, which is disabled by default, specifies whether you want to enable or disable fast reconnect to reduce reauthentication times. For more information, see the PEAP Fast Reconnect section later in this chapter.

Configuring PEAP on the IAS Server

Figure 5-9 shows the server-side Protected EAP Properties dialog box for Windows 2000 with Microsoft 802.1X Authentication Client and Windows Server 2003 IAS. This dialog box can be accessed from the Authentication tab of the profile properties of a remote access policy.

Figure 5-9. Server-side Protected EAP Properties dialog box.

From the server-side Protected EAP Properties dialog box, you can view and configure the following:

• Certificate Issued

  This option allows you to select the computer certificate to send to the wireless client during the initial PEAP authentication. The certificates in this list correspond to the list of certificates in the Local Computer certificate store. If a certificate in the Local Computer certificate store does not appear in this list, the certificate does not support the SChannel cryptographic provider, so it cannot be used for authentication by the client.

• Friendly Name

  This field displays the friendly name for the certificate, which might not be configured by default. To configure a friendly name, obtain properties of the certificate by using the Certificates snap-in configured for the computer account (for the Local Computer certificate store). From the Details tab, click Edit Properties. On the General tab, type a friendly name in the Friendly Name text box.

• Issuer

  This field displays the name of the CA that issued the selected certificate.

• Expiration Date

  This field displays the expiration date and time for the selected certificate.

• Enable Fast Reconnect

  This option, which is disabled by default, specifies whether you want to use fast reconnect to reduce reauthentication times. For more information, see the PEAP Fast Reconnect section later in this chapter.

• EAP Types

  This option lists the EAP types selected for use with PEAP. No EAP types are listed by default, unless automatically configured using the Windows Server 2003 New Remote Access Policy Wizard. To add a PEAP EAP type, click Add. To configure the properties of a PEAP EAP type, select the EAP type and click Edit. To remove a PEAP EAP type, select the EAP type and click Remove.

PEAP-MS-CHAP v2 and PEAP-TLS are provided with Windows XP (SP1 and later) and Windows Server 2003 as part of enhanced EAP and IEEE 802.1X support.

Microsoft 802.1X Authentication Client provides client-side PEAP-MS-CHAP v2 and PEAP-TLS support for computers running Windows 2000. Microsoft 802.1X Authentication Client also updates IAS on Windows 2000 Server to support PEAP-MS-CHAP v2 and PEAP-TLS, allowing an IAS server to authenticate wireless clients running Windows XP (SP1 or later), Windows Server 2003, and Microsoft 802.1X Authentication Client.

PEAP-MS-CHAP v2

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. Microsoft originally designed MS-CHAP v2 as a PPP authentication protocol to provide better protection for dial-up and 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.

Like EAP-TLS, PEAP-MS-CHAP v2 has a client-side and server-side configuration.

Configuring PEAP-MS-CHAP v2 on the Wireless Client

Figure 5-10 shows the client-side EAP MSCHAPv2 Properties dialog box for Windows XP (SP 1 and later), Windows 2000 with Microsoft 802.1X Authentication Client, and Windows Server 2003. This dialog box can be accessed from the Authentication tab on the properties of a wireless network or wireless network adapter.

Figure 5-10. Client-side EAP MSCHAPv2 Properties dialog box.

From the EAP MSCHAPv2 Properties dialog box, you can configure the Automatically Use My Windows Logon Name And Password (And Domain If Any) check box. When enabled (which is the default), the current user-based Windows logon name and password is used for the MS-CHAP v2 authentication credentials.

Configuring PEAP-MS-CHAP v2 on the IAS Server

Figure 5-11 shows the server-side EAP MSCHAPv2 Properties dialog box for Windows 2000 with Microsoft 802.1X Authentication Client and Windows Server 2003 IAS. This dialog box can be accessed from the Authentication tab of the profile properties of a remote access policy. To view this dialog box, click EAP Methods, add the Protected EAP (PEAP) EAP provider (if needed), and then edit the Protected EAP (PEAP) EAP providers. From the Protected EAP Properties dialog box, click the Secured Password (EAP-MS-CHAP v2) EAP type and then click Edit.

Figure 5-11. Server-side EAP MSCHAPv2 Properties dialog box.

From the EAP MSCHAPv2 Properties dialog box, you can view and configure the following:

• Number Of Authentication Retries

  This option specifies the number of times that an PEAP-MS-CHAP v2-based authentication can be retried before rejecting the connection. The default is two retries.

• Allow Client To Change Password After It Has Expired

  This option, which is enabled by default, enables or disables the ability of the user at the wireless client to change their password using MS-CHAP v2 after the password has expired.

PEAP with MS-CHAP v2 Operation

The PEAP authentication process occurs in two parts: the first part uses EAP and the PEAP EAP type to create an encrypted TLS channel; the second part uses EAP and a different EAP type to authenticate network access. This section examines the PEAP with MS-CHAP v2 operation, using 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:

PEAP Part 1: Creating the 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 (username 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 by 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 keys for the TLS channel by using public key cryptography, not passwords. All subsequent EAP messages sent between the wireless client and the RADIUS server are encrypted.

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

PEAP Part 2: Authenticating 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, indicating that the wireless client response is 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 is 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).

• The RADIUS server has provided proof of knowledge of the correct password (the response to the wireless client challenge string).

• The entire exchange has been encrypted through the TLS channel created in the first part of the PEAP authentication.

PEAP-MS-CHAP v2 requires a certificate on each RADIUS server, 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 2000, Windows XP, and Windows Server 2003 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 clients do not include a corresponding root CA certificate, you must install the root CA certificate on each wireless client.

PEAP-TLS

PEAP-TLS is the EAP-TLS authentication method used after PEAP has created a secure channel. PEAP-TLS is slightly more secure than EAP-TLS alone because the entire EAP-TLS authentication exchange is protected with the PEAP secure channel.

You should not use both EAP-TLS and PEAP-TLS for the same kind of network access. Allowing both protected (PEAP) and unprotected (EAP) authentication traffic for the same type of network connection renders the protected authentication traffic susceptible to spoofing attacks. Therefore, do not allow EAP-TLS and PEAP-TLS authentication at the same time for the same type of network access (for example, for wireless). This is not an issue with MS-CHAP v2, which is available only as PEAP-MS-CHAP v2.

The configuration of PEAP-TLS for both the client and server side is the same as that for EAP-TLS.

PEAP with TLS Operation

This section examines PEAP with TLS operation by using a wireless client that attempts to authenticate to a wireless AP that uses a RADIUS server for authentication and authorization.

PEAP Part 1: Creating the TLS Channel

• PEAP Part 1 occurs in the same way as previously described for PEAP-MS-CHAP v2.

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

PEAP Part 2: Authenticating with TLS

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 (username or computer name) of the wireless client.

3. The RADIUS server sends an EAP-Request/Start TLS message.

4. The wireless client responds with an EAP-Response/TLS Client Hello message.

5. The RADIUS server sends an EAP-Request/TLS message that includes the RADIUS server s certificate chain.

6. The wireless client responds with an EAP-Response/TLS message that includes the wireless client s certificate chain.

7. The RADIUS server sends an EAP-Request/TLS message that includes the cipher suite and an indication that TLS authentication message exchanges are complete.

8. The wireless client responds with an EAP-Response/TLS message.

9. 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 private key corresponding to its sent certificate and validated the RADIUS server s certificate.

• The RADIUS server has provided proof of knowledge of the private key corresponding to its sent certificate and validated the wireless client s certificate.

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 fully perform PEAP Part 1 or Part 2. In this case, an EAP-Success message is sent almost immediately for a reauthentication attempt. This process, which is known as fast reconnect, minimizes the connection delay in wireless environments when a wireless client roams from one wireless AP to another.

Fast reconnect in Windows is enabled from the Protected EAP Properties dialog box, which can be accessed from the following locations:

• For Windows XP (SP1 and later) wireless clients, from the Authentication tab for the settings of a wireless network.

• For Microsoft 802.1X Authentication Client wireless clients, from the Authentication tab for the settings of a wireless network adapter.

• For Windows Server 2003 IAS, from the Authentication tab in the profile settings of a remote access policy.

Fast reconnect is disabled by default. You can enable fast reconnect for multiple wireless clients by using the Wireless Network (IEEE 802.11b) Policies computer configuration Group Policy setting, as described in Chapter 3, Windows Wireless Client Support.

Windows 2000 IAS with Microsoft 802.1X Authentication Client installed does not support fast reconnect.