Passwords vs Certificates for 802.1X

Passwords vs Certificates – TL;DR

• Understand your use-cases. Select the right authentication method (802.1X or MPSK) that has the right balance between security vs client and user capabilities.
• Certificates are always recommended especially as a long-term solution, current onboarding mechanisms provide good way to control cert provisioning at scale for all your client population.
• Use password based 802.1X authentication only as a stop-gap solution or as a phased approach, while migrating to certificate based authentication.
• For BYOD scenarios, do not use 802.1X, but leverage other more user-friendly BYOD methods such as Multi-PSK with Self Onboarding.

Overview

802.1X is an IEEE standard that provides framework for controlling access to wired or wireless network using secure authentication.

However 802.1X is just a transport for protocol called EAP (Extensible Authentication Protocol). EAP determines a way a client would authenticate (using a certificate, credentials, tokens etc) and a way how these credentials will be exchanged. This is called EAP method. There are many EAP methods available today, but the most common methods used in modern wired and wireless networks are:

• EAP-TLS
  • EAP-TLS provides mutual authentication by leveraging certificates and cryptography. It uses certificates on both the client side, as well as the server side for authentication (client needs to trust server certificate, server needs to trust client certificate). This is the most secure access method available today:
• PEAP/MSCHAPv2
  • PEAP-MSCHAPv2 uses username/password on the client side, and server certificate on the server side (client needs to trust server certificate, server validates username/password combination against an Active Directory).
  • Due to the password hashing mechanism used (NTLMv1), PEAP/MSCHAPv2 is only supported in combination with local RADIUS server and on-premises based Active Directory. It is not supported by any of the cloud based Identity Providers (including Azure AD) or any other Identity sources. Also NTLMv1 has been considered vulnerable since 1997, Microsoft recommends moving away from it for quite a while.
  • Note: PEAP/MSCHAPv2 is not supported by Mist Access Assurance.
• EAP-TTLS/PAP
  • EAP-TTLS/PAP also uses username/password on the client side, and server certificate on the server side.
  • After establishing a secure TLS tunnel, credentials are passed using PAP protocol inside an encrypted tunnel.
  • Unlike many articles that suggest PAP is less secure than MSCHAPv2, the opposite is true. Please refer to the following study and enclosed references for more details.

Password Based Authentication

Since the inception of 802.1X many many years ago, one of the most popular authentication mechanisms was a use of credentials, or a username & password combination. However, there are few aspects that are setting a new trend of moving away from popular PEAP-MSCHAPv2 methods towards certificate-based EAP-TLS methods:

• Windows 11 with the recent edition of Windows 11 Enterprise and Windows 11 Education editions disables any form of password based authentication by enabling Credential Guard by default. We can expect more OS vendors to follow this trend.
• Most Identity Providers security practices dictate the use of MFA (Multi-Factor Authentication) when using password based authentication. Using MFA however is not viable in 802.1X scenarios, especially in wireless networks, i.e. when you need to roam between APs and do a full-auth with password plus generated token. Also most client supplicants will timeout by the time a user will get to their 2FA code. This makes traditional PEAP/MSCHAPv2 or TTLS/PAP password authentication a legacy authentication method using single-factor authentication, and only good as a stop-gap before moving to a certificate based authentication.
• Cloud-based Identity Providers (e.g. Azure AD, Okta, Google Workspace, Ping Id etc) do not support support NTLM, which is a requirement for PEAP-MSCHAPv2, so your only real option for 802.1X authentication with cloud IdP is EAP-TTLS/PAP.
• Password re-use issue (when end-users tend to use the same password across all their accounts) might result in a high security risk in case a MITM attack is executed (both PEAP/MSCHAPv2 and EAP-TTLS/PAP are susceptible if not properly configured).
• Directly related to the previous issue – organizations tend to use password based 802.1X mechanisms as a form of “BYOD” solution, i.e. “just input your AD username and password and you client is connected”. The issue with this approach is end-users would have to skip one very important step – server certificate validation – which easily opens up credentials to Man-In-The-Middle attacks. Now some operating systems (like Android) started to block the ability to disable server certificate validation in client config, making such scenarios difficult to use.

We recommend to use password based authentication only if you cannot afford deploying PKI infrastructure in the near term or you are in a migration phase to certificate-based authentication. Password based 802.1X authentication is not recommended for BYOD scenarios, as it creates potential MITM attack vectors.

EAP-TTLS – Client Device Support

Windows 10 / 11: supported

Android 9+: supported

iOS/iPadOS/MacOS: supported, but needs additional configuration.

Certificate Based Authentication

Mist Access Assurance seamless integrates with any existing Public Key Infrastructure and can leverage identity obtained from a certificate to get additional context by integrating with a cloud-based Identity Provider, such as Microsoft Azure AD, Okta or Google.

We recommend to always use certificate based authentication in all scenarios when clients are managed by IT (either via MDM or GPO) and they support 802.1X.