[PATCH 0/2] crypto: remove MD4 generic shash

[Jeremy Allison]

On Wed, Aug 18, 2021 at 11:47:53AM -0500, Steve French via samba-technical wrote:
>I don't object to moving ARC4 and/or MD4 into cifs.ko, but we do have
>to be careful that we don't make the defaults "less secure" as an
>unintentional side effect.
>
>The use of ARC4 and MD4 is the NTLMSSP authentication workflow is
>relatively small (narrow use case), and NTLMSSP is the default for
>many servers and clients - and some of the exploits do not apply in
>the case of SMB2.1 and later (which is usually required on mount in
>any case).
>
>There is little argument that kerberos ("sec=krb5") is more secure and
>does not rely on these algorithms ... but there are millions of
>devices (probably over 100 million) that can support SMB3.1.1 (or at
>least SMB3) mounts but couldn't realistically join a domain and use
>"sec=krb5" so would be forced to use "guest" mounts (or in the case of
>removing RC4 use less secure version of NTLMSSP).
>
>In the longer term where I would like this to go is:
>- make it easier to "require Kerberos" (in module load parameters for cifs.ko)
>- make sure cifs.ko builds even if these algorithms are removed from
>the kernel, and that mount by default isn't broken if the user chooses
>to build without support for NTLMSSP, the default auth mechanism (ie
>NTLMSSP being disabled because required crypto algorithms aren't
>available)
>- add support in Linux for a "peer to peer" auth mechanism (even if it
>requires an upcall), perhaps one that is certificate based and one
>that is not (and thus much easier to use) that we can plumb into
>SPNEGO (RFC2478).    By comparison, it sounds like it is much easier
>in Windows to add in additional authentication mechanisms (beyond
>Kerberos, PKU2U and NTLMSSP) - see
>https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/jj852232(v=ws.11)
>so perhaps we just need to do something similar for the kernel client
>and samba and ksmbd where they call out to a library which is
>configured to provide the SPNEGO blobs for the new stronger
>peer-to-peer authentication mechanism the distro chooses to enable
>(for cases where using Kerberos for authentication is not practical)

My 2 cents. Preventing NTLM authentication/signing from working would be
a negative for the Linux kernel client. I don't mind if that code has
to be isolated inside cifs.ko, but it really needs to keep working,
at least until we have a pluggable client auth in cifs.ko and Samba
that allows the single-server (non AD-Domain) case to keep working
easily.