ppp 2.4.4 eap-tls patch
hi all,
based on Beniamino Galvani's work ( <[email protected] <mailto:[email protected]>> ) I have created a patch for ppp 2.44 to allow EAP-TLS authentication (RFC2716), both in client and server mode, including MPPE 40/128 bit encryption. You can find the patch on
http://www.nikhef.nl/~janjust/ppp/ppp-2.4.4-eaptls-mppe-0.9.patch
<http://www.nikhef.nl/%7Ejanjust/ppp/ppp-2.4.4-eaptls-mppe-0.9.patch>
The patched code is marked by #ifdef USE_EAPTLS blocks. This allows me to enable or disable it in the Makefiles using
USE_EAPTLS=y|n
respectively.
I have tested the patch on Linux acting as a server, with Windows 2000 and XP clients as well as a Linux client with the same patch applied.
share and enjoy,
JJK / Jan Just Keijser
Thanks, I've asked the pptp and pptpd mailing lists for test reports, since there have been some requests for EAP-TLS support.
You've used OpenSSL, which has a license that is not altogether open, specifically clause 6 which requires acknowledgement. Is there any reason why you couldn't use MatrixSSL?
The OpenWrt project already ships MatrixSSL, and I can see this EAP-TLS support being useful in OpenWrt.
Signature · 3 lines
James Cameron http://quozl.netrek.org/ HP Open Source, Volunteer http://opensource.hp.com/ PPTP Client Project, Release Engineer http://pptpclient.sourceforge.net/
Quoted 3 lines · James Cameron
You've used OpenSSL, which has a license that is not altogether open, specifically clause 6 which requires acknowledgement. Is there any reason why you couldn't use MatrixSSL?
I would hate to see EAP-TLS depend on a niche license.
I do not think I would enable EAP-TLS in the Debian package in this case since it would require pulling the MatrixSSL package in the base system.
If you do not like the advertisement clause in the OpenSSL license there is libgnutls which is LGPL'ed and widely used (and has a sane API...).
Signature · 2 lines
ciao, Marco
The patch is based on OpenSSL basically because I have used openssl in the past and have come to know it a bit; I don't see any reason why MatrixSSL (which I do not know) or libgnutls (which I know a little but have had problems with in the past) could not be used. The EAP-TLS patch uses an SSL TLSv1 context and not much more than that, so I can't think of a reason why any other package which provides the same functionality could not be used.
I will give libgnutls a shot over the next few days/weeks, and perhaps MatrixSSL as well.
share and enjoy,
JJK
Quoted 18 lines · Marco d'Itri
Quoted 5 lines · James Cameron
You've used OpenSSL, which has a license that is not altogether open, specifically clause 6 which requires acknowledgement. Is there any reason why you couldn't use MatrixSSL?
I would hate to see EAP-TLS depend on a niche license.
I do not think I would enable EAP-TLS in the Debian package in this case since it would require pulling the MatrixSSL package in the base system.If you do not like the advertisement clause in the OpenSSL license there is libgnutls which is LGPL'ed and widely used (and has a sane API...).
to follow up on my previous posting:
- gnutls does not provide the HMAC functions, which are needed for MPPE, hence I will rule that out for now
- matrixssl seems to have a very odd licence, with the split between commercial and non-commerical use...
- openwrt already provides support for openvpn, which in turn uses openssl so why is there a need to switch to matrixssl ?
conclusion: for now, I won't be bothered to migrate my patch from openssl to gnutls or matrixssl any time soon. Others are most welcome to try , of course, and I am willing to test any patches that others provide.
share and enjoy,
JJK
Quoted 38 lines · Jan Just Keijser
The patch is based on OpenSSL basically because I have used openssl in the past and have come to know it a bit; I don't see any reason why MatrixSSL (which I do not know) or libgnutls (which I know a little but have had problems with in the past) could not be used. The EAP-TLS patch uses an SSL TLSv1 context and not much more than that, so I can't think of a reason why any other package which provides the same functionality could not be used.
I will give libgnutls a shot over the next few days/weeks, and perhaps MatrixSSL as well.
share and enjoy,
JJK
Quoted 18 lines · Marco d'Itri
Quoted 4 lines · James Cameron
You've used OpenSSL, which has a license that is not altogether open, specifically clause 6 which requires acknowledgement. Is there any reason why you couldn't use MatrixSSL?
I would hate to see EAP-TLS depend on a niche license.
I do not think I would enable EAP-TLS in the Debian package in this case since it would require pulling the MatrixSSL package in the base system.If you do not like the advertisement clause in the OpenSSL license there is libgnutls which is LGPL'ed and widely used (and has a sane API...).
Quoted 2 lines · Jan Just Keijser
- gnutls does not provide the HMAC functions, which are needed for MPPE, hence I will rule that out for now
Crypto primitives are provided by its companion library libgcrypt.
Signature · 2 lines
ciao, Marco
Quoted 4 lines · Marco d'Itri
Quoted 1 line · James Cameron
Is there any reason why you couldn't use MatrixSSL?
I would hate to see EAP-TLS depend on a niche license.
MatrixSSL is dual licensed, and last I checked the GPL is quite common rather than being niche. It is unfortunate that it isn't LGPL, and maybe that will stop the idea.
Quoted 2 lines
I do not think I would enable EAP-TLS in the Debian package in this case since it would require pulling the MatrixSSL package in the base system.
Oh, certainly. Debian already has OpenSSL. Hopefully it would be a build option to choose the appropriate dependency, and so the Debian packaging would use the OpenSSL.
Quoted 2 lines · Jan Just Keijser
- openwrt already provides support for openvpn, which in turn uses openssl so why is there a need to switch to matrixssl ?
OpenWrt is used on embedded systems with very low memory, and the OpenVPN package occasionally cannot be used because of the dependency on OpenSSL (415183 bytes). MatrixSSL is much smaller (41411 bytes), and is already included in the base system for use by dropbear, the SSH implementation.
Quoted 3 lines
conclusion: for now, I won't be bothered to migrate my patch from openssl to gnutls or matrixssl any time soon. Others are most welcome to try , of course, and I am willing to test any patches that others provide.
No worries, I'll ponder it.
(I'm sensitive to the OpenSSL license because of the problems we had getting an MPPE implementation accepted into the kernel. An early implementation used source fragments from OpenSSL. The current implementation does not use source from OpenSSL, but instead uses the in-kernel crypto.)
Signature · 3 lines
James Cameron http://quozl.netrek.org/ HP Open Source, Volunteer http://opensource.hp.com/ PPTP Client Project, Release Engineer http://pptpclient.sourceforge.net/
Quoted 3 lines · James Cameron
Quoted 2 lines
Quoted 1 line
Is there any reason why you couldn't use MatrixSSL?
I would hate to see EAP-TLS depend on a niche license.
MatrixSSL is dual licensed, and last I checked the GPL is quite common
Sorry, I meant "on a niche library", as in "I do not want to add another dependency without a good reason".
Signature · 2 lines
ciao, Marco