Hi Chuck,
On Mon, Mar 6, 2023 at 5:17 PM Chuck Lever III chuck.lever@oracle.com wrote:
On Mar 6, 2023, at 3:16 AM, Geert Uytterhoeven geert@linux-m68k.org wrote: On Sun, 15 Jan 2023, Chuck Lever wrote:
From: Chuck Lever chuck.lever@oracle.com
Because the DES block cipher has been deprecated by Internet standard, highly secure configurations might require that DES support be blacklisted or not installed. NFS Kerberos should still be able to work correctly with only the AES-based enctypes in that situation.
Also note that MIT Kerberos has begun a deprecation process for DES encryption types. Their README for 1.19.3 states:
Beginning with the krb5-1.19 release, a warning will be issued if initial credentials are acquired using the des3-cbc-sha1 encryption type. In future releases, this encryption type will be disabled by default and eventually removed.
Beginning with the krb5-1.18 release, single-DES encryption types have been removed.
Aside from the CONFIG option name change, there are two important policy changes:
- The 'insecure enctype' group is now disabled by default.
Distributors have to take action to enable support for deprecated enctypes. Implementation of these enctypes will be removed in a future kernel release.
- des3-cbc-sha1 is now considered part of the 'insecure enctype'
group, having been deprecated by RFC 8429, and is thus disabled by default
After this patch is applied, SunRPC support can be built with Kerberos 5 support but without CRYPTO_DES enabled in the kernel. And, when these enctypes are disabled, the Linux kernel's SunRPC RPCSEC GSS implementation fully complies with BCP 179 / RFC 6649 and BCP 218 / RFC 8429.
Tested-by: Scott Mayhew smayhew@redhat.com Signed-off-by: Chuck Lever chuck.lever@oracle.com
Thanks for your patch, which is now commit dfe9a123451a6e73 ("SUNRPC: Enable rpcsec_gss_krb5.ko to be built without CRYPTO_DES") in v6.3-rc1.
--- a/net/sunrpc/Kconfig +++ b/net/sunrpc/Kconfig @@ -19,10 +19,10 @@ config SUNRPC_SWAP config RPCSEC_GSS_KRB5 tristate "Secure RPC: Kerberos V mechanism" depends on SUNRPC && CRYPTO
- depends on CRYPTO_MD5 && CRYPTO_DES && CRYPTO_CBC && CRYPTO_CTS
- depends on CRYPTO_ECB && CRYPTO_HMAC && CRYPTO_SHA1 && CRYPTO_AES default y select SUNRPC_GSS
- select CRYPTO_SKCIPHER
- select CRYPTO_HASH help Choose Y here to enable Secure RPC using the Kerberos version 5 GSS-API mechanism (RFC 1964).
While updating my defconfigs for v6.3-rc1, I noticed this change has an interesting side-effect: if any of the CRYPTO_* algorithms were modular before, RPCSEC_GSS_KRB5 was modular, too. After this change, RPCSEC_GSS_KRB5 is promoted to builtin.
I'm not following. Which CRYPTO_ options trigger the behavior? On my test system, CONFIG_RPCSEC_GSS_KRB5=m and the CRYPTO stuff is all =y.
On v6.2, "make ARCH=m68k defconfig" gives you CONFIG_RPCSEC_GSS_KRB5=m On v6.3, it became builtin, due to dropping the dependencies on the individual crypto modules.
$ grep -E "CRYPTO_(MD5|DES|CBC|CTS|ECB|HMAC|SHA1|AES)" .config CONFIG_CRYPTO_AES=y CONFIG_CRYPTO_AES_TI=m CONFIG_CRYPTO_DES=m CONFIG_CRYPTO_CBC=m CONFIG_CRYPTO_CTS=m CONFIG_CRYPTO_ECB=m CONFIG_CRYPTO_HMAC=m CONFIG_CRYPTO_MD5=m CONFIG_CRYPTO_SHA1=m
This is not necessarily bad in-se, but you might want to be aware of it, and perhaps change the "default y".
Well that might be there to address the need for GSS to be enabled if NFSv4 support is built. See commit df486a25900f ("NFS: Fix the selection of security flavours in Kconfig")
I'm not claiming I understand exactly how that fix works.
And that was changed again a little bit later in commit e3b2854faabd1043 ("SUNRPC: Fix the SUNRPC Kerberos V RPCSEC_GSS module dependencies").
Gr{oetje,eeting}s,
Geert