KDC: weak crypto in default settings

[Thomas Dreibholz]

[ 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 to 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 main aspects:
- upgrades must not change the existing encryption type, and won't get a dpkg conf prompt
- fresh installs must use 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, i.e., the system will still be using the deprecated 3des-sha1 algorithm for the master key/stash file.

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 ]

The crypto that is being changed for new fresh installations affects the /etc/krb5kdc/stash file[2], and the K/M@REALM principal key (which are the same: it's called the master key). This is the key that encrypts the database.

For deployments with a primary KDC and a secondary KDC (replication), the stash file has to be copied to the secondary so that it can decrypt the replicated database. If that secondary has no support for the crypto algorithm that was chosen for the stash file (for example, it could be an older KDC version that only supports 3des-sha1, and not aes256), then it won't be able to decrypt it, and thus won't be able to read the database.

2. https://web.mit.edu/kerberos/krb5-latest/doc/basic/stash_file_def.html#stash-definition

[ 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. The master_key_type only affects the crypto algorithm used to protect the stash file.

Changing the existing stash file to use another encryption method is very involved and requires several steps. It's documented upstream: https://web.mit.edu/kerberos/krb5-latest/doc/admin/enctypes.html#migrating-away-from-older-encryption-types

Even if someone changes the kdc.conf file and updates the master_key_type encryption in there without changing the actual stash file, it won't break. The KDC is still able to read the file and decrypt it, even though the encryption type of the file no longer matches the configuration.

[ 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)

[Thomas Dreibholz (dreibh)]

A helpful hwoto for users who want to update the weak KDC master key with state-of-the-art crypto:
https://docs.oracle.com/cd/E36784_01/html/E37126/st-mkey-1.html

[Andreas Hasenack (ahasenack)]

Here is a collection of guides from upstream MIT kerberos:

https://web.mit.edu/kerberos/krb5-latest/doc/admin/enctypes.html#migrating-away-from-older-encryption-types

[Andreas Hasenack (ahasenack)]

This was fixed in debian and is currently in kinetic-proposed:

https://launchpad.net/ubuntu/+source/krb5/1.20-1

I'm unsure how to approach this from an SRU perspective, given it's a configuration setting in the default config file that is ship:

--- a/debian/kdc.conf
+++ b/debian/kdc.conf
@@ -10,7 +10,7 @@
         kdc_ports = 750,88
         max_life = 10h 0m 0s
         max_renewable_life = 7d 0h 0m 0s
- master_key_type = des3-hmac-sha1
+ #master_key_type = aes256-cts
         #supported_enctypes = aes256-cts:normal aes128-cts:normal
         default_principal_flags = +preauth
     }

[Andreas Hasenack (ahasenack)]

Actually, looks like it could be simple, as in, do nothing out of the ordinary. The config file is not shipped as /etc/krb5kdc/kdc.conf:
    db_get krb5-kdc/debconf
    DEBCONF="$RET"

    if [ ! -f /etc/krb5kdc/kdc.conf ] && [ $DEBCONF = "true" ] ; then
        sed -e "s/@MYREALM/$KRB5LD_DEFAULT_REALM/" \
            /usr/share/krb5-kdc/kdc.conf.template > /etc/krb5kdc/kdc.conf
    fi

A quick upgrade test in a few scenarios should suffice.

@mdeslaur, should we SRU this?

[Marc Deslauriers (mdeslaur)]

Oh, so it only copies the file over on new installs, that makes sense, and could be easily changed in stable releases.

I have no big preference, but perhaps it would be good to have it SRUed to 22.04.

[Sam Hartman (hartmans)]

>>>>> "Marc" == Marc Deslauriers <email address hidden> writes:

    Marc> Oh, so it only copies the file over on new installs, that
    Marc> makes sense, and could be easily changed in stable releases.

It's actually even less likely to cause problems than it might appear.
That config value should only be used by kdb5_util create.
Once /etc/krb5kdc/stash is created, I'd expect the encryption type in
that file will be used, and even if somehow kdc.conf were updated, it
would still continue to work.

We probably should start thinking about how to upgrade existing
databases, because we're going to want to do that before 3DES is removed
from the code.
That's going to be tricky because of the various replication and
database storage strategies. For example a Freeipa database is handled
differently than a raw Kerberos database than an LDAP database.
But we don't need to solve any of that today, and whatever we can do to
make new realms work better will help that eventual upgrade process
along.

--Sam

[Andreas Hasenack (ahasenack)]

This was fixed in Kinetic with https://launchpad.net/ubuntu/+source/krb5/1.20-1

krb5 (1.20-1) unstable; urgency=medium

  * New Upstream Version
  * Do not specify master key type to avoid weak crypto, Closes: #1009927

 -- Sam Hartman <email address hidden> Fri, 22 Jul 2022 16:32:38 -0600

[Steve Langasek (vorlon)]

Hello Thomas, or anyone else affected,

Accepted krb5 into jammy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/krb5/1.19.2-2ubuntu0.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-jammy to verification-done-jammy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-jammy. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Andreas Hasenack (ahasenack)]

