rlm_raw in 3.1.x
paul at freedomwifi.com.au
Tue Jul 14 09:36:27 CEST 2015
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.
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
> — Aaron
> > On Jul 7, 2015, at 3:16 PM, Alan DeKok <aland at deployingradius.com>
> > On Jul 6, 2015, at 9:36 AM, Paul Trappitt <paul at freedomwifi.com.au>
> >> 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
> >> 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
> >> 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
> >> 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
> List info/subscribe/unsubscribe? See
More information about the Freeradius-Devel