From: Steve French <email@example.com> To: Denis Kenzior <firstname.lastname@example.org> Cc: Ard Biesheuvel <email@example.com>, Linux Crypto Mailing List <firstname.lastname@example.org>, Herbert Xu <email@example.com>, Eric Biggers <firstname.lastname@example.org>, ronnie sahlberg <email@example.com>, linux-cifs <firstname.lastname@example.org>, Steve French <email@example.com>, David Howells <firstname.lastname@example.org>, email@example.com, samba-technical <firstname.lastname@example.org> Subject: Re: [PATCH 0/2] crypto: remove MD4 generic shash Date: Wed, 18 Aug 2021 11:47:53 -0500 [thread overview] Message-ID: <CAH2r5muhHnrAbu-yX3h1VPjW+2CUyUtSCzyoOs7MXw=fE7HA_Q@mail.gmail.com> (raw) In-Reply-To: <email@example.com> 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) On Wed, Aug 18, 2021 at 11:24 AM Denis Kenzior <firstname.lastname@example.org> wrote: > > Hi Ard, > > >> The previous ARC4 removal > >> already caused some headaches . > > > > This is the first time this has been reported on an upstream kernel list. > > > > As you know, I went out of my way to ensure that this removal would > > happen as smoothly as possible, which is why I contributed code to > > both iwd and libell beforehand, and worked with distros to ensure that > > the updated versions would land before the removal of ARC4 from the > > kernel. > > > > It is unfortunate that one of the distros failed to take that into > > account for the backport of a newer kernel to an older distro release, > > but I don't think it is fair to blame that on the process. > > Please don't misunderstand, I don't blame you at all. I was in favor of ARC4 > removal since the kernel AF_ALG implementation was broken and the ell > implementation had to work around that. And you went the extra mile to make > sure the migration was smooth. The reported bug is still a fairly minor > inconvenience in the grand scheme of things. > > But, I'm not in favor of doing the same for MD4... > > > > >> Please note that iwd does use MD4 for MSCHAP > >> and MSCHAPv2 based 802.1X authentication. > >> > > > > Thanks for reporting that. > > > > So what is your timeline for retaining MD4 support in iwd? You are > > aware that it has been broken since 1991, right? Please, consider > > having a deprecation path, so we can at least agree on *some* point in > > time (in 6 months, in 6 years, etc) where we can start culling this > > junk. > > > > That is not something that iwd has any control over though? We have to support > it for as long as there are organizations using TTLS + MD5 or PEAPv0. There > are still surprisingly many today. > > Regards, > -Denis -- Thanks, Steve
next prev parent reply other threads:[~2021-08-18 16:48 UTC|newest] Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-08-18 14:46 Ard Biesheuvel 2021-08-18 14:51 ` Denis Kenzior 2021-08-18 16:10 ` Ard Biesheuvel 2021-08-18 16:23 ` Denis Kenzior 2021-08-18 16:47 ` Steve French [this message] 2021-08-18 22:08 ` Jeremy Allison 2021-08-19 3:49 ` Andrew Bartlett 2021-08-19 5:18 ` Eric Biggers 2021-08-19 5:23 ` Andrew Bartlett 2021-08-18 21:11 ` ronnie sahlberg 2021-08-18 22:10 ` Ard Biesheuvel 2021-08-18 22:22 ` Denis Kenzior 2021-08-18 23:03 ` Steve French 2021-08-19 16:56 ` Denis Kenzior 2021-08-19 10:42 ` Jarkko Sakkinen 2021-08-19 17:10 ` Steve French 2021-08-19 20:54 ` ronnie sahlberg
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAH2r5muhHnrAbu-yX3h1VPjW+2CUyUtSCzyoOs7MXw=fE7HA_Q@mail.gmail.com' \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH 0/2] crypto: remove MD4 generic shash' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).