On Sun, Jan 07, 2001 at 12:19:08PM +0100, Peter Stamfest wrote:
> On Sun, 7 Jan 2001, Kris Kennaway wrote:

> > Date: Sun, 7 Jan 2001 01:48:01 -0800
> > From: Kris Kennaway <[EMAIL PROTECTED]>
> > Reply-To: [EMAIL PROTECTED]
> > To: [EMAIL PROTECTED]
> > Subject: Re: Open VPN - Anybody interested / suggestions

> > On Fri, Jan 05, 2001 at 11:51:03AM +0100, Peter Stamfest wrote:

> > > So do you think it is a waste of time to start such a project?

> > Frankly, yes. Just use the industry-standard IPSEC, don't try and
> > reinvent the wheel yet again and possibly screw up the crypto like M$
> > did with PPTP.

> OK, I see your point of view, but after some more researching during the
> last couple of days I still have the following problemes:

> * IPSec is hard to configure

        This is subjective.  I find IPSec (now) no harder to setup than
any other VPN and far more reliable.  In the early days of shared keys,
FreeS/WAN was a bugger to set up.  Now, with RSA keys and certificates,
it's really pretty simple and dependent on the complexity of the networks
you are trying to connect.  I can't totally vouch for PGPNet, but many
people speak highly of it.  TimeSTEP and VPN-1 seem to be pretty straight
forward to install as well.  Even end users can handle that without IS
holding their hands (and some of them have trouble with WinZIP).

> * There seems to be no good certificate based IPSec solution for W95/W98

        What?!?!?!?  This makes no sense.  Most of the IPSec solutions
I know of (TimeStep, Checkpoint VPN-1, PGPNet) support certificates
and most support some form of Token Cards (SecureID, S/KEY).  Most of
them can use Radius servers for authentication, so anything supported by
your Radius server should be supported.  Or is this hinging on your
usages of the work "good".  And is that "good certificates" or is that
"good .... solution"?  Personally, I have a low opinion of certificates
in general due to the administrative heirarchy (certifying authorities)
that they create.  Authentication is definitely the bugger in VPN's though.

> * There is no good AND free VPN solution out there. 

        Depends a lot on your definition of good and what you are trying
to do.  If you are just worried about transport mode, PGPNet is free and
supports certificates (that FreeS/WAN can use).

> As an example, I would like to mention PGPNet:

> * One needs to use shared secrets if combined with FreeS/Wan

        Ok...  Where have you been?  We've got people using PGPNet X.509
certificates in FreeS/WAN (with patches) for some time now.  We have
reported successes on the FreeS/WAN list of people using PGPNet 7 with
FreeS/WAN using PGPNet keys and certificates.  This is just flat out wrong
and based on out of date information (like almost a year out of date).

> * The freeware version does not allow to access a whole network behind the
>   VPN gateway   

        True.  But rumor has it you can get the full version for some
reasonable bucks if you try hard enough.  Actually, I think someone was
saying that the International version DOES allow tunnel mode (for network
gateways) and is free.  Might be some older versions work too.  The
time limited version also tunnels, if you want to run some proof of
concept tests before committing bucks.

> * The non-free version is expensive. [Especially, since I am looking for a
>   way to allow students of educational institutions some very limited
>   access to some resources, something that could be easily done based on 
>   certificates and PPP encapuslation and some firewall rules.]

        So, if you want to set up a network gateway, why not use a Linux
box for the gateway.  You are complaining that you don't have free software
for the gateway.  But you do: Linux with FreeS/WAN.  You don't have free
software for a gateway on Windows.  So you don't have free software for
a security gateway that you want to run with some of the world's most
insecure software and for which you had to pay Redmond a license.  When
there is a more secure, free, option available.  Does this make sense?
It would be a cold day in hell before I ran a Microsoft product on a
security gateway.  Since you HAVE to pay (one way or the other) for
Windows, it's tautological that there can be no free VPN gateway
software when Windows is involved (unless you want to ignore that cost).

        Developing your own solution is also not free.  Figure what your
time is worth at your nominal rate (salary, hourly, or contract) and then
figure 6 man months just to find out how big the elephant is that you
are trying to eat.  That "free" project is not so free anymore.

