The two most popular EAP Types are PEAP-MSCHAPv2 for UserName and Password Authentication and EAP-TLS for certificate-based authentication.

Extended Authentication Protocol (EAP) is an authentication framework not to be confused with an authentication mechanism. The supported EAP types for NetAlly units include the following:

Certificate-Based EAP Types:
 

EAP-TLS – Is an open standard that uses the TLS (Transport Layer Security) Protocol. It uses PKI to secure communication to a RADIUS authentication server or another type of authentication server.

PEAP-TLS – Is very similar to EAP-TLS, but is slightly more secure, because portions of the certificate in EAP-TLS that are unencrypted are encrypted in PEAP-TLS.

TTLS-EAP-TLS – Securely tunnels the EAP-TLS certificate within the TLS records.

UserName & Password EAP Types:

EAP-FAST – EAP-FAST (Flexible Authentication via Secure Tunneling) uses a Protected Access Credential (PAC) to establish a TLS tunnel in which client credentials are verified. EAP-FAST is Cisco replacement for LEAP.

EAP-GTC – Carries a text challenge from the authentication server, and a reply generated by a security token.

EAP-MD5 – Differs from other EAP methods in that it only provides authentication of the EAP peer to the EAP server but not mutual authentication.

EAP-MSCHAPv2 – Authentication process, both the client and the RADIUS server must prove that they have knowledge of the user's password for authentication to succeed.

PEAP (Protected Extensible Authentication Protocol) – Was designed to provide increased security over EAP in modern 802.1x environments. In PEAP, once the PEAP server and the PEAP client establish the TLS tunnel, the PEAP server generates an EAP-Identity request and transmits it down the TLS tunnel. The client responds to this second EAP-Identity request by sending an EAP-Identity response containing the user’s true identity down the encrypted tunnel. This prevents anyone eavesdropping on the 802.11 traffic from discovering the user’s true identity.

PEAP-MD5 – Lets a RADIUS server authenticate LAN stations by verifying an MD5 hash of each user's password.

PEAP-GTC – Was created by Cisco to provide interoperability with existing token card and directory based authentication systems via a protected channel.

PEAP-MSChapV2 – Is the most common form of PEAP in use trailing just behind EAP-TLS. It uses MSCHAPv2 meaning it can authenticate to databases that support the MSCHAPv2 format, including Microsoft NT and Microsoft Active Directory.

TTLS (Tunneled Transport Layer Security) – With TTLS, the client typically authenticates via PAP or CHAP protected by the TLS tunnel. In this case, the client will include a User-Name attribute and either a Password or CHAP-Password attribute in the first TLS message sent after the tunnel is established.

TTLS-PAT – The client initiates PAP by tunneling User-Name and User-Password AVPs to the TTLS server.

TTLS-CHAP – Securely tunnels client password authentication within the TLS records. The client initiates MS-CHAP by tunneling User-Name, MS-CHAP-Challenge and MS-CHAP-Response AVPs to the TTLS server.

TTLS-MSCHAP – Securely tunnels client password authentication and MSCHAP response within the TLS records. The client initiates MS-CHAP by tunneling User-Name, MS-CHAP-Challenge and MS-CHAP-Response AVPs to the TTLS server.

TTLS-MSCHAPv2 – Securely tunnels client password authentication and MSCHAPv2 response within the TLS records. The client initiates MS-CHAP by tunneling User-Name, MS-CHAP-Challenge and MS-CHAP-Response AVPs to the TTLS server.

TTLS-EAP-MD5 – Secure tunnels the MD5 hash within the TLS records.

TTLS-EAP-GTC – Securely tunnels the GTC token within the TLS records.

TTLS-EAP-MSCHAPv2 – Securely tunnels client password authentication and MSCHAPv2 response within the TLS records. The client initiates MS-CHAP by tunneling User-Name, MS-CHAP-Challenge and MS-CHAP-Response AVPs to the TTLS server.

Both PEAP and TTLS where created in response to PKI barrier in EAP-TTLS. Both TTLS and PEAP were designed to use older authentication mechanisms while retaining the strong cryptographic foundation of TLS.