3.10. EAP configuration

This section introduces the parameters used for EAP configuration. EAP parameters are available for several AuthBys. For more information about supported EAP methods, see Section 17. Extensible Authentication Protocol (EAP).
Important
System certificate store is not used. The configuration parameters for TLS based EAP methods must cover all CAs, CRLs and other settings that are needed.

3.10.1. EAPType

This optional parameter specifies which EAP authentication methods are permitted when EAP authentication is requested by the NAS. See RFCs 3748, 5216, and 2433 for more details. When an EAP identity request is received, Radiator replies with the first EAP type given. If the NAS requests another type, it is permitted only if it appears in EAPType list. It is ignored and has no effect unless EAP authentication is requested. This parameter is not set by default, which means that Radiator does not perform EAP authentication by default. The allowed values for EAPType are given by the following table.

Table 6. Allowed values for EAPType

EAPType Explanation
MD5 This is the default value. Use MD5-Challenge as per RFC 3748. This can be used with any authentication method that provides a plaintext password, such as <AuthBy FILE>, <AuthBy SQL>, and <AuthBy LDAP2>. See goodies/eap_md5.cfg for example configuration. MD5-Challenge is an old alias for MD5.  
OTP Use One-time-password authentication as per RFC 3748. This requires a one-time password authenticator such as <AuthBy OTP>. One-Time-Password is an old alias for OTP.
GTC Use Generic Token authentication as per RFC 3748. This requires a token-based authenticator such as <AuthBy OTP>, <AuthBy ACE>, or <AuthBy RSAAM>. Generic-Token is an old alias for GTC.
TLS Use Transport Layer Security (TLS). This can be used with any authentication method. TLS checks that the client certificate is valid and has a short enough certificate chain to the root certificate. It requires an SSL certificate for the server and one on each client requiring authentication. See goodies/eap_tls.cfg for example configuration.
TTLS Use Tunnelled TLS as required by Funk Odyssey wireless clients. This can be used with any authentication method. TTLS does not usually involve a client certificate, but the client may be configured to check the server's SSL certificate. See goodies/eap_ttls.cfg for example configuration.
PEAP Use PEAP tunnel as used by Windows XP and others. This can be used with any authentication method. See goodies/eap_peap.cfg for example configuration.
LEAP This is compatible with Cisco LEAP authentication, a proprietary authentication protocol. LEAP requires an authenticator that supplies plaintext passwords, such as <AuthBy FILE>, <AuthBy SQL>, or <AuthBy LDAP2>, or MSCHAPV2, such as <AuthBy LSA>.
SIM Use EAP-SIM which authenticates against SIM cards. This requires the additional EAP-SIM bundle from Radiator Software.
AKA Use EAP-AKA. This requires the additional EAP-SIM bundle from Radiator Software, which contains support for EAP-AKA.
AKA-PRIME Use EAP-AKA'. This requires the additional EAP-SIM bundle from Radiator Software, which contains support for EAP-AKA'.
MSCHAP-V2 Use EAP-MSCHAPV2, which is commonly tunneled inside PEAP
TNC Support EAP-TNC, a protocol for assessing the security posture of end points.
FAST Use EAP-FAST, a rarely-used protocol from Cisco.
PAX Use EAP-PAX (Password Authenticated Exchange)
PSK Use EAP-PSK (Pre-Shared Key).
PWD Use EAP-pwd, a method which uses a shared password for authentication.

3.10.2. EAPContextTimeout

This optional parameter specifies the maximum time period in seconds an EAP context is retained. The default value is 120 seconds. Usually there is no need to change this.

3.10.3. EAPAnonymous

For tunnelling EAP types, such as TTLS and PEAP, this optional parameter specifies the User-Name that is used in the RADIUS request resulting from the EAP inner request. The default value is anonymous. Special characters can be used. %0 is replaced by the EAP identity of the inner EAP request.
This parameter is useful when proxying the inner authentication. If there is a realm in the EAPAnonymous name, it is used to choose a local Realm to handle the inner authentication.

3.10.4. EAPTLS_CAFile

For TLS based EAP types such as TLS, TTLS and PEAP, this parameter specifies the name of a file containing Certificate Authority (CA) root certificates that may be required to validate TLS client certificates. The certificates must be in PEM format. The file can contain several root certificates for one or more CA's. Radiator looks for root certificates first in EAPTLS_CAFile, then in EAPTLS_CAPath, so there usually is no need to set both.
EAPTLS_CAFile is expected to contain a stack of CA one or more CA certificates that will be used to validate client certificates. The list of CA issuers in that is also sent to the client during handshaking to tell the client which certificates Radiator accepts.
Special characters are supported.

3.10.5. EAPTLS_CAPath

For TLS based EAP types such as TLS, TTLS and PEAP, this parameter specifies the name of a directory containing CA root certificates that may be required to validate TLS client certificates. Radiator looks for root certificates first in EAPTLS_CAFile, then in EAPTLS_CAPath, so there usually is no need to set both. When Certificate Revocation List (CRL) checks are enabled, this directory is also used by TLS library to look for CRL files. Special characters are supported.
The certificates and CRLs must be in PEM format, one per file. The file name has a special format. Setting up this directory is described in Section 3.11.3. TLS_CAPath.

