Export (0) Print
Expand All

Understanding 802.1X authentication for wireless networks

Updated: January 21, 2005

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Understanding 802.1X authentication for wireless networks

802.1X is an IEEE standard for authenticated network access to wired Ethernet networks and wireless 802.11 networks. IEEE 802.1X enhances security and deployment by providing support for centralized user identification, authentication, dynamic key management, and accounting.

EAP, EAP-TLS, EAP-MS-CHAP v2, and PEAP authentication

The support that 802.1X provides for Extensible Authentication Protocol (EAP) types allows you to choose from several different authentication methods for wireless clients and servers.

EAP

802.1X uses EAP for message exchange during the authentication process. With EAP, an arbitrary authentication method, such as certificates, smart cards, or credentials, is used. EAP allows for an open-ended conversation between an EAP client (such as a wireless computer) and an EAP server (such as an Internet Authentication Service (IAS) server). The conversation consists of requests for authentication information by the server and responses by the client. In order for authentication to be successful, the client and the server must use the same authentication method.

EAP-TLS

EAP-Transport Layer Security (TLS) is an EAP type that is used in certificate-based security environments, and it provides the strongest authentication and key determination method. EAP-TLS provides mutual authentication, negotiation of the encryption method, and encrypted key determination between the client and the authenticating server. If you want to use certificates or smart cards for user and client computer authentication, you must use EAP-TLS or, for enhanced security, Protected EAP (PEAP) with EAP-TLS.

EAP-MS-CHAP v2

EAP-Microsoft Challenge Handshake Authentication Protocol version 2 (MS-CHAP v2) is a mutual authentication method that supports password-based user or computer authentication. During the EAP-MS-CHAP v2 authentication process, both the server and client must prove that they have knowledge of the user's password in order for authentication to succeed. With EAP-MS-CHAP v2, after successful authentication, users can change their passwords, and they are notified when their passwords expire.

Note

  • EAP-MS-CHAP v2 is available only with PEAP.

PEAP

PEAP is an authentication method that uses TLS to enhance the security of other EAP authentication protocols. PEAP provides the following benefits: an encryption channel to protect EAP methods running within PEAP, dynamic keying material generated from TLS, fast reconnect (the ability to reconnect to a wireless access point by using cached session keys, which allows for quick roaming between wireless access points), and server authentication that can be used to protect against the deployment of unauthorized wireless access points.

PEAP authentication process

The PEAP authentication process consists of two main phases:

  1. Server authentication and the creation of a TLS encryption channel. The server identifies itself to a client by providing certificate information to the client. After the client verifies the identity of the server, a master secret is generated. The session keys that are derived from the master secret are then used to create a TLS encryption channel that encrypts all subsequent communication between the server and the wireless client.

  2. EAP conversation and user and client computer authentication. A complete EAP conversation between the client and the server is encapsulated within the TLS encryption channel. With PEAP, you can use any one of several EAP authentication methods, such as passwords, smart cards, and certificates, to authenticate the user and client computer.

The session keys that are generated during the PEAP authentication process provide keying material for the Wired Equivalent Privacy (WEP) encryption keys that encrypt the data that is sent between wireless clients and wireless access points.

You can use PEAP with any of the following authentication methods for wireless authentication:

  • EAP-TLS, which uses certificates for server authentication and either certificates or smart cards for user and client computer authentication.

  • EAP-MS-CHAP v2, which uses certificates for server authentication and credentials for user authentication.

  • Non-Microsoft EAP authentication methods.

Notes

  • PEAP is not supported for use with EAP-MD5.

  • PEAP is available as an authentication method for 802.11 wireless clients, but it is not supported for virtual private network (VPN) clients or other remote access clients. Therefore, you can configure PEAP as the authentication method for a remote access policy only when you are using Internet Authentication Service (IAS).

PEAP support for fast reconnect

When clients connect to an 802.11 wireless network, the authenticated session has a set expiration interval that the network administrator determines to limit the duration of authenticated sessions. To avoid the notices that require authenticated clients to provide their credentials to reauthenticate and resume a session, you can enable the fast reconnect option.

PEAP supports fast reconnect, which allows roaming users to maintain continuous wireless network connectivity when traveling between different wireless access points on the same network, as long as each wireless access point is configured as a client of the same IAS (RADIUS) server. In addition, fast reconnect must be enabled on both the wireless client and the RADIUS server.

After the initial PEAP authentication succeeds, users are not prompted to supply their credentials (if PEAP with EAP-MS-CHAP v2 is used for authentication) or their personal identification number (PIN) (if PEAP with smart cards is used for authentication) each time they travel to a new wireless access point. Instead, when PEAP fast reconnect is enabled, after the initial PEAP authentication succeeds, the client and the server cache TLS session keys. When users associate with a new wireless access point, the client and the server use the cached keys to reauthenticate each other until the cache has expired. Because the keys are cached, the RADIUS server can quickly determine that the client connection is a reconnect. This reduces the delay in time between an authentication request by a client and the response by the RADIUS server. It also resource requirements for the client and the server.

If the original RADIUS server is not used, full authentication must occur, and the user is again prompted for credentials or a PIN. This can occur in the following situations:

  • The user associates with a new wireless access point that is configured as a client of a new RADIUS server.

  • The user associates with the same wireless access point, but the wireless access point forwards the authentication request to a new RADIUS server.

