Last update: June 22, 2009
RADIUS is a widely deployed protocol for network access authentication, authorization and accounting (AAA). There are many problems with it, including issues with security and transport, yet it is likely that RADIUS will continue to be widely used for many years to come. Why? RADIUS is simple, efficient and easy to implement -- making it possible for RADIUS to fit into the most inexpensive embedded devices.
The issues with transport are most relevant for accounting, in situations where services are billed according to usage. In these situations packet loss = revenue loss! RADIUS runs on UDP, with no defined retransmission or accounting record retension policy, and does not support application-layer acknowledgments or error messages (like "I'm busy, come back later" or "No disk space left"). This makes RADIUS accounting unreliable for usage-based billing services, particularly in inter-domain usage (such as roaming) where there can be substantial packet loss.
As a result, usage-based billing is often done with SNMP today. Although SNMP runs over UDP (a TCP transport mapping has been developed but is not deployed yet), the retry policy and polling interval can be configured on the management station, so that you are not at the mercy of the RADIUS retransmission and retension policy of a particular NAS vendor. To enable SNMP-based accounting for 802.11, as well as RADIUS accounting, we designed the IEEE 802.1X MIB to provide all the information available in RADIUS accounting within the MIB tables. The situation is better for RADIUS authentication and authorization, because if packet loss prevents users from being authenticated, they will typically try to get on again soon afterwards.
In terms of security, RADIUS includes its own application-layer integrity protection and authentication, as well as confidentiality for "hidden attributes". In RFC 2865, RADIUS Access Requests need not be authenticated and integrity protected; the situation was improved somewhat in RFC 2869, which requires that all messages involved in an EAP conversation include authentication and integrity protection via the Message-Authenticator attribute. As noted in the RADIUS security analysis, RADIUS security is particularly poor when dealing with cleartext passsword authentication (PAP). RFC 2865 requires that the RADIUS Response Authenticator be globally and temporally unique, since the stream cipher that RADIUS uses to encrypt User-Password is based on the Response Authenticator, and thus if it were to repeat, the keystream would be compromised. Unfortunately, not all implementations do a good job of ensuring that the Response Authenticator is not repeated.
Since the RADIUS Response Authenticator and Message-Authenticator attributes are both vulnerable to dictionary attack, it's a good idea to make sure your RADIUS shared secret has sufficient entropy and is not the same for multiple NASen. However, in real-life simple shared secrets shared with many NASen (or even all of them!) are common, and so this is probably the most serious RADIUS security vulnerability.
In terms of solutions, the best thing to do is to turn off PAP support on the NAS; that way the User-Password attribute will never be sent. Fortunately, EAP does not support PAP, and so RADIUS usage with IEEE 802.1X is not vulnerable to this particular class of attack. If possible, it is a good idea to use authentication methods that offer protection against an offline dictionary attack. These include EAP TLS (RFC 2716), EAP SRP and PEAP (both still under development), but not EAP GSS with Kerberos V, EAP MD5 or Cisco LEAP.
If the NAS can support IPsec, then the best thing to do is foresake RADIUS application-layer security entirely and just run RADIUS over IPsec ESP with a non-null transform. This is described in RFC 3162. Unfortunately, many embedded systems do not have the horsepower or headroom to run IPsec, so RADIUS/IPsec is not widely used today.
RADIUS authentication (Proposed
Standard, RFC 2865)
IETF RADIUS WG Archives
RADIUS Accounting (Informational, RFC 2866)
RADIUS tunneling accounting attributes (Informational, RFC 2867)
RADIUS tunneling authentication attributes (Informational, RFC 2868)
RADIUS Extensions (Informational, RFC 2869)
RADIUS IANA Considerations (Proposed Standard, RFC 3575)
RADIUS Dynamic Authorization (Informational, RFC 5176)
Chargeable User Id (Proposed Standard, RFC 4372)
RADIUS Filter Rule Attribute (Proposed Standard, RFC 4849)
Common RADIUS Implementation Issues and Suggested Fixes (Proposed Standard, RFC 5080)
RADIUS Extension for Digest Authentication (Proposed Standard, RFC 5090)