3.10.6. EAPTLS_CertificateFile

For TLS-based EAP types, such as TLS, TTLS and PEAP, this parameter specifies the name of a file containing the RADIUS server certificate. The server certificate is sent to the EAP client and validated by the client during EAP authentication. The certificate file may be in PEM or ASN1 format, depending on the setting of the EAPTLS_CertificateType parameter. The certificate file can also contain the server's TLS private key if the EAPTLS_PrivateKeyFile parameter specifies the same file. If the server certificate is a chain of certificates, use EAPTLS_CertificateChainFile instead.
Special characters are supported.
Important
System certificate store is not used. The TLS configuration parameters must cover all CAs, CRLs and other settings that are needed.

3.10.7. EAPTLS_CertificateChainFile

For TLS-based EAP types, such as TLS, TTLS and PEAP, this parameter specifies the name of a file containing a certificate chain for the Radius server certificate. The server certificate chain is sent to the EAP client and validated by the client during EAP authentication. The certificate chain must be in PEM format. EAPTLS_CertificateChainFile can be used instead of EAPTLS_CertificateFile for explicitly constructing the server certificate chain which is sent to the client.
Use EAPTLS_CertificateChainFile to specify a chain of certificates that the server uses to identify itself to the client. If there is only one server certificate, and not a chain, you can use EAPTLS_CertificateFile instead.
Special characters are supported.

3.10.8. EAPTLS_CertificateType

For TLS-based EAP types, such as TLS, TTLS and PEAP, this optional parameter specifies the format of the EAPTLS_CertificateFile. The options are:
  • PEM
  • ASN1
The default value is ASN1.
Special characters are supported.

3.10.9. EAPTLS_PrivateKeyFile

For TLS-based EAP types, such as TLS, TTLS, and PEAP, this optional parameter specifies the name of the file containing the server's private key. It can be located in the same file as the server certificate (EAPTLS_CertificateFile). If the private key is encrypted,which is usually the case, EAPTLS_PrivateKeyPassword is the key to decrypt it.
Special characters are supported.

3.10.10. EAPTLS_PrivateKeyPassword

For TLS-based EAP types, such as TLS, TTLS, and PEAP, this optional parameter specifies the password that is used to decrypt the EAPTLS_PrivateKeyFile.
Special characters are supported.

3.10.11. EAPTLS_Protocols

This specifies the comma-separated list of TLS protocols that are permissible for TLS-based EAP types. Currently supported protocols are:
  • TLSv1
  • TLSv1.1
  • TLSv1.2
  • TLSv1.3
    CAUTION
    TLSv1.3 is not enabled by default with Radiator yet. Testing reports are welcome. Net::SSLeay 1.83 or later is required if you use Radiator with SSL/TLS library that has TLSv1.3 enabled. Net::SSLeay 1.92 or later is recommended.
There is no default value. If this parameter is not set, all protocols, which are supported by the SSL/TLS library within Radiator, except of TLSv1.3, are permitted.
The available TLS protocols depend on your system's TLS library. See Radiator debug log for details when the first EAP message is processed by this AuthBy.
# Do not allow TLSv1
EAPTLS_Protocols TLSv1.1, TLSv1.2

3.10.12. EAPTLS_Ciphers

This parameter specifies which subset of cipher suites is permissible for TLS-based EAP types. It uses the standard OpenSSL string format. The default is DEFAULT:!EXPORT:!LOW.
# Exclude cipher suites using RC4 too
EAPTLS_Ciphers DEFAULT:!EXPORT:!LOW:!RC4
When SSL library supports security levels, a level can be set for each configuration clause together with cipher string. For more information about security levels, see Section 3.10.13. EAPTLS_SecurityLevel
# System default level 2 is too strict for this module
EAPTLS_Ciphers DEFAULT:!EXPORT:!LOW@SECLEVEL=1

3.10.13. EAPTLS_SecurityLevel

EAPTLS_SecurityLevel is an integer parameter that sets the SSL library security level for the enclosing clause. Security levels were added in OpenSSL 1.1.0 and are detailed in OpenSSL manual page SSL_CTX_set_security_level. There is no default and the system default is used. This parameter may be needed if you see unexpected TLS errors with older clients.
Security level can also set together with ciphers in which case EAPTLS_SecurityLevel is not needed. For more information, see Section 3.10.12. EAPTLS_Ciphers
# The default on this system, 2, is too strict for our clients,
# lower it for this Radiator module
EAPTLS_SecurityLevel 1

3.10.14. EAPTLS_RandomFile

For TLS-based EAP types, such as TLS, TTLS, and PEAP, this optional parameter specifies the name of a file containing randomness. Usually there is no need to set this parameter.
Special characters are supported.

