[Openswan dev] Openswan + FIPS thoughts

[Ken Bantoft]

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.

> > > 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.

> > > 	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.


> > > 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)

> > 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.

Ken