# Jammy verification

a) Upgrade test does not change algorithm

With the release packages installed:
$ apt-cache policy krb5-kdc
krb5-kdc:
  Installed: 1.19.2-2ubuntu0.1
  Candidate: 1.19.2-2ubuntu0.1
  Version table:
 *** 1.19.2-2ubuntu0.1 500
        500 http://br.archive.ubuntu.com/ubuntu jammy-updates/universe amd64 Packages
(...)

We get the expected deprecation cipher and warnings:
$ sudo grep master_key_type /etc/krb5kdc/kdc.conf
        master_key_type = des3-hmac-sha1

$ sudo klist -ke /etc/krb5kdc/stash
Keytab name: FILE:/etc/krb5kdc/stash
KVNO Principal
---- --------------------------------------------------------------------------
   1 K/M@LXD (DEPRECATED:des3-cbc-sha1)

Upgrading to the package in proposed:
$ apt-cache policy krb5-kdc
krb5-kdc:
  Installed: 1.19.2-2ubuntu0.2
  Candidate: 1.19.2-2ubuntu0.2
  Version table:
 *** 1.19.2-2ubuntu0.2 500
        500 http://br.archive.ubuntu.com/ubuntu jammy-proposed/universe amd64 Packages
(...)

Repeating the checks, the algorithm is the same:

$ sudo grep master_key_type /etc/krb5kdc/kdc.conf
        master_key_type = des3-hmac-sha1

$ sudo klist -ke /etc/krb5kdc/stash
Keytab name: FILE:/etc/krb5kdc/stash
KVNO Principal
---- --------------------------------------------------------------------------
   1 K/M@LXD (DEPRECATED:des3-cbc-sha1)

(to be continued)

[Andreas Hasenack (ahasenack)]

# Jammy verification (continuation)

b) Fresh install of proposed packages
$ apt-cache policy krb5-kdc
krb5-kdc:
  Installed: 1.19.2-2ubuntu0.2
  Candidate: 1.19.2-2ubuntu0.2
  Version table:
 *** 1.19.2-2ubuntu0.2 500
        500 http://br.archive.ubuntu.com/ubuntu jammy-proposed/universe amd64 Packages
(...)

Master key type changed, but commented:

$ sudo grep master_key_type /etc/krb5kdc/kdc.conf
        #master_key_type = aes256-cts

Actual algorithm used for it is now 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)

Jammy verification succeeded.

[Launchpad Janitor (janitor)]

This bug was fixed in the package krb5 - 1.19.2-2ubuntu0.2

---------------
krb5 (1.19.2-2ubuntu0.2) jammy; urgency=medium

  * d/kdc.conf: Do not specify master key type to avoid weak crypto for
    new realms. Existing realms will not be changed. (LP: #1981697)

 -- Andreas Hasenack <email address hidden> Thu, 06 Apr 2023 19:21:06 -0300

[Robie Basak (racb)]

The verification of the Stable Release Update for krb5 has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.