[Openswan dev] Openswan + FIPS thoughts

[David McCullough]

Jivin Ken Bantoft lays it down ...
> 
> On Tue, 30 Oct 2007, David McCullough wrote:
> 
> > 
> > Jivin Paul Wouters lays it down ...
> > > On Tue, 30 Oct 2007, David McCullough wrote:
> > > 
> > > > We are just starting out on a FIPS certification for some of our
> > > > products,  and they will include Openswan.  So far we can see no
> > > > problems with getting the certification,  but we are interested in some
> > > > feedback on the changes we need to make to get this through.
> > > 
> > > We have had inquieries in the past. Usually couped with "openssl is
> > > already paid for with FIPS, and so is NETKEY, can we change pluto to
> > > only use openssl with NETKEY".
> > 
> > It's not paid for, everyone needs to certify their version ...
> > 
> > The difference is that is has been certified and is using FIPS approved
> > algs etc.
> 
> I think (hope) Paul meant 'openssl is already certifiable for FIPS'.. so 
> no arguments there.

No problems :-)

> > > > We are considering two possible approaches:
> > > >
> > > > 	1) Replace all the libgmp/crypto code in Openswan user space to use
> > > > 	   libssl/openssl exclusively.  This will mean we have a single
> > > > 	   point of testing/implementation for FIPS.  It also means that
> > > > 	   OpenSwan will continue to use OCF for user space as appropriate,
> > > > 	   but can also take advantage of the many other openssl engines and
> > > > 	   accelerators.
> > > 
> > > We found that hw accelerators for userland was hardly worth it (and at
> > > times slower then using hardware)
> > 
> > Yes,  know all about that,  but you don't need to use them.
> > 
> > The thing is that on platforms like Via/Geode and so on,  the openssl
> > engine doesn't have to call into the kernel.  A lot of CPU manufacturers
> > also accelerate openssl first which can be useful (depending on the
> > platform).
> > 
> > Seemed like a nice side affect,  and since I though you guys had already
> > included the OCF accelerations into pluto,  this actually seems cleaner
> > IMO.
> 
> These patches would be welcome, I think.  I'm hoping you are working 
> around 2.5/#testing/etc.. and not based around 2.4.x.

I figured if we were to go this route we would have to dump the stable
2.4.x we are currently working on and move to a 3.0 (or whatever it is
now) tree.

So there are no issues with that,  I had already assumed it would be
required.

> > > > 	2) The second,  perhaps not so pretty solution,  is to hook
> > > > 	   everything in openswan userspace as has been done already for
> > > > 	   OCF, but to do it for everything that FIPS cares about.
> > > >
> > > > I am not sure of the history here,  so perhaps there is a reason why it
> > > > should or shouldn't be done this way or that.
> > > 
> > > Part is probably history (openssl didnt have the functionality needed).
> > > Part is bloat (openssl is huge)
> > 
> > No arguments on that one,  though it is also hard to produce a useful
> > platform without it in some form.
> > 
> > > Part of it was security (openssl is vulnerable on a weekly basis to something)
> > 
> > Which is also a good thing right ?  More eye's and faster fixes and all
> > that ?
> > 
> > > While it may satisy FIPS, it might not actually be more secure.
> > 
> > No one who knows there stuff will ever say that FIPS is more secure.
> > It's more about expected behaviour and being able to test that the
> > system is indeed producing the expected behaviour.
> 
> And part of it was politics - OpenSSL had US-based developers, and during 
> the FreeS/WAN era, there was the rule against accepting patches from US 
> developers.  We're long since that, so I don't see any reason why not.

Thats the bit I was missing, thanks.

> > > > Would switching from libgmp/ouwn crypto to a completely libssl solution
> > > > for the big num and user space crypto code be attractive to the openswan
> > > > community ?
> > > 
> > > I guess ideally, we could allow either one.
> > 
> > It may not be too much work to allow a compile time switch to select.
> > I just remember Michael complaining that the OCF changes didn't rip out
> > all the old crufty crypto.  I figured I would see if this was desired
> > this time around ;-)
> 
> Yes, patches to remove cruft are always welcome.. and tend to get 
> integrated a bit quicker these days (provided they are against #testing) 
> since we're back to running daily regression builds (so we know in a day 
> if they broke stuff)

ok.

> > > Michael has more intimate knowledge about the aceleration issues.
> > 
> > The acceleration (if you get it) is only a side benefit at best.  It
> > seemed like a possible plus to switching to OpenSSL.
> > 
> > Our primary goal is to create a system that will pass FIPS with the minimum
> > of overheads (boot/runtime tests).  To us this means having one of
> > everything.  One 3DES implementation, one key gen, one big num lib and
> > so on.  Since the system will have Openswan, OpenSSL amd other systems,
> > we are looking to reduce duplication of algs and so on.
> 
> Sounds good to me.

As always,  I have trouble knowing which git tree to pull from you guys :-)
I noticed some IKEv2 commits going on.  That is something ew would also
be keen to include,  and we need OCF in our Openswan stack.

Actually,  given all the requirements,  I think we need to use 3.0.
Is that even an option ?  Porting our OCF changes up to 2.5 may be safer
at this point if 3.0 is truly unstable and untested ?  Seems like #testing
is 2.5 based.

Thoughts ?

Thanks,
Davidm

-- 
David McCullough,  david_mccullough at securecomputing.com,   Ph:+61 734352815
Secure Computing - SnapGear  http://www.uCdot.org http://www.cyberguard.com