RADIUS

Limitations of RADIUS

RADIUS, while having many positive attributes to its name, does have limitations. Doesn’t everything, after all?

First, security is an obstacle in some implementations. Despite the irony, if an implementation in which there are several proxy RADIUS servers is used, all hops must view, perform logic on, and pass on all data in the request, hidden or not. This means that all data is available at every hop, which is not the most secure environment in which to place such sensitive data as certificates and passwords.

Second, RADIUS, at least in its most general incarnation, has no support for recalling and deallocating resources after an authorization has been issued. For instance, as mentioned earlier, it’s possible to have a multi-hop proxy RADIUS chain in which the first server grants the request and subsequently contacts the necessary equipment to provision the services. If for some reason the service is not available (possibly because of a time-of-day restriction or an account suspension that the frontline RADIUS server isn’t aware of), there is no provision in the RFC specification to deny and disconnect the service now that a rejection has been made. Some vendors have developed support for subsequent rejections—including knocking a user off at his specific time limit rather than just denying him access the next time he attempts to connect—but there’s not a provision for this in the official specification.

Third, RADIUS is stateless (you heard about this earlier). ...