Extensible Authentication Protocol (EAP) for network access
The Extensible Authentication Protocol (EAP) is an authentication framework that allows for the use of different authentication methods for secure network access technologies. Examples of these technologies include wireless access using IEEE 802.1X, wired access using IEEE 802.1X, and Point-to-Point Protocol (PPP) connections like Virtual Private Networking (VPN). EAP isn't a specific authentication method like MS-CHAP v2, but rather a framework that enables networking vendors to develop and install new authentication methods, known as EAP methods, on the access client and authentication server. The EAP framework is originally defined by RFC 3748 and extended by various other RFCs and standards.
Authentication methods
EAP authentication methods that are used within tunneled EAP methods are commonly known as inner methods or EAP types. Methods that are set up as inner methods have the same configuration settings as they would when used as an outer method. This article contains configuration information specific to the following authentication methods in EAP.
EAP-Transport Layer Security (EAP-TLS): Standards-based EAP method that uses TLS with certificates for mutual authentication. Appears as Smart Card or other Certificate (EAP-TLS) in Windows. EAP-TLS can be deployed as an inner method for another EAP method or as a standalone EAP method.
Tip
EAP methods that use EAP-TLS, being certificate-based, generally offer the highest level of security. For example, EAP-TLS is the only allowed EAP method for WPA3-Enterprise 192-bit mode.
EAP-Microsoft Challenge Handshake Authentication Protocol version 2 (EAP-MSCHAP v2): Microsoft-defined EAP method that encapsulates the MSCHAP v2 authentication protocol, which uses username and password, for authentication. Appears as Secure password (EAP-MSCHAP v2) in Windows. EAP-MSCHAPv2 can be used as a standalone method for VPN, but only as an inner method for wired/wireless.
Warning
MSCHAPv2-based connections are subject to similar attacks as for NTLMv1. Windows 11 Enterprise, version 22H2 (build 22621) enables Windows Defender Credential Guard which may cause issues with MSCHAPv2-based connections.
Protected EAP (PEAP): Microsoft-defined EAP method that encapsulates EAP within a TLS tunnel. The TLS tunnel secures the inner EAP method, which could be unprotected otherwise. Windows supports EAP-TLS and EAP-MSCHAP v2 as inner methods.
EAP-Tunneled Transport Layer Security (EAP-TTLS): Described by RFC 5281, encapsulates a TLS session that performs mutual authentication using another inner authentication mechanism. This inner method can be either an EAP protocol, such as EAP-MSCHAP v2, or a non-EAP protocol, such as Password Authentication Protocol (PAP). In Windows Server 2012, the inclusion of EAP-TTLS only provides support on the client-side (in Windows 8). NPS doesn't support EAP-TTLS at this time. The client support enables interoperation with commonly deployed RADIUS servers that support EAP-TTLS.
EAP-Subscriber Identity Module (EAP-SIM), EAP-Authentication and Key Agreement (EAP-AKA), and EAP-AKA Prime (EAP-AKA'): Described by various RFCs, enables authentication by using SIM cards, and is implemented when a customer purchases a wireless broadband service plan from a mobile network operator. As part of the plan, the customer commonly receives a wireless profile that is preconfigured for SIM authentication.
Tunnel EAP (TEAP): Described by RFC 7170, tunneled EAP method that establishes a secure TLS tunnel and executes other EAP methods inside that tunnel. Supports EAP chaining - authenticating the machine and user within one authentication session. In Windows Server 2022, the inclusion of TEAP only provides support for the client-side - Windows 10, version 2004 (build 19041). NPS doesn't support TEAP at this time. The client support enables interoperation with commonly deployed RADIUS servers that support TEAP. Windows supports EAP-TLS and EAP-MSCHAP v2 as inner methods.
The following table lists some common EAP methods and their IANA assigned method Type numbers.
| EAP method | IANA assigned Type number | Native Windows support |
|---|---|---|
| MD5-Challenge (EAP-MD5) | 4 | ❌ |
| One-Time Password (EAP-OTP) | 5 | ❌ |
| Generic Token Card (EAP-GTC) | 6 | ❌ |
| EAP-TLS | 13 | ✅ |
| EAP-SIM | 18 | ✅ |
| EAP-TTLS | 21 | ✅ |
| EAP-AKA | 23 | ✅ |
| PEAP | 25 | ✅ |
| EAP-MSCHAP v2 | 26 | ✅ |
| Protected One-Time Password (EAP-POTP) | 32 | ❌ |
| EAP-FAST | 43 | ❌ |
| Pre-Shared Key (EAP-PSK) | 47 | ❌ |
| EAP-IKEv2 | 49 | ❌ |
| EAP-AKA' | 50 | ✅ |
| EAP-EKE | 53 | ❌ |
| TEAP | 55 | ✅ |
| EAP-NOOB | 56 | ❌ |
Configuring EAP properties
You can access the EAP properties for 802.1X authenticated wired and wireless access in the following ways:
- Configuring the Wired Network (IEEE 802.3) Policies and Wireless Network (IEEE 802.11) Policies extensions in Group Policy.
- Computer Configuration > Policies > Windows Settings > Security Settings
- Using Mobile Device Management (MDM) software, such as Intune (Wi-Fi/Wired)
- Manually configuring wired or wireless connections on client computers.
You can access the EAP properties for virtual private network (VPN) connections in the following ways:
- Using Mobile Device Management (MDM) software, such as Intune
- Manually configuring VPN connections on client computers.
- Using Connection Manager Administration Kit (CMAK) to configure VPN connections.
For more information on configuring EAP properties, see Configure EAP profiles and settings in Windows.
XML profiles for EAP
The profiles used for different connections types are XML files that contain the configuration options for that connection. Each different connection type follows a specific schema:
However, when configured to use EAP, each profile schema has a child element EapHostConfig element.
- Wired/Wireless:
EapHostConfigis a child element of the EAPConfig element. MSM > security (Wired/Wireless) > OneX > EAPConfig - VPN:
EapHostConfigis a child element of NativeProfile > Authentication > Eap > Configuration
This configuration syntax is defined in the Group Policy: Wireless/Wired Protocol Extension specification.
Note
The various configuration GUIs don't always show every technically possible option. For example, Windows Server 2019 and earlier are unable to configure TEAP in UI. However, it is often possible to import an existing XML profile that has previously been configured.
The remainder of the article is intended to provide a mapping between the EAP specific portions of the Group Policy/Control Panel UI and the XML configuration options, as well as providing a description of the setting.
More information about configuring XML profiles can be found in XML Profiles. An example of using an XML profile containing EAP settings can be found in Provision a Wi-Fi profile via a website.
Security settings
The following table explains the configurable security settings for a profile that uses 802.1X. These settings map to OneX.
| Setting | XML element | Description |
|---|---|---|
| Select a network authentication method: | EAPConfig | Allows you to select the EAP method to use for authentication. See Authentication method configuration settings and Cellular authentication configuration settings |
| Properties | Opens the properties dialog for the selected EAP method. | |
| Authentication Mode | authMode | Specifies the type of credentials used for authentication. The following values are supported: 1. User or computer authentication 2. Computer authentication 3. User authentication 4. Guest authentication "Computer", in this context, means "Machine" in other references. machineOrUser is the default in Windows. |
| Max Authentication Failures | maxAuthFailures | Specifies the maximum number of authentication failures allowed for a set of credentials, defaulting to 1. |
| Cache user information for subsequent connections to this network | cacheUserData | Specifies whether the user's credentials should be cached for subsequent connections to the same network, defaulting to true. |
Advanced security settings > IEEE 802.1X
If Enforce advanced 802.1X settings is checked, all of the following settings will be configured. If it's unchecked, default settings apply. In XML, all elements are optional, with the default values used if they aren't present.
| Setting | XML element | Description |
|---|---|---|
| Max Eapol-Start Msgs | maxStart | Specifies the maximum number of EAPOL-Start messages that can be sent to the authenticator (RADIUS server) before the supplicant (Windows client) assumes there's no authenticator present, defaulting to 3. |
| Start Period (seconds) | startPeriod | Specifies the time period (in seconds) to wait before an EAPOL-Start message is sent to start the 802.1X authentication process, defaulting to 5. |
| Held Period (seconds) | heldPeriod | Specifies the time period (in seconds) to wait after a failed authentication attempt to reattempt authentication, defaulting to 1. |
| Auth Period (seconds) | authPeriod | Specifies the time period (in seconds) to wait for a response from the authenticator (RADIUS server) before assuming there's no authenticator present, defaulting to 18. |
| Eapol-Start Message | supplicantMode | Specifies the method of transmission used for EAPOL-Start messages. The following values are supported: 1. Do not transmit ( inhibitTransmission)2. Transmit ( includeLearning)3. Transmit per IEEE 802.1X ( compliant)"Computer", in this context, means "Machine" in other references. compliant is the default in Windows, and is the only valid option for wireless profiles. |
Advanced security settings > Single Sign On
The following table explains the settings for Single Sign On (SSO), formerly known as Pre-Logon Access Provider (PLAP).
| Setting | XML element | Description |
|---|---|---|
| Enable Single Sign On for this network | singleSignOn | Specifies whether SSO is enabled for this network, defaulting to false. Don't use singleSignOn in a profile if the network doesn't require it. |
| Perform immediately before User Perform immediately after User |
type | Specifies when SSO should be performed - either before or after the user logs on. |
| Max delay for connectivity(seconds) | maxDelay | Specifies the maximum delay (in seconds) before the SSO attempt fails, defaulting to 10. |
| Allow additional dialogs to be displayed during Single Sign On | allowAdditionalDialogs | Specified whether to allow EAP dialogs to be displayed during SSO, defaulting to false. |
| This network uses different VLAN for authentication with machine and user credentials | userBasedVirtualLan | Specifies whether the virtual LAN (VLAN) used by the device changes based on the user's credentials, defaulting to false. |
Authentication method configuration settings
Caution
If a Network Access Server is configured to allow the same type of authentication method for a tunneled EAP method (e.g. PEAP) and a non-tunneled EAP method (e.g. EAP-MSCHAP v2), there is a potential security vulnerability. When you deploy both a tunneled EAP method and EAP (which isn't protected), don't use the same authentication type. For example, if you deploy PEAP-TLS, don't also deploy EAP-TLS. This is because if you require the protection of the tunnel, it serves no purpose to permit the method to be executed outside of the tunnel as well.
The following table explains the configurable settings for each authentication method.
The EAP-TLS settings in the UI map to EapTlsConnectionPropertiesV1, which is extended by EapTlsConnectionPropertiesV2 and EapTlsConnectionPropertiesV3.
| Setting | XML element | Description |
|---|---|---|
| Use my smart card | CredentialsSource > SmartCard | Specifies that clients making authentication requests must present a smart card certificate for network authentication. |
| Use a certificate on this computer | CredentialsSource > CertificateStore | Specifies that authenticating clients must use a certificate located in the Current User or Local Computer certificate stores. |
| Use simple certificate selection (Recommended) | SimpleCertSelection | Specifies whether Windows will automatically select a certificate for authentication without user interaction (if possible) or if Windows will show a dropdown for the user to select a certificate. |
| Advanced | Opens the Configure Certificate Selection dialog box. | |
| Server validation options | ||
| Use a different user name for the connection | DifferentUsername | Specifies whether to use a user name for authentication that is different from the user name in the certificate. |
The following lists the configuration settings for Configure Certificate Selection. These settings define the criteria a client uses to select the appropriate certificate for authentication. This UI maps to TLSExtensions > FilteringInfo.
| Setting | XML element | Description |
|---|---|---|
| Certificate Issuer | CAHashList Enabled="true" |
Specifies whether Certificate Issuer filtering is enabled. If both Certificate Issuer and Extended Key Usage (EKU) are enabled, only those certificates that satisfy both conditions are considered valid for authenticating the client to the server. |
| Root Certification Authorities | IssuerHash | Lists the names of all of the issuers for which corresponding certification authority (CA) certificates are present in the Trusted Root Certification Authorities or Intermediate Certification Authorities certificate store of local computer account. This includes: 1. All the root certification authorities and intermediate certification authorities. In XML, this is the SHA-1 thumbprint (hash) of the certificate. |
| Extended Key Usage (EKU) | Allows you to select All Purpose, Client Authentication, AnyPurpose, or any combination of these. Specifies that when a combination is selected, all the certificates satisfying at least one of the three conditions are considered valid certificates for authenticating the client to the server. If EKU filtering is enabled, one of the choices must be selected, otherwise the Extended Key Usage (EKU) checkbox will get unchecked. | |
| All Purpose | AllPurposeEnabled | When selected, this item specifies that certificates having the All Purpose EKU are considered valid certificates for authenticating the client to the server. The Object Identifier (OID) for All Purpose is 0 or empty. |
| Client Authentication | ClientAuthEKUList Enabled="true" (> EKUMapInList > EKUName) |
Specifies that certificates having the Client Authentication EKU, and the specified list of EKUs are considered valid certificates for authenticating the client to the server. The Object Identifier (OID) for Client Authentication is 1.3.6.1.5.5.7.3.2. |
| AnyPurpose | AnyPurposeEKUList Enabled="true" (> EKUMapInList > EKUName) |
Specifies that all certificates having AnyPurpose EKU and the specified list of EKUs are considered valid certificates for authenticating the client to the server. The Object Identifier (OID) for AnyPurpose is 1.3.6.1.4.1.311.10.12.1. |
| Add | EKUMapping > EKUMap > EKUName/EKUOID | Opens the Select EKUs dialog box, which enables you to add standard, custom, or vendor-specific EKUs to the Client Authentication or AnyPurpose list. Selecting Add or Edit within the Select EKUs dialog box will open the Add/Edit EKU dialog box, which provides two options: For example, entering |
| Edit | Enables you to edit custom EKUs that you have added. The default, predefined EKUs can't be edited. | |
| Remove | Removes the selected EKU from the Client Authentication or AnyPurpose list. |
Server validation
Many EAP methods include an option for the client to validate the server's certificate. If the server certificate isn't validated, the client can't be sure that it's communicating with the correct server. This exposes the client to security risks, including the possibility that the client might unknowingly connect to a rogue network.
Note
Windows requires the server certificate have the Server Authentication EKU. The object identifier (OID) for this EKU is 1.3.6.1.5.5.7.3.1.
The following table lists the server validation options applicable to each EAP method. Windows 11 updated the server validation logic to be more consistent (see Updated server certificate validation behavior in Windows 11). Should they conflict, the descriptions in the following table describe the behavior for Windows 10 and earlier.
| Setting | XML element | Description |
|---|---|---|
| Verify the server's identity by validating the certificate | EAP-TLS: PerformServerValidation PEAP: PerformServerValidation |
This item specifies that the client verifies that server certificates presented to the client computer have the correct signatures, haven't expired, and were issued by a trusted root certification authority (CA). Disabling this check box causes client computers to be unable to verify the identity of your servers during the authentication process. If server authentication does not occur, users are exposed to severe security risks, including the possibility that users might unknowingly connect to a rogue network. |
| Connect to these servers | EAP-TLS: ServerValidation > ServerNames PEAP: ServerValidation > ServerNames EAP-TTLS: ServerValidation > ServerNames TEAP: ServerValidation > ServerNames |
Allows you to specify the name for Remote Authentication Dial-In User Service (RADIUS) servers that provide network authentication and authorization. You must type the name exactly as it appears in the subject field of each RADIUS server certificate or use regular expressions (regex) to specify the server name. The complete syntax of the regular expression can be used to specify the server name, but to differentiate a regular expression with the literal string, you must use at least one You can also include a If no RADIUS servers are specified, the client only verifies that the RADIUS server certificate was issued by a trusted root CA. |
| Trusted Root Certification Authorities | EAP-TLS: ServerValidation > TrustedRootCA PEAP: ServerValidation > TrustedRootCA EAP-TTLS: ServerValidation > TrustedRootCAHashes TEAP: ServerValidation > TrustedRootCAHashes |
Lists the trusted root certification authorities. The list is built from the trusted root CAs that are installed in the computer and in the user certificate stores. You can specify which trusted root CA certificates supplicants use to determine whether they trust your servers, such as your server running Network Policy Server (NPS) or your provisioning server. If no trusted root CAs are selected, the 802.1X client verifies that the computer certificate of the RADIUS server was issued by an installed trusted root CA. If one or multiple trusted root CAs are selected, the 802.1X client verifies that the computer certificate of the RADIUS server was issued by a selected trusted root CA. If no trusted root CAs are selected, the client verifies that the RADIUS server certificate was issued by any trusted root CA. If you have a public key infrastructure (PKI) on your network, and you use your CA to issue certificates to your RADIUS servers, your CA certificate is automatically added to the list of trusted root CAs. You can also purchase a CA certificate from a non-Microsoft vendor. Some non-Microsoft trusted root CAs provide software with your purchased certificate that automatically installs the purchased certificate into the Trusted Root Certification Authorities certificate store. In this case, the trusted root CA automatically appears in the list of trusted root CAs. Don't specify a trusted root CA certificate that isn't already listed in client computers' Trusted Root Certification Authorities certificate stores for Current User and Local Computer. If you designate a certificate that isn't installed on client computers, authentication will fail. In XML, this is the SHA-1 thumbprint (hash) of the certificate (or SHA-256 for TEAP). |
Server validation user prompt
The following table lists the server validation user prompt options applicable to each EAP method. These options would be used, in the case of an untrusted server certificate, to either:
- immediately fail the connection, or
- allow the user to manually accept or reject the connection.
| Setting | XML element |
|---|---|
| Don't prompt user to authorize new servers or trusted certification authorities | ServerValidation > DisableUserPromptForServerValidation |
Prevents the user from being prompted to trust a server certificate if that certificate is incorrectly configured, isn't already trusted, or both (if enabled). To simplify the user experience and prevent users from mistakenly trusting a server deployed by an attacker, it's recommended that you select this checkbox.
Cellular authentication configuration settings
The following lists the configuration settings for EAP-SIM, EPA-AKA, and EPA-AKA' respectively.
EAP-SIM is defined in RFC 4186. EAP Subscriber Identity Module (SIM) is used for authentication and session key distribution using the 2nd generation mobile network Global System for Mobile Communications (GSM) Subscriber Identity Module (SIM).
The EAP-SIM settings in the UI map to EapSimConnectionPropertiesV1.
| Item | XML element | Description |
|---|---|---|
| Use strong cipher keys | UseStrongCipherKeys | Specifies that if selected, the profile uses strong encryption. |
| Don't reveal real identity to server when pseudonym identity is available | DontRevealPermanentID | When enabled, forces the client to fail the authentication if server requests for permanent identity though the client have a pseudonym identity with it. Pseudonym identities are used for identity privacy so that the actual or permanent identity of a user isn't revealed during authentication. |
| ProviderName | Only available in XML, a string that indicates the provider name that is allowed for authentication. | |
| Enable usage of realms | Realm=true |
Provides a place to type the realm name. If this field is left blank with Enable usage of realms selected, the realm is derived from the International Mobile Subscriber Identity (IMSI) using the realm 3gpp.org, as described in the 3rd Generation Partnership Project (3GPP) standard 23.003 V6.8.0. |
| Specify a realm | Realm | Provides a place to type a realm name. If Enable usage of realms is enabled, this string is used. If this field is empty, the derived realm is used. |
WPA3-Enterprise 192-bit mode
WPA3-Enterprise 192-bit mode is a special mode for WPA3-Enterprise that enforces certain high security requirements on the wireless connection to provide a minimum of 192 bits of security. These requirements align with the Commercial National Security Algorithm (CNSA) Suite, CNSSP 15, which is a set of cryptographic algorithms that is approved to protect classified and top secret information by the United States National Security Agency (NSA). 192-bit mode can sometimes be referred to as "Suite B mode," which is a reference to the NSA Suite B Cryptography specification, which was replaced by CNSA in 2016.
Both WPA3-Enterprise and WPA3-Enterprise 192-bit mode are available starting in Windows 10, version 2004 (build 19041) and Windows Server 2022. However, WPA3-Enterprise was singled out as a separate authentication algorithm in Windows 11. In XML, this is specified in the authEncryption element.
The following table lists the algorithms required by the CNSA Suite.
| Algorithm | Description | Parameters |
|---|---|---|
| Advanced Encryption Standard (AES) | Symmetric block cipher used for encryption | 256-bit key (AES-256) |
| Elliptic Curve Diffie-Hellman (ECDH) Key Exchange | Asymmetric algorithm used to establish a shared secret (key) | 384-bit prime modulus curve (P-384) |
| Elliptic Curve Digital Signature Algorithm (ECDSA) | Asymmetric algorithm used for digital signatures | 384-bit prime modulus curve (P-384) |
| Secure Hash Algorithm (SHA) | Cryptographic hash function | SHA-384 |
| Diffie-Hellman (DH) Key Exchange | Asymmetric algorithm used to establish a shared secret (key) | 3072-bit modulus |
| Rivest-Shamir-Adleman (RSA) | Asymmetric algorithm used for digital signatures or key-establishment | 3072-bit modulus |
Aligning with CNSA, WPA3-Enterprise 192-bit mode requires that EAP-TLS is used with the following cipher suites with restrictions:
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384- ECDHE and ECDSA using the 384-bit prime modulus curve P-384
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384/TLS_DHE_RSA_AES_256_GCM_SHA384- ECDHE using the 384-bit prime modulus curve P-384
- RSA >= 3072-bit modulus
Note
P-384 is also known as secp384r1 or nistp384. Other elliptic curves, such as P-521 are not permitted.
SHA-384 is in the SHA-2 family of hash functions. Other algorithms and variants, such as SHA-512 or SHA3-384, are not permitted.
Windows supports only the TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 and TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 cipher suites for WPA3-Enterprise 192-bit mode. The TLS_DHE_RSA_AES_256_GCM_SHA384 cipher suite isn't supported.
TLS 1.3 uses new simplified TLS suites, of which only TLS_AES_256_GCM_SHA384 is compatible with WPA3-Enterprise 192-bit mode. As TLS 1.3 requires (EC)DHE and allows ECDSA or RSA certificates, along with the AES-256 AEAD and SHA384 hash, TLS_AES_256_GCM_SHA384 is equivalent to TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 and TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. However, RFC 8446 requires that TLS 1.3-compliant applications support P-256, which is forbidden by CNSA. Therefore, WPA3-Enterprise 192-bit mode can't be fully compliant with TLS 1.3. However, there are no known interoperability issues with TLS 1.3 and WPA3-Enterprise 192-bit mode.
To configure a network for WPA3-Enterprise 192-bit mode, Windows requires EAP-TLS be used with a certificate that meets the requirements described previously.