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 compromise—namely the request authenticator fields and the
User-Password,Tunnel-Password, andMPPE-Keyattributes—cannot 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-Authenticatorattribute in allAccess-Requestmessages. On the client side, make sure theMessage-Authenticatoris used and ensure it can be configured. On the server side, require that the
Message-Authenticatorattribute be ...