3.10.15. EAPTLS_DHFile

For TLS-based EAP types, such as TLS, TTLS, and PEAP, this optional parameter specifies the name of the DH group. Usually there is no need to set this parameter. It is required if you use ephemeral DH keys.
Special characters are supported.

3.10.16. EAPTLS_ECDH_Curve

For TLS-based EAP types, this optional parameter enables ephemeral EC keying by specifying the name of the elliptic curve to use. The default is to not enable ephemeral EC keying.
# Curves often have multiple aliases. Need OpenSSL name here.
# openssl ecparam -list_curves
EAPTLS_ECDH_Curve prime256v1

3.10.17. EAPTLS_AllowUnsafeLegacyRenegotiation

This optional parameter enables legacy insecure renegotiation between OpenSSL and unpatched clients or servers. It is used with TLS-based EAP types, such as TLS, TTLS, and PEAP, and with OpenSSL version 0.9.8m or later. OpenSSL 0.9.8m and later always attempts to use secure renegotiation as described in RFC5746. This counters the prefix attack described in CVE-2009-3555 and elsewhere.

3.10.18. EAPTLS_MaxFragmentSize

For TLS-based EAP types, such as TLS, TTLS, and PEAP, this optional parameter specifies the maximum size in octets permitted for each TLS message fragment. The default value is 2048, but many EAP clients, routers, and wireless Access Points have limitations that require EAPTLS_MaxFragmentSize to be set as low as 1000 or less. Setting this number too small can result in excessive RADIUS request round trips during EAP TLS authentication. This slows down the authentication process. Setting this number too large can result in failure to complete TLS authentication for some types of clients and devices. Many customers find that 1300 is a good compromise.
The EAP packet that is encapsulated inside EAP-Message and all other radius attributes must not exceed one Ethernet frame because EAP does not support fragmentation.
Depending on the number of other RADIUS attributes your switches or WLAN controllers send to the RADIUS servers, you can increase EAPTLS_MaxFragmentSize, which may result in fewer RADIUS requests in the EAP conversation which reduces the authentication time and lowers to load on both the RADIUS client (switch, WLAN controller) and RADIUS server.
If incoming RADIUS requests have Framed-MTU that is less than EAPTLS_MaxFragmentSize, then Radiator uses the reported Framed-MTU to limit fragment size when doing TLS, TTLS, PEAP, and PSK.
Special characters are supported.

3.10.19. EAPTLS_CRLCheck

This optional flag parameter specifies if Certificate Revocation List must be checked for revoked certificates. It is used with TLS-based EAP types, such as TLS, TTLS, and PEAP, that have been configured to check client certificates.

3.10.20. EAPTLS_CRLCheckUseDeltas

This optional flag parameter specifies if Delta Certificate Revocation List must be checked for revoked certificates in addition to base CRL. It is used with TLS-based EAP types, such as TLS, TTLS, and PEAP, that have been configured to check client certificates. Currently delta CRL files are loaded with EAPTLS_CRLFile parameter, similar to base CRL files.
CAUTION
EAPTLS_CRLCheckUseDeltas is currently experimental.
Before enabling EAPTLS_CRLCheckUseDeltas, note the following requirements and restrictions:
  • EAPTLS_CRLCheck must be enabled in Radiator configuration
  • Both base and delta CRLs must use CRL v2 format
  • Do not use delta CRL files without enabling EAPTLS_CRLCheckUseDeltas
  • OpenSSL indicates only one delta CRL file can be used
  • Review OpenSSL notes about delta CRLs on OpenSSL manual page for X509_VERIFY_PARAM_set_flags. Opens in new window
  • Test that your base and delta CRL work when CRL files are updated or refreshed
Please contact Radiator support about success or possible problems there might be with delta CRLs.

3.10.21. EAPTLS_CRLCheckAll

For TLS-based EAP types, this optional flag parameter enables CRL checks for the entire certificate chain. EAPTLS_CRLCheckAll is not enabled by default. The CRL files for the intermediate CAs must be found, otherwise the certificate check fails. See Section 3.10.22. EAPTLS_CRLFile for the details.
Note
EAPTLS_CRLCheck must be enabled for any certificate checks to happen.

3.10.22. EAPTLS_CRLFile

For TLS-based EAP types, such as TLS, TTLS, and PEAP, and where CRL checking has been enabled with EAPTLS_CRLCheck, this optional parameter specifies one or more CRL files that are used to check client certificates for revocation. These files are also used when EAPTLS_CRLCheckAll is enabled. Special characters are supported.
If a CRL file is not found, or if the CRL says the certificate has been revoked, TLS authentication will fail with an error:
SSL3_GET_CLIENT_CERTIFICATE:no certificate returned
To ease automation, CRLs may follow a file naming convention where each CRL file uses a special file name in EAPTLS_CAPath directory. Setting up this directory is described in Section 3.11.3. TLS_CAPath. In this case you do not need to configure EAPTLS_CRLFile.
If CRLs are not stored in the CAPath directory, one or more CRLs can be named with multiple EAPTLS_CRLFile parameters. The intended way CRL reloading works is this: Each CRL file named with EAPTLS_CRLFile will be automatically reloaded and reread at the start of each new EAP-TLS, EAP-TTLS or PEAP session if the modification date of the named CRL file has changed since the last time it was loaded. If the CRL for a particular issuer changes, it is sufficient to replace the existing CRL file with the newer version and Radiator will reload the new CRL when required.
Tip
Operating system wildcards are supported, so you can name multiple CRLs with a single wildcard like:
EAPTLS_CRLFile %D/crls/revocations-*.pem

