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-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 allAccess-Request
messages. On the client side, make sure theMessage-Authenticator
is used and ensure it can be configured. On the server side, require that the
Message-Authenticator
attribute be ...
Get RADIUS now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.