rlm_raw in 3.1.x

[Paul Trappitt]

Hi Aaron,

Thanks for the info, are you able to provide any links or details on how to
set this up please? I can't find any documentation on setting up dynamic
clients with TLS enabled.

Cheers



On Wed, Jul 8, 2015 at 8:25 AM, Aaron Hurt via Freeradius-Devel <
freeradius-devel at lists.freeradius.org> wrote:

> For what it’s worth we currently have several thousand APs deployed across
> multiple sites/states as part of a managed WiFi solution for K-12 school
> systems and are doing exactly what Alan has suggested.  The APs connect via
> RADSEC and we have a single 0.0.0.0/0 client entry which enforces TLS.
> We us this in conjunction with the rlm_couchbase module to collect
> real-time accounting and provide captive portal authentication/guest
> registration.  We’ve been doing this since before 3.0.x was even officially
> released and it’s been working better than anticipated and scales
> wonderfully.
>
> — Aaron
>
> > On Jul 7, 2015, at 3:16 PM, Alan DeKok <aland at deployingradius.com>
> wrote:
> >
> > 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.
> >
> >
> > -
> > List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/devel.html
>
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/devel.html
>