3.10.23. EAPTLS_SessionResumption

For TLS-based EAP types such as TLS, TTLS, and PEAP, this optional parameter enables or disables support for TTLS Session Resumption and PEAP Fast Reconnect. It is enabled by default.
# Disable session resumption
EAPTLS_SessionResumption 0
Special characters are supported.

3.10.24. EAPTLS_SessionResumptionLimit

For TLS-based EAP types such as TLS, TTLS, and PEAP, this optional parameter allows you to limit how long after the initial session that a session can be resumed. The time is given in seconds and the default value is 43200 seconds (12 hours).
Special characters are supported.

3.10.25. EAPTLS_SessionContextId

For TLS-based EAP types, such as TLS, TTLS, and PEAP, this optional parameter allows you to set the context within which the TLS session resumption is allowed. The default value is %1:%3:%n, which means that TLS session resumption is allowed if the resumed and the full authentication are processed by the same Handler, EAP Type, and original user name.
Special characters are supported. %0 is replaced by value referring to Client, %1 is replaced by value referring to Handler, %2 is replaced by value referring to AuthBy, and %3 with the current EAP type number.
Here is an example of using EAPTLS_SessionContextId:
# Allow resumption when using the same Client and Handler
EAPTLS_SessionContextId %0%1

3.10.26. EAPTLSRewriteCertificateCommonName

For TLS-based EAP types such as TLS, TTLS, and PEAP, this optional parameter allows you to rewrite the Common Name in the client's TLS certificate before using it to find the user name in the Radiator database:
EAPTLSRewriteCertificateCommonName s/testUser/mikem/

3.10.27. EAPTLS_PEAPVersion

For PEAP, this optional parameter allows you to control which version of the draft PEAP protocol to honour. The default value is 0. Set it to 1 for unusual clients.

3.10.28. EAPTLS_PEAPBrokenV1Label

This optional parameter makes PEAP Version 1 support compatible with non-standard PEAP V1 clients that use the old TLS encryption labels. These labels appear to be used frequently, due to Microsoft's use of the incorrect label in its V0 client.

3.10.29. EAP_PEAP_MSCHAP_Convert

For EAP-PEAP MSCHAPV2 authentication, this optional parameter tells Radiator to convert the inner EAP-MSCHAPV2 request into a conventional RADIUS-MSCHAPV2 request. The new RADIUS-MSCHAPV2 request is re-despatched to the Handlers, where it is detected and handled with <Handler ConvertedFromEAPMSCHAPV2= 1>.
This is useful when proxying PEAP-MSCHAPV2 inner requests to a remote RADIUS server that can handle ordinary RADIUS-MSCHAPV2, but not EAP authentication. See goodies/eap_peap_mschap_proxy.cfg in your distribution for an example of how to configure convert and proxy system.

3.10.30. EAPTLS_RequireClientCert

This optional parameter forces TTLS and PEAP to require a valid client certificate to be presented by the client. TLS always requires a valid client certificate, regardless of the setting of this parameter. In this case, valid means that the certificate is within its validity dates and has been signed by a CA for which Radiator has a root certificate.

3.10.31. EAPTLS_PolicyOID

For TLS based EAP types such as TLS, TTLS, and PEAP, when the client presents a certificate, this optional parameter enables certificate policy checking. It also specifies one or more policy OIDs that must be present in the certificate path. It sets the 'require explicit policy' flag as defined in RFC3280. Using this requires Perl Net::SSLeay module 1.37 or later.
When multiple EAPTLS_PolicyOID parameters are configured, the peer certificate needs to match only one of the configured OIDs, not all of them.
# Require just one policy
EAPTLS_PolicyOID 1.3.6.1.4.1.9048.33.2

3.10.32. EAP_LEAP_MSCHAP_Convert

For LEAP authentication, this optional parameter tells Radiator to convert the LEAP request into a conventional RADIUS-MSCHAP request. The new RADIUS-MSCHAP request is re-despatched to the Handlers, where it is detected and handled with <Handler ConvertedFromLEAP=1>.
This is useful for proxying LEAP requests to a remote RADIUS server that cannot handle LEAP, but which can handle RADIUS-MSCHAP. See goodies/eap_leap_proxy.cfg in your distribution for an example of how to configure such a convert and proxy system.

3.10.33. EAP_GTC_MaxLength

