EAP Methods (authentication phase)

Extensible Authentication Protocol (EAP) methods are configured inside an authentication block by adding an eap { ... } container which lists one or more concrete EAP methods. Each EAP method may establish a TLS tunnel and optionally negotiate an inner (non‑EAP) credential exchange such as PAP, CHAP, or MSCHAPv2.

authentication {
    backend "USERS";
    eap {
        eap-tls {
            tls {
                certificate "EAP_SERVER_CERT";
                certificate_key "EAP_SERVER_KEY";
                client_ca_certificate "CLIENTS_CA";
                require_client_certificate true;
            }
        }
    }
}

eap (container)

Groups method blocks. Order can matter if the negotiation implementation prefers the first mutually supported method; keep the strongest methods first (e.g. eap-tls ahead of tunneled password methods).

eap-tls

Characteristics:

• Mutual certificate-based authentication (no passwords transmitted).
• Strong resistance against credential phishing and offline attacks.
• Requires PKI lifecycle (issuing, revocation, renewal).

eap-ttls

Inside inner_methods list only the credential methods you genuinely need. Exposing weak methods (PAP) is acceptable only inside the protected tunnel.

eap-peap

Similar to TTLS but with Microsoft centric compatibility. Standard inner usage:

• mschapv2 (dominant for Windows domain integration)
• Potentially eap-gtc (generic token card)

TLS Sub-Block

The tls { ... } block (common shape across all TLS-capable EAP methods) references objects from the global certificates clause. Example:

tls {
    certificate "EAP_SERVER_CERT";
    certificate_key "EAP_SERVER_KEY";
    # client_ca_certificate "CORP_DEVICES_CA";
    # require_client_certificate false;
}