[Bug 1981697] Re: KDC: weak crypto in default settings
Andreas Hasenack
1981697 at bugs.launchpad.net
Wed Apr 5 17:50:04 UTC 2023
** 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 at j-kdc-weak-crypto:~# klist -ke /etc/krb5kdc/stash
Keytab name: FILE:/etc/krb5kdc/stash
KVNO Principal
---- --------------------------------------------------------------------------
1 K/M at 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 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 at 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 at 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?
+ The crypto that is being changed for new fresh installations affects the
+ /etc/krb5kdc/stash file[2], and the K/M at REALM principal key (which are
+ the same: it's called the master key). This is the key that encrypts the
+ database.
- * 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.
+ 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.
- * 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.
-
+ 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)
** 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 at j-kdc-weak-crypto:~# klist -ke /etc/krb5kdc/stash
Keytab name: FILE:/etc/krb5kdc/stash
KVNO Principal
---- --------------------------------------------------------------------------
1 K/M at 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 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 at 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.
+ 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 at 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 at 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
+ 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)
** 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 at j-kdc-weak-crypto:~# klist -ke /etc/krb5kdc/stash
Keytab name: FILE:/etc/krb5kdc/stash
KVNO Principal
---- --------------------------------------------------------------------------
1 K/M at 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
+ 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 at 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 at 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 at 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)
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, 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 at j-kdc-weak-crypto:~# klist -ke /etc/krb5kdc/stash
Keytab name: FILE:/etc/krb5kdc/stash
KVNO Principal
---- --------------------------------------------------------------------------
1 K/M at 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 at 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 at 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 at 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)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/krb5/+bug/1981697/+subscriptions
More information about the foundations-bugs
mailing list