RADIUS

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, and MPPE-Key attributes—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-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 ...