EAP authentication

EAP is not a specific authentication mechanism, it is more like a framework for various authentication methods. The LCOS RADIUS server supports a range of EAP methods:

• EAP/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.
• EAP/MSCHAPv2, defined in draft-kamath-pppext-eap-mschapv2-01.txt. 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.
• EAP/TLS, defined in RFC2716. 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.
  Note: Please note that the TLS implementation in LCOS does not support certificate chains or certificate revocation lists (CRLs).
• EAP/TTLS, defined in draft-ietf-pppext-eap-ttls-05.txt. 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
• EAP/PEAPv0, defined in draft-kamath-pppext-peapv0-00.txt. Similar to TTLS, PEAP is based on TLS and works with an EAP negotiation inside the TLS tunnel.

At this time, authentication methods cannot be suppressed. The EAP supplicant and the RADIUS server negotiate the EAP method with the standard EAP mechanism. Clients requesting a non-EAP method will be rejected by the RADIUS server.