> > Yes you have understood correctly, we are talking about the password > hashing algorithms supported by Freeradius. > > > basically, if you want to use any of these authentication > protocols, you have to use these hashes because the password comes > already hashed from the supplicant. If you want to use another > hash you have to configure FR to pass along the password in clear, > and then do your own hashing. You can do this using the PAP > protocol, which sends the password in clear (!!) and then you can > hash it at the destination. To make this reasonably secure you > have to embed it into a TTLS tunnel. This may be even supported by > other applications so you can re-use the db for other uses. > > > We don't want to use one of those hashing algorithms for the reasons > stated in the first email. The password can then be sent to freeradius > in cleartext using a TTLS tunnel. In some cases, the NAS (network > access server) sits on the same host of freeradius or in a trusted LAN > (eg: the LAN of a virtualized physical server) and a TTLS tunnel is > not needed.
maybe I was not clear enough, need a picture to explain: SU --- AU -------------- Radius ---- DB this is the typical authentiation set-up, with a supplicant, an authenticator, a radius and a user db. I think in your case SU and AU are co-located in the web server. With protocols like MSCHAPv2 this happens: SU --- AU -------------- Radius ---- DB hash(pwd)------------------------------> so basically Radius knows nothing about hashes, and you have to cope with crappy hashes (which, BTW, is what everybody uses, because you still pass through a TLS tunnel, so it is not that horrible, and collisions are still hard enough not to be practical). With PAP this happens: SU --- AU -------------- Radius ---- DB pwd---------------------------------->hash(pwd) So the pwd passes in the clear up to the DB. There you can hash it with whatever you want, including a salted SHA256. But, since everything passes in clear, you have to be extremely sure that you have no leaks anywhere (and that authentication is bi-directional in some way, but this may not be your case). I am pretty sure there is a working ldap configuration for this, even if i never tried it myself. > We want to let freeradius do what is good at doing: speak the RADIUS > protocol to perform AAA with popular networking software (captive > portals, WPA enterprise). > Freeradius can read /write from/to one or more datastores to > retrieve/log data about authorization, authentication and accounting, > SQL is just one of the several datastores supported by freeradius. > Other datastores supported are redis, couchdb, a REST API, an external > program and some more. > > Using a REST API built purposely for freeradius we can let freeradius > focus on speaking the RADIUS protocol with other networking software > and equipment while we can handle all the application level details > autonomously overcoming limitations that would make the application > less useful in the long term. > > We can say that two pieces of software are highly coupled when both > know many specific details about each other, in this design freeradius > doens't know anything about django because it limits itself to sending > DATA via HTTPS according to its configuration and expects a response > in a specific format. It can be reconfigured any time. If someone > changes their mind and wants to migrate to a different radius > management solution they can just migrate the data and reconfigure > their freeradius instances to speak to a different URL or they can > reconfigure it entirely to use SQL queries or other datastores. before i answer, maybe i miss the big picture. generally you want to interface to RADIUS because you have some external DB of passwords that are already in use, and you want to plug your application into it. But maybe you are interested in the other way around, you want to embed an user DB and a FreeRadius server into the host where openwisp is running, so you can offer to third-party applications all-in-one with OpenWISP and a RADIUS interface? best, leonardo. > > I hope is clear. If not, let me know. > > Federico > -- > You received this message because you are subscribed to the Google > Groups "OpenWISP" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected] > <mailto:[email protected]>. > For more options, visit https://groups.google.com/d/optout. -- Leonardo Maccari, Assistant Professor @DISI, University of Trento Tel: +39 0461 285323, www.disi.unitn.it/~maccari, gpg ID: AABE2BD7 -- You received this message because you are subscribed to the Google Groups "OpenWISP" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
