Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Bug#1009927: krb5: deprecated encryption type for master_key_type

90 views
Skip to first unread message

Andreas Hasenack

unread,
Apr 20, 2022, 5:00:04 PM4/20/22
to
Package: krb5
Version: 1.19.2-2
Severity: normal

Dear Maintainer,

when creating a new realm using `krb5_newrealm`, the following warning
is logged in /var/log/syslog:

Apr 20 20:43:16 kdc krb5kdc[3136]: Stash file /etc/krb5kdc/stash uses
DEPRECATED enctype des3-cbc-sha1!

This comes from the kdc.conf template in
/usr/share/krb5-kdc/kdc.conf.template which has "master_key_type =
des3-hmac-sha1".

Maybe it's time to update that encryption type? The kdc.conf manpage
says that the current default is "aes256-cts-hmac-sha1-96". The sample
kdc.conf in the documentation at
https://web.mit.edu/kerberos/krb5-latest/doc/admin/install_kdc.html#kdc-conf
suggests just "master_key_type = aes256-cts".

I understand there may be important upgrade path considerations. Given
all the care and precautions that are shown for migrating away from
single DES in https://web.mit.edu/kerberos/krb5-latest/doc/admin/advanced/retiring-des.html,
changing the default master key type for fresh installs might also
require careful planning and thought, but at some point this process
must start. And upstream is now flagging DES3 as deprecated already.

Benjamin Kaduk

unread,
Apr 24, 2022, 1:00:03 AM4/24/22
to
I'm pretty sure that changing the master key encryption type used for new
databases has basically no upgrade considerations and could be "just done".
Updating the encryption type for that key on existing databases will have
nontrivial upgrade considerations (and in fact will not be possible to do
automatically in a maintainer script in all cases).

It is even possible that we might drop that configuration stanza entirely
rather than just changing the encryption type, though we would want to more
thoroughly research the consequences of doing so before actually making
that change.

Thanks for the report, this is definitely something we should be taking
action on.

-Ben

Sam Hartman

unread,
May 12, 2022, 2:30:03 PM5/12/22
to
>>>>> "Benjamin" == Benjamin Kaduk <ka...@mit.edu> writes:

Benjamin> I'm pretty sure that changing the master key encryption
Benjamin> type used for new databases has basically no upgrade
Benjamin> considerations and could be "just done". Updating the
Benjamin> encryption type for that key on existing databases will
Benjamin> have nontrivial upgrade considerations (and in fact will
Benjamin> not be possible to do automatically in a maintainer script
Benjamin> in all cases).

Agreed.

Benjamin> It is even possible that we might drop that configuration
Benjamin> stanza entirely rather than just changing the encryption
Benjamin> type, though we would want to more thoroughly research the
Benjamin> consequences of doing so before actually making that
Benjamin> change.

For new installations, I think that's fine. I think going back and
changing kdc.conf on existing installations would be fine so long as
they aren't old enough to use the pre-keytab stash file format.
As I recall that format didn't include enctype.
But I think that was a really long time ago.

I'll remove the master_key_type from kdc.conf in an upload soon.
I'll also add a news item recommending that people upgrade their master
key.
We can talk about how much automated upgrade is possible, but in the
case of kpropd, that's going to be hard.
0 new messages