Edit

Extensible Authentication Protocol (EAP) for network access

  • Article

Applies to: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012, Windows 11, Windows 10, Windows 8.1

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: EapHostConfig is a child element of the EAPConfig element. MSM > security (Wired/Wireless) > OneX > EAPConfig
  • VPN: EapHostConfig is 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.
2. Contains only those issuers for which there are corresponding valid certificates that are present on the computer (for example, certificates that aren't expired or not revoked).
3. The final list of certificates that are allowed for authentication contains only those certificates that were issued by any of the issuers selected in this list.

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:
1. Enter the name of the EKU - Provides a place to type the name of the custom EKU.
2. Enter the EKU OID - Provides a place to type the OID for the EKU. Only numeric digits, separators, and . are allowed. Wild cards are permitted, in which case all of the child OIDs in the hierarchy are allowed.

For example, entering 1.3.6.1.4.1.311.* allows for 1.3.6.1.4.1.311.42 and 1.3.6.1.4.1.311.42.2.1.
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 * in the string specified. For example, you can specify nps.*\.example\.com to specify the RADIUS server nps1.example.com or nps2.example.com.

You can also include a ; to separate multiple servers.

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.

Additional resources