[ale] IPSec client for Linux?

[Michael H. Warfield]

Yo Bob...

	This is getting more entangled than I expected...  Oh well...  Love
digging into the dark bowels of cryptography...

On Fri, 2005-06-17 at 14:47 -0400, Bob Toxen wrote:
> On Thu, Jun 16, 2005 at 05:31:45PM -0400, Michael H. Warfield wrote:
> > On Wed, 2005-06-15 at 18:40 -0400, Bob Toxen wrote:
> > > On Tue, Jun 14, 2005 at 03:36:53PM -0500, ChangingLINKS.com wrote:
> > > > Does anyone VPN in to their employer's network using anykind of IPSec client
> > > > for Linux?

> > > > If I had a solution for that, I think I could stop using windows. On
> > > > Windows, I'm currently using a Cisco IPsec client to access a customer VPN
> > > > and a Lucent IPsec client to access Lucent's network.  
> > > FreeS/WAN is the Open Source standard and it works as well as any IPSec
> > > implementation does.  (IPSec is garbage and hard to use but it
> > > is STANDARD garbage and everyone supports it.)

> > 	Define "garbage"?
> IMO, you did define "garbage" in your reply to my previous post:

>   1. Royal pain over NAT devices (except when using the new NAT-T).

	Ok...  So NAT borked another protocol yet again and so they
incorporated a workaround for the broken NAT.  Sounds like an echo
around here, whenever NAT comes into the conversation.  NAT-T is not new
by any means.  NAT-T is now (and has been) a part of IPSec (and
standardized - RFC 3947 and 3948) and is in all of the Linux IPSec
projects including Klips and the 2.6 kernel stacks and supported by
Pluto from Openswan / FreeS/WAN / Strongswan as well as Racoon from
IPSec Tools.  This has been in there for years.  It was plugged into
FreeS/WAN long before Gilmore and crew closed up shop on FreeS/WAN and
it forked into the other two projects (Openswan and Strongswan).  I
THINK is was even in later versions of the old 1.x FreeS/WAN, it's that
old.  It's just a feature of IPSec now, and has been for a long time, so
I fail to see your point.  Nothing new here at all.

>   2. New protocols for no good reason (now fixed with ESPinUDP, in other
>      words now using UDP as it should have all along).

	Not hardly.  You don't use UDP in all cases (and would never need to on
IPv6 at all), why would you want to?  It's just another example of
people having to deal with broken NAT implementations.  NAT is broken
and continues to break other things and people continue to have to work
around it.  That's the very nature of NAT.  Why have to insert another
protocol header (UDP) just to have some non-relevant port information so
that the two networking layers can be transported?  Waste of bandwidth
and MTU that does nothing to improve the protocols.  The "as it should
have all along" makes no sense at all.

> Frankly, I much prefer CIPE as a much better design, IMO.

	Are you serious or just trying to troll me?

	Word I've heard on several mailing lists is that support for CIPE is
evaporating (has evaporated).  Last version was version 1.6.0 which was
released almost a year ago (August 4 2004) for compatibility with the
crypto API in the 2.6 kernels.  At that time, the public key code was
alpha quality only, with last update dating back to July of 2003 and a
warning in the README not to use or rely on it.  So you only had static
shared secret keys, even in the latest version, unless you wanted to
ignore his warnings about not using the PKCIPE code.  AFAICT, that
version (1.6.0) has never made it into any .apt or .rpm repositories
that I've been able to uncover.  You also can't even compile it and get
it to work on Suse 9.x or Redhat w/ the 2.6 kernels (and probably not
with Mandrake or any others with 2.6 kernels) without recompiling the
entire kernel (incompatible build option, you have to compile the kernel
with REGPARM = disabled or, it's been reported, you get kernel panics
when connections are established).  It also has not been updated for the
latest 2.6 build systems and still requires full source trees
under /usr/src/linux rather than referencing the build
under /lib/modules/kernel{ver}/build/...  So, you've got no modern
prebuilt packages and you're going to have to build up a complete custom
kernel (each time the kernel gets updated) and you've got no production
quality public key crypto and have to rely on shared secrets.  This is a
better design?

	CIPE also only had clients for Linux and Windows and those two projects
were developing independently.  There were no clients on the horizon for
other platforms, AFAICT.  That's nice if your world is strictly Windows
and Linux.  And you don't run into version skew between the two
projects.

	Since it does support IPv6, I was tempted to incorporate it into a
small project / distro I'm working on along side IPSec and OpenVPN (and
Miredo and several other IPv6 compatible transports).  Unfortunately,
CIPE seems to be unavailable and incompatible with most of the most
recent (2.6 kernel based) distros.  CIPE was removed from Fedora Core
way back in Fedora Core 2 (which is now moving to legacy with the
releases of FC4) because it was incompatible with the 2.6 kernel.  That
situation only marginally improved with the 1.6.0 release of CIPE but it
never made it back as a supported package (and Debian is still on 1.5.4
in all repositories, which is not compatible with the 2.6 kernels at
all).

	Since production quality crypto has finally made it into the mainline
kernel sources, we're seeing some significant fallout from natural
selection in some of the crypto projects.

	File systems (devices) use to have ppdd and cryptoloop and loopback
