EAP authentication is configured via
EAP is not a specific authentication mechanism, it is more like a framework for various authentication methods.
- Default method
-
The LCOS RADIUS server supports a range of EAP methods:
- MD5
- Defined in RFC 2284. EAP/MD5 is a simple challenge/response protocol. It does not cater for mutual authentication nor does it offer a dynamic key such as those required for 802.1X authentication in wireless networks (WLANs). Thus it is only used for the authentication of non-wireless clients or as a tunneled method as a part of TTLS.
- GTC
- Generic Token Card. EAP-GTC is an EAP method defined in RFC 3748, also known as PEAPv1. It is based on a text sent by an authentication server, which must be processed by a security token sent back. The entire transmission is not encrypted.
- MSCHAPv2
- As opposed to EAD/MD5, EAP/MSCHAPv2 does supports mutual authentication but does not support dynamic keys, making it just as prone to dictionary attacks as EAP/MD5. This method is usually used within PEAP tunnels.
- TLS
-
Defined in RFC 2716. The use of EAP/TLS requires the use of a root certificate, a device certificate and a private key in the device. EAP/TLS provides outstanding security and the dynamic keys necessary for wireless connections; its implementation is complex, however, because each individual client requires a certificate and a private key.
Important: Please note that the TLS implementation in LCOS does not support certificate chains or certificate revocation lists (CRLs).
- TTLS
-
TTLS is based on TLS; it does not make use of client certificates and it utilizes the existing TLS tunnel to authenticate the client. The LCOS RADIUS server supports the following TTLS methods:
- PAP
- CHAP
- MSCHAP
- MSCHAPv2
- EAP, preferably EAP/MD5
- PEAP
-
Similar to TTLS, PEAP is based on TLS and works with an EAP negotiation inside the TLS tunnel.
Important: Please note that although PEAP enables the use of any authentication method, the LCOS RADIUS server only supports MSCHAPv2 for tunneling.
- OTP
- One Time Password. This value must be used with EAP-OTP for two-factor authentication in the VPN, because with the LANCOM Advanced VPN Client the EAP method is specified by the EAP server.
- Tunnel server
- To process the tunneled EAP requests used for TTLS and PEAP, simply specify an account that is listed in the forwarding table. Choose a realm that does not conflict with other configured realms. If this field is left empty, the local RADIUS server handles the request itself. This means that the internal and external EAP phase is performed by the local RADIUS server.
- For EAP/TLS, check the subject name against the RADIUS user table
- TLS authenticates the client via certificate only. If this is selected, the RADIUS server additionally checks to see if the certificate username (common name, CN in the subject) is included in the RADIUS user table. If the corresponding entry in the RADIUS user table also contains a VLAN ID, this is transmitted to the authenticator as well.
- Default tunnel method
-
- TTLS default / PEAP default
- When either TTLS or PEAP is used, two authentication methods are negotiated. First, a secure TLS tunnel is negotiated via EAP. Then a second authentication method is negotiated in this tunnel. In each of these negotiating processes the server offers a method that the client can either accept (ACK) or reject (NAK). If the client rejects it, it sends the server a proposal for a method that it would like to use. If enabled in the server, the method proposed by the client is will be used. Otherwise the server breaks off negotiation. This parameter is used to determine the method that the server offers to clients for authentication in the TLS tunnel. The value specified here can help to avoid rejected proposals and thus speed up the process of negotiation.
- Timeouts
-
- Reauth period
- When the internal RADIUS server responds to a client request with a CHALLENGE (negotiation of authentication method not yet completed), the RADIUS server can inform the authenticator how long it should wait (in seconds) for a response from the client before issuing a new CHALLENGE. If the value is 0, no timeout is sent to the authenticator.
- Retransmit timeout
- When the internal RADIUS server responds to a client request with an ACCEPT (negotiation of authentication method completed successfully), the RADIUS server can inform the authenticator how long it should wait (in seconds) before triggering repeat authentication of the client. If the value is 0, no timeout is sent to the authenticator.
