Extensible Authentication Protocols
The Extensible Authentication Protocol (EAP) is an authentication framework widely used in network access authentication. It provides a flexible and extensible way to support multiple authentication methods, making it a versatile choice for various networking environments such as wireless networks, VPNs, and wired Ethernet.
Protocol |
Description |
Use Case |
|---|---|---|
EAP‑TLS |
Certificate‑based mutual authentication using X.509 over TLS; highly secure but infrastructure-intensive. |
Enterprise Wi‑Fi and secure access networks. |
EAP‑PEAP (MSCHAPv2) |
Encapsulates MSCHAPv2 inside a TLS tunnel; password-based, simpler setup, widely supported. |
WPA2‑Enterprise for mixed‑device networks. |
EAP‑PEAP (TLS) |
Inner TLS authentication using client certificate within PEAP tunnel. |
High‑security enterprise deployments with cert‑based identity. |
EAP‑PEAP (GTC) |
Uses Generic Token Card inside TLS—suitable for OTP or token systems. |
Network access using one‑time tokens. |
EAP‑PEAP (MD5‑Challenge) |
Legacy MD5 challenge inside TLS; deprecated due to weak hashing. |
Legacy systems only. |
EAP‑TTLS (EAP‑MD5‑Challenge) |
Uses legacy MD5 challenge inside TTLS tunnel. |
Backward‑compatibility deployments. |
EAP‑TTLS (EAP‑GTC) |
GTC inner method inside TTLS. |
Token‑based secure access. |
EAP‑TTLS (EAP‑MSCHAPv2) |
MSCHAPv2 inside TTLS. |
Commonly used in RADIUS Wi‑Fi networks. |
EAP‑TTLS (MSCHAPv2) |
Variant with only MSCHAPv2. |
Similar use as above. |
EAP‑TTLS (EAP‑TLS) |
Client cert inside TTLS tunnel. |
High‑security deployments avoiding full EAP‑TLS rollout. |
EAP‑TTLS (MSCHAP) |
MSCHAP (v1) inside TTLS. |
Legacy support for older devices. |
EAP‑TTLS (PAP) |
PAP inside TTLS—simplest but least secure. |
Legacy integration. |
EAP‑TTLS (CHAP) |
CHAP inside TTLS. |
Slightly better than PAP. |
EAP‑SIM |
Uses GSM SIM credentials for authentication. |
Seamless cellular network authentication. |
EAP‑AKA |
Uses UMTS/3G USIM credentials. |
Mobile networks (3G/LTE). |
EAP‑AKA′ (Prime) |
Enhanced AKA with improved privacy and protection. |
Secure 4G/5G authentication. |
EAP‑PAX |
Password‑based authenticated key exchange method. |
Secure access with password only. |
EAP‑PSK |
Uses a pre‑shared symmetric key (AES‑128) for mutual auth and key derivation :contentReference[oaicite:0]{index=0}. |
Lightweight secure Wi‑Fi without PKI. |
EAP‑SAKE |
Password and key based authentication with shared secret. |
Secure network access where PSK needed with improved protection. |
EAP‑FAST |
Cisco’s Flexible Authentication via Secure Tunneling; uses PAC instead of certs. |
Enterprise access with reduced PKI reliance. |
EAP‑IKEv2 |
Leverages IKEv2 for mutual authentication and key derivation. |
Secure, certificate‑based access. |
EAP‑GPSK |
Group PSK method for multiple clients. |
Group access scenarios with shared key. |
EAP‑MD5‑Challenge |
Simple MD5‑based challenge; one-sided authentication. |
Limited internal networks; deprecated for higher‑security needs. |
EAP‑MSCHAPv2 |
Microsoft challenge‑response protocol. |
Windows networks, older legacy setups. |
EAP‑GTC |
Generic Token Card pass‑through method. |
Token or OTP based access systems. |
EAP‑TNC |
Network Access Control with integrity checking (Trusted Network Connect). |
Compliance‑based network access controls. |
EAP-OTP |
One-Time Password based EAP method that provides password authentication using OTP tokens; enhances security over static passwords. |
Secure wireless and VPN access with dynamic password tokens. |
EAP-TTLS/EAP-OTP |
Uses tunneled TLS to protect inner EAP-OTP authentication; combines certificate-based server authentication with OTP client authentication. |
Enterprise wireless networks requiring strong server authentication and OTP client authentication. |
EAP-PEAP/OTP |
Encapsulates OTP authentication inside a TLS tunnel secured by server certificates; protects OTP exchange and enhances security. |
WPA2-Enterprise with OTP for added security in wireless environments. |
LEAP |
Cisco proprietary EAP using password-based MS-CHAP mutual authentication; simple but vulnerable to dictionary attacks. |
Legacy Cisco wireless networks (mostly deprecated today). |
EAP‑PWD |
Performs mutual authentication via a zero-knowledge password proof using elliptic curve cryptography (ECC). No certificates required. |
Secure password-only Wi‑Fi authentication without certificate infrastructure. |
EAP‑EKE |
Password-authenticated key exchange using encrypted Diffie-Hellman; protects against dictionary attacks, no certificates required. |
Lightweight mutual authentication in networks lacking certificate management (e.g., IoT, VPN, Wi‑Fi). |
RFC / Specification: RFC 5216
Main Features:
Uses mutual authentication with client and server certificates
Strongest security among EAP methods (based on TLS)
Supports session resumption via TLS caching
Vulnerable to poor certificate management, but highly secure if managed properly
Typically used with RADIUS for backend authentication
Use Cases:
Enterprise Wi-Fi security (WPA2/WPA3-Enterprise)
VPN authentication requiring high assurance
Environments demanding certificate-based identity verification
Alternative Protocols:
EAP-PEAP – TLS tunnel but only server-side cert required
EAP-TTLS – TLS tunnel with flexible inner authentication
EAP-FAST – Tunnel-based, supports faster re-authentication
EAP-MSCHAPv2 – Password-based, weaker compared to cert-based options
Let us learn more about EAP-TLS:
RFC / Specification: Drafts by Microsoft, Cisco, RSA; not formally RFC-standardized.
Main Features:
Encapsulates EAP within a secure TLS tunnel (only server certificate required)
Inside the tunnel, performs username/password authentication using MSCHAPv2
Widely supported across platforms (Windows, Linux, Android, etc.)
Provides encryption and integrity through TLS, simplifying cert management
Vulnerable to dictionary attacks if password complexity is weak
Use Cases:
WPA2/WPA3-Enterprise networks in corporate environments
University or enterprise-level wireless access requiring username/password
Environments where client certificates are not feasible
Alternative Protocols:
EAP-TLS – stronger security, mutual certificate authentication
EAP-TTLS – similar tunnel but with multiple inner auth options
EAP-FAST – more efficient re-authentication with similar tunnel setup
Let us learn more about EAP-PEAP-MSCHAPv2:
RFC / Specification: Draft-based (PEAP not an official IETF RFC) Common Implementations: Microsoft NPS, FreeRADIUS, Cisco ISE
Main Features:
Uses TLS tunnel (outer method) to protect inner authentication method
Inner method is EAP‑TLS, enabling mutual authentication with client/server certificates
Secure channel prevents exposure of credentials or authentication data
Supports server certificate validation and optional client certificate authentication
Provides strong encryption and integrity via TLS handshake
More flexible than plain EAP‑TLS, with support for tunneled methods
Use Cases:
Secure enterprise Wi‑Fi authentication (e.g., 802.1X networks)
Organizations requiring strong mutual certificate-based auth over a protected tunnel
Scenarios where PKI is already deployed for users and infrastructure
Hybrid systems where PEAP is used with fallback methods like MSCHAPv2 or GTC
Alternative Protocols:
EAP‑TLS – Direct certificate-based authentication without inner method
EAP‑PEAP‑MSCHAPv2 – Same outer tunnel, but inner method is password-based
EAP‑TTLS‑EAP‑TLS – Similar tunneled certificate-based approach using TTLS instead of PEAP
EAP‑FAST – Cisco alternative using PACs instead of certificates
Let us learn more about EAP‑PEAP‑TLS:
RFC / Specification: Draft (not standardized as an RFC) Common Implementations: Cisco ISE, FreeRADIUS, Microsoft NPS (limited)
Main Features:
PEAP (Protected EAP) provides an outer encrypted TLS tunnel
GTC (Generic Token Card) is used as the inner method
Supports one-time passwords (OTPs), token-based credentials, or plaintext passwords
Server certificate required; client certificate not required
Passwords or tokens are sent inside the TLS tunnel in plaintext or challenge form
Compatible with hardware/software tokens (e.g., RSA SecurID, OTP apps)
Use Cases:
Two-factor authentication (2FA) using OTP inside an EAP method
Organizations using token-based identity systems
Enterprises with RADIUS backend supporting OTP schemes
Secure Wi‑Fi (802.1X) login with time-based tokens (TOTP/HOTP)
Alternative Protocols:
EAP‑PEAP‑MSCHAPv2 – Uses password-based challenge-response (no OTP)
EAP‑TTLS‑GTC – Similar approach using TTLS instead of PEAP
EAP‑FAST – Cisco protocol with support for tunneled inner authentication
EAP‑TLS – Strong security using certificates, but no OTP support
EAP‑TTLS‑PAP – Can carry plaintext passwords over a secure tunnel
Let us learn more about EAP‑PEAP‑GTC:
RFC / Specification: - PEAP: Defined in [Microsoft Draft and Cisco Implementations] - EAP-MD5: [RFC 3748] (as an inner method)
Main Features:
PEAP provides an encrypted outer TLS tunnel
MD5-Challenge is used as the inner authentication method
Relies on username/password challenge-response
No support for mutual authentication
Server certificate is required; client certificate is optional
Weak security due to outdated MD5 hash algorithm
Vulnerable to dictionary and offline attacks if tunnel is compromised
Use Cases:
Legacy systems requiring lightweight challenge-response authentication
Test environments with minimal security requirements
Low-resource devices using simple password authentication
Temporary setups in closed, isolated networks
Alternative Protocols:
EAP-PEAP-MSCHAPv2 – Stronger password-based authentication
EAP-TTLS-MSCHAPv2 – Uses TTLS tunnel with MSCHAPv2 inner method
EAP-TLS – Strong certificate-based mutual authentication
EAP-FAST – Secure tunneling with optional PAC provisioning
EAP-TTLS-PAP – Allows plaintext password inside secure tunnel
Let us learn more about EAP‑PEAP‑MD5‑Challenge: * Learnings in this section
Specification: RFC 5281
Main Features:
EAP-TTLS (Tunneled TLS) used as outer authentication method.
EAP-MD5-Challenge used as inner authentication method.
Credentials (username/password) are transmitted within the secure TLS tunnel.
Provides encryption and server authentication via certificates.
EAP-MD5 does not support mutual authentication or password salting.
Use Cases:
Enterprise Wi-Fi networks with internal user databases.
Legacy systems requiring EAP-MD5 for backward compatibility within a secure tunnel.
Scenarios where fast authentication is needed but full mutual authentication is not critical.
Alternative Protocols:
EAP-TTLS with MSCHAPv2 or PAP – for better security and password compatibility.
EAP-PEAP with MSCHAPv2 – for Microsoft environment compatibility.
EAP-TLS – for mutual certificate-based authentication.
EAP-FAST – Cisco proprietary, lightweight tunnel alternative.
Let us learn more about EAP-TTLS-EAP-MD5-Challenge:
Specification: RFC 5281
Main Features:
EAP-TTLS (Tunneled TLS) used as the outer authentication layer.
EAP-GTC (Generic Token Card) used as the inner authentication protocol.
Credentials (e.g., one-time password or token) are transmitted securely within the TLS tunnel.
Enables token-based or one-time password authentication over secure transport.
TLS provides encryption, integrity, and server authentication via digital certificates.
Use Cases:
Enterprises using hardware or software token generators for two-factor authentication.
Authentication systems requiring support for non-password-based credentials.
Secure Wi-Fi access in organizations requiring token-based login methods.
VPN or remote access setups using EAP with secure credential exchange.
Alternative Protocols:
EAP-TTLS with MSCHAPv2 – for compatibility with password-based systems.
EAP-PEAP with GTC – for Microsoft-friendly GTC in a PEAP tunnel.
EAP-FAST – Cisco’s protocol with PAC-based tunnel authentication.
EAP-TLS – for mutual certificate-based authentication without token dependency.
Let us learn more about EAP-TTLS-EAP-GTC:
Specification: RFC 5281
Main Features:
EAP-TTLS provides a secure outer TLS tunnel.
MSCHAPv2 (Microsoft Challenge Handshake Authentication Protocol v2) used inside the tunnel.
Password-based authentication protected within an encrypted TLS session.
Supports mutual authentication (server certificate + client credentials).
Reduces client certificate requirement; only server-side cert needed.
Use Cases:
Enterprise Wi-Fi (802.1X) with username/password login.
VPN authentication using EAP methods.
Institutions needing secure password authentication without deploying client certificates.
RADIUS-based authentication systems.
Alternative Protocols:
EAP-PEAP with MSCHAPv2 – Microsoft-preferred equivalent.
EAP-TLS – for full certificate-based mutual authentication.
EAP-TTLS with PAP or CHAP – alternative tunneled credential options.
EAP-FAST – PAC-based tunnel without requiring external certificates.
Let us learn more about EAP-TTLS-EAP-MSCHAPv2:
Specification: RFC 5281
Main Features:
EAP-TTLS establishes a secure outer TLS tunnel.
MSCHAPv2 credentials (username/password) are sent directly within the TLS tunnel.
No inner EAP method used—only raw MSCHAPv2 inside the secure tunnel.
Reduces deployment complexity by eliminating need for client certificates.
Supports server certificate authentication.
Use Cases:
Secure enterprise Wi-Fi access using RADIUS backend.
Environments where user credentials must remain private without full EAP stack.
Institutions or corporations standardizing on MSCHAPv2 for password handling.
VPN and network access solutions using TTLS with legacy authentication.
Alternative Protocols:
EAP-TTLS with EAP-MSCHAPv2 – adds more flexibility via inner EAP method.
EAP-PEAP with MSCHAPv2 – Microsoft’s preferred tunnel method.
EAP-TLS – stronger security through certificate-based mutual authentication.
EAP-FAST – PAC-based approach with lightweight tunnel.
Let us learn more about EAP-TTLS-MSCHAPv2:
Specification: RFC 5281
Main Features:
Combines EAP-TTLS (outer TLS tunnel) with EAP-TLS as the inner authentication method.
Provides mutual certificate-based authentication within a protected tunnel.
Separates authentication layers: TLS tunnel protects inner EAP method.
Offers strong security without exposing credentials to the outer network.
Useful in complex identity environments or for adding secondary identity validation.
Use Cases:
Enterprises requiring dual-layer certificate-based authentication.
Environments with legacy support for TTLS but needing EAP-TLS internally.
Enhanced secure Wi-Fi access in universities, large offices, or sensitive environments.
Migration paths from password-based EAP methods to full certificate-based EAP-TLS.
Alternative Protocols:
EAP-TLS – simpler, direct certificate-based authentication without nesting.
EAP-TTLS with MSCHAPv2 – for password-based methods within a TLS tunnel.
EAP-PEAP with TLS – similar nesting but using PEAP instead of TTLS.
EAP-FAST – uses PACs to enable tunneled authentication, no certificates required.
Let us learn more about EAP-TTLS-EAP-TLS:
Specification: RFC 5281
Main Features:
Uses EAP-TTLS to create a secure TLS tunnel and performs MSCHAP (not v2) inside it.
Supports username/password-based authentication without exposing credentials in clear text.
Offers protection of legacy authentication protocols via encrypted tunnel.
More secure than using MSCHAP without tunneling.
Reduces need for client-side certificates.
Use Cases:
Legacy enterprise systems still using MSCHAP needing encryption.
Secure Wi-Fi access in older or mixed-platform environments.
VPNs and remote access systems requiring tunneled password authentication.
Migration environments where certificate deployment is limited.
Alternative Protocols:
EAP-TTLS-MS-CHAPv2 – newer version of MSCHAP inside TTLS.
EAP-TTLS-PAP – simple password auth within TLS tunnel.
EAP-PEAP-MS-CHAPv2 – Microsoft-compatible password-based EAP in TLS tunnel.
EAP-TLS – certificate-based authentication without MSCHAP.
Let us learn more about EAP-TTLS-MSCHAP:
Specification: RFC 5281
Main Features:
Uses EAP-TTLS to create a secure TLS tunnel and performs PAP (Password Authentication Protocol) inside it.
Sends username and password in clear text within the TLS tunnel, providing confidentiality.
Simple and widely supported; easy to implement on client and server sides.
No need for client-side certificates.
Good balance between security and ease of deployment.
Use Cases:
Campus or enterprise Wi-Fi environments where simplicity is prioritized.
Legacy systems or lightweight clients that can’t support more complex EAP methods.
Environments with internal RADIUS infrastructure supporting PAP inside secure tunnels.
Situations requiring minimal configuration on endpoints.
Alternative Protocols:
EAP-TTLS-CHAP – stronger than PAP, but similar architecture.
EAP-PEAP-MS-CHAPv2 – Microsoft-oriented tunnel-based EAP method.
EAP-TTLS-MS-CHAPv2 – more secure alternative to PAP using a tunneled version of MSCHAPv2.
EAP-TLS – uses client certificates, offering higher security.
Let us learn more about EAP-TTLS-PAP:
Specification: RFC 5281
Main Features:
Uses EAP-TTLS to establish a secure TLS tunnel and performs CHAP (Challenge Handshake Authentication Protocol) inside it.
Provides improved security over PAP by avoiding transmission of plaintext passwords, even within the tunnel.
Still does not require client-side certificates, simplifying deployment.
Ensures authentication of the server via TLS certificates.
Suitable when backward compatibility with legacy CHAP-based systems is needed.
Use Cases:
Enterprise Wi-Fi authentication where legacy CHAP-based identity stores are in use.
Environments with RADIUS servers supporting CHAP authentication inside secure tunnels.
Network scenarios where EAP-TTLS-PAP is not acceptable due to its plaintext password usage (even inside TLS).
Alternative Protocols:
EAP-TTLS-PAP – simpler, but sends password in plaintext inside TLS.
EAP-TTLS-MS-CHAPv2 – more secure than CHAP, widely supported.
EAP-PEAP-MS-CHAPv2 – Microsoft-friendly method using PEAP tunneling.
EAP-TLS – highest security using mutual certificates.
Let us learn more about EAP-TTLS-CHAP:
Specification: RFC 4186
Main Features:
Uses the SIM (Subscriber Identity Module) from GSM networks for authentication.
Enables mutual authentication and session key generation between the user and network.
Does not require user-entered credentials—uses SIM card securely instead.
Vulnerability to man-in-the-middle attacks mitigated via optional server certificate validation.
Operates within existing EAP framework and integrates with RADIUS/AAA infrastructure.
Use Cases:
Secure Wi-Fi access using SIM credentials (e.g., 802.1X in mobile networks).
Seamless authentication in cellular offload scenarios (e.g., Wi-Fi Hotspot 2.0).
Carrier Wi-Fi deployments and mobile network authentication extensions.
Smart devices with embedded SIMs requiring minimal user interaction.
Alternative Protocols:
EAP-AKA – 3G/UMTS equivalent of EAP-SIM, more advanced.
EAP-AKA’ (AKA-Prime) – LTE/5G-compatible, with stronger security guarantees.
EAP-TLS – Certificate-based, suitable for non-SIM devices.
EAP-PEAP – Tunnel-based credential exchange.
Specification: RFC 4187
Main Features:
Uses the AKA (Authentication and Key Agreement) mechanism from 3G/UMTS networks.
Provides mutual authentication and session key derivation between client and server.
Designed for devices with USIM (Universal Subscriber Identity Module).
Supports identity privacy (temporary identities) and re-authentication.
Resistant to replay and man-in-the-middle attacks.
Use Cases:
Wi-Fi authentication using mobile network credentials (e.g., Hotspot 2.0, Wi-Fi offloading).
Telecom environments with 3GPP authentication infrastructure.
SIM-based device authentication in enterprise or campus networks.
Seamless authentication for mobile subscribers.
Alternative Protocols:
EAP-SIM – For 2G (GSM) networks.
EAP-AKA’ (AKA-Prime) – LTE/5G-focused, with improved security.
EAP-TLS – Non-SIM devices with certificate-based authentication.
EAP-PEAP – Tunnel-based, credential-based authentication.
Specification: RFC 5448
Main Features:
An enhanced version of EAP-AKA designed for LTE and 5G networks.
Provides stronger cryptographic algorithms and improved privacy protections.
Supports key derivation for secure session establishment.
Includes mechanisms to resist active and passive attacks.
Maintains backward compatibility with EAP-AKA.
Use Cases:
Authentication in LTE and 5G cellular networks.
Wi-Fi offloading with improved security.
Mobile devices using USIM with LTE/5G capabilities.
Enterprise and carrier-grade network access control.
Alternative Protocols:
EAP-AKA – Predecessor for 3G networks.
EAP-TLS – Certificate-based authentication.
EAP-PEAP – Tunnel-based password or certificate authentication.
EAP-SIM – For 2G GSM network devices.
Specification: RFC 4742
Main Features:
Password-based authentication protocol designed to provide mutual authentication.
Uses strong cryptographic primitives to resist dictionary attacks.
Establishes a secure key between client and server after authentication.
Does not require certificates or public key infrastructure (PKI).
Suitable for environments with limited resources.
Use Cases:
Wireless networks requiring password-based authentication without certificates.
Small office or home networks with minimal security infrastructure.
Situations where mutual authentication is desired but PKI is unavailable.
Legacy systems supporting password authentication.
Alternative Protocols:
EAP-PEAP – Uses TLS tunnel for password authentication.
EAP-TTLS – Tunnel-based password or legacy authentication methods.
EAP-SAKE – Similar password-based mutual authentication protocol.
EAP-TLS – Certificate-based mutual authentication.
Specification: RFC 4764
Main Features:
Uses pre-shared keys (PSK) for mutual authentication.
Provides secure key exchange without requiring certificates.
Designed for low-complexity devices and environments.
Resistant to dictionary attacks and man-in-the-middle attacks.
Establishes fresh session keys for encryption after authentication.
Use Cases:
Wireless networks where deploying certificates is impractical.
IoT devices with limited computational power.
Small-scale or private networks relying on shared secrets.
Situations requiring fast and secure authentication without PKI.
Alternative Protocols:
EAP-PAX – Password-based mutual authentication alternative.
EAP-TLS – Certificate-based authentication for higher security.
EAP-PEAP – Uses TLS tunnel for password authentication.
EAP-TTLS – Tunnel-based password or legacy authentication.
Specification: RFC 4763
Main Features:
Stands for “Shared Secret Authentication and Key Establishment.”
Uses symmetric key cryptography for mutual authentication.
Provides key establishment and fresh session keys for encryption.
Designed to be resistant to dictionary and replay attacks.
Suitable for wireless networks with pre-shared secrets.
Does not require public key infrastructure (PKI).
Use Cases:
Wireless LANs where pre-shared secrets are used.
Environments without a PKI or certificate infrastructure.
Low-power or legacy devices requiring secure authentication.
Enterprise and private networks focusing on lightweight security.
Alternative Protocols:
EAP-PSK – Another symmetric key-based authentication method.
EAP-TLS – Certificate-based strong authentication.
EAP-PEAP – Tunnel-based authentication with passwords.
EAP-TTLS – Tunnel-based authentication supporting multiple inner methods.
Specification: RFC 4851
Main Features:
Stands for Flexible Authentication via Secure Tunneling.
Uses Protected Access Credential (PAC) to establish a secure tunnel.
Supports mutual authentication and session key generation.
Designed to be a lightweight alternative to EAP-TLS without requiring client certificates.
Can operate in both tunneled and non-tunneled modes.
Resilient against dictionary and man-in-the-middle attacks.
Use Cases:
Enterprise wireless networks requiring strong security but without client certificates.
Environments where legacy devices need compatibility with modern authentication.
Networks that deploy centralized authentication with RADIUS servers.
Situations requiring flexible authentication methods with secure tunnels.
Alternative Protocols:
EAP-TLS – Certificate-based mutual authentication.
EAP-PEAP – Password-based tunnel authentication.
EAP-TTLS – Tunnel-based authentication supporting multiple inner methods.
EAP-SIM / EAP-AKA – For mobile and cellular network authentication.
Specification: RFC 5106
Main Features:
Extends the Internet Key Exchange version 2 (IKEv2) protocol for EAP.
Provides mutual authentication and key exchange in a secure manner.
Uses strong cryptographic algorithms to ensure confidentiality and integrity.
Supports various authentication methods inside the IKEv2 framework.
Designed for environments requiring robust security, such as VPNs and enterprise networks.
Provides seamless key management and fast re-authentication.
Use Cases:
VPN client authentication with strong mutual authentication.
Enterprise wireless networks requiring high security.
Environments where integration with IPsec is desired.
Situations needing fast and secure session establishment.
Alternative Protocols:
EAP-TLS – certificate-based authentication.
EAP-FAST – lightweight tunnel-based authentication.
EAP-PEAP – password-based tunneled authentication.
EAP-TTLS – flexible tunnel supporting multiple inner methods.
Specification: RFC 5433
Main Features:
Extends EAP with pre-shared key (PSK) based authentication.
Provides mutual authentication using shared keys.
Lightweight and efficient for constrained environments.
Offers protection against replay and man-in-the-middle attacks.
Designed for scenarios where certificates are not feasible.
Uses cryptographic key derivation to generate session keys.
Use Cases:
Wireless networks with pre-shared keys.
IoT devices with limited processing capabilities.
Environments where simple key management is preferred.
Secure authentication without complex PKI infrastructure.
Alternative Protocols:
EAP-TLS – certificate-based authentication.
EAP-PSK – more general pre-shared key based EAP.
EAP-MD5 – simple challenge-response authentication.
EAP-GTC – generic token card authentication.
Specification: RFC 3748 (original EAP), RFC 1994 (CHAP)
Main Features:
Simple challenge-response authentication using MD5 hash.
One-way authentication of the client to the server.
Does not provide mutual authentication.
Vulnerable to replay and dictionary attacks.
Fast and minimal overhead.
Widely supported but considered insecure for modern networks.
Use Cases:
Legacy systems requiring simple authentication.
Environments where minimal security is acceptable.
Testing and lab environments.
Use cases without need for confidentiality or mutual trust.
Alternative Protocols:
EAP-TLS – strong certificate-based mutual authentication.
EAP-MS-CHAPv2 – improved challenge-response with mutual auth.
EAP-GTC – token-based authentication.
EAP-PEAP – tunneled password-based authentication.
Let us learn more about EAP-MD5 Challenge:
Specification: RFC 2759
Main Features:
Challenge-handshake authentication protocol v2, integrated into EAP.
Provides mutual authentication between client and server.
Uses MS-CHAPv2 for password-based authentication.
Supports key derivation for encryption of subsequent sessions.
Vulnerable to offline password guessing if weak passwords are used.
Commonly used in VPNs and Microsoft environments.
Use Cases:
VPN user authentication.
Microsoft Active Directory integrated networks.
Wireless networks requiring password-based authentication.
Environments where legacy MS-CHAP support is needed.
Alternative Protocols:
EAP-TLS – certificate-based strong authentication.
EAP-PEAP – tunneled password authentication with MS-CHAPv2.
EAP-GTC – token-based generic authentication.
EAP-MD5 – simpler but weaker challenge-response.
Let us learn more about EAP-MS-CHAPv2:
Specification: RFC 3748 (EAP), RFC 4851
Main Features:
Generic Token Card protocol for EAP.
Allows passing of arbitrary authentication tokens (e.g., OTPs).
Supports challenge-response mechanisms.
Simple, flexible, and extensible.
Often used with one-time passwords or token-based authentication.
Does not provide encryption itself, relies on underlying secure transport.
Use Cases:
Token card based authentication systems.
Integration with hardware tokens and OTP devices.
Environments needing flexible authentication methods.
Systems supporting multiple authentication tokens.
Alternative Protocols:
EAP-TLS – certificate-based strong authentication.
EAP-PEAP – tunneled password authentication.
EAP-MS-CHAPv2 – password-based mutual authentication.
EAP-GPSK – pre-shared key based lightweight authentication.
Specification: RFC 5792
Main Features:
Trusted Network Connect (TNC) extension for EAP.
Provides endpoint integrity assessment and network access control.
Supports posture validation before network access.
Can carry vendor-specific integrity data.
Designed for environments requiring endpoint security checks.
Integrates with policy enforcement systems.
Use Cases:
Network access control (NAC) deployments.
Enterprise networks enforcing endpoint compliance.
Environments requiring dynamic security posture checks.
Systems needing vendor-specific integrity measurements.
Alternative Protocols:
EAP-TLS – certificate-based authentication.
EAP-FAST – fast tunnel-based authentication.
EAP-PEAP – tunneled password authentication.
EAP-GTC – token card based authentication.
RFC / Specification: No specific RFC; implementation varies by vendor and OTP system
Main Features:
Uses One-Time Password (OTP) tokens for authentication
Provides dynamic password-based authentication, reducing risks of password reuse
Typically combined with a TLS tunnel (like PEAP or TTLS) for secure transport
Strong protection against replay and phishing attacks due to OTP use
Requires backend OTP server or infrastructure for verification
Use Cases:
Secure wireless access requiring two-factor or dynamic authentication
VPN authentication using OTP tokens for added security
Environments demanding stronger security than static passwords
Alternative Protocols:
EAP-PEAP/OTP – OTP authentication inside a TLS tunnel with server certificate verification
EAP-TTLS/EAP-OTP – Flexible inner authentication with OTP inside a secure TLS tunnel
EAP-TLS – Certificate-based mutual authentication for highest security
EAP-MSCHAPv2 – Password-based authentication, less secure than OTP or cert-based methods
Let us learn more about EAP-OTP:
RFC / Specification: RFC 4851 (PEAP) + vendor-specific OTP extensions
Main Features:
Encapsulates OTP authentication inside a TLS tunnel secured by server certificates
Protects OTP credentials from interception and replay attacks
Provides strong server authentication and client authentication via OTP
Commonly used with backend OTP authentication servers
Supports flexible OTP mechanisms (hardware tokens, software tokens, SMS OTP)
Use Cases:
Enterprise wireless networks requiring strong two-factor authentication
VPN access where OTP is combined with TLS protection
Environments demanding protection of dynamic credentials over insecure networks
Alternative Protocols:
EAP-TTLS/EAP-OTP – Similar TLS tunnel with flexible inner authentication using OTP
EAP-TLS – Certificate-based mutual authentication, no passwords or OTP needed
EAP-OTP – OTP without TLS tunnel (less secure)
EAP-MSCHAPv2 – Password-based authentication, less secure compared to OTP
Let us learn more about EAP-PEAP/OTP:
RFC / Specification: RFC 5281 (TTLS) + vendor-specific OTP extensions
Main Features:
Establishes a secure TLS tunnel with server certificate authentication
Supports flexible inner authentication methods, including OTP for client authentication
Protects OTP credentials inside the encrypted tunnel to prevent interception
Allows legacy password protocols and OTP to be used securely
Requires backend OTP server infrastructure for verification
Use Cases:
Enterprise wireless and VPN networks needing secure OTP authentication
Environments with mixed authentication requirements (passwords, OTP)
Networks requiring strong server validation and dynamic client authentication
Alternative Protocols:
EAP-PEAP/OTP – OTP inside a TLS tunnel with server cert validation
EAP-TLS – Full certificate-based mutual authentication without passwords
EAP-OTP – OTP authentication without TLS tunnel (less secure)
EAP-MSCHAPv2 – Password-based authentication, less secure than OTP
RFC / Specification: Cisco proprietary (no formal RFC)
Main Features:
Password-based mutual authentication using MS-CHAP
Simple and easy to deploy but vulnerable to dictionary and brute-force attacks
No certificate support or TLS tunneling
Primarily designed for Cisco wireless networks
Considered deprecated due to security weaknesses
Use Cases:
Legacy Cisco wireless networks
Environments where backward compatibility with older Cisco devices is required
Not recommended for new deployments due to security risks
Alternative Protocols:
EAP-TLS – Strong certificate-based authentication
EAP-PEAP – TLS tunnel with password or OTP authentication
EAP-TTLS – Flexible TLS tunnel with various inner methods
EAP-OTP – Dynamic password authentication using one-time passwords
Let us learn more about LEAP:
RFC / Specification: RFC 6124
Main Features:
Provides mutual authentication using password-authenticated key exchange
No need for certificates or pre-shared keys
Uses encryption and zero-knowledge techniques to protect passwords from offline dictionary attacks
Establishes a shared secret (PMK) securely between client and server
Designed to be resistant to passive and active attacks
Suitable for environments where lightweight but secure authentication is required
Use Cases:
Enterprise Wi-Fi networks without a Public Key Infrastructure (PKI)
VPN authentication using password-only mechanisms
Secure IoT device onboarding with minimal resource usage
Systems requiring strong password-only authentication with protection against replay and dictionary attacks
Alternative Protocols:
EAP-PWD – Also offers secure mutual authentication without certificates
EAP-TLS – Certificate-based, stronger but more complex setup
EAP-PEAP – Tunnel-based with password inside TLS
EAP-PAX – Lightweight password-based mutual authentication
Let us learn more about EAP-EKE:
RFC / Specification: RFC 5931
Main Features:
Performs mutual authentication using password-based elliptic curve cryptography
Does not require certificates or external infrastructure
Resistant to dictionary attacks and replay attacks
Uses zero-knowledge proof to verify shared secrets
Secure and efficient for environments without PKI
Fully integrated into the EAP framework; supported by FreeRADIUS and hostapd
Use Cases:
Secure wireless (WPA2/WPA3-Enterprise) environments without certificate infrastructure
Environments requiring lightweight, strong password-only authentication
IoT or embedded devices where certificate handling is complex
Integration with FreeRADIUS or hostapd for enterprise Wi-Fi
Alternative Protocols:
EAP-TLS – Certificate-based mutual authentication
EAP-PEAP – TLS tunnel with inner password/token methods
EAP-TTLS – TLS-based tunneling for multiple inner methods
EAP-EKE – Similar certificate-less password-authentication with key exchange
Let us learn more about EAP-PWD: