hi
> > > > > Anybody making NAS boxes that support IPSec tunnelling? you can still install a small linux-box tunnelling the packet from each NAS through to the server... ugly, i know; but it could be a diskless thin client, for example... or you replace your nas by a software nas running at this box - could even come out cheaper... > > > > Yes, but the number that support IPSec tunneling of radius packets is > > > > about equal to the number that support EAP authentication. :\ what is EAP supposed to do with IPSec??? sorry, i didn't get this one. > > > I'm curious if there would be any use/interest in hacking FreeRADIUS > > >to "encrypt" packets it's sending to a proxy. > > > > I wouldn't invent a proprietary method. IMHO radius proxy feature should definitely be protected by an underlayer method, i.e. IPSec (since tls doesn't work with udp...). in this case you are going to travel between some public unknown networks and the used algorithm never ever been considered being strong crypto... it's basically "just a hash" used for hiding secrets what was not its original purpose. it should be used with care. besides, IPSec provides much more than what a udp higher level protocol could ever do unless it implements the whole suite itself... so, Alan, i don't think it would be necessary to have a "proxy-encrypt-hack". modularity with crypto-systems is what we need; otherwise it's a horrible work to verify their quality. small remark to what's been said before: IPSec doesn't need to be tunnel the packets. I would even suggest to install IPSec at the Radius-servers themselves and use the transport mode if it is possible. It appears that the tranport mode is far more efficient. that's what we do here. chris (sorry if it wasn't your comment): even if i agree that the attacks against RADIUS are mostly theoretical, we should keep in mind that, statistically, the most attacks against IT systems come from inside of the networks. so i wouldn't insist too much on the fact that you need to be within the network to raise an attack against RADIUS, since that's probably exactly what you can expect. chris: what exactly did you mean by incorporating IPSec support? alan wrote: > You can get a LOT of information about what's going on in the > network just by looking at ports and packet sizes. > So my question is: What purpose would be served by encrypting > packets? What information do you want to hide from prying eyes? talking about IPSec: ESP would hide the actual size of the packets, e.g. not talking about the ports. but the problem with IPSec is that it can hardly be found in the NAS, so you probably will have to setup an additional box just before NAS... Raghu wrote: > I think, for now EAP-TTLS does not have any added advantage over IPSec. At least, in the wireless LANs (802.11), EAP begins after the association, i.e. after the logical port assignment. So, the assignment of the logical port is *not* authenticated. One could imagine attacks based on that even if they need a lot of technical understanding how to push away the actual participator who has really been authenticated. Additionally: does EAP-TTLS provides for any packet signing? just my six pences... artur -- Artur Hecker artur[at]hecker.info - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
