8.3 Compensating for the Deficiencies

All of the security issues presented in this chapter have workarounds. Some have been listed within the discussion of each vulnerability, but this section serves as a quick reference checklist, from which you can decide which workarounds to employ in your RADIUS implementation. This section outlines some of the basic steps you can use to compensate for some of the more nefarious RADIUS design decisions:

Use the IPsec protocol with ESP and an encryption algorithm such as 3DES.

When IPsec encrypts the whole RADIUS message, fields open to compromisenamely the request authenticator fields and the User -Password , Tunnel-Password , and MPPE-Key attributescannot be viewed . To decrypt these fields, an attacker first must break into the ESP-protected message. This protects the entire RADIUS message and keeps it from prying eyes.

Require any shared secrets in use to be either 22 keyboard characters long or 32 hexadecimal digits long.

This protects against the deficiencies and the unprotected nature of the shared secret concept.

Use a different shared secret for each RADIUS client and server pair.

This is just a basic security measure, much like having a different password for a variety of web sites and computing resources.

Use the Message-Authenticator attribute in all Access-Request messages. On the client side, make sure the Message-Authenticator is used and ensure it can be configured.

On the server side, require that the Message-Authenticator attribute be present and also allow here for its configuration. This compensates for having no Access-Request messages authenticated anywhere along the transaction path .

Use a cryptographic-quality random number generator to generate the request authenticator.

This offsets the rather limited quality of the request authenticator's implementation.

You might also consider protecting the links from the end user to the RADIUS client gear using EAP and one of the strong encryption types available with its use. For example, you could use EAP-TLS, which is a strong EAP method that requires the exchange of client and RADIUS server certificates. The use of EAP messages inherently requires a valid Message-Authenticator certificate, which protects messages that can't otherwise be protected by the use of IPsec.

Also, along with EAP, think about using mutual authentication methods . Very simply, both ends of the connection authenticate their peer in mutual authentication. The authentication attempt is rejected if either end's authentication fails. EAP-TLS is a mutual authentication method: the RADIUS server validates the user certificate of the client, and the client validates the computer certificate of the RADIUS server.

Finally, if the PAP authentication protocol is not required, disable it on both the client and the server end. PAP should only be used as a secure connection when it's used in conjunction with OTP and Token Card authentication where the password is reasonably complex and changes with each use. However, even in this situation, having PAP enabled allows for misconfigured end users to negotiate with the RADIUS client gear and at that point, they could potentially send unprotected passwords. If at all possible, use EAP with the OTP and Token Card authentication types instead of PAP. In the same line of thinking, disable LAN Manager encoding if you use MS-CHAP.