FreeRADIUS InkBridge

EAP Sub-Types

This page lists the different types of EAP authentication which are supported.

EAP-TLS

EAP-TLS is defined in RFC 5216, is an IETF standard with wide support among wireless vendors. It uses PKI to secure communication to the RADIUS server, providing strong security. A client-side certificate is required, which can be stored on a smartcard for maximum security.

EAP-TLS is universally supported by all manufacturers of wireless LAN hardware and software. A compromised password alone is not enough to break into EAP-TLS enabled systems - the attacker would also need the client-side certificate.

EAP-MD5

EAP-MD5 is defined in RFC 3748, is an IETF open standard but offers minimal security. The MD5 hash function is vulnerable to dictionary attacks and doesnot support mutual authentication or key generation, making it unsuitable for use with dynamic WEP or WPA/WPA2 enterprise.

EAP-Tunneled Transport Layer Security (EAP-TTLS)

EAP-TTLS is widely supported across platforms and offers good security using PKI certificates only on the authentication server. EAP-TTLS is defined in RFC 5281.

Flexible Authentication via Secure Tunneling (EAP-FAST)

EAP-FAST was designed to replace LEAP. EAP-FAST uses a Protected Access Credential (PAC) that can be provisioned manually or dynamically. It has three phases:

  • Phase 0 (optional) - Dynamic PAC provisioning.

  • Phase 1 - The client and the AAA server use the PAC to establish a TLS tunnel.

  • Phase 2 - The client sends user credentials across the tunnel.

EAP-FAST is defined in RFC 4851.

EAP-pwd

EAP-pwd provides password-based mutual authentication without the need for certificates. The cleartext password is taken from control.Password.Cleartext, consistent with other password-based modules.

EAP-GTC (Generic Token Card)

EAP-GTC is defined in RFC 3748. It is most often used as an inner authentication method inside EAP-TTLS or EAP-PEAP tunnels. The server sends a text challenge and the client response is treated as a User-Password and passed to another module for verification.

EAP-MSCHAPv2

EAP-MSCHAPv2 provides MS-CHAP version 2 authentication inside of an EAP exchange. It is most commonly used as the inner authentication method for PEAP.

Protected Extensible Authentication Protocol (PEAP)

PEAP is similar to EAP-TTLS, and is the most common WiFi authentication method used by Windows. It requires only a server-side PKI certificate to create a secure TLS tunnel, similar to EAP-TTLS.

PEAP has two commonly used sub-types:

PEAP/EAP-MSCHAPv2

This type is the most widely deployed PEAP variant. It is supported by Microsoft, Cisco, Apple, Linux, and many open source clients. PEAP is defined in the IETF internet draft draft-josefsson-pppext-eap-tls-eap.

PEAP/EAP-GTC

PEAP/EAP-GTC is most often used for a token-card authentication, and is not generally suitable for Wi-Fi.

Windows does not support for PEAP/EAP-GTC.

EAP for GSM Subscriber Identity (EAP-SIM)

EAP-SIM standard rovides authentication and session key distribution using the GSM Subscriber Identity Module (SIM). EAP-SIM is defined in RFC 4186.

AP for UMTS Authentication and Key Agreement (EAP-AKA)

EAP-AKA provides authentication and session key distribution using the UMTS Subscriber Identity Module (USIM). EAP-AKA is defined in RFC 4187.

EAP-AKA'

EAP-AKA' is an improved version of EAP-AKA with stronger key derivation. It is defined in RFC 5448.