rlm_raw in 3.1.x

Aaron Hurt ahurt at ena.com
Tue Jul 14 14:57:23 CEST 2015


Sorry for the late response.  There is a pretty good example included with the FR source ( https://github.com/FreeRADIUS/freeradius-server/blob/v3.1.x/raddb/sites-available/tls <https://github.com/FreeRADIUS/freeradius-server/blob/v3.1.x/raddb/sites-available/tls> ).  That site example describes the server and client sections to enforce RADIUS over TCP/TLS (RadSec).

— Aaron

> On Jul 14, 2015, at 2:36 AM, Paul Trappitt <paul at freedomwifi.com.au> wrote:
> 
> 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 <mailto: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 <http://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 <mailto:aland at deployingradius.com>> wrote:
> >
> > On Jul 6, 2015, at 9:36 AM, Paul Trappitt <paul at freedomwifi.com.au <mailto: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 <http://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 <http://www.freeradius.org/list/devel.html>
> 
> 
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html <http://www.freeradius.org/list/devel.html>
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freeradius.org/pipermail/freeradius-devel/attachments/20150714/b1a146c8/attachment.sig>


More information about the Freeradius-Devel mailing list