rlm_raw in 3.1.x
aland at deployingradius.com
Tue Jul 7 22:16:24 CEST 2015
On Jul 6, 2015, at 9:36 AM, Paul Trappitt <paul at freedomwifi.com.au> wrote:
> Thanks for the response and I fully appreciate your position on it, but
> personally think it's useful functionality that should be available if
> someone wants to use it.
I disagree. Seeing as I have a strong say in what the server does, my opinion is the decisive one.
It's not "useful" functionality. It's insecure, broken, and wrong.
> My only current option to truly allow dynamic
> clients is to run the dynamic clients with 0.0.0.0/0 which deems it
> completely insecure anyway.
That is the standard way. And to be honest, more secure than your suggested method.
> If IP addresses of nas are constantly changing
> then the IP isn't a value that can be used to securely identify the device
> anyway so it becomes a bit null and void.
Which is why RADIUS over TLS was standardized.
> We're then left processing the
> rest of the packet to find the same data we can get from raw and just
> rejecting the request later down the track.
> In the scenario of the public wifi service provider (eg something like
> hotspotsystem, cloud4wi etc), generally the hotspot is running on embedded
> devices with limited resources so the TLS option and local proxy is just
> not feasible.
Nonsense. They can run radsecproxy, or FreeRADIUS with minimal impact. If the embedded system can run a web server and 10 WiFi clients, it can run a RADIUS proxy with TLS.
> Plus it really impacts the "off the shelf" approach to
> providing such a service.
It's your choice to use a non-standard and insecure solution.
> Would just be nice if the option was there for those who want to use it or
> some alternative that can provide similar functionality then we can.
You can port rlm_raw to v3, and maintain it yourself.
More information about the Freeradius-Devel