| Message ID | 20210818144617.110061-1-ardb@kernel.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | crypto: remove MD4 generic shash | expand |
Hi Ard, On 8/18/21 9:46 AM, Ard Biesheuvel wrote: > As discussed on the list [0], MD4 is still being relied upon by the CIFS > driver, even though successful attacks on MD4 are as old as Linux > itself. > > So let's move the code into the CIFS driver, and remove it from the > crypto API so that it is no longer exposed to other subsystems or to > user space via AF_ALG. > Can we please stop removing algorithms from AF_ALG? The previous ARC4 removal already caused some headaches [0]. Please note that iwd does use MD4 for MSCHAP and MSCHAPv2 based 802.1X authentication. Regards, -Denis [0] https://bugs.launchpad.net/ubuntu/+source/iwd/+bug/1938650
On Wed, 18 Aug 2021 at 16:51, Denis Kenzior <denkenz@gmail.com> wrote: > > Hi Ard, > > On 8/18/21 9:46 AM, Ard Biesheuvel wrote: > > As discussed on the list [0], MD4 is still being relied upon by the CIFS > > driver, even though successful attacks on MD4 are as old as Linux > > itself. > > > > So let's move the code into the CIFS driver, and remove it from the > > crypto API so that it is no longer exposed to other subsystems or to > > user space via AF_ALG. > > > > Can we please stop removing algorithms from AF_ALG? I don't think we can, to be honest. We need to have a deprecation path for obsolete and insecure algorithms: the alternative is to keep supporting a long tail of broken crypto indefinitely. > The previous ARC4 removal > already caused some headaches [0]. 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 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.
Hi Ard, >> The previous ARC4 removal >> already caused some headaches [0]. > > 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
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 <denkenz@gmail.com> wrote:
>
> Hi Ard,
>
> >> The previous ARC4 removal
> >> already caused some headaches [0].
> >
> > 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
On Thu, Aug 19, 2021 at 2:23 AM Denis Kenzior <denkenz@gmail.com> wrote: > > Hi Ard, > > >> The previous ARC4 removal > >> already caused some headaches [0]. > > > > 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. The same situation exist for cifs. The cifs client depends on md4 in order to authenticate to Windows/Azure/Samba/... cifs servers. And like you we have no control of the servers. Our solution will likely be to fork the md4 code and put a private copy in our module. Maybe you need to do the same. -- ronnie > > Regards, > -Denis
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.
On Wed, 18 Aug 2021 at 18:23, Denis Kenzior <denkenz@gmail.com> wrote: > > Hi Ard, > > >> The previous ARC4 removal > >> already caused some headaches [0]. > > > > 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... > Fair enough. > > > >> 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. > Does that code rely on MD4 as well?
Hi Ard, >> 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 Ah, my brain said MSCHAP but my fingers typed MD5. >> are still surprisingly many today. >> > > Does that code rely on MD4 as well? > But the answer is yes. Both PEAP and TTLS use MSCHAP or MSCHAPv2 in some form. These are commonly used for Username/Password based WPA(2|3)-Enterprise authentication. Think 'eduroam' for example. MD4 is used to hash the plaintext password, but the hash is sent inside a TLS tunnel, so there's really no immediate crypto weakness concern? At least there's not a replacement on the horizon as far as I know. EAP-PWD has its own problems and I doubt certificate based authentication will overtake username/password any time soon. Regards, -Denis
On Wed, Aug 18, 2021 at 5:22 PM Denis Kenzior <denkenz@gmail.com> wrote: > > Hi Ard, > > >> 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 > > Ah, my brain said MSCHAP but my fingers typed MD5. > > >> are still surprisingly many today. > >> > > > > Does that code rely on MD4 as well? > > > > But the answer is yes. Both PEAP and TTLS use MSCHAP or MSCHAPv2 in some form. > These are commonly used for Username/Password based WPA(2|3)-Enterprise > authentication. Think 'eduroam' for example. Can you give some background here? IIRC MS-CHAPv2 is much worse than the NTLMSSP case in cifs.ko (where RC4/MD5 is used narrowly). Doesn't MS-CHAPv2 depend on DES?
On Wed, 2021-08-18 at 15:08 -0700, Jeremy Allison via samba-technical wrote: > > 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. I would echo that, and also just remind folks that MD4 in NTLMSSP is used as a compression only, it has no security value. The security would be the same if the password was compressed with MD4, SHA1 or SHA256 - the security comes from the complexity of the password and the HMAC-MD5 rounds inside NTLMv2. I'll also mention the use of MD4, which is used to re-encrypt a short- term key with the long-term key out of the NTLMv2 scheme. This thankfully is an unchecksumed simple RC4 round of one random value with another, so not subject to known-plaintext attacks here. I know neither MD4 nor HMAC-MD5 is not flavour of the month any more, with good reason, but we would not want to go with way of NFSv4 which is, as I understand it, full Kerberos or bust (so folks choose no protection). Andrew Bartlett
On Thu, Aug 19, 2021 at 03:49:14PM +1200, Andrew Bartlett wrote: > I know neither MD4 nor HMAC-MD5 is not flavour of the month any more, > with good reason, but we would not want to go with way of NFSv4 which > is, as I understand it, full Kerberos or bust (so folks choose no > protection). I'm not sure you understand how embarrassing it is to still be using these algorithms. MD4 has been broken for over 25 years, and better algorithms have been recommended for 29 years. Similarly MD5 has been broken for 16 years and better algorithms have been recommended for 25 years (though granted, HMAC-MD5 is more secure than plain MD5 when properly used). Meanwhile SHA-2 is 20 years old and is still considered secure. So this isn't something that changes every month -- we're talking about no one bothering to do anything in 30 years. Of course, if cryptography isn't actually applicable to the use case, then cryptography shouldn't be used at all. - Eric
On Wed, 2021-08-18 at 22:18 -0700, Eric Biggers wrote: > I'm not sure you understand how embarrassing it is to still be using > these > algorithms. MD4 has been broken for over 25 years, and better > algorithms have > been recommended for 29 years. Similarly MD5 has been broken for 16 > years and > better algorithms have been recommended for 25 years (though granted, > HMAC-MD5 > is more secure than plain MD5 when properly used). Meanwhile SHA-2 > is 20 years > old and is still considered secure. So this isn't something that > changes every > month -- we're talking about no one bothering to do anything in 30 > years. > > Of course, if cryptography isn't actually applicable to the use case, > then > cryptography shouldn't be used at all. I'm sorry that Samba - or the Kernel, you could implement whatever is desired between cifs.ko and kcifsd - hasn't gone it alone to build a new peer-to-peer mechanism, but absent a Samba-only solution Microsoft has been asked and has no intention of updating NTLM, so embarrassing or otherwise this is how it is. Thankfully only the HMAC-MD5 step in what you mention is cryptographically significant, the rest are just very lossy compression algorithms. Andrew Bartlett
On Wed, 2021-08-18 at 18:10 +0200, Ard Biesheuvel wrote: > On Wed, 18 Aug 2021 at 16:51, Denis Kenzior <denkenz@gmail.com> > wrote: > > Hi Ard, > > > > On 8/18/21 9:46 AM, Ard Biesheuvel wrote: > > > As discussed on the list [0], MD4 is still being relied upon by > > > the CIFS > > > driver, even though successful attacks on MD4 are as old as Linux > > > itself. > > > > > > So let's move the code into the CIFS driver, and remove it from > > > the > > > crypto API so that it is no longer exposed to other subsystems or > > > to > > > user space via AF_ALG. > > > > > > > Can we please stop removing algorithms from AF_ALG? > > I don't think we can, to be honest. We need to have a deprecation > path > for obsolete and insecure algorithms: the alternative is to keep > supporting a long tail of broken crypto indefinitely. I think you are ignoring the fact that by doing that you might be removing a migration path to more secure algorithms, for some legacy systems. I.e. in some cases this might mean sticking to insecure algorithm *and* old kernel for unnecessary long amount of time because migration is more costly. Perhaps there could be a comman-line parameter or similar to enable legacy crypto? /Jarkko
Hi Steve, >> But the answer is yes. Both PEAP and TTLS use MSCHAP or MSCHAPv2 in some form. >> These are commonly used for Username/Password based WPA(2|3)-Enterprise >> authentication. Think 'eduroam' for example. > > Can you give some background here? IIRC MS-CHAPv2 is much worse than > the NTLMSSP case What background are you looking for? iwd [0] is a wifi management daemon, so we implement various EAP [1] and wifi authentication protocols. > in cifs.ko (where RC4/MD5 is used narrowly). Doesn't MS-CHAPv2 depend on DES? > You are quite correct. MSCHAPv2 also uses DES for generating the responses. EAP with TTLS+MSCHAPv2 and PEAP+MSCHAPv2 are two of the most deployed variants of WPA-Enterprise authentication using Username + Password. Deprecating MD4, MD5, SHA1 or DES would be quite disruptive for us. We are using these through AF_ALG userspace API, so if they're removed, some combination of kernel + iwd version will break. We went through this with ARC4, and while that was justified, I don't think the same justification exists for MD4. [0] https://git.kernel.org/pub/scm/network/wireless/iwd.git [1] https://en.wikipedia.org/wiki/Extensible_Authentication_Protocol Regards, -Denis
On Thu, Aug 19, 2021 at 5:42 AM Jarkko Sakkinen <jarkko@kernel.org> wrote: > > On Wed, 2021-08-18 at 18:10 +0200, Ard Biesheuvel wrote: > > On Wed, 18 Aug 2021 at 16:51, Denis Kenzior <denkenz@gmail.com> > > wrote: > > > Hi Ard, > > > > > > On 8/18/21 9:46 AM, Ard Biesheuvel wrote: > > > > As discussed on the list [0], MD4 is still being relied upon by > > > > the CIFS > > > > driver, even though successful attacks on MD4 are as old as Linux > > > > itself. > > > > > > > > So let's move the code into the CIFS driver, and remove it from > > > > the > > > > crypto API so that it is no longer exposed to other subsystems or > > > > to > > > > user space via AF_ALG. > > > > > > > > > > Can we please stop removing algorithms from AF_ALG? > > > > I don't think we can, to be honest. We need to have a deprecation > > path > > for obsolete and insecure algorithms: the alternative is to keep > > supporting a long tail of broken crypto indefinitely. > > I think you are ignoring the fact that by doing that you might be > removing a migration path to more secure algorithms, for some legacy > systems. > > I.e. in some cases this might mean sticking to insecure algorithm *and* > old kernel for unnecessary long amount of time because migration is > more costly. > > Perhaps there could be a comman-line parameter or similar to enable > legacy crypto? There are. For example less secure NTLMv1 is disabled in the build. On the command line "sec=krb5" will use kerberos, and we can move that to be the default, or at least autonegotiate it, but will require some minor changes to cifs-utils to detect if plausible Kerberos ticket is available for this mount before requesting krb5 automatically. But ... we already have parameters to disable SMB1, and in fact if you mount with "mount -t smb3 ..." we won't let you use SMB1 or SMB2 so we get the security advantages of preventing man-in-the-middle attacks during negotiation and encryption etc. In addition, SMB1 can be disabled completely by simply doing "echo 1 > /sys/module/cifs/parameters/disable_legacy_dialects" but even without that, to mount insecurely with SMB1 requires specifying it (vers=1.0) on the command line. In addition requiring the strongest encryption can be set by "echo 1 > /sys/module/parameters/cifs/require_gcm_256" Although moving to a peer to peer auth solution better than NTLMSSP is something important to do ASAP (we should follow up e.g. on making sure we work with the "peer to peer Kerberos" (which is used by Apple for this purpose) see e.g. https://discussions-cn-prz.apple.com/en/thread/252949265) Andrew Bartlett's note explains the bigger picture well: "I would echo that, and also just remind folks that MD4 in NTLMSSP is used as a compression only, it has no security value. The security would be the same if the password was compressed with MD4, SHA1 or SHA256 - the security comes from the complexity of the password and the HMAC-MD5 rounds inside NTLMv2. I'll also mention the use of MD4, which is used to re-encrypt a short- term key with the long-term key out of the NTLMv2 scheme. This thankfully is an unchecksumed simple RC4 round of one random value with another, so not subject to known-plaintext attacks here. I know neither MD4 nor HMAC-MD5 is not flavour of the month any more, with good reason, but we would not want to go with way of NFSv4 which is, as I understand it, full Kerberos or bust (so folks choose no protection)." "Thankfully only the HMAC-MD5 step in what you mention is cryptographically significant, the rest are just very lossy compression algorithms." -- Thanks, Steve
On Fri, Aug 20, 2021 at 3:10 AM Steve French <smfrench@gmail.com> wrote: > > On Thu, Aug 19, 2021 at 5:42 AM Jarkko Sakkinen <jarkko@kernel.org> wrote: > > > > On Wed, 2021-08-18 at 18:10 +0200, Ard Biesheuvel wrote: > > > On Wed, 18 Aug 2021 at 16:51, Denis Kenzior <denkenz@gmail.com> > > > wrote: > > > > Hi Ard, > > > > > > > > On 8/18/21 9:46 AM, Ard Biesheuvel wrote: > > > > > As discussed on the list [0], MD4 is still being relied upon by > > > > > the CIFS > > > > > driver, even though successful attacks on MD4 are as old as Linux > > > > > itself. > > > > > > > > > > So let's move the code into the CIFS driver, and remove it from > > > > > the > > > > > crypto API so that it is no longer exposed to other subsystems or > > > > > to > > > > > user space via AF_ALG. > > > > > > > > > > > > > Can we please stop removing algorithms from AF_ALG? > > > > > > I don't think we can, to be honest. We need to have a deprecation > > > path > > > for obsolete and insecure algorithms: the alternative is to keep > > > supporting a long tail of broken crypto indefinitely. > > > > I think you are ignoring the fact that by doing that you might be > > removing a migration path to more secure algorithms, for some legacy > > systems. > > > > I.e. in some cases this might mean sticking to insecure algorithm *and* > > old kernel for unnecessary long amount of time because migration is > > more costly. > > > > Perhaps there could be a comman-line parameter or similar to enable > > legacy crypto? > > There are. For example less secure NTLMv1 is disabled in the build. > On the command line "sec=krb5" will use kerberos, and we can move that > to be the default, > or at least autonegotiate it, but will require some minor changes to > cifs-utils to detect if > plausible Kerberos ticket is available for this mount before > requesting krb5 automatically. > > But ... we already have parameters to disable SMB1, and in fact if you > mount with > "mount -t smb3 ..." we won't let you use SMB1 or SMB2 so we get the > security advantages > of preventing man-in-the-middle attacks during negotiation and encryption etc. > In addition, SMB1 can be disabled completely by simply doing > > "echo 1 > /sys/module/cifs/parameters/disable_legacy_dialects" > > but even without that, to mount insecurely with SMB1 requires > specifying it (vers=1.0) on the command line. > > In addition requiring the strongest encryption can be set by > > "echo 1 > /sys/module/parameters/cifs/require_gcm_256" > > > Although moving to a peer to peer auth solution better than NTLMSSP is > something important to do ASAP Agreed. We need a new peer-to-peer authentication mechanism. But this is storage so things move slowly and we can't remove a feature that hundreds of millions of people depend on and break their environments just because "need tickbox". As an example of how long it takes to migrate to a different solution in mass deployed storage technologies just look at SMB1. The whole industry has been working hard and as fast as possible to move away from SMB1 since 2006 and we are still NOT at the stage where we can delete this functionality. Disable it by default for some configurations but delete? No. Even if we get a new peer-to-peer mechanism today, it will take up to 20 years before we will be able to delete MD4 support in the linux kernel for CIFS. Unless we want a wildly disruptive event where we either break storage for hundreds of millions of people or we force them to remain on 5.13 for the next 20 years. Storage is not the same as a cell-phone, or some consumer device where you can drop support or break them every few years. The timelines for migrating in storage is measured in decades. But I guess we will have a loadable module for MD4 in cifs that both the cifs client and the cifs server will be able to use. Other subsystems that have hard dependency on MD4 and can not just break their users can probably also just use the cifs_md4 module too if they want to. At least we can try to avoid a situation where we will have multiple different MD4 implementations for the next decade or two in the kernel. > (we should follow up e.g. on making sure we work with the "peer to > peer Kerberos" (which is used by Apple > for this purpose) see e.g. > https://discussions-cn-prz.apple.com/en/thread/252949265) > > Andrew Bartlett's note explains the bigger picture well: > > "I would echo that, and also just remind folks that MD4 in NTLMSSP is > used as a compression only, it has no security value. The security > would be the same if the password was compressed with MD4, SHA1 or > SHA256 - the security comes from the complexity of the password and the > HMAC-MD5 rounds inside NTLMv2. > > I'll also mention the use of MD4, which is used to re-encrypt a short- > term key with the long-term key out of the NTLMv2 scheme. This > thankfully is an unchecksumed simple RC4 round of one random value with > another, so not subject to known-plaintext attacks here. I know neither > MD4 nor HMAC-MD5 is not flavour of the month any more, > with good reason, but we would not want to go with way of NFSv4 which > is, as I understand it, full Kerberos or bust (so folks choose no > protection)." > > "Thankfully only the HMAC-MD5 step in what you mention is > cryptographically significant, the rest are just very lossy compression > algorithms." > > > > -- > Thanks, > > Steve