In both situations, after the initial authentication with the new RADIUS server succeeds, the client caches the new TLS session keys. Clients can cache TLS session keys for multiple RADIUS servers.

For more information, see EAP, MS-CHAP version 2, and PEAP.

For more information about configuring the session time-out for wireless remote access policies, see Introduction to remote access policies, Configure Remote Access Policies, and Elements of a remote access policy.

Security and deployment considerations

When choosing an authentication method, balance the level of security that you require with the effort that you want to devote to deployment. For the highest level of security, choose PEAP with certificates (EAP-TLS). For the greatest ease of deployment, choose PEAP with passwords (EAP-MS-CHAP v2).

Although both PEAP with EAP-TLS and EAP-TLS alone provide strong security through the use of certificates for server authentication and either certificates or smart cards for client computer and user authentication, when PEAP with EAP-TLS is used, client certificate information is encrypted. PEAP with EAP-MS-CHAP v2 requires the least effort to deploy because client authentication is password-based, so certificates or smart cards do not need to be installed on clients. Because PEAP creates an end-to-end encrypted channel before EAP-MS-CHAP v2 authentication occurs, the authentication exchange reduces the risk of offline dictionary attacks.

For information about certificate requirements for 802.1X authentication methods, see Network access authentication and certificates. For information about deploying smart cards, see Checklist: Deploying smart cards for logging on to Windows.

Important

  • When you deploy both PEAP and EAP unprotected by PEAP, do not use the same EAP authentication type with and without PEAP. For example, if you deploy PEAP with EAP-TLS (PEAP-EAP-TLS), do not also deploy EAP-TLS without PEAP. Deploying authentication methods with the same type--one with and the other without the protection of PEAP--creates a security vulnerability.

  • Certificate Templates provide a new version 2 certificate template, named Workstation Authentication. This certificate template, which can be configured for auto-enrollment, is available for enterprise certification authorities (CAs) on computers running Windows Server 2003, Enterprise Edition; Windows Server 2003, Datacenter Edition; or the 64-bit versions of the Windows Server 2003 family. Certificates based on this template allow client computers to authenticate their identity to servers. You should use this certificate template if you are both using certificate-based authentication for wireless clients running Windows XP and providing an enterprise CA on a computer running Windows Server 2003, Enterprise Edition; Windows Server 2003, Datacenter Edition; or the 64-bit versions of Windows Server 2003 family. If you use the Computer certificate template in this case, client authentication will fail. For more information, see Certificate Templates and Manage Certificate Templates for an Enterprise Certification Authority.

How 802.1X works on 802.11 wireless networks

802.1X implements port-based network access control. Port-based network access control uses the physical characteristics of a switched local area network (LAN) infrastructure to authenticate computing devices that are attached to a LAN port and to prevent access to that port when the authentication process fails.

During a port-based network access control interaction, a LAN port adopts one of two roles: authenticator or supplicant. In the role of authenticator, a LAN port enforces authentication before it allows user access to the services that can be accessed through that port. In the role of supplicant, a LAN port requests access to the services that can be accessed through the authenticator's port. An authentication server, which can either be a separate entity or co-located with the authenticator, checks the supplicant's credentials on behalf of the authenticator. The authentication server then responds to the authenticator, indicating whether the supplicant is authorized to access the authenticator's services.

The authenticator’s port-based network access control defines two logical data paths to the LAN through one physical LAN port. The first data path, the uncontrolled port, allows data exchange between the authenticator and a computing device on the LAN, regardless of the authentication state of that device. This is the path that EAPOL (EAP over LAN) messages will take. The second data path, the controlled port, allows data exchange between an authenticated LAN user and the authenticator. This is the path that all other network traffic will take, after the computing device is authenticated.

802.1X and IAS

To support authentication, authorization, and accounting for wireless network connections, you can use 802.1X with IAS. IAS is the Microsoft implementation of a Remote Authentication Dial-in User Service (RADIUS) server and proxy server. When RADIUS is implemented, a wireless access point prevents data traffic from being forwarded to a wired network or to another wireless client without a valid authentication key. The process of obtaining a valid authentication key is as follows:

  1. When a wireless client comes within range of a wireless access point, the wireless access point challenges the client.

  2. The wireless client sends its identity to the wireless access point, which forwards this information to a RADIUS server.

  3. The RADIUS server requests the credentials of the wireless client to verify the identity of the client. As part of this request, the RADIUS server specifies the type of credentials that are required.

  4. The wireless client sends its credentials to the RADIUS server.

  5. The RADIUS server verifies the credentials of the wireless client. If the credentials are valid, the RADIUS server sends an encrypted authentication key to the wireless access point.

  6. The wireless access point uses this authentication key to securely transmit per-station unicast session and multicast authentication keys to the wireless client.

For information about configuring IAS for wireless access authentication, see Checklist: Configuring the IAS server and wireless access points for wireless access and Wireless access.

For information about how to configure 802.1X settings for clients, see Define 802.1X authentication for wireless networks on a client computer.

For general information about security for wireless networks, see Security information for wireless networks.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft