Table of Contents Table of contents: Radiator® AAA Server RadSec (RFC 6614) 16 - RadSec (RFC 6614) Monitor command language 18 - Monitor command language

17. Extensible Authentication Protocol (EAP)

Extensible Authentication Protocol (EAP) is a standard for defining and extending authentication protocols. EAP is defined by RFC 3748, and RFC 2869 defines how EAP authentication messages are carried in RADIUS packets. Radiator complies with these standards, and can be extended to handle any EAP-compliant protocol. Because EAP is designed to be easily extensible, a number of EAP protocols have been defined for various special requirements This includes mutual authentication between client and RADIUS server, and encryption of the authentication conversation. EAP over RADIUS is commonly used as the authentication protocol for 802.1X wired and wireless networks. For more information, see IETF website Opens in new window
Conventional RADIUS requests send the User-Name in one RADIUS attribute and the User-Password in another attribute. All EAP-over-RADIUS requests send their authentication information in the EAP-Message attribute. Usually the client sends some EAP protocol information in the EAP-Message attribute in a RADIUS Access-Request message, and the RADIUS server asks for some more information from the client by sending back another EAP-Message in a RADIUS Access-Challenge. When the server has enough information from the client, the RADIUS server replies with an Access-Accept or an Access-Reject message. Some EAP protocols, such as TLS, TTLS and PEAP, often require a number of messages (10 or more) to be exchanged between client and RADIUS server during authentication. Such a group of EAP-over-RADIUS messages while authenticating a user is called a conversation.
Note that many EAP protocols hide or encrypt the identity of the real user name of the user being authenticated, and send a generic name (typically anonymous) as the visible User-Name in the RADIUS requests.
Radiator supports several EAP protocols. This section describes their characteristics and how Radiator can be configured to support them. In order to configure Radiator to support EAP, the relevant AuthBy clauses must have the EAPType parameter set to the names of the EAP types that you need to support. In addition, a number of other special configuration parameters may have to be set in order to support those EAP types. An AuthBy clause can be configured to accept more than one EAP type. When that is the case, the first one in the list will be the default EAP method offered to the client. The client can accept the offered method or request another EAP method. If the requested method is one of the methods named in the EAPType parameter, then EAP authentication continues with that method.
There are many example configuration files covering various EAP authentication requirements in the goodies/ directory of the Radiator distribution. See goodies/README for details.

17.1. EAP MD5-Challenge

In EAP MD5-Challenge, the RADIUS server sends a random challenge to the client. The client forms an MD5 hash of the user's password and the challenge and sends the result back to the server. The server then validates the MD5 hash using the known correct plaintext password from the user database. EAP MD5-Challenge does not support dynamic WEP keys.
EAP MD5-Challenge can work with most Radiator AuthBy clauses that support the retrieval of a plaintext password, such as FILE, DBFILE, SQL, LDAP etc.

17.2. EAP One-Time-Password

In EAP One-Time-Password, the client sends a plaintext one-time password to the server, which then checks the password and either accepts or rejects the request. The one-time password is sent in the clear, so it is subject to eavesdropping, and should not be used with static password. EAP One-Time-Password does not support dynamic WEP keys.
EAP One-Time-Password can work with Radiator AuthBy clauses that support one-time passwords, such as AuthBy OTP, LDAPDIGIPASS and SQLDIGIPASS.

17.3. EAP Generic-Token

EAP Generic-Token is intended to support a range of authentication tokens from various vendors. In this context, a ‘token’ is a small device that the end user carries and which displays a login passcode that is used to authenticate the user. Examples are RSA SecurID, Encotone TeleID and Vasco tokens. Most such systems have back end servers that do the actual authentication. EAP Generic-Token does not support dynamic WEP keys.
EAP Generic-Token can be used with Radiator AuthBy clauses ACE, LDAPDIGIPASS, SQLDIGIPASS, OTP and RSAAM to support one-time passwords. It can also be used with all AuthBy clauses that support static passwords, such as FILE, SQL, LDAP, UNIX etc. In this case, it prompts the user ‘Enter your static password’.

17.4. EAP TLS

EAP TLS uses Public Key Infrastructure (PKI) digital certificates to provide mutual authentication between the EAP client and the RADIUS server. A PKI certificate is a file created by a program called a Certificate Authority. The certificate contains the name of the server or user that has been issued to. The EAP client and RADIUS server use the certificates to verify that the other party is indeed who it claims to be. In EAP TLS, a PKI certificate is required for the Radiator RADIUS server and for each and every EAP TLS client. EAP TLS does support dynamic WEP keys.
You can obtain certificates from a Public Certificate authority such as Thawte Opens in new window. The advantage of Public Certificates is that they will generally be recognised by any client or server without taking any special steps. A disadvantage of Public certificates is that you usually have to pay an annual fee for each one. With a Private Certificate Authority, you can generate your own server and client certificates for free, but you will generally have to install the ‘Root Certificate’ from your Certificate Authority on each client before it will recognise a private server certificate. Private Certificates are considered by many to be more secure that Public Certificates.
The basic steps of EAP TLS authentication are:
  1. The EAP TLS client and RADIUS server establish a communications channel via the RADIUS protocol.
  2. The RADIUS server sends its Server PKI Certificate to the client.
  3. The client verifies that the server certificate is valid and is the correct certificate for the RADIUS server it is communicating with. It uses the Root Certificate of the Certificate Authority that issued the Server Certificate to validate the Server Certificate. (Root Certificates for most Public Certificate Authorities are built in to most clients. If the Server Certificate was issued by a Private Certificate Authority, the client requires a copy of the Root Certificate to be installed in order to validate the Server Certificate.)
  4. If the client validates the server certificate, it then sends the user's PKI certificate to the RADIUS server.
  5. The RADIUS server verifies that the client certificate is valid and is the correct certificate for the user name that is being authenticated. The RADIUS server can be configured to validate Private Client Certificates using a locally installed copy of the Root Certificate of the Certificate Authority that issued the client certificate.
  6. If the RADIUS server validates the client certificate then the authentication is successful, and the client is permitted to be connected to the network.
EAP TLS does not use or exchange any passwords, but you can use AuthBy methods in Radiator to enable or disable EAP TLS users based on their user name, time of day etc.

17.5. EAP LEAP

EAP LEAP (often called just LEAP) is a proprietary protocol from Cisco Opens in new window. It provides password based authentication that can be used with any Radiator authentication method that stores plaintext passwords (such as FILE, SQL, LDAP) etc., as well as direct Windows authentication using AuthBy LSA. LEAP authentication requires a special LEAP client that is only available from Cisco.

17.6. EAP TTLS

Like EAP TLS (see Section 17.4. EAP TLS), EAP TTLS uses Public Key Infrastructure (PKI) digital certificates. Unlike TLS, it only uses a Server Certificate so the client can validate the server, and then establish a secure, encrypted communications channel with the RADIUS server. When this channel is established, it is used to tunnel conventional RADIUS attributes, such as User-Name, User-Password etc. to the RADIUS server. Radiator converts each of these so-called ‘inner requests’ into a new RADIUS request which can be authenticated by any supported AuthBy method. So EAP TTLS authentication happens in 2 phases following these basic steps:
  1. The EAP TTLS client and RADIUS server establish a communications channel via the RADIUS protocol.
  2. The RADIUS server sends its Server PKI Certificate to the client.
  3. The client verifies that the server certificate is valid and is the correct certificate for the RADIUS server it is communicating with. It uses the Root Certificate of the Certificate Authority that issued the Server Certificate to validate the Server Certificate. (Root Certificates for most Public Certificate Authorities are built in to most clients. If the Server Certificate was issued by a Private Certificate Authority, the client requires a copy of the Root Certificate to be installed in order to validate the Server Certificate.)
  4. If the client validates the server certificate, it then sends the real user name and password in a RADIUS request through the encrypted TLS tunnel. Any conventional RADIUS authentication system may be used depending on the client configuration, such as PAP, CHAP, MSCHAP, MSCHAPV2 etc.
  5. Radiator converts this ‘inner’ request into a new RADIUS request and dispatches it to the first matching Realm or Handler clause, where it can be handled by one or more AuthBy clauses. To assist in discriminating TTLS inner requests, each inner request is tagged with the pseudo-attribute TunnelledByTTLS set to 1.
  6. The result of the inner authentication is sent back to the client through the TLS tunnel.
In order to use EAP TTLS, you must install a unique Server Certificate on your RADIUS server host, and configure Radiator to use it. For more information about Public and Private certificates and how to obtain them, see Section 17.4. EAP TLS. EAP TTLS does support dynamic WEP keys.
You can configure Radiator to handle the inner and outer requests in separate Handler or Realm clauses. You can also configure Radiator to proxy the inner RADIUS requests to another RADIUS server, which means that Radiator can server as a gateway between EAP TTLS clients and a non-EAP enabled RADIUS server.

17.7. EAP SIM

This protocol is used to authenticate using a GSM SIM card. EAP-SIM support is available as an add-on package for Radiator. See https://radiatorsoftware.com/products/radiator-sim-pack/ or contact info@radiatorsoftware.com for more details.

17.8. EAP AKA

This protocol is used to authenticate using a UMTS SIM card. EAP-AKA support is available as an add-on package for Radiator. See https://radiatorsoftware.com/products/radiator-sim-pack/ or contact info@radiatorsoftware.com for more details.

17.9. EAP AKA’

This protocol is a revision of EAP-AKA and is used to authenticate using a UMTS SIM card. EAP-AKA’ support is available as an add-on package for Radiator. See https://radiatorsoftware.com/products/radiator-sim-pack/ or contact info@radiatorsoftware.com for more details.

17.10. EAP PEAP

Like EAP TLS (See Section 17.4. EAP TLS), EAP PEAP (often called just PEAP) uses Public Key Infrastructure (PKI) digital certificates. Unlike TLS, it only uses a Server Certificate so the client can validate the server, and then establish a secure, encrypted communications channel with the RADIUS server. When this channel is established, it is used to tunnel encrypted EAP messages to the RADIUS server. Radiator converts each of these so-called ‘inner requests’ into a new RADIUS request which can be authenticated by any supported AuthBy method. So EAP PEAP authentication happens in 2 phases following these basic steps:
  1. The EAP PEAP client and RADIUS server establish a communications channel via the RADIUS protocol.
  2. The RADIUS server sends its Server PKI Certificate to the client.
  3. The client verifies that the server certificate is valid and is the correct certificate for the RADIUS server it is communicating with. It uses the Root Certificate of the Certificate Authority that issued the Server Certificate to validate the Server Certificate. (Root Certificates for most Public Certificate Authorities are built in to most clients. If the Server Certificate was issued by a Private Certificate Authority, the client requires a copy of the Root Certificate to be installed in order to validate the Server Certificate.)
  4. If the client validates the server certificate, it then sends one or more EAP requests through the encrypted TLS tunnel. The type of inner EAP request depends on the PEAP client configuration, but the most common types of inner EAP requests are EAP MSCHAPV2 and EAP TLS.
  5. Radiator converts this ‘inner’ request into a new RADIUS request and dispatches it to the first matching Realm or Handler clause, where it can be handled by one or more AuthBy clauses. To assist in discriminating PEAP inner requests, each inner request is tagged with the pseudo-attribute TunnelledByPEAP set to 1.
  6. The result of the inner authentication is sent back to the client through the TLS tunnel.
In order to use EAP PEAP, you must install a unique Server Certificate on your RADIUS server host, and configure Radiator to use it. For more information about Public and Private certificates and how to obtain them, see Section 17.4. EAP TLS. EAP PEAP does support dynamic WEP keys.
You can configure Radiator to handle the inner and outer requests in separate Handler or Realm clauses. You can also configure Radiator to convert an inner EAP-MSCHAPV2 request into a conventional RADIUS-MSCHAPV2 request, which means that Radiator can act as a gateway between EAP PEAP clients and a non-EAP enabled RADIUS server.

17.11. EAP MSCHAPV2

EAP MSCHAPV2 is an EAP version of the common MSCHAPV2 authentication mechanism. It provides mutual authentication between client and server. It is most commonly used as the inner authentication protocol with EAP PEAP on Microsoft Windows clients. EAP MSCHAPV2 does support dynamic WEP keys.
EAP MSCHAPV2 can be used with any Radiator AuthBy that has access to plaintext passwords, such as FILE, SQL, LDAP2, DBM etc. It can also be used with AuthBy LSA to authenticate with a Windows Local Security Authority, Windows Domain Controller etc. It can also be used with LDAPDIGIPASS and SQLDIGIPASS.

17.12. EAP PAX

EAP PAX provides strong encryption and mutual authentication between supplicant and server based on a per-user Authentication Key (AK). It is described in RFC 4746. Based on the per-user AK, the server and supplicant derive strong cryptographic keys and authenticate each others knowledge of the AK. The derived keys can be used for dynamic WEP and WPA keys.
The AK is required to be configured into the per-user data in the Radiator user database, and also into each user’s EAP-PAX supplicant configuration. The AK is required to be 16 bytes. It can be specified in a Radiator user database as 32 hex digits:
pskuser     User-Password=1234567890123456789012345678901
EAP PAX can be used with any Radiator user database that supports a plaintext User-Password.

17.13. EAP PSK

EAP PSK provides strong encryption and mutual authentication between supplicant and server based on a per-user Pre-Shared-Key (PSK). It is described in RFC 4764. Based on the per-user PSK, the server and supplicant derive strong cryptographic keys and authenticate each others knowledge of the PSK. The derived keys can be used for dynamic WEP and WPA keys.
The PSK is required to be configured into the per-user data in the Radiator user database, and also into each user’s EAP-PSK supplicant configuration. The PSK is required to be 16 bytes. It can be specified in a Radiator user database as 32 hex digits:
pskuser     User-Password=1234567890123456789012345678901
If the User-Password does not appear to be 32 hex digits, it will be regarded as a plaintext password, and will be converted into a PSK using the algorithm described in RFC 4764. The conversion to a PSK depends on the plaintext password and the server and supplicant IDs. Use of such plaintext passwords is discouraged by RFC 4764 (because the PSK then becomes vulnerable to dictionary attacks) and is not supported by all EAP PSK supplicants. We also discourage use of such plaintext passwords.
EAP PSK can be used with any Radiator user database that supports a plaintext User-Password. Requires Crypt::Rijndael. For more information, see Section 2.1.2. CPAN.

17.14. EAP PWD

EAP PWD provides strong encryption and mutual authentication between supplicant and server based on a shared password. It is described in RFC 5931. Based on the per-user password, the server and supplicant derive strong cryptographic keys and authenticate each others knowledge of the password. The derived keys can be used for dynamic WEP and WPA keys.
EAP PWD is highly secure (the password is never transmitted, even in encrypted form), and does not require PKI certificates, and also requires only 3 authentication roundtrips. Further, it is not encumbered by intellectual property issues. So it is considered efficient to roll out in eduroam and other environments.
Authentication of EAP PWD by Radiator depends in having access to the user's plain text password. EAP PWD can be used with any Radiator user database that supports a User-Password in format like below. Some EAP PWD clients may also support additional password formats. For more information, see Section 3.10.58. EAP_PWD_PrepMethod. :
username    User-Passsword=fred
EAP PWD requires OpenSSL 0.9.8i libraries or later, Crypt::OpenSSL::EC and Crypt::OpenSSL::Bignum 0.06 or later.
Tip
Crypt::OpenSSL::EC and Crypt::OpenSSL::Bignum may not be readily available for Windows. We recommend Linux or Unix hosts for deployment of EAP PWD.
Table of Contents Table of contents: Radiator® AAA Server RadSec (RFC 6614) 16 - RadSec (RFC 6614) Monitor command language 18 - Monitor command language