Getting Samba out of crypto (was: Re: [PATCH] Update to the Samba crypto requirements document)

[Andreas Schneider]

On Wednesday, 21 February 2018 03:46:07 CET Andrew Bartlett wrote:
> On Wed, 2018-01-03 at 11:36 +0100, Andreas Schneider via samba-
> 
> technical wrote:
> > Hi,
> > 
> > I've had a call with Nikos (GnuTLS maintainer) and we updated the
> > REQUIREMENTS document.
> > 
> > We've opened bugs to support missing crypto algorithms we require in
> > GnuTLS
> > and nettle. The plan is to move to GnuTLS one day to get out of the crypto
> > business and have more hardware accelerated crypto in Samba.
> 
> Picking this part of the thread back up, I would really like to get
> Samba out of the crypto game.  Even when copied from a 'safe' source
> (and while we trust it, if you were an auditor would you say Heimdal
> really the most well-respected source?), each one of these libraries
> needs careful checking.
> 
> Others feel the same way.  I've been slowly trying to get Samba the
> 'CII Best Practices' badge:
> https://bestpractices.coreinfrastructure.org/projects/200#security
> 
> There, one criteria is:
> https://github.com/coreinfrastructure/best-practices-badge/blob/master/
> doc/criteria.md#crypto_call
> 
> > If the software produced by the project is an application or library,
> > and its primary purpose is not to implement cryptography, then it SHOULD
> > 
> >  only call on software specifically designed to implement cryptographic
> > 
> > functions; it SHOULD NOT re-implement its own. (N/A allowed.)
> > [crypto_call]
> 
> Similarly, I've been asked to explain our in-tree crypto for a client,
> resulting in this page:
> 
> https://gitlab.com/catalyst-samba/samba-docs/wikis/cryptography/where-is-the
> -raw-crypto-implemented
> 
> I came back to this because the shamozzle in the encrypted_secrets
> module was raised in https://bugzilla.samba.org/show_bug.cgi?id=13276
> 
> As background, the choice of dependency there on either nettle or
> GnuTLS came about because the project started with GnuTLS, but then it
> was discovered later that RHEL6 (an important target platform) didn't
> offer the AEAD modes we wanted to use.
> 
> Sadly the in-tree option was missed.  (However while helpful in this
> instance the duplicate bindings isn't a pattern I would like to see
> repeated often.)
> 
> So, I would like to know what the remaining technical/political
> barriers to getting out of the crypto game really are:
> 
> * Are we willing in principle to require users install a crypto library
> like libnettle?

We should use GnuTLS and not libnettle as we want hardware-backed crypto. 
GnuTLS uses libnettle for a lot of crypto but not all.

See the updated REQUIREMENTS file here:

https://git.samba.org/?p=samba.git;a=blob;f=lib/crypto/
REQUIREMENTS;h=ff91a2f91749841998103a9bfdd56ef0513fb65e;hb=refs/heads/master

And especially:

https://gitlab.com/gnutls/gnutls/milestones/14


Recently GnuTLS got:
https://gitlab.com/gnutls/gnutls/merge_requests/572

which we need to activate RC4 etc for backwards compatibility in FIPS mode.


What is missing in nettle/gnutls is AES-CMAC support, Nikos asked for 
permission to use the Samba source code and ported it to nettle which will be 
merged soon. See:

https://git.lysator.liu.se/nettle/nettle/commits/cmac-support

> * Alternately (if anything) are we willing to disable for users who
> "can't/won't" install it?  

We should keep the old crypto around for some time and use GnuTLS if 
available.
 
> (I'm very comfortable with the AD DC requiring external crypto libs as
> long as it is installable somehow on RHEL 6).

RHEL6 will have it's last release soon and till we have GnuTLS as our crypto 
rolled out, it is probably unsupported.


	Andreas

-- 
Andreas Schneider                   GPG-ID: CC014E3D
Samba Team                             asn at samba.org
www.samba.org