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@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@deployingradius.com> wrote:
On Jul 6, 2015, at 9:36 AM, Paul Trappitt <paul@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