Hi Alan, 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. 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. 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. 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. Plus it really impacts the "off the shelf" approach to providing such a service. 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. Cheers Paul On Mon, Jul 6, 2015 at 9:05 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Jul 6, 2015, at 8:37 AM, Paul Trappitt <paul@freedomwifi.com.au> wrote:
Thanks, yeah I had found that post. I guess it's not really of much help though. Why is it wrong and what is a valid alternative? Seems as though the dynamic clients module is a bit "cut off at the knees" in a public wifi service provider scenario if all it can access is the src IP address.
It's about security. The various fields in the packet are just data. Anyone can invent anything, and put the data there. Forging source IPs and having them route across the wider internet is a lot more difficult.
If you need random machines to be RADIUS clients, you should use RADIUS over TLS. v3 supports it. You can put a local proxy onto the remote site, and then have that proxy connect to a central server. The central server can then do certificate authentication of the edge machines.
Anything else is insecure, and terrible in practice. It doesn't matter if it's convenient. Not using protection is convenient. But the side effects can be grim.
If you want to use rlm_raw in v3, go right ahead. But the build system has changed. The internal APIs have changed. You'll have to know C in order to get it working.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html