rlm_raw in 3.1.x

[Alan DeKok]

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.

  No.

> 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.

  Alan DeKok.