Hi,

They also claim that it's less secure to expose the RADIUS servers directly, but I don't really buy that argument.

eh? if you just use a national proxy you only need prot 2083 open to those few hosts. if you use dynamic server discovery you need to open up port 2083 to the whole internet (as you dont know the source addresses of all legitimate RADIUS servers). alan

On Jan 12, 2016, at 4:59 AM, Sebastian Hagedorn <Hagedorn@uni-koeln.de> wrote:

just as information, we explored using the RadSec module of Freeradius 3.0.10 for Eduroam, but while we got it to work locally after the recent fix, the German Eduroam hub insists we use radsecproxy instead. The main reason they give is that Freeradius lacks support for Dynamic Server Discovery. While that feature isn't yet actively used, it's on the roadmap, so that institutions won't have to proxy via central hubs anymore, but can discover the right proxy for each realm dynamically via NAPTR/SRV records.

We're working on dynamic home server discovery. Some of the infrastructure is there, but it has to be finalized.

They also claim that it's less secure to expose the RADIUS servers directly, but I don't really buy that argument.

I do. The less code exposed to the internet, the better.

We will go forward with radsecproxy for the time being, but if Freeradius gains support for Dynamic Server Discovery in the future, we will definitely look into that.

The only downside to radsecproxy is that it has no policies. It's a proxy... and not much else. But that means there's less code, and less possibility for bugs. We run FreeRADIUS through 3 different static analysis tools every week. So we're pretty sure it's safe. But the tools aren't perfect, and neither are we. Alan DeKok.