FreeRADIUS and OpenSSL Linkage
It would be useful to be able to link FreeRADIUS with OpenSSL, for systems like Debian that have restrictive license policies. Upon auditing the source code (and some offline discussion), it looks like it may be possible. The code using OpenSSL is: src/main/threads.c src/modules/rlm_eap/ src/modules/rlm_otp/ src/modules/rlm_wimax/ The ownership of the relevant code is largely myself, a bankrupt company (rlm_eap), and Tri-D systems (rlm_otp). We've tried contacting Tri-D systems (now owned by RedHat), but have had little response. My suggestion is to do the following: 1) add a license exception to the main LICENSE file: In addition, as a special exception, the copyright holders give permission to link the code of portions of this program with the OpenSSL library, and distribute linked combinations including the two. This exception does not apply to the "rlm_otp" module. You must obey the GNU General Public License in all respects for all of the code used other than OpenSSL. If you modify file(s) with this exception, you may extend this exception to your version of the file(s), but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version. 2) remove rlm_otp from the "stable" module list. It's not being maintained, and I'm not sure anyone is using it. This will make life easier for package maintainers, as they can just configure --without-rlm_otp. The result will be a version of the server that can be linked with OpenSSL on Debian-based systems. Thoughts? Alan DeKok.
On Wed, Jan 07, 2009 at 10:44:52AM +0100, Alan DeKok said:
It would be useful to be able to link FreeRADIUS with OpenSSL, for systems like Debian that have restrictive license policies. Upon auditing the source code (and some offline discussion), it looks like it may be possible.
The code using OpenSSL is:
src/main/threads.c src/modules/rlm_eap/ src/modules/rlm_otp/ src/modules/rlm_wimax/
The ownership of the relevant code is largely myself, a bankrupt company (rlm_eap), and Tri-D systems (rlm_otp). We've tried contacting Tri-D systems (now owned by RedHat), but have had little response.
My suggestion is to do the following:
1) add a license exception to the main LICENSE file:
In addition, as a special exception, the copyright holders give permission to link the code of portions of this program with the OpenSSL library, and distribute linked combinations including the two. This exception does not apply to the "rlm_otp" module. You must obey the GNU General Public License in all respects for all of the code used other than OpenSSL. If you modify file(s) with this exception, you may extend this exception to your version of the file(s), but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version.
2) remove rlm_otp from the "stable" module list. It's not being maintained, and I'm not sure anyone is using it.
This will make life easier for package maintainers, as they can just configure --without-rlm_otp. The result will be a version of the server that can be linked with OpenSSL on Debian-based systems.
Thoughts?
That is fantastic news! Thanks so much for doing the legwork for this, and I really look forward to the results. -- -------------------------------------------------------------------------- | Stephen Gran | May you do Good Magic with Perl. -- | | steve@lobefin.net | Larry Wall's blessing | | http://www.lobefin.net/~steve | | --------------------------------------------------------------------------
Alan DeKok <aland@deployingradius.com> wrote:
[snipped]
2) remove rlm_otp from the "stable" module list. It's not being maintained, and I'm not sure anyone is using it.
This will make life easier for package maintainers, as they can just configure --without-rlm_otp. The result will be a version of the server that can be linked with OpenSSL on Debian-based systems.
Thoughts?
I was thinking of using playing with EAP-GTC and OTP's at some stage, probably more likely EAP-TTLS/OTP or something if such a thing can be put together. Of course 'some stage' is after the 101 other things more pressing I have to do... Users can obviously not be trusted with passwords, SecureW2 with jfreesafe[1] would make for a nice combination. Cheers Alex [1] http://stuff.digriz.org.uk/mobile/jfreesafe.jad -- Alexander Clouter .sigmonster says: Don't say "yes" until I finish talking. -- Darryl F. Zanuck
Alexander Clouter wrote:
I was thinking of using playing with EAP-GTC and OTP's at some stage, probably more likely EAP-TTLS/OTP or something if such a thing can be put together.
rlm_otp does *not* implement the EAP-OTP protocol. It implements X9.9 and related "one time password" systems. Alan DeKok.
Sounds fine to me. Maybe we should also in future invesitgate using axtls in place of openssl. Not only is it an order of magnitude smaller which is great for embedded systems, it is also BSD licensed. Cheers Peter On Wed 07 Jan 2009, Alan DeKok wrote:
It would be useful to be able to link FreeRADIUS with OpenSSL, for systems like Debian that have restrictive license policies. Upon auditing the source code (and some offline discussion), it looks like it may be possible.
The code using OpenSSL is:
src/main/threads.c src/modules/rlm_eap/ src/modules/rlm_otp/ src/modules/rlm_wimax/
The ownership of the relevant code is largely myself, a bankrupt company (rlm_eap), and Tri-D systems (rlm_otp). We've tried contacting Tri-D systems (now owned by RedHat), but have had little response.
My suggestion is to do the following:
1) add a license exception to the main LICENSE file:
In addition, as a special exception, the copyright holders give permission to link the code of portions of this program with the OpenSSL library, and distribute linked combinations including the two. This exception does not apply to the "rlm_otp" module. You must obey the GNU General Public License in all respects for all of the code used other than OpenSSL. If you modify file(s) with this exception, you may extend this exception to your version of the file(s), but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version.
2) remove rlm_otp from the "stable" module list. It's not being maintained, and I'm not sure anyone is using it.
This will make life easier for package maintainers, as they can just configure --without-rlm_otp. The result will be a version of the server that can be linked with OpenSSL on Debian-based systems.
Thoughts?
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
-- Peter Nixon http://peternixon.net/
Peter Nixon wrote:
Sounds fine to me. Maybe we should also in future invesitgate using axtls in place of openssl. Not only is it an order of magnitude smaller which is great for embedded systems, it is also BSD licensed.
FWIW in Fedora we're trying to consolodate all of the crypto usage in our distribution so that it uses NSS (Network Security Services), http://www.mozilla.org/projects/security/pki/nss. We're doing this by incrementally porting applications using OpenSSL or GNU TLS to NSS. We're doing this for a few reasons, to reduce the attack surface by having only a single crypto library which is well vetted, because NSS is FIPS-140 certified (a government requirement), because NSS has a lot more features (e.g. smart cards, integration with an entire PKI ecosystem (e.g. the open source certificate management system DogTag, http://pki.fedoraproject.org/wiki/PKI_Main_Page), and to eliminate the obnoxious licensing issues with OpenSSL). FreeRADIUS is on our list of applications to be ported to NSS. At the moment the only thing holding that back is the lack of time (I'm the mostly likely person to perform the port and I don't have any space cycles at the moment). If anybody else has some extra cycles to help port FreeRADIUS to NSS please let me know, your help would be greatly appreciated! Alan has told me in the past he is in favor of having a NSS port. -- John Dennis <jdennis@redhat.com>
Hi,
cycles at the moment). If anybody else has some extra cycles to help port FreeRADIUS to NSS please let me know, your help would be greatly appreciated!
..this sounds more like reinventing the wheel for the sake of a couple of small issues. OpenSSL can be FIPS 140-2 too with the right version + FIPS patch. What are the main issues with moving to NSS from OpenSSL - what code changes would be required , how would eg the demo certs be generated upon base install and what resources will be provided for those folk who use many other systems that are all OpenSSL based so that they can learn this lingo.... and finally, how many distros will be using NSS in the future - or is this a very local Redhat thing? alan
Peter Nixon wrote:
Sounds fine to me. Maybe we should also in future invesitgate using axtls in place of openssl. Not only is it an order of magnitude smaller which is great for embedded systems, it is also BSD licensed.
That seems to be designed to use sockets for all SSL communication. It will require a fair bit of hacking to get it to work with SSL with "in memory" buffers. Alan DeKok.
participants (6)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Alexander Clouter -
John Dennis -
Peter Nixon -
Stephen Gran