Phil Mayers [[email protected]] wrote > I'm curious about what you mean here. I don't see the difference between > a single server performing attribute filter & auth, versus two separate > processes. > > Can you explain what threat model you think this addresses?
It limits the exposed fuzzable surface. Any vulnerabilities present or introduced in the low level RADIUS packet processing compromise only the external server. The packets that reach the internal server post-filter have been cleanly regenerated. The option also exists at that point to place the external server on an entirely different host, for DoS mitigation. You still have some unnecessary code surface exposure what with EAP being processed on the internal server (unless you were to manage to somehow get tunneling of unwrapped MSCHAP working and do the EAP unwrap on the external server.) Normally I wouldn't be quite so bug-paranoid, but RADIUS is tied pretty tightly to the most security-sensitive and mission-critical systems we have. (As an aside, while the virtual server functionality is very useful when it comes to providing an integrated inner/outer tunnel solution, I've found it much more convenient to administer discrete usage cases with individual instances. Then you can do work on one server without worrying that a change will somehow have unintended consequences on other services when you reload the config.) - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