> Name a solution that can do all that on the currently available operating 
> systems.

        Huh????

        For Linux:

        VPN Solution:   FreeS/WAN 1.8 w/ X.509 patches

        Supported:      Shared Keys
                        RSA Keys
                        RSA Keys in secure DNS distribution
                        X.509 Certificates
                        PGP Net Keys

        Similar solutions (Kame for FreeBSD, Builtin for OpenBSD) exist
for FreeBSD, OpenBSD, and NetBSD.

        Now...  You say "the currently available operating systems".
You really have to define yourself much better.  I don't know what's
available on Mac or BeOS, but they are currently available operating
systems.  IPSec is available for Solaris and (I'm pretty sure) many
of the other *NIX operating systems such as HP/UX, AIX, IRIX, UnixWare,
and SCO Unix.  These are also "the currently available operating systems"
but I suspect they are not what you are referring to and I doubt you
are proposing to develope for.

        Windows, you have FreeWare, ShareWare, and PayWare solutions.
You want CHEAP and reliable and secure, dump Windows and go with Linux.
You would NEVER want someone actually working on a security gateway.
as a workstation, anyways.  Just the virus threat alone is enough to
say that the security gateway to a network should never be a Windows
system with someone actually using it.  So then, why use Windows?

> I like the idea to use L2TP, but IPSec is quite an overkill (though it is
> a good solution, in principle).

        IPSec in and of itself is really pretty simple.  It's IKE that
gets ugly.  The encryption layer itself is no big deal (and has absolutely
nothing to do with certificates).  It's the key management and key exchange
that gets ugly.  Are you going to periodically refresh your session keys?
If so, what's your key exchange protocol for negotiating new session
keys and how do you coordinate if one side or the other drops a key exchange
packet and ends up out of step?

> The main problem is the availablility of a free windows client that does
> all I want.

        You have a free Windows client.  You don't have one for using
Windows as a security gateway to an entire network, but I seriously
question why anyone would want to do that when there are better and
cheaper alternatives.

> The client would not be hard to write, actually. It mainly consists of a
> virtual modem driver and an application level service. The virtual modem
> could be good for hundreds of other things as well, so it could provide
> for more than just a free VPN solution. [ I guess many people look for
> free windows driver source code, have a look at some newsgroups. ] 

        I think you underestimate the degree of difficulty you are facing.
The virtual modem driver is trivial compared to what you will have to
write at the application layer.  The cryptography itself is also canned
and pretty trivial compared to the non-negligible tasks of key management
and key distribution and insuring that those take place in a secure maner.

        IPSec is SIMPLE!  IKE is HARD!

        If you are not going to have users configuring their own clients,
then you have to get into the arena of key/certificate distribution and
management.  You also have to consider attempts to spoof connections
or hijaack connections (Man In The Middle attacks ala dnsniff) or simple
DoS connections (ala CookieCrumbs against IKE / ISKMP/OAKLEY).  Plus
you have the various attacks and flaws pointed out by Bruce Schneier and
Dr Muge in PPTP.

> That is what I am really looking for. It is always so simple to say: There
> is this and that out there, use that, if there is no solution implementing
> it.

        You would need to spend time just designing (or understanding)
the protocols before even the first line of code is written.  It's easy
to speak in broad generalizations.  It's a lot tougher when the rubber
means the road an you have to actually design something.

> I totally agree that I do not want to screw up security like MS did with
> PPTP, that is why I do not like their VPN concept. I am looking for
> something better.

        Don't worry.  You will.  It's almost axiomatic that if you think
you know how to do this, then you don't.  Even IPSec has it's problems.
Nothing, NOTHING, is going to be created correctly first time, or in
isolation.  Certainly not security solutions or cryptography.  Expect
that you WILL fail and that you WILL have holes in it the first several
times around (look at SSH, SSL, or even PGP for that matter).

> Ideally, it should be easily deployable (most users are frankly
> unable to configure anything), free, secure and expandable.

        Look at those criterion very carefully and you will discover that
they are incompatible.  What you have are tradeoffs.  How do you verify
that you are talking to the systems you think you are.  Certificates?
How do you trust the certificates?  Certifying authorities?  How do
you trust the certifying authorities?  How do you distribute the
certificates?

        Define secure?  Secure is not connected to the network.  Anything
else is a series of risk assessments (intelligent or ignorant or something
in between) and compromises.  Recognize that.

        Define expandable?

> Unfortunately, I do not know of any such solution (yet). That is why I
> propose such a project.

> Is it still a waste of time to start something like this given the
> thought from above?

        Yes, unless you are interested in doing this as an intellectual
exercise.  It's probably a waste of time if your goal is to deploy
something for a production environment in any reasonable amount of time.
By the time you got this done, I suspect your production environment
will have adopted something else, moved on the other problems, or
morphed beyond your original expectations.

        The solutions are there and the elephant that you are trying
to eat is bigger than you imagine.  Participate in some of the other
VPN projects for a while and see where those projects are at and the
level of work involved.  The fact that you were ignorant of the support
for X.509 certificates and PGP Keys in FreeS/WAN tells me that you've
just been skimming over some out of date information sheets and FAQs.
You really need to be deeper involved before taking on a project like
this.  Read up on Bruce Schneier's paper about "Why Cryptography is
Harder Than It Looks" and apply the same ideas to VPNs.  The same
mistakes can be made.

> This is not a religious thing for me. I would be much happier without such
> a project. It is just that I need it. The sooner the better. Working.
> Stable. I also do not like to reinvent the wheel. I guess nobody likes it,
> but sometimes one is almost forced to do it. 

        Working and stable and soon are not things you will see together
(especially in the same pot with "cheap") in one spot by trying to reinvent
this whole process yourself.  I like what some of our development people
say, "You can have it stable, cheap, and fast.  Pick two."  You want it
stable, cheap, and as soon as possible.  Pick two.  You won't get there
by trying to create something like this new, on your own.  It will be
unstable, barely working, and take forever to get to something you can
use.  And it will cost you man months or more.

        Think about it.  If it was so easy to just cook something like
this up, why hasn't anyone else done it?  It's not for lack of attempts
or effort or expertise or trying?  We've got lots of brilliant people
working on this and no one has discovered the holy grail yet.

> More input is very welcome. I would really like to be convinced that such
> a project is complete nonsense and that I am a fool to have even proposed
> it. 

        You MIGHT find some help in the CIPE project.  That's a project
along lines similar to what you describe but is strictly Linux to Linux.
It's also UPD based.  Maybe you would want to look at that as try your
ideas for a Windows client out against their protocol.  At least then
you don't have to recreate ALL of the wheels (just a couple of them).
You don't have to design a protocol or create the Linux side of the
house.  Just create a conforming Windows client.

> Also, I may discover this by myself. I have received some very welcomed
> input already, and I am still investigating. So maybe I will find out that
> I am a fool in just half an hour, but the last day showed many problems
> with alternatives.

        I don't want to discourage you.  I do want to encourage you into
looking deeper into the development efforts that are taking place right
now.  You may be able to contribute something back to the effort (like
maybe a free tunnel mode IPSec client for Windows).  You may get a better
idea of the development effort involved and, hopefully, learn of some
of the non-obvious pitfalls in software like this.

        But if you are seriously bound and determined...  By all means,
have at it.  Miracles have occured and this is how we get new projects
off the ground.  I would also suggest you read Eric Raymonds papers
about "The Cathedral and the Baazar".  If you are expecting to start
a project, it becomes up to you to bring it to a certain level of
functionality in order to begin attracting outsiders into contributing
(if that's what you goal is).  I don't seriously see how you could
manage to accomplish this totally on your own in any reasonable amount
of time.  The testing time, in all kinds of different environments
with different firewalls and filters and MTU sizes and transports,
alone is going to eat you alive.  You will have to have volunteers
and contributors just to deal with the diverse environments your
software will have to encounter out in the wild.  For that, you have
to have something to interest them and entice them.  Something more
attractive than the current projects.

        That's how this project, OpenSSL (originally SSLeay), got started
with Eric Young and Tim Hudson.  But look how long that's been...  And
it's still evolving.  :-)

> peter

        Mike
-- 
 Michael H. Warfield    |  (770) 985-6132   |  [EMAIL PROTECTED]
  (The Mad Wizard)      |  (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!

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [EMAIL PROTECTED]
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to