Phil Mayers wrote: > I'm not entirely sure I buy that it ensures only the outer server is > affected; once compromised, the outer server can be used to send > arbitrary UDP packets to the inner server since the sockets are already > open. But I guess the same could be said of any perimeter defence > architecture.
True, it's just one layer. >> 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.) >If you were going to do that, I would strongly recommend *not* >transforming EAP-MSCHAPv2 into plain MSCHAP; the code that does this is >hairy. In an exercise of folly I did try that. Then I tried letting it rewrap the EAP, but it didn't seem up for the task. Left it for future dull days. > 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 in... what? It authenticates against your password database? I would > have thought that all the internet-facing web properties would be rather > more of a risk than radius requests coming from hosts with a shared secret. Well, I shouldn't go into that on a public forum. As far as SSO web services, there are things I'm responsible for, and things I am not. I don't worry too much about the latter :-) > I'm wondering if you would feel all this was necessary if RadSec were in > use? It is. Some decade from now it is also possible RadSec within eduroam will migrate to a more (PKI-based) peer-to-peer model, so if anything that's more hosts we'd be talking to. > (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.) > This is something that we *do* use. Basically I have separate processes > for wired macauth, local wireless/wired 802.1x, eduroam visited/SP, > eduroam home/IdP, vpn mschap and so on. Same here, but the eduroam instances are each split into two (a 3.0 for radsec/filter and a system stock version for the internal.) The SP instance also allows our users to gain the same privileges (and be subject to the same NAC criteria) as they would on the normal SSID. That way they can configure for eduroam and never have to mess with changing profiles, but it also means that a crash of the instance that does this local authentication will strand my users and then the pitchfork closets will be raided, so I'd rather any problems that might occur when a guest makes us talk to the federation were isolated to guests only. > The main reason is fault isolation; a long while ago (several years now) > the occasional crash bug would surface in either the TLS or SQL code, > and it was useful for this to be confined. This is the most tangible benefit, yes. Helps me sleep much sounder. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