This parameter specifies the maximum length of EAP GTC token that is accepted from the client. The default value is 253, which is compatible with RADIUS protocol.

3.10.34. EAP_GTC_PAP_Convert

For EAP-GTC authentication, this optional parameter tells Radiator to convert the EAP-GTC request into a conventional RADIUS-PAP request. The new RADIUS-PAP request is re-despatched to the Handlers, where it is detected and handled with <Handler ConvertedFromGTC=1>.

3.10.35. EAP_MSCHAPv2_UseMultipleAuthBys

Note
Avoid using this parameter. It will probably be deprecated if additional features, such as support for password change, are implemented in EAP MSCHAP-V2. If you need support for multiple user database lookups, use EAP_PEAP_MSCHAP_Convert instead. For more information, see Section 3.10.29. EAP_PEAP_MSCHAP_Convert.
This optional parameter is used with EAP MSCHAP-V2 authentication. It allows using multiple AuthBys within one Handler or AuthBy GROUP. If this parameter is not set, using multiple EAP MSCHAP-V2 causes an authentication failure. To avoid this, define EAP_MSCHAPv2_UseMultipleAuthBys in all AuthBys within Handler or AuthBy GROUP. This flag is not set by default.
Here is an example of using EAP_MSCHAPv2_UseMultipleAuthBys:
<Handler>
 AuthByPolicy ContinueUntilAcceptOrChallenge
  <AuthBy SQL>
    EAPType MSCHAP-V2
    EAP_MSCHAPv2_UseMultipleAuthBys
  </AuthBy>
   <AuthBy SQL>
    EAPType MSCHAP-V2
    EAP_MSCHAPv2_UseMultipleAuthBys
  </AuthBy>
</Handler>

3.10.36. EAPTLS_NoCheckId

For EAP-TLS authentication, this optional parameter prevents matching the User-Name to certificate CN or subjectAltName and then using the matched value to fetch the user from the user database. EAPTLS_CommonNameHook and EAPTLSRewriteCertificateCommonName are not run and the user's check and reply attributes are not applied because no user lookup is done. This allows Radiator to mimic the behaviour of some other RADIUS servers.
The certificate will be accepted based only on the validity dates and the verification chain to the root certificate. EAPTLS_OCSPCheck is allowed and EAPTLS_CertificateVerifyHook is run.

3.10.37. EAPTLS_CertificateVerifyHook

For EAP-TLS authentication, this optional parameter specifies a Perl function that is called after the request user name or identity has been matched with the certificate CN. It passes the certificate and various other details, and returns a different user name which is used to do the user database lookup.
The function is passed the following arguments:
  • $_[0]: $matchedcn, the CN that matched the user name or identity with or without the domain name. $matchedcn is the CN in the certificate that was matched against either the user name or EAP identity. It is normally used as the user name to do the user database lookup, but you can return a new name from this function.
  • $_[1]: $x509_store_ctx, the EAP SSLEAY store context (you can pass this to Net::SSLeay::X509_STORE_CTX_get_current_cert)
  • $_[2]: $cert, the current certificate, result of Net::SSLeay::X509_STORE_CTX- _get_current_cert($x509_store_ctx)
  • $_[3]: $subject_name, the certificates subject name, result of &Net::SSLeay::X509_get_subject_name($cert)
  • $_[4]: $subject, the certificate subject, result of &Net::SSLeay::X509_NAME_oneline($subject_name)
  • $_[5]: $p, the current Radius::Radius request
The function is expected to return a new value for $matchedcn, which is used to do the user database lookup. If it returns undef, the certificate verification is deemed to fail with the OpenSSL error X509_V_ERR_APPLICATION_VERIFICATION.

3.10.38. EAPTLS_CertificateVerifyFailedHook

EAPTLS_CertificateVerifyFailedHook specifies a Perl function that is called if the certificate cannot be verified. It is an optional parameter and is used with EAP-TLS authentication. It is passed the certificate (if present), and various other details.
The peer certificate $cert is not always present. An example of such case is a policy OID mismatch .
EAPTLS_CertificateVerifyFailedHook is passed the following arguments:
  • $_[0]: $verify_error
    This is the EAP SSLEAY store context verification code.
  • $_[1]: $x509_store_ctx
    This is the EAP SSLEAY store context.
  • $_[2]: $cert
    This is the current certificate. May be undefined.
  • $_[3]: $subject_name
    This is the certificate's subject name. Undefined when $cert is undefined.
  • $_[4]: $subject
    This is the certificate subject. Undefined when $cert is undefined.
  • $_[5]: $p
    This is the current Radius::Radius request.
EAPTLS_CertificateVerifyFailedHook must return a single value. This value is used as an OpenSSL error code to set the verify result code as follows:
  • > 0: Non-zero error code
    This is a new verification result code.
  • 0
    This changes verification failure to verification success.
  • < 0
    The verification process is immediately stopped with "verification failed" state.
  • Undefined
    This is handled as an OpenSSL error X509_V_ERR_APPLICATION_VERIFICATION.
Here is a example of using EAPTLS_CertificateVerifyFailedHook. This configuration accepts all certificates. Any additional authorisation must be done later.
EAPTLS_CertificateVerifyFailedHook sub { return 0; }
The following example allows expired certificates. 10 is X509_V_ERR_CERT_HAS_EXPIRED.
EAPTLS_CertificateVerifyFailedHook sub { \
                if ($_[0] == 10) { return 0; } else { return $_[0]; } }
Note
This parameter may cause security issues if not used properly. Use it only in special cases.

3.10.39. EAPTLS_CommonNameHook

This optional parameter specifies a Perl hook that is used to choose the authenticated CN from the client certificate during EAP-TLS authentication. Normally, EAP-TLS attempts to match each CN in the client certificate (after EAPTLSRewriteCertificateCommonName is executed) against the User-Name (with and without any trailing @domain) and the EAP identity (with and without any trailing @domain). If a match is found, that is the authenticated CN, and it is the name that is be used to look up the user name in the user database.
If EAPTLS_CommonNameHook is defined, it returns the user name that matches with the CN.
It is called for each CN in the client certificate with the following arguments:
  • $_[0]: the CN
  • $_[1]: the User-Name from the incoming request
  • $_[2]: the EAP Identity of the TLS handshake
It is expected to return the matched CN or undef if no match is found.

3.10.40. EAPTLS_TraceState

EAPTLS_TraceState is a flag parameter that turns on TLS state tracing for TLS-based EAP modules such as EAP-TLS, EAP-TTLS and PEAP. This may be useful for additional debugging of TLS handshake processing. EAPTLS_TraceState is not set by default.
Radiator 4.27 with Net::SSLeay 1.92 and later automatically enables TLS handshake message logging when log level is set to DEBUG or higher with Trace or PacketTrace parameter. When TLS message logging is enabled, TLS state tracing can also be enabled by setting EAPTLS_TraceState. TLS state and messaging logging contain similar information and in most cases it's not useful have them both enabled.
Here is an example of using EAPTLS_TraceState:
# Turn on TLS state tracing for this AuthBy
EAPTLS_TraceState

3.10.41. EAPTLS_CopyToInnerRequest

This parameter overrides the default list of attributes that is copied from an outer EAP request, such as PEAP, EAP-TTLS, or EAP-FAST, to an inner request. The default list of attributes for PEAP and EAP-FAST is NAS-IP-Address NAS-Identifier NAS-Port Calling-Station-Id. The default list is empty for EAP-TTLS.
Here is an example of using EAPTLS_CopyToInnerRequest:
EAPTLS_CopyToInnerRequest Calling-Station-Id, Called-Station-Id

3.10.42. EAPTLS_CAPartialChain

This is a flag parameter. It is used with TLS-based EAP types, such as TLS, TTLS, and PEAP. When it is enabled, only a partial CA certificate chain is required to validate TLS client certificates. This is not set by default.

3.10.43. EAPTLS_UseCADefaultLocations

This is a flag parameter. It is used with TLS-based EAP types, such as TLS, TTLS, and PEAP. When set, the default locations are used for loading CA certificates. This is not set by default.
The default CA certificate directory is certs/ in the default OpenSSL directory. Use SSL_CERT_DIR environment variable to override the default location. The default CA certificate file is cert.pm in the default OpenSSL directory. Use SSL_CERT_FILE environment variable to override the default file name.

3.10.44. EAPTLS_NoClientCert

This is a flag parameter. It is used with TLS-based EAP types, such as TTLS and PEAP. When set, it disables loading of any CA certificates for client certificate verification. This allows you to simplify PEAP and EAP-TTLS configuration when client certificates are not requested with EAPTLS_RequireClientCert. Do not set this if EAP-TLS support is needed.

3.10.45. EAPTLS_OCSPCheck

This optional flag parameter is alternative to EAPTLS_OCSPAsyncCheck. This defines if Online Certificate Status must be checked for revoked certificates. It is used only with TLS-based EAP types, such as TLS, TTLS, and PEAP, that are configured to check client certificates. Using this parameter requires LWP::UserAgent and HTTP::Request Perl modules.
Here are the requirements for using OCSP parameters:
  • OpenSSL 1.0.0 or later
  • Net::SSLeay 1.59 or later. Net::SSLeay 1.82 or later is recommended.
    If you use EAPTLS_OCSPStapling, Net::SSLeay 1.82 or later is required.

3.10.46. EAPTLS_OCSPAsyncCheck

This optional flag parameter defines if Online Certificate Status must be checked asynchronously for revoked certificates. This is used only with TLS-based EAP types, such as TLS, TTLS, and PEAP, that are configured to check client certificates. Using this parameter requires HTTP::Async and HTTP::Request Perl modules.
EAPTLS_OCSPAsyncCheck is alternative to EAPTLS_OCSPCheck, the same requirements apply also with EAPTLS_OCSPAsyncCheck. For more information, see Section 3.10.45. EAPTLS_OCSPCheck.

3.10.47. EAPTLS_OCSPStapling

This optional flag parameter defines if Radiator provides OCSP staple with its server certificate. This is used only with TLS-based EAP types, such as TLS, TTLS, and PEAP. Using this parameter requires LWP::UserAgent and HTTP::Request Perl modules.
Using EAPTLS_OCSPStapling does not require that EAPTSL_OCSPCheck or EAPTSL_OCSPAsyncCheck is set, but the same requirements apply when you use only TLS_OCSPStapling. See the requirements list in Section 3.10.45. EAPTLS_OCSPCheck.

3.10.48. EAPTLS_OCSPURI

This string defines the OCSP URI that is used for all OCSP queries.

3.10.49. EAPTLS_OCSPFailureBackoffTime

If the OCSP query fails, the query is not sent again to the failed OCSP URI. This integer defines the time for how long the failed OCSP URI is not contacted. The unit is seconds.

3.10.50. EAPTLS_OCSPStrict

This optional flag parameter defines if Online Certificate Status must be checked successfully. This is used only with TLS-based EAP types, such as TLS, TTLS, and PEAP, that are configured to check client certificates.
When EAPTLS_OCSPStrict is set, the certificate check must be successful in all phases. Here are some examples when the certificate check fails if EAPTLS_OCSPStrict is set:
  • EAPTLS_OCSPURI is not set and the certificate does not have OCSP URI.
  • OCSP responder is not responding.
  • OCSP responder cannot be reached.

3.10.51. EAPTLS_OCSPCacheTime

This integer defines the time for how long OCSP replies are save in the cache. The unit is seconds. The default value is 1200, that is 20 minutes.

3.10.52. EAPTLS_OCSPCacheSize

This integer defines the maximum number of OCSP cache entries. The default value is 1000.

3.10.53. EAPFAST_PAC_Lifetime

For EAP-FAST, this parameter specifies the maximum lifetime for each PAC.

3.10.54. EAPFAST_PAC_Reprovision

For EAP-FAST, this parameter specifies the time after which a PAC is re-provisioned.

3.10.55. EAP_TTLS_AllowInRequest

For EAP-TTLS authentication, this optional parameter tells Radiator to allow only the specified attributes in requests from EAP-TTLS clients. Attributes that are not allowed are ignored and logged on debug level.
By default, the following attributes are allowed in requests.
  • User-Name
  • User-Password
  • CHAP-Password
  • CHAP-Challenge
  • EAP-Message
  • MS-CHAP-Response
  • MS-CHAP-Challenge
  • MS-CHAP2-Response
These are the attributes from EAP-TTLS RFC 5281 except of the password change related attributes, which are currently not allowed by default.
Here is an example of using EAP_TTLS_AllowInRequest:
# Also allow our vendor specific attribute in EAP-TTLS requests
EAP_TTLS_AllowInRequest OSC-AVPAIR, User-Name, User-Password, \
         CHAP-Password, CHAP-Challenge, EAP-Message, \
         MS-CHAP-Response, MS-CHAP-Challenge, MS-CHAP2-Response

3.10.56. EAP_TTLS_AllowInReply

For EAP-TTLS authentication, this optional parameter tells Radiator to allow only the specified attributes in replies to EAP-TTLS clients. Attributes that are not allowed are silently ignored.
By default, the following attributes are allowed in requests:
  • EAP-Message
  • MS-CHAP2-Success
These are the attributes from EAP-TTLS RFC 5281 except of the password change related attributes, which are currently not allowed by default.
Here is an example of using EAP_TTLS_AllowInReply:
# Also allow our vendor specific attribute in EAP-TTLS replies
EAP_TTLS_AllowInReply OSC-AVPAIR, EAP-Message, MS-CHAP2-Success

3.10.57. EAP_Identity_MaxLength

This is an integer that specifies the maximum length of EAP identity. The default value is 253.

3.10.58. EAP_PWD_PrepMethod

This parameter specifies a password preparation method to be used in EAP-pwd authentication. RFC 5931, that defines EAP-pwd, specifies three password pre-processing methods. RFC 8146 specifies additional methods which are not implemented by Radiator yet. Preparation methods are configured with an optional parameter EAP_PWD_PrepMethod. The default value is None. The currently available methods are shown in the table below.

Table 7. Allowed values for EAP_PWD_PrepMethod

Preparation method Explanation
None Password is used as is. No additional preparation is done. The password must be stored in plain text, including rcrypt, format.
NtHash Password is processed to produce the output PasswordHashHash, as defined in RFC 2759. The password must be stored in plain text, including rcrypt, or NT hashed format. This requires Digest::MD4 Perl module.
SASLprep Password is processed according to RFC 5931 SASLprep specification. The password must be stored in plain text, including rcrypt, format. This requires Authen::SASL::SASLprep version 1.100 or later.
CAUTION
EAP-pwd clients may not support other methods than None. For example, wpa_supplicant 2.6+fixes is needed for the NtHash method to work.
Here is an example of using EAP_PWD_PrepMethod:
# Our passwords are stored in {nthash} prefixed format
EAP_PWD_PrepMethod NtHash

3.10.59. UsernameCharset

This optional parameter checks that every user name consists only of the characters in the specified character set. This can be useful to reject requests that have user names that cannot be valid. The value of the parameter is a Perl character set specification. See your Perl reference manual for details about how to construct Perl character set specifications. Note that the some special characters must be escaped with a backslash. This parameter is not set by default and no character set check is done.
UsernameCharset is available as a global and Handler level parameter. The character set checks are done for both User-Name attribute and EAP identity.
When a request is processed by a Handler, User-Name attribute must pass both global and per Handler UsernameCharset checks. When an EAP-Response/Identity message is handled by an AuthBy, the EAP identity must pass both global and per Handler UsernameCharset checks. The Handler is the last Handler that processed the request before it was passed to the AuthBy.
This example permits only alphanumeric, period, underscore, the @-sign, and dash. Note that a dash at the end of character class needs not to be escaped with a backslash:
UsernameCharset a-zA-Z0-9._@-

3.10.60. NoEAP

This optional parameter disables EAP authentication in the specific AuthBy. If the AuthBy would otherwise do EAP authentication, this parameter forces it to do conventional authentication. This is useful for performing additional checks besides EAP authentication, for example, when doing MAC Address whitelist checking as well as EAP authentication.
AuthByPolicy ContinueWhileAccept
# Check the MAC address is valid..
<AuthBy FILE>
      NoEAP
      AuthenticateAttribute Calling-Station-Id
      Filename ...
      ...
</AuthBy>
# then check the username and password, perhaps by EAP
<AuthBy LDAP2>
      EAPType ....
      ....
</AuthBy>

3.10.61. PreHandlerHook

This optional parameter allows you to define a Perl function that is called during packet processing. It can be configured within several types of clauses for which its functionality is slightly different:
  • Client clause
    PreHandlerHook is called for each request after per-Client user name rewriting and duplicate rejection, and before the request is passed to a Realm or Handler clause.
  • AuthBy clause
    The functionality depends on the used EAP authentication type:
    • PEAP, EAP-TTLS, EAP-FAST
      PreHandlerHook specifies a Perl hook to be called before the inner request is re-dispatched to a matching Realm or Handler.
    • LEAP
      If EAP_LEAP_MSCHAP_Convert flag is set, PreHandlerHook specifies a Perl hook to be called before the converted request is re-dispatched to a matching Realm or Handler.
    • EAP-MSCHAPv2
      If EAP_PEAP_MSCHAP_Convert flag is set, PreHandlerHook specifies a Perl hook to be called before the converted request is re-dispatched to a matching Realm or Handler.
    • EAP-GTC
      If EAP_GTC_PAP_Convert flag is set, PreHandlerHook specifies a Perl hook to be called before the converted request is re-dispatched to a matching Realm or Handler.
  • AuthBy DYNAUTH clause
    PreHandlerHook is called for each request created by the clause before the request is passed to a Realm or Handler clause.
  • ServerRADSEC clause
    PreHandlerHook is called for each request after global and per-ServerRADSEC user name rewriting and before the request is passed to a Realm or Handler clause.
  • ServerDIAMETER clause
    PreHandlerHook is called for each request received by ServerDIAMETER before the request is passed to a Realm or Handler clause.
  • ServerTACACSPLUS clause
    PreHandlerHook is called for each request before it is passed to a Realm or Handler clause. If a Client is found for the request, Client's PrehandlerHook is run before ServerTACASPLUS's PreHandlerHook. Global and per-Client user name rewriting and other processing is done before the hooks are run.
A reference to the request is passed as the only argument.
The hook code is compiled by Perl when Radiator starts up. Compilation errors in your hook code are reported to the log file at start-up time. Runtime errors in your hook are also reported to the log file when your hook executes. Multiline hooks with trailing backslashes (\) are parsed by Radiator into one long line. Therefore, do not use trailing comments in your hook.
PreHandlerHook can be an arbitrarily complicated Perl function, that might run external processes, consult databases, change the contents of the current request or many other things. Here is an example of using PreHandlerHook:
# Fake a new attribute into the request
PreHandlerHook sub { ${$_[0]}->add_attr('test-attr', \
      'test-value');}

3.10.62. EAPTLS_KeylogFilename

Sets the name of file Radiator uses for logging TLS key material. TLS key log allows fully decrypting EAP and Stream SSL/TLS sessions, including those that have forward security enabled. TLS keylog should only be used for debugging to avoid security issues.
The keylog file is written in NSS Key Log Format, also known as SSLKEYLOGFILE. Tools, such as Wireshark, can read this file and fully decrypt TLS, including TLS sessions that have forward security enabled.
# Enable when debugging, remove when in production
EAPTLS_KeylogFilename %L/eap-keylog
DANGER
Keylog should only be used for debugging to avoid security issues.