** Description changed: [ Impact ] The default crypto algorithm suite selected for the master key in the ubuntu krb5-kdc package is des3-hmac-sha1. This comes from a config file shipped with the packaging which overrides upstream's default choice. Users who deploy a KDC using this package will be using an algorithm deprecated since many years ago, and considered broken nowadays for security applications. Furthermore, the KDC will highlight this fact with "deprecated" warnings in the logs and elsewhere. For example: root@j-kdc-weak-crypto:~# klist -ke /etc/krb5kdc/stash Keytab name: FILE:/etc/krb5kdc/stash KVNO Principal ---- -------------------------------------------------------------------------- 1 K/M@LXD (DEPRECATED:des3-cbc-sha1) And in the kdc logs: Apr 05 14:20:01 j-kdc-weak-crypto krb5kdc[7323]: Stash file /etc/krb5kdc/stash uses DEPRECATED enctype des3-cbc-sha1! This update removes the specification of an algorithm and leaves it to the upstream default, which is aes256-cts-hmac-sha1-96[1]. Kerberos is quite conservative when it comes to updating encryption algorithms, and one could argue that the default should be something like aes256-cts-hmac-sha384-192, but in this SRU we are sticking the upstream default (by not specifying any value). This is also what debian is doing, and what we have in kinetic and later. 1. https://manpages.ubuntu.com/manpages/jammy/man5/kdc.conf.5.html search for "master_key_type" [ Test Plan ] The test plan will involve two major aspects: - upgrades must not change the existing encryption type, and won't get a dpkg conf prompt - verify that fresh installs are indeed using the new crypto algorithm a) Upgrade does not change algorithm Start by installing a kdc with the released packages (not from proposed): # When prompted, accept the defaults sudo apt install krb5-kdc krb5-admin-server # Verify that master_key_type is set to the deprecated des3-hmac-sha1 value: $ sudo grep master_key_type /etc/krb5kdc/kdc.conf master_key_type = des3-hmac-sha1 # bootstrap a new realm, type in a password of your choosing (you won't need it again): $ sudo krb5_newrealm # Verify the actual encryption used in the stash file and confirm it's the same, and that you get a DEPRECATED warning: $ sudo klist -ke /etc/krb5kdc/stash Keytab name: FILE:/etc/krb5kdc/stash KVNO Principal ---- -------------------------------------------------------------------------- 1 K/M@LXD (DEPRECATED:des3-cbc-sha1) # Upgrade to the packages in proposed. Confirm there is no dpkg conf prompt, and repeat the two checks above (the grep, and the klist command). Their output must not have changed. + + b) Fresh install of proposed packages + + # Perform a fresh install of the packages in proposed. As before, accept + the defaults when asked debconf questions: + + sudo apt install krb5-kdc krb5-admin-server + + + # Verify that the master_key_type is now commented ("#" in front) and no longer shows the deprecated "3des-hmac-sha1" value, but instead shows "aes256-cts": + $ sudo grep master_key_type /etc/krb5kdc/kdc.conf + #master_key_type = aes256-cts + + # bootstrap a new realm, type in a password of your choosing (you won't + need it again): + + $ sudo krb5_newrealm + + # Verify the actual encryption used in the stash file, and confirm it's + no longer "des3-cbc-sha1", but instead "aes256-cts-hmac-sha1-96": + + $ sudo klist -ke /etc/krb5kdc/stash + Keytab name: FILE:/etc/krb5kdc/stash + KVNO Principal + ---- -------------------------------------------------------------------------- + 1 K/M@LXD (aes256-cts-hmac-sha1-96) + + [ Where problems could occur ] * Think about what the upload changes in the software. Imagine the change is wrong or breaks something else: how would this show up? * It is assumed that any SRU candidate patch is well-tested before upload and has a low overall risk of regression, but it's important to make the effort to think about what ''could'' happen in the event of a regression. * This must '''never''' be "None" or "Low", or entirely an argument as to why your upload is low risk. * This both shows the SRU team that the risks have been considered, and provides guidance to testers in regression-testing the SRU. [ Other Info ] The master_key_type setting does not affect the crypto algorithms that are used for tickets and the like. Even with the deprecated 3des setting, the tickets obtained by users will be typically using aes256. [ Original Description ] Default setting in /etc/krb5kdc/kdc.conf, as installed from krb5-kdc in Ubuntu 22.04 Server: master_key_type = des3-hmac-sha1 3DES was deprecated by NIST in 2017, i.e. give years ago! Reference: https://csrc.nist.gov/News/2017/Update-to-Current-Use-and-Deprecation- of-TDEA . This should not be a default since a very long time, and particularly not for new installations. If a compatibility with out-of- date installations is necessary, this should be explicitly made be the administrator. SHA-1 was deprecated as well, in 2011, i.e. eleven years ago! Reference: https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-131a.pdf . A reasonable default would probably be: master_key_type = aes256-cts-hmac-sha384-192 ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: krb5-kdc 1.19.2-2 ProcVersionSignature: Ubuntu 5.15.0-40.43-generic 5.15.35 Uname: Linux 5.15.0-40-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 CasperMD5CheckResult: pass Date: Thu Jul 14 12:34:22 2022 InstallationDate: Installed on 2022-05-30 (45 days ago) InstallationMedia: Ubuntu-Server 22.04 LTS "Jammy Jellyfish" - Release amd64 (20220421) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR=<set> LANG=en_IE.UTF-8 SHELL=/bin/bash SourcePackage: krb5 UpgradeStatus: No upgrade log present (probably fresh install)
-- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to krb5 in Ubuntu. https://bugs.launchpad.net/bugs/1981697 Title: KDC: weak crypto in default settings Status in krb5 package in Ubuntu: Fix Released Status in krb5 source package in Jammy: In Progress Status in krb5 source package in Kinetic: Fix Released Status in krb5 package in Debian: Fix Released Bug description: [ Impact ] The default crypto algorithm suite selected for the master key in the ubuntu krb5-kdc package is des3-hmac-sha1. This comes from a config file shipped with the packaging which overrides upstream's default choice. Users who deploy a KDC using this package will be using an algorithm deprecated since many years ago, and considered broken nowadays for security applications. Furthermore, the KDC will highlight this fact with "deprecated" warnings in the logs and elsewhere. For example: root@j-kdc-weak-crypto:~# klist -ke /etc/krb5kdc/stash Keytab name: FILE:/etc/krb5kdc/stash KVNO Principal ---- -------------------------------------------------------------------------- 1 K/M@LXD (DEPRECATED:des3-cbc-sha1) And in the kdc logs: Apr 05 14:20:01 j-kdc-weak-crypto krb5kdc[7323]: Stash file /etc/krb5kdc/stash uses DEPRECATED enctype des3-cbc-sha1! This update removes the specification of an algorithm and leaves it to the upstream default, which is aes256-cts-hmac-sha1-96[1]. Kerberos is quite conservative when it comes to updating encryption algorithms, and one could argue that the default should be something like aes256-cts-hmac-sha384-192, but in this SRU we are sticking the upstream default (by not specifying any value). This is also what debian is doing, and what we have in kinetic and later. 1. https://manpages.ubuntu.com/manpages/jammy/man5/kdc.conf.5.html search for "master_key_type" [ Test Plan ] The test plan will involve two major aspects: - upgrades must not change the existing encryption type, and won't get a dpkg conf prompt - verify that fresh installs are indeed using the new crypto algorithm a) Upgrade does not change algorithm Start by installing a kdc with the released packages (not from proposed): # When prompted, accept the defaults sudo apt install krb5-kdc krb5-admin-server # Verify that master_key_type is set to the deprecated des3-hmac-sha1 value: $ sudo grep master_key_type /etc/krb5kdc/kdc.conf master_key_type = des3-hmac-sha1 # bootstrap a new realm, type in a password of your choosing (you won't need it again): $ sudo krb5_newrealm # Verify the actual encryption used in the stash file and confirm it's the same, and that you get a DEPRECATED warning: $ sudo klist -ke /etc/krb5kdc/stash Keytab name: FILE:/etc/krb5kdc/stash KVNO Principal ---- -------------------------------------------------------------------------- 1 K/M@LXD (DEPRECATED:des3-cbc-sha1) # Upgrade to the packages in proposed. Confirm there is no dpkg conf prompt, and repeat the two checks above (the grep, and the klist command). Their output must not have changed. b) Fresh install of proposed packages # Perform a fresh install of the packages in proposed. As before, accept the defaults when asked debconf questions: sudo apt install krb5-kdc krb5-admin-server # Verify that the master_key_type is now commented ("#" in front) and no longer shows the deprecated "3des-hmac-sha1" value, but instead shows "aes256-cts": $ sudo grep master_key_type /etc/krb5kdc/kdc.conf #master_key_type = aes256-cts # bootstrap a new realm, type in a password of your choosing (you won't need it again): $ sudo krb5_newrealm # Verify the actual encryption used in the stash file, and confirm it's no longer "des3-cbc-sha1", but instead "aes256-cts-hmac-sha1-96": $ sudo klist -ke /etc/krb5kdc/stash Keytab name: FILE:/etc/krb5kdc/stash KVNO Principal ---- -------------------------------------------------------------------------- 1 K/M@LXD (aes256-cts-hmac-sha1-96) [ Where problems could occur ] * Think about what the upload changes in the software. Imagine the change is wrong or breaks something else: how would this show up? * It is assumed that any SRU candidate patch is well-tested before upload and has a low overall risk of regression, but it's important to make the effort to think about what ''could'' happen in the event of a regression. * This must '''never''' be "None" or "Low", or entirely an argument as to why your upload is low risk. * This both shows the SRU team that the risks have been considered, and provides guidance to testers in regression-testing the SRU. [ Other Info ] The master_key_type setting does not affect the crypto algorithms that are used for tickets and the like. Even with the deprecated 3des setting, the tickets obtained by users will be typically using aes256. [ Original Description ] Default setting in /etc/krb5kdc/kdc.conf, as installed from krb5-kdc in Ubuntu 22.04 Server: master_key_type = des3-hmac-sha1 3DES was deprecated by NIST in 2017, i.e. give years ago! Reference: https://csrc.nist.gov/News/2017/Update-to-Current-Use-and-Deprecation- of-TDEA . This should not be a default since a very long time, and particularly not for new installations. If a compatibility with out- of-date installations is necessary, this should be explicitly made be the administrator. SHA-1 was deprecated as well, in 2011, i.e. eleven years ago! Reference: https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-131a.pdf . A reasonable default would probably be: master_key_type = aes256-cts-hmac-sha384-192 ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: krb5-kdc 1.19.2-2 ProcVersionSignature: Ubuntu 5.15.0-40.43-generic 5.15.35 Uname: Linux 5.15.0-40-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 CasperMD5CheckResult: pass Date: Thu Jul 14 12:34:22 2022 InstallationDate: Installed on 2022-05-30 (45 days ago) InstallationMedia: Ubuntu-Server 22.04 LTS "Jammy Jellyfish" - Release amd64 (20220421) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR=<set> LANG=en_IE.UTF-8 SHELL=/bin/bash SourcePackage: krb5 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/krb5/+bug/1981697/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
