RADIUS EAP with IKEv2: A Deep Dive into EAP-GTC and EAP-MSCHAPv2

🔐 RADIUS EAP with IKEv2: Understanding EAP-GTC & EAP-MSCHAPv2

When securing remote-access VPNs and enterprise wireless networks, the combination of RADIUS, EAP (Extensible Authentication Protocol), and IKEv2 forms a powerful tri-layer authentication backbone. Two of the most widely deployed EAP inner methods are EAP-GTC and EAP-MSCHAPv2. Understanding how each works—and when to use which—is essential for network architects, security engineers, and IT administrators.

🏗️ The Big Picture: RADIUS + EAP + IKEv2 Architecture
👤 Client
(Supplicant)
🔒 IKEv2 Tunnel
(ESP/IKE)
🌐 VPN / NAS
(Authenticator)
🖧 RADIUS
Server
🗄️ Identity
Store (AD/LDAP)
EAP messages are tunneled inside IKEv2 → forwarded as RADIUS Access-Request/Challenge/Accept packets

📡 What is RADIUS?

RADIUS (Remote Authentication Dial-In User Service, RFC 2865/2866) is a client-server protocol that provides Authentication, Authorization, and Accounting (AAA) services. In the context of IKEv2 VPNs, the NAS (Network Access Server) — typically a VPN gateway — acts as a RADIUS client. It forwards authentication data from the end-user to the RADIUS server (e.g., Cisco ISE, FreeRADIUS, Microsoft NPS), which in turn validates the credentials against a backend identity store.

📦 RADIUS Packet Flow for EAP Authentication
1. Access-Request
User-Name only
2. Access-Challenge
EAP-Request
3. Access-Request
EAP-Response
4. Access-Accept
+ RADIUS attrs
RADIUS uses UDP port 1812 (Auth) / 1813 (Acct). EAP payload rides in the EAP-Message attribute (Attr 79).

🔑 What is EAP?

EAP (RFC 3748) is an authentication framework — not a specific authentication mechanism. It defines a set of message types (Request, Response, Success, Failure) and allows pluggable methods (EAP-TLS, EAP-TTLS, PEAP, EAP-GTC, EAP-MSCHAPv2, etc.) to be carried inside. When used with IKEv2, EAP is negotiated via the IKE_AUTH exchange after the IKEv2 tunnel is established, providing identity protection for the inner authentication.

🛡️ What is IKEv2?

IKEv2 (Internet Key Exchange version 2, RFC 7296) is the signaling protocol used to set up IPsec Security Associations (SAs). It replaced IKEv1 and added native EAP support (RFC 5998), allowing EAP-based user authentication while the gateway uses certificate-based authentication. This asymmetric model is used in virtually all modern remote-access VPN products (Cisco AnyConnect, StrongSwan, Windows Built-in VPN, etc.).

🔄 IKEv2 Exchange with EAP — Step by Step
IKE_SA_INIT →
Diffie-Hellman key exchange, nonces, SA proposals
← IKE_SA_INIT
DH public key, nonce, chosen SA, certificate request
IKE_AUTH →
Client sends IDi (identity), no AUTH payload (signals EAP)
← IKE_AUTH
Server sends IDr, CERT, AUTH (server authenticates itself)
← EAP-Request
Server initiates EAP method (Identity / GTC / MSCHAPv2)
EAP-Response →
Client responds (credentials, challenge response, etc.)
... (multiple rounds possible) ...
← EAP-Success
RADIUS Access-Accept → IKEv2 forwards EAP-Success
IKE_AUTH →
Client sends AUTH payload (derived from EAP MSK)
← IKE_AUTH
Server sends AUTH payload, Child SA established ✅

⚡ EAP-GTC (Generic Token Card) — RFC 3748

What is EAP-GTC?

EAP-GTC (EAP Generic Token Card) is a simple, lightweight EAP method originally designed to carry one-time passwords (OTPs) from hardware token cards (like RSA SecurID). The server sends a text challenge/prompt, and the client responds with a cleartext password or OTP value. It was popularized by Cisco as an inner EAP method within PEAP (Protected EAP) tunnels — hence the common term PEAP-GTC.

🎯 EAP-GTC Authentication Flow
Supplicant
RADIUS / Auth Server
Server →
EAP-Request/GTC
"Enter password:" (prompt text)
EAP-Response/GTC
Cleartext Password / OTP
→ Server
Server →
EAP-Success ✅
(RADIUS Access-Accept)
⚠️ Security Note: EAP-GTC transmits the password in plaintext! It MUST always be wrapped inside a secure outer tunnel (PEAP or EAP-TTLS) to protect credentials from eavesdropping.

📋 EAP-GTC Packet Structure

EAP-Request (GTC):
+--------+--------+--------+--------+-------------------------+
|  Code  | Ident  |     Length      |  Type  |  Message (text) |
|  0x01  | 0xXX   |     0xXXXX      |  0x06  | "Enter OTP:"    |
+--------+--------+--------+--------+-------------------------+

EAP-Response (GTC):
+--------+--------+--------+--------+-------------------------+
|  Code  | Ident  |     Length      |  Type  |  Value (token)  |
|  0x02  | 0xXX   |     0xXXXX      |  0x06  | "847291"        |
+--------+--------+--------+--------+-------------------------+
  EAP Type 6 = GTC

✅ When & Where EAP-GTC is Used

  • OTP / Token-based Authentication: RSA SecurID, TOTP (Google Authenticator), SafeNet tokens — the RADIUS server challenges the user with a prompt, the user enters the current token code.
  • PEAP-GTC with Cisco Infrastructure: Cisco PEAP uses GTC as the inner method instead of MSCHAPv2, enabling authentication against LDAP/OTP backends without NT hashes.
  • Non-Windows Clients: macOS, Linux, and Android supplicants that support PEAP-GTC can authenticate against LDAP/Active Directory without needing NTLM.
  • IKEv2 with EAP-GTC: Used when the VPN gateway (e.g., StrongSwan) is configured to tunnel EAP-GTC inside the IKE_AUTH exchange for OTP-based VPN login.
🗺️ EAP-GTC Deployment Topology
📱 Mobile Client
PEAP-GTC
🔒 TLS
🌐 WLC / VPN GW
NAS / Authenticator
RADIUS
🖧 Cisco ISE /
FreeRADIUS
🔑 RSA SecurID /
LDAP
PEAP outer tunnel (TLS) protects the cleartext GTC password from network exposure

🔐 EAP-MSCHAPv2 — RFC 3079 / Microsoft Extension

What is EAP-MSCHAPv2?

EAP-MSCHAPv2 is Microsoft's encapsulation of the MS-CHAPv2 (Microsoft Challenge Handshake Authentication Protocol v2) within the EAP framework. Unlike EAP-GTC, it uses a mutual challenge-response mechanism — both the client and server prove knowledge of the password without ever transmitting the password itself. It is the most widely used inner EAP method for PEAP (PEAP-MSCHAPv2) and is natively supported on all Windows systems.

🔄 EAP-MSCHAPv2 Detailed Authentication Flow
Client
Message
RADIUS Server
Step 1
Server → Client:
EAP-Request/Identity
Step 2
Client → Server:
EAP-Response/Identity
Username
Step 3
Server → Client:
EAP-Request/MSCHAPv2
OpCode=1 (Challenge): 16-byte Server Challenge (SC)
Step 4
Client → Server:
EAP-Response/MSCHAPv2
OpCode=2 (Response): 16-byte Peer Challenge + 24-byte NT-Response
Step 5
Server → Client:
EAP-Request/MSCHAPv2
OpCode=3 (Success): AuthenticatorResponse string
Step 6
Client → Server:
EAP-Response/MSCHAPv2
OpCode=3 (Success ACK)
Step 7
Server → Client:
EAP-Success ✅

🧮 The MSCHAPv2 Cryptographic Engine

NT-Response Computation (Client Side):
1. ChallengeHash = SHA1(PeerChallenge + ServerChallenge + Username)[0:8]
2. PasswordHash   = MD4(UTF16LE(Password))   // NT Hash
3. PasswordHashHash = MD4(PasswordHash)
4. NT-Response = DES(ChallengeHash, K1) || DES(ChallengeHash, K2) || DES(ChallengeHash, K3)
   (3x 7-byte DES keys derived from padded NT Hash (21 bytes))

AuthenticatorResponse (Server-side Mutual Auth):
AR = "S=" + HEX(SHA1(PasswordHashHash + NTResponse +
               SHA1("Magic server to client signing constant" +
                    ChallengeHash + NTResponse)))

✅ When & Where EAP-MSCHAPv2 is Used

  • PEAP-MSCHAPv2 (802.1X Wi-Fi): The dominant enterprise wireless authentication method on Windows networks. The outer PEAP TLS tunnel protects the MSCHAPv2 exchange.
  • IKEv2 + EAP-MSCHAPv2 VPN: Windows natively supports IKEv2 with EAP-MSCHAPv2 for Always On VPN. The VPN gateway (Microsoft RRAS, StrongSwan, Cisco) forwards credentials to RADIUS/NPS.
  • Active Directory Integration: RADIUS server (NPS, ISE) validates the NT-Response directly against Active Directory NT hashes — no cleartext password needed.
  • Legacy PPP/SSTP: MSCHAPv2 originated as a PPP authentication method and is still used in older VPN protocols (PPTP, SSTP).
🗺️ EAP-MSCHAPv2 with IKEv2 VPN — Full Stack
Windows Client
IKEv2/EAP
IKEv2+ESP
VPN Gateway
(NAS/RADIUS Client)
RADIUS UDP/1812
NPS / ISE
RADIUS Server
LDAP/Kerberos
Active Directory
NT Hash Store
EAP-MSCHAPv2 msgs ride inside IKE_AUTH payloads → RADIUS EAP-Message attrs → AD validates NT-Response

⚖️ EAP-GTC vs EAP-MSCHAPv2 — Side-by-Side Comparison

📊 EAP-GTC vs EAP-MSCHAPv2 Comparison Table
FeatureEAP-GTCEAP-MSCHAPv2
RFC / StandardRFC 3748 (Type 6)Microsoft / RFC 3079
Password TransmissionCleartext (requires TLS tunnel)NT-Hash Challenge-Response
Mutual AuthenticationNoYes (server proves identity)
OTP / Token SupportNativeNo
Active DirectoryIndirect (LDAP bind)Native (NT hash)
Windows Native SupportNo (3rd party)Yes (built-in)
ComplexitySimple (1 round-trip)Moderate (3 round-trips)
IKEv2 EAP UsageOTP-based VPN (StrongSwan)Windows Always On VPN
PEAP Inner MethodPEAP-GTC (Cisco default)PEAP-MSCHAPv2 (MS default)
Security Without Tunnel❌ Insecure⚠️ Vulnerable to offline attack

🚨 Security Considerations

🛡️ Security Risk Matrix
Attack VectorEAP-GTC RiskEAP-MSCHAPv2 RiskMitigation
Credential EavesdroppingHIGH without tunnelLOW (no cleartext)Always use PEAP/EAP-TTLS outer tunnel
Rogue AP / MITMHIGHMEDIUMValidate server certificate strictly
Offline Dictionary AttackLOW (OTP)HIGH (asleap, hashcat)Strong passwords, MFA, EAP-TLS preferred
Replay AttackHIGH (no nonce)LOW (random challenges)OTPs are single-use; MSCHAPv2 uses random challenges
Best Practice: For maximum security with IKEv2, prefer EAP-TLS (certificate-based). When password-based auth is required, use PEAP-MSCHAPv2 with strict server certificate validation, or PEAP-GTC with OTP tokens for phishing-resistant authentication.

⚙️ Configuration Reference

StrongSwan IKEv2 + EAP-MSCHAPv2 (ipsec.conf)

conn ikev2-eap-mschapv2
    keyexchange=ikev2
    ike=aes256-sha256-modp2048!
    esp=aes256-sha256!
    left=%any
    leftid=@vpn.example.com
    leftcert=server-cert.pem
    leftauth=pubkey
    right=%any
    rightauth=eap-mschapv2
    rightsendcert=never
    eap_identity=%any
    auto=add

FreeRADIUS EAP Configuration (eap.conf)

eap {
    default_eap_type = mschapv2   # or gtc

    mschapv2 {
        # handled by rlm_mschap
    }

    gtc {
        auth_type = PAM           # For OTP - points to rlm_otp or PAM
    }

    peap {
        default_eap_type = mschapv2  # Inner method
        tls = tls-common
    }
}

🏁 Summary

Both EAP-GTC and EAP-MSCHAPv2 serve distinct roles in the enterprise authentication ecosystem. EAP-GTC shines in OTP/token-card deployments where one-time passwords provide phishing resistance, but its cleartext nature demands a protecting tunnel. EAP-MSCHAPv2 provides a self-contained challenge-response mechanism with mutual authentication and native Windows support, making it the workhorse of corporate Wi-Fi and Windows IKEv2 VPN. In both cases, wrapping the exchange inside IKEv2 (for VPNs) or PEAP/EAP-TTLS (for 802.1X) is non-negotiable for production security. For new deployments, seriously consider migrating toward EAP-TLS with certificates for the strongest security posture.

🎯 Quick Decision Guide: Which EAP Method?
🔑 EAP-GTC
✔ OTP / Token cards
✔ Non-Windows clients
✔ LDAP-only backends
✔ Cisco PEAP-GTC
🪟 EAP-MSCHAPv2
✔ Windows AD environments
✔ Always On VPN (IKEv2)
✔ 802.1X corporate Wi-Fi
✔ PEAP-MSCHAPv2
🏆 EAP-TLS
✔ Maximum security
✔ Certificate-based
✔ No password risk
✔ Recommended for new deployments

Post a Comment

Previous Post Next Post