crypto (kerneli) and loopAES.  Now, some of those are still around but
support for them is dying (in spite of what Jari might say on the
linux-crypto list about loopAES).  I had contributed to more than one of
those projects.  Cryptoloop is still usable in the kernel but why bother
with it when dm_mapper and dm_crypt is so much better (in spite of what
Jari might say on the linux-crypto list) and supported and stable (my
entire laptop is encrypted using dm_crypt).  Ppdd is pretty much dead
and loopAES is fading fast (who wants to recompile a kernel every time
things are updated plus rebuild the support utilities like losetup and I
don't think it's been updated to the latest kernels IAC).   So, what
ever the technical merits the adherents may proclaim, natural selection
is weeding out the field of contenders and some of the older projects
are now unmanned and largely unsupported outside of legacy.

	Same thing is taking place in the transport crypto and VPNs.  IPSec is
the defacto interoperability standard.  In fact, the CIPE FAQ even
claims its only advantage over IPSec MIGHT be performance improvements
due to a simpler protocol.  The fact that IPSec with NAT-T is built into
the 2.6 kernels pretty much assures it dominance.  OpenVPN is hanging in
there with some interesting niches such as the JOIN project (which was
using OpenVPN with the NULL cipher as an IPv6 tunnel broker) and it has
a broad base of platforms it supports and it finally got an IANA port
assignment.  So, I see OpenVPN hanging around for a while in spite of
some of the scaling problems they have (JOIN project had to drop the
crypto for performance reasons and still needed a beefy server to
service all that user space packet handling and all those processes).
Other projects are not faring so well.

	Given the complexity and difficulty of setting up CIPE on a modern 2.6
system plus being stuck with shared secrets, I would have to say that
IPSec with shared secrets would be simpler to set up and just as secure.
Maybe even more secure, since IPSec and IKE support perfect forward
secrecy and compromising the shared secret need not compromise the
confidentiality of the communications channel.  From reading the doco on
CIPE it sounds like he is negotiating a new ephemeral session key
periodically but not by means of Diffie-Hellman or other negotiation
mechanism that would insure perfect forward secrecy.  That leaves you
with "once a channel is compromised, by any means (key compromise, key
leakage), it remains compromised and future ephemeral keys can be
deduced from the traffic".  I don't like that at all.  Maybe I'm reading
his docs (and the sources) all wrong and maybe he does a true D-H
negotiation in there.  But I don't see it.  That may also relate to the
"replay vulnerability" mentioned in a message on the CIPE mailing list
quoted below.

	So I guess, if you tried really hard, you could dumb down IPSec to the
point that it was the equivalent of CIPE and then CIPE might have some
performance advantage over IPSec (at least over IPSec NAT-T - I don't
see how having yet another protocol layer (UDP) in there will improve
performace).  But I would contend that setting up CIPE on ANY 2.6 based
system is going to be painful beyond belief and a nightmare to maintain.
And would you really trust it?

	A quick browsing of the CIPE mailing list shows that Olaf Titz hasn't
posted there in months.  Not even to reply to some security issues!
Last posting by him was to announce the 1.6.0 release and nobody has
heard a peep since.

	Things like this concern me:

> Hi,
> 
> today I have found a link that claims cipe to be vulnerable for being
> easy to encrypt by third party and even being vulnerable to replay
> attacks.
> 
> The page is quite old but as it is representing a mail archive, it may
> be up-to-date?
> 
> See
>         http://diswww.mit.edu/bloom-picayune/crypto/14238
> 
> Is this still the case?
> 
> cu
> Sascha

	And the response back was:

> Sascha,
> 
> I have not heard of any protocol change which fixes these issues, either in
> the official release or in any available patch.  I'd like it very much if
> Olaf is still around and reading this to be able to make a comment, even if
> it's one that says he doesn't have time.
> 
> Regards,
> 
> --
> Mark Smith - Avco Systems Ltd                        Tel: +44 (0)1784 430996
> email: mark.smith,AT,avcosystems,DOT,co,DOT,uk                  Fax: +44 
> (0)1784 431078

	I like this one:

> On Wed, 2005-02-23 at 14:38 +0100, Sascha Wuestemann wrote:
> > Hi,
> > 
> > today I have found a link that claims cipe to be vulnerable for being
> > easy to encrypt by third party and even being vulnerable to replay
> > attacks.
> > 
> > The page is quite old but as it is representing a mail archive, it may
> > be up-to-date?
> 
> I'm thinking that IPSEC + NAT-T will work out better for people.  Though
> I think IKE is ugly.  :-(
> 
> Have fun (if at all possible),
> -- 
> The best we can hope for concerning the people at large is that they
> be properly armed.  -- Alexander Hamilton
> -- Eric Hopper (hopper,AT,omnifarious,DOT,org  
> http://www.omnifarious.org/~hopper) --

	So they're opining on the CIPE list that IPSec + NAT-T will work out
better for people...  That list is getting really quiet, lately...
Ominous.

	No response from Olaf...  And that was back in February...

	Unless Olaf gets off the dime and does some serious updating to get
CIPE back into the modern world and addresses some of the issues, I see
that as yet another dead-end crypto project on a very short leash.
ITMT...  I would avoid CIPE...

	Regards,
	Mike
-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw at WittsEnd.com  
  /\/\|=mhw=|\/\/       |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part