๐ RADIUS EAP with IKEv2: Understanding EAP-GTC & EAP-MSCHAPv2
For remote-access VPNs, a possible architecture combines RADIUS , EAP (Extensible Authentication Protocol), and IKEv2 for separate transport, authentication and AAA roles. Enterprise Wi-Fi usually carries EAP over 802.1X instead of IKEv2. Two methods worth comparing 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.
(Supplicant)
(encrypted IKE messages)
(Authenticator)
Server
(backend depends on method)
๐ก 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.
EAP response or configured EAP start
EAP-Request
EAP-Response
EAP result and policy attributes
๐ 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 such as EAP-TLS, EAP-TTLS, PEAP, EAP-GTC and EAP-MSCHAPv2. IKEv2 carries EAP during encrypted IKE_AUTH exchanges, after IKE_SA_INIT but before authentication completes. Encryption at this stage is not a substitute for validating the gateway identity. Source: RFC 3748: EAP and GTC; RFC 7296: IKEv2 §§2.15–2.16;
๐ก️ What is IKEv2?
IKEv2 establishes and maintains IPsec security associations. EAP support is part of the base protocol described in RFC 7296; RFC 5998 is a separate EAP-only authentication extension for suitable mutually authenticating, key-generating methods. The base EAP flow below uses gateway public-key authentication. Product and client support must be checked rather than assumed universal. Source: RFC 5998: EAP-only extension;
⚡ EAP-GTC (Generic Token Card) — RFC 3748
What is EAP-GTC?
EAP-GTC is a simple text challenge/response method defined in RFC 3748. It can carry token output or another user-entered response; the method itself does not encrypt that response or derive session keys. One supported deployment pattern is GTC inside a PEAP tunnel, often called PEAP-GTC . Source: RFC 3748: EAP and GTC;
"Enter password:" (prompt text)
Cleartext Password / OTP
(RADIUS Access-Accept)
๐ Illustrative GTC packet fields — sample token, not real credentials
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: A backend may validate RSA SecurID, TOTP or other token responses if that integration and the client prompt are supported. GTC does not itself implement the token algorithm, enforce one-time use or make OTP phishing-resistant. Source: NIST SP 800-63B-4: phishing resistance;
- PEAP-GTC with Cisco Infrastructure: PEAP-GTC is an interoperability choice on implementations supporting that inner method; it is not a universal Cisco default. Its backend can validate a supplied password or token without computing an MSCHAPv2 response, subject to the backend’s actual capabilities.
- Non-Windows Clients: Support depends on the supplicant, OS version, configured EAP profile and backend—not just the operating-system family. LDAP password validation and AD challenge-response validation are different integration paths.
- IKEv2 with EAP-GTC: strongSwan documents an IKEv2 eap-gtc plugin. GTC generates no MSK: RFC 7296 discourages non-key-generating EAP methods and defines SK_pi/SK_pr for their final AUTH computations. Treat support as implementation-specific and validate the server; this is not the RFC 5998 EAP-only model. Source: strongSwan eap-gtc; RFC 7296: IKEv2 §§2.15–2.16;
PEAP-GTC
NAS / Authenticator
FreeRADIUS
LDAP
๐ EAP-MSCHAPv2 — Microsoft EAP encapsulation of RFC 2759
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 that proves possession of password-derived material without sending the password itself. Captured exchanges can still enable offline attacks, so this does not replace server-certificate validation and a protected channel. Windows supports this method in documented profiles, but behavior depends on version, policy and Credential Guard; do not disable platform protection simply to preserve legacy SSO. Source: Microsoft: Credential Guard considerations; Microsoft: VPN authentication;
Username
OpCode=1 (Challenge): 16-byte Server Challenge (SC)
OpCode=2: includes a 16-byte PeerChallenge and 24-byte NT-Response (other packet fields omitted)
OpCode=3 (Success): AuthenticatorResponse string
OpCode=3 acknowledgment only after the client validates AuthenticatorResponse Source: Microsoft: EAP-MSCHAPv2 syntax;
๐งฎ MSCHAPv2 cryptographic outline — explanatory, not an implementation
Explanatory notation, not runnable cryptographic code.
|| means byte concatenation. UserName excludes a prepended domain.
Challenge = SHA1(PeerChallenge || AuthenticatorChallenge || UserName)[0:8]
PasswordHash = MD4(UTF16LE(Password))
PasswordHashHash = MD4(PasswordHash)
PaddedHash = PasswordHash zero-padded to 21 bytes
K1, K2, K3 = its three 7-byte pieces, converted to DES keys with parity
NTResponse = DES(K1, Challenge) || DES(K2, Challenge) || DES(K3, Challenge)
Digest1 = SHA1(PasswordHashHash || NTResponse || Magic1)
Digest2 = SHA1(Digest1 || Challenge || Magic2)
AuthenticatorResponse = "S=" || uppercase_hex(Digest2)
Magic1 and Magic2 are the distinct byte constants in RFC 2759 section 8.7.
This legacy construction is not a recommendation for new cryptography.
Outline references: RFC 2759: MS-CHAPv2; Microsoft: EAP-MSCHAPv2 syntax;
✅ When & Where EAP-MSCHAPv2 is Used
- PEAP-MSCHAPv2 (802.1X Wi-Fi): A common legacy enterprise Wi-Fi profile wraps EAP-MSCHAPv2 in PEAP. The TLS server name and trusted CA must be enforced; relying on a user to accept any presented certificate defeats the protection.
- IKEv2 + EAP-MSCHAPv2 VPN: Microsoft documents EAP-MSCHAPv2 for its built-in VPN authentication. An IKEv2 gateway may handle the method locally or proxy EAP to RADIUS; the latter is an explicit configuration choice. Always On VPN has multiple authentication designs, so validate the actual profile and security policy. Source: Microsoft: VPN authentication;
- Active Directory Integration: The verifier needs suitable password-derived material or a service able to validate the challenge response. AD integration may delegate to a domain controller, for example through Samba/winbind in FreeRADIUS. It is not a generic LDAP read of AD NT hashes or a Kerberos replacement for MSCHAPv2. Source: FreeRADIUS: AD integration (4.0 documentation);
- Legacy PPP/SSTP: MSCHAPv2 was defined for PPP and appears in legacy VPN authentication designs. That history is not a recommendation to deploy PPTP or to treat all PPP-based transports as equivalent.
IKEv2/EAP
(NAS/RADIUS Client)
RADIUS Server
Domain-controller validation
⚖️ EAP-GTC vs EAP-MSCHAPv2 — Side-by-Side Comparison
| Feature | EAP-GTC | EAP-MSCHAPv2 |
|---|---|---|
| RFC / Standard | RFC 3748 (Type 6) | Microsoft EAP; RFC 2759; RFC 3079 for keys |
| Password Transmission | Cleartext (needs authenticated protection) | NT-Hash Challenge-Response |
| Mutual Authentication | No, not by GTC alone | Yes (password-derived proof; still validate server) |
| OTP / Token Support | Carries a supported backend’s token response | Not a native generic OTP transport |
| Active Directory | Depends on backend (for example, supported password validation) | Backend integration required (challenge-response validation) |
| Windows Native Support | Check the chosen client (often requires another supplicant) | Documented in Windows profiles (version and policy dependent) |
| Complexity | Simple (core challenge/response; outer rounds vary) | Moderate (identity, challenge and success exchanges) |
| IKEv2 EAP Usage | Implementation-specific; no EAP MSK | Supported profiles; verify policy |
| PEAP Inner Method | PEAP-GTC where supported | PEAP-MSCHAPv2 where configured |
| Security Without Tunnel | ❌ Insecure | ⚠️ Vulnerable to offline attack |
๐จ Security Considerations
| Attack Vector | EAP-GTC Risk | EAP-MSCHAPv2 Risk | Mitigation |
|---|---|---|---|
| Credential Eavesdropping | Response visible without protected channel | Password not sent, but captured response is sensitive | Authenticate the server and protect the complete path |
| Rogue AP / MITM | Secret or OTP can be relayed | Captured challenge-response enables attacks | Validate server certificate strictly |
| Offline Dictionary Attack | Depends on response type; GTC may carry a password | Known weakness of the legacy construction | Prefer supported certificate-based designs; protect legacy exchanges |
| Replay Attack | Depends on backend one-time-use and freshness checks | Fresh challenges help; implementation still matters | Enforce token replay checks; use fresh challenges; OTP can still be phished |
⚙️ Configuration review, not deployment instructions
strongSwan: distinguish local EAP from a RADIUS proxy
NON-EXECUTABLE strongSwan REVIEW CHECKLIST
- Decide whether EAP is verified locally or proxied to RADIUS.
- The original rightauth=eap-mschapv2 selects a local EAP method;
it does not alone configure a RADIUS backend.
- The eap-radius plugin provides proxying when explicitly configured.
- Review the installed release and its swanctl.conf/plugin documentation.
- Verify gateway certificate trust and expected identity on each client.
- Review allowed algorithms, client addressing, traffic selectors,
routing, policy, revocation and the independently protected AAA path.
- Review secret handling without embedding credentials in examples.
- Test compatibility and failure cases in an authorized isolated lab.
No configuration is applied and no credentials are accessed here.
Outline references: strongSwan eap-radius;
FreeRADIUS: version-specific EAP/backend review
NON-EXECUTABLE FreeRADIUS REVIEW CHECKLIST
- Identify the actual server version; configuration schemas differ.
- Choose the EAP method and, where applicable, its protected outer method.
- For MSCHAPv2, identify the supported challenge-response verifier.
- For GTC, identify the actual password or OTP validation backend.
- PAM and an OTP module are not interchangeable just because a comment says so.
- Configure server identity, trust, access policy and AAA transport protection.
- Test token reuse, wrong passwords, wrong server identity and backend failure.
- Keep secrets out of logs and review material.
This is not a deployable eap.conf file and has not been executed.
Outline references: FreeRADIUS: AD integration (4.0 documentation);
๐ Summary
Both EAP-GTC and EAP-MSCHAPv2 solve different integration problems. GTC carries a text response and relies on authenticated channel protection and backend token/password checks; OTP is not inherently phishing-resistant. MSCHAPv2 provides legacy password-derived challenge-response, not modern immunity to offline attacks. Match the EAP method, transport, client, AAA service and identity backend explicitly. For a new supported design, evaluate EAP-TLS with sound certificate lifecycle and private-key management. No method label alone guarantees a secure deployment. Source: Microsoft: Credential Guard considerations;
✔ Verified client support
✔ Compatible password/token backend
✔ Supported PEAP or IKEv2 profile
✔ Verified IKEv2/Windows policy
✔ Protected legacy 802.1X profile
✔ Migration plan for legacy password use
✔ Certificate-based
✔ Protect keys; passwords are not the only risk
✔ Evaluate support and certificate lifecycle