On Fri, Jul 14, 2017 at 11:53 AM Leonardo Maccari <[email protected]> wrote:
> > On 14/07/17 10:43, Federico Capoano wrote: > > > > On Thu, Jul 13, 2017 at 11:00 PM Leonardo Maccari < > [email protected]> wrote: > >> >> >> 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. >> > > Yes this is the solutions we are talking about, using PAP (encrypted with > TTLS or not depending on where the communication between radius clients and > radius). > > Each method has trade offs. The method we have discussed is easy enough to > implement, secure, flexible, has low mantainance costs. > > As said, storing passwords in SHA1 or MD5 is not viable unless we only > store passwords in that form only for users of a freeradius > instance/federation, but we would need to store these passwords in a > different location than the main user passwords (eg: administrators, > operators, future contributors when we will introduce the possibility of > contributing to the network by adding nodes into the system), this means we > should keep the SHA1/MD5 encrypted passwords for freeradius users either in > separate fields or a different DB entirely: this solution would be > cumbersome, bug prone and costly to mantain. > > > Ok I understand you don't want to have MD5/SHA1, but with the PAP > solution, you don't have to. Unless you are telling me that the > documentation or rlm_pap is wrong: > > https://freeradius.org/radiusd/man/rlm_pap.txt > which is entirely plausible. Even if I am thinking that i miss some pieces > because i don't understand why you want to replicate the user DB, once you > have a RADIUS server. > I don't think the documentation is wrong. See the following table in that documentation: Header Attribute Description ------ --------- ----------- {clear} Cleartext-Password clear-text passwords {cleartext} Cleartext-Password clear-text passwords {crypt} Crypt-Password Unix-style "crypt"ed passwords {md5} MD5-Password MD5 hashed passwords {base64_md5} MD5-Password MD5 hashed passwords {smd5} SMD5-Password MD5 hashed passwords, with a salt {sha} SHA-Password SHA1 hashed passwords SHA1-Password SHA1 hashed passwords {ssha} SSHA-Password SHA1 hashed passwords, with a salt SSHA1-Password SHA1 hashed passwords, with a salt {ssh2} SHA2-Password SHA2 hashed passwords {ssh256} SHA2-Password SHA2 hashed passwords {ssh512} SHA2-Password SHA2 hashed passwords {nt} NT-Password Windows NT hashed passwords {nthash} NT-Password Windows NT hashed passwords {x-nthash} NT-Password Windows NT hashed passwords {ns-mta-md5} NS-MTA-MD5-Password Netscape MTA MD5 hashed passwords {x- orcllmv} LM-Password Windows LANMAN hashed passwords {X- orclntv} LM-Password Windows LANMAN hashed passwords When receiving a password with the PAP module, we have to choose either one of those algorithms or cleartext. Se we are choosing cleartext (over an encrypted tunnel if necessary), but delegating the authorization, that is the check of the password stored with a stronger hashing algorithm (and possibly more complex checks) to an external application. 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? >> > > Sorry, I'm not following you. > > > let's try again: what is the architecture you have in mind? given the > following scheme: > > > SU --- AU -------------- Radius ---- DB > > what are the components you control and what are the external components > you only plan to connect to? > In public wifi or university wifi settings, we control everything. captive portal, VPNs, freeradius, openwisp2. In other settings like Eduroam or other 802.1x settings we may not have control of access points that talk to freeradius, in that case we would need to properly setup the TTLS tunnel between freeradius and the parts we don't control. Let me offer a bit more context about django-freeradius <https://github.com/openwisp/django-freeradius> because maybe you are not aware of it. We are working to renovate an existing application called OpenWISP User Management System <https://github.com/openwisp/OpenWISP-User-Management-System>, which is basically a freeradius management interface which creates a (very weird) MySQL database that is then used by freeradius (usually deployed with freeradius 2). This application has been used for many years by many companies and municipalities to offer public wifi. OWUMS has many important limitations and shortcomings which we are trying to solve with this renovation. So with django-freeradius we are trying to create the base openwisp2 module that will take care of AAA in openwisp2, but in a cleaner way which we aim will be simpler to extend and less costly to mantain and evolve over time. I hope is clearer now. 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]. For more options, visit https://groups.google.com/d/optout.
