krb5 commit: Update retiring-des with real-world experience
Benjamin Kaduk
kaduk at MIT.EDU
Mon Dec 17 18:50:59 EST 2012
https://github.com/krb5/krb5/commit/d44dfe4c097c7bc8eff6fe4931208ebfd968dc44
commit d44dfe4c097c7bc8eff6fe4931208ebfd968dc44
Author: Ben Kaduk <kaduk at mit.edu>
Date: Thu Dec 13 15:26:38 2012 -0500
Update retiring-des with real-world experience
We took notes when upgrading the ZONE.MIT.EDU realm to reduce
its usage of single-DES. Use these to give examples for the upgrade
procedure, and flesh out some parts of it that were missing or
under-specified.
ticket: 7501 (new)
tags: pullup
target_version: 1.11
doc/admin/advanced/retiring-des.rst | 403 +++++++++++++++++++++++++++++------
1 files changed, 337 insertions(+), 66 deletions(-)
diff --git a/doc/admin/advanced/retiring-des.rst b/doc/admin/advanced/retiring-des.rst
index 30f9677..da9d1fc 100644
--- a/doc/admin/advanced/retiring-des.rst
+++ b/doc/admin/advanced/retiring-des.rst
@@ -6,7 +6,7 @@ Retiring DES
Version 5 of the Kerberos protocol was originally implemented using
the Data Encryption Standard (DES) as a block cipher for encryption.
While it was considered secure at the time, advancements in computational
-ability have rendered it vulnerable to brute force attacks on its 56-bit
+ability have rendered DES vulnerable to brute force attacks on its 56-bit
keyspace. As such, it is now considered insecure and should not be
used (:rfc:`6649`).
@@ -25,39 +25,38 @@ ordinary operation without administrator intervention.
Types of keys
-------------
-The entire Kerberos database is encrypted using the database master
-key, presently stored as ``K/M`` by default. Each entry in the
-Kerberos database has a set of keys with different encryption types,
-corresponding to that principal's current key version number.
-For a user principal, these keys are derived from the user's password
-via the various string2key functions for those encryption types;
-for a service principal with keys stored in a keytab, the keys of
-different encryption types are all stored in the keytab.
-When a new principal is added or a principal's key is updated (for
-example, due to a user password change), new keys are generated for
-that principal with all of the different encryption types that the
-KDC is configured to use (the **supported_enctypes** variable in kdc.conf).
-This list can be overridden on a case-by-case basis using arguments
-to :ref:`kadmin(1)`.
-
-When a Kerberos client initiates a Kerberos transaction, the client
-requests a service ticket for a given service from the KDC; this service
-ticket will contain only a single key, of a particular encryption type.
-When sending its request to the KDC, the client can request a particular
-list of encryption types, as controlled by the client machine's
-:ref:`krb5.conf(5)` configuration file or specific API calls in the
-client software.
-To choose the encryption type for the service ticket's key, the KDC
-must accomodate the client's preference and also confirm that the service
-principal has a key in the Kerberos database of that encryption type.
-Note that the encryption types supported by the krb5 installation on
-the server that will receive the service ticket is not a factor in
-the KDC's choice of encryption type; this information is not available
-in the Kerberos protocol. In order to allow uninterrupted operation to
-clients while migrating away from DES, care must be taken to ensure that
-the krb5 installation on server machines is configured to support newer
-encryption types before keys of those new encryption types are created
-in the Kerberos database for those server principals.
+* The database master key: This key is not exposed to user requests,
+ but is used to encrypt other key material stored in the kerberos
+ database. The database master key is currently stored as ``K/M``
+ by default.
+* Password-derived keys: User principals frequently have keys
+ derived from a password. When a new password is set, the KDC
+ uses various string2key functions to generate keys in the database
+ for that principal.
+* Keytab keys: Application server principals generally use random
+ keys which are not derived from a password. When the database
+ entry is created, the KDC generates random keys of various enctypes
+ to enter in the database, which are conveyed to the application server
+ and stored in a keytab.
+* Session keys: These are short-term keys generated by the KDC while
+ processing client requests, with an enctype selected by the KDC.
+
+For details on the various enctypes and how enctypes are selected by the KDC
+for session keys and client/server long-term keys, see :ref:`enctypes`.
+When using the :ref:`kadmin(1)` interface to generate new long-term keys,
+the **-e** argument can be used to force a particular set of enctypes,
+overriding the KDC default values.
+
+.. note::
+
+ When the KDC is selecting a session key, it has no knowledge about the
+ kerberos installation on the server which will receive the service ticket,
+ only what keys are in the database for the service principal.
+ In order to allow uninterrupted operation to
+ clients while migrating away from DES, care must be taken to ensure that
+ kerberos installations on application server machines are configured to
+ support newer encryption types before keys of those new encryption types
+ are created in the Kerberos database for those server principals.
Upgrade procedure
-----------------
@@ -65,61 +64,327 @@ Upgrade procedure
This procedure assumes that the KDC software has already been upgraded
to a modern version of krb5 that supports non-DES keys, so that the
only remaining task is to update the actual keys used to service requests.
+The realm used for demonstrating this procedure, ZONE.MIT.EDU,
+is an example of the worst-case scenario, where all keys in the realm
+are DES. The realm was initially created with a very old version of krb5,
+and **supported_enctypes** in :ref:`kdc.conf(5)` was set to a value
+appropriate when the KDC was installed, but was not updated as the KDC
+was upgraded:
+
+::
+
+ [realms]
+ ZONE.MIT.EDU = {
+ [...]
+ master_key_type = des-cbc-crc
+ supported_enctypes = des-cbc-crc:normal des:normal des:v4 des:norealm des:onlyrealm des:afs3
+ }
+
+This resulted in the keys for all principals in the realm being forced
+to DES-only, unless specifically requested using :ref:`kadmin(1)`.
+
+Before starting the upgrade, all KDCs were running krb5 1.11,
+and the database entries for some "high-value" principals were:
-While it is possible to upgrade individual service principals to non-DES
-keys before transitioning the entire realm, it is probably best to
-start with upgrading the key for the ticket-granting service principal,
-``krbtgt/REALM``. Since the server that will handle service tickets
+::
+
+ [root at casio krb5kdc]# kadmin.local -r ZONE.MIT.EDU -q 'getprinc krbtgt/ZONE.MIT.EDU'
+ [...]
+ Number of keys: 1
+ Key: vno 1, des-cbc-crc, Version 4
+ [...]
+ [root at casio krb5kdc]# kadmin.local -r ZONE.MIT.EDU -q 'getprinc kadmin/admin'
+ [...]
+ Number of keys: 1
+ Key: vno 15, des-cbc-crc, no salt
+ [...]
+ [root at casio krb5kdc]# kadmin.local -r ZONE.MIT.EDU -q 'getprinc kadmin/changepw'
+ [...]
+ Number of keys: 1
+ Key: vno 14, des-cbc-crc, no salt
+ [...]
+
+The ``krbtgt/REALM`` key appears to have never been changed since creation
+(its kvno is 1), and all three database entries have only a des-cbc-crc key.
+
+The krbtgt key and KDC keys
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Perhaps the biggest single-step improvement in the security of the cell
+is gained by strengthening the key of the ticket-granting service principal,
+``krbtgt/REALM``---if this principal's key is compromised, so is the
+entire realm. Since the server that will handle service tickets
for this principal is the KDC itself, it is easy to guarantee that it
will be configured to support any encryption types which might be
-selected. However, just creating a new key version (and new keys) for
-that principal will invalidate all existing tickets issued against that
-principal, which in practice means all tickets obtained by clients.
+selected. However, the default KDC behavior when creating new keys is to
+remove the old keys, which would invalidate all existing tickets issued
+against that principal, rendering the TGTs cached by clients useless.
Instead, a new key can be created with the old key retained, so that
existing tickets will still function until their scheduled expiry
(see :ref:`changing_krbtgt_key`).
-Once the krbtgt key is updated, users will get non-DES (usually AES in
-modern releases) session keys for their TGT, but subsequent requests
-for service tickets will still get DES keys, because the database
-entry for the service principal still only has DES keys. Application service
+::
+
+ [root at casio krb5kdc]# enctypes=aes256-cts-hmac-sha1-96:normal,\
+ > aes128-cts-hmac-sha1-96:normal,des3-hmac-sha1:normal,des-cbc-crc:normal
+ [root at casio krb5kdc]# kadmin.local -r ZONE.MIT.EDU -q "cpw -e ${enctypes} -randkey \
+ > -keepold krbtgt/ZONE.MIT.EDU"
+ Authenticating as principal root/admin at ZONE.MIT.EDU with password.
+ Key for "krbtgt/ZONE.MIT.EDU at ZONE.MIT.EDU" randomized.
+
+.. note::
+
+ The new ``krbtgt at REALM`` key should be propagated to slave KDCs
+ immediately so that TGTs issued by the master KDC can be used to
+ issue service tickets on slave KDCs. Slave KDCs will refuse requests
+ using the new TGT kvno until the new krbtgt entry has been propagated
+ to them.
+
+It is necessary to explicitly specify the enctypes for the new database
+entry, since **supported_enctypes** has not been changed. Leaving
+**supported_enctypes** unchanged makes a potential rollback operation
+easier, since all new keys of new enctypes are the result of explicit
+administrator action and can be easily enumerated.
+Upgrading the krbtgt key should have minimal user-visible disruption other
+than that described in the note above, since only clients which list the
+new enctypes as supported will use them, per the procedure
+in :ref:`session_key_selection`.
+Once the krbtgt key is updated, the session and ticket keys for user
+TGTs will be strong keys, but subsequent requests
+for service tickets will still get DES keys until the service principals
+have new keys generated. Application service
remains uninterrupted due to the key-selection procedure on the KDC.
-At this point, service administrators can update their services and the
-servers behind them. If necessary, the krb5 installation should be
-upgraded to a version supporting non-DES keys, and :ref:`krb5.conf(5)`
-edited so that the default enctype list includes the additional enctypes
-needed. Only when the service is configured to accept non-DES keys should
-the key version number be incremented and new keys generated.
-Until the KDC's configuration is changed to generate non-DES keys by
-default, it is necessary to use :ref:`kadmin(1)` to produce new keys
-with the desired enctypes; the ``-keepold`` functionality may also be
-desired in some cases. When a single service principal is shared by
-multiple backend servers in a load-balanced environment, it may be
-necessary to schedule downtime or adjust the population in the load-balanced
-pool in order to propagate the updated keytab to all hosts in the pool
-with minimal service interruption.
+After the change, the database entry is now:
+
+::
+
+ [root at casio krb5kdc]# kadmin.local -r ZONE.MIT.EDU -q 'getprinc krbtgt/ZONE.MIT.EDU'
+ [...]
+ Number of keys: 5
+ Key: vno 2, aes256-cts-hmac-sha1-96, no salt
+ Key: vno 2, aes128-cts-hmac-sha1-96, no salt
+ Key: vno 2, des3-cbc-sha1, no salt
+ Key: vno 2, des-cbc-crc, no salt
+ Key: vno 1, des-cbc-crc, Version 4
+ [...]
+
+Since the expected disruptions from rekeying the krbtgt principal are
+minor, after a short testing period, it is
+appropriate to rekey the other high-value principals, ``kadmin/admin at REALM``
+and ``kadmin/changepw at REALM``. These are the service principals used for
+changing user passwords and updating application keytabs. The kadmin
+and password-changing services are regular kerberized services, so the
+session-key-selection algorithm described in :ref:`session_key_selection`
+applies. It is particularly important to have strong session keys for
+these services, since user passwords and new long-term keys are conveyed
+over the encrypted channel.
+
+::
+
+ [root at casio krb5kdc]# enctypes=aes256-cts-hmac-sha1-96:normal,\
+ > aes128-cts-hmac-sha1-96:normal,des3-hmac-sha1:normal
+ [root at casio krb5kdc]# kadmin.local -r ZONE.MIT.EDU -q "cpw -e ${enctypes} -randkey \
+ > kadmin/admin"
+ Authenticating as principal root/admin at ZONE.MIT.EDU with password.
+ Key for "kadmin/admin at ZONE.MIT.EDU" randomized.
+ [root at casio krb5kdc]# kadmin.local -r ZONE.MIT.EDU -q "cpw -e ${enctypes} -randkey \
+ > kadmin/changepw"
+ Authenticating as principal root/admin at ZONE.MIT.EDU with password.
+ Key for "kadmin/changepw at ZONE.MIT.EDU" randomized.
+
+It is not necessary to retain a single-DES key for these services, since
+password changes are not part of normal daily workflow, and disruption
+from a client failure is likely to be minimal. Furthermore, if a kerberos
+client experiences failure changing a user password or keytab key,
+this indicates that that client will become inoperative once services
+are rekeyed to non-DES enctypes. Such problems can be detected early
+at this stage, giving more time for corrective action.
+
+Adding strong keys to application servers
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Before switching the default enctypes for new keys over to strong enctypes,
+it may be desired to test upgrading a handful of services with the
+new configuration before flipping the switch for the defaults. This
+still requires using the **-e** argument in :ref:`kadmin(1)` to get non-default
+enctypes:
+
+::
+
+ [root at casio krb5kdc]# enctypes=aes256-cts-hmac-sha1-96:normal,\
+ > aes128-cts-hmac-sha1-96:normal,des3-cbc-sha1:normal,des-cbc-crc:normal
+ [root at casio krb5kdc]# kadmin -r ZONE.MIT.EDU -p zephyr/zephyr at ZONE.MIT.EDU -k -t \
+ > /etc/zephyr/krb5.keytab -q "ktadd -e ${enctypes} \
+ > -k /etc/zephyr/krb5.keytab zephyr/zephyr at ZONE.MIT.EDU"
+ Authenticating as principal zephyr/zephyr at ZONE.MIT.EDU with keytab /etc/zephyr/krb5.keytab.
+ Entry for principal zephyr/zephyr at ZONE.MIT.EDU with kvno 4, encryption type aes256-cts-hmac-sha1-96 added to keytab WRFILE:/etc/zephyr/krb5.keytab.
+ Entry for principal zephyr/zephyr at ZONE.MIT.EDU with kvno 4, encryption type aes128-cts-hmac-sha1-96 added to keytab WRFILE:/etc/zephyr/krb5.keytab.
+ Entry for principal zephyr/zephyr at ZONE.MIT.EDU with kvno 4, encryption type des3-cbc-sha1 added to keytab WRFILE:/etc/zephyr/krb5.keytab.
+ Entry for principal zephyr/zephyr at ZONE.MIT.EDU with kvno 4, encryption type des-cbc-crc added to keytab WRFILE:/etc/zephyr/krb5.keytab.
+
+Be sure to remove the old keys from the application keytab, per best
+practice.
+
+::
+
+ [root at casio krb5kdc]# k5srvutil -f /etc/zephyr/krb5.keytab delold
+ Authenticating as principal zephyr/zephyr at ZONE.MIT.EDU with keytab /etc/zephyr/krb5.keytab.
+ Entry for principal zephyr/zephyr at ZONE.MIT.EDU with kvno 3 removed from keytab WRFILE:/etc/zephyr/krb5.keytab.
+Adding strong keys by default
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Once the high-visibility services have been rekeyed, it is probably
appropriate to change :ref:`kdc.conf(5)` to generate keys with the new
encryption types by default. This enables server administrators to generate
-new keys with :ref:`k5srvutil(1)` ``change``, and causes user password
+new enctypes with the **change** subcommand of :ref:`k5srvutil(1)`,
+and causes user password
changes to add new encryption types for their entries. It will probably
be necessary to implement administrative controls to cause all user
principal keys to be updated in a reasonable period of time, whether
by forcing password changes or a password synchronization service that
has access to the current password and can add the new keys.
+::
+
+ [realms]
+ ZONE.MIT.EDU = {
+ supported_enctypes = aes256-cts-hmac-sha1-96:normal aes128-cts-hmac-sha1-96:normal des3-cbc-sha1:normal des3-hmac-sha1:normal des-cbc-crc:normal
+
+.. note::
+
+ The krb5kdc process must be restarted for these changes to take effect.
+
+At this point, all service administrators can update their services and the
+servers behind them to take advantage of strong cryptography.
+If necessary, the server's krb5 installation should be configured and/or
+upgraded to a version supporting non-DES keys. See :ref:`enctypes` for
+krb5 version and configuration settings.
+Only when the service is configured to accept non-DES keys should
+the key version number be incremented and new keys generated
+(``k5srvutil change && k5srvutil delold``).
+
+::
+
+ root at dr-willy:~# k5srvutil change
+ Authenticating as principal host/dr-willy.xvm.mit.edu at ZONE.MIT.EDU with keytab /etc/krb5.keytab.
+ Entry for principal host/dr-willy.xvm.mit.edu at ZONE.MIT.EDU with kvno 3, encryption type AES-256 CTS mode with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5.keytab.
+ Entry for principal host/dr-willy.xvm.mit.edu at ZONE.MIT.EDU with kvno 3, encryption type AES-128 CTS mode with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5.keytab.
+ Entry for principal host/dr-willy.xvm.mit.edu at ZONE.MIT.EDU with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab.
+ Entry for principal host/dr-willy.xvm.mit.edu at ZONE.MIT.EDU with kvno 3, encryption type DES cbc mode with CRC-32 added to keytab WRFILE:/etc/krb5.keytab.
+ root at dr-willy:~# klist -e -k -t /etc/krb5.keytab
+ Keytab name: WRFILE:/etc/krb5.keytab
+ KVNO Timestamp Principal
+ ---- ----------------- --------------------------------------------------------
+ 2 10/10/12 17:03:59 host/dr-willy.xvm.mit.edu at ZONE.MIT.EDU (DES cbc mode with CRC-32)
+ 3 12/12/12 15:31:19 host/dr-willy.xvm.mit.edu at ZONE.MIT.EDU (AES-256 CTS mode with 96-bit SHA-1 HMAC)
+ 3 12/12/12 15:31:19 host/dr-willy.xvm.mit.edu at ZONE.MIT.EDU (AES-128 CTS mode with 96-bit SHA-1 HMAC)
+ 3 12/12/12 15:31:19 host/dr-willy.xvm.mit.edu at ZONE.MIT.EDU (Triple DES cbc mode with HMAC/sha1)
+ 3 12/12/12 15:31:19 host/dr-willy.xvm.mit.edu at ZONE.MIT.EDU (DES cbc mode with CRC-32)
+ root at dr-willy:~# k5srvutil delold
+ Authenticating as principal host/dr-willy.xvm.mit.edu at ZONE.MIT.EDU with keytab /etc/krb5.keytab.
+ Entry for principal host/dr-willy.xvm.mit.edu at ZONE.MIT.EDU with kvno 2 removed from keytab WRFILE:/etc/krb5.keytab.
+
+When a single service principal is shared by multiple backend servers in
+a load-balanced environment, it may be necessary to schedule downtime
+or adjust the population in the load-balanced pool in order to propagate
+the updated keytab to all hosts in the pool with minimal service interruption.
+
+Removing DES keys from usage
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This situation remains something of a testing or transitory state,
+as new DES keys are still being generated, and will be used if requested
+by a client. To make more progress removing DES from the realm, the KDC
+should be configured to not generate such keys by default.
+
+::
+
+ [realms]
+ ZONE.MIT.EDU = {
+ supported_enctypes = aes256-cts-hmac-sha1-96:normal aes128-cts-hmac-sha1-96:normal des3-cbc-sha1:normal des3-hmac-sha1:normal
+
+.. note::
+
+ As before, the KDC process must be restarted for this change to take
+ effect. It is best practice to update kdc.conf on all KDCs, not just the
+ master, to avoid unpleasant surprises should the master fail and a slave
+ need to be promoted.
+
+It is now appropriate to remove the legacy single-DES key from the
+``krbtgt/REALM`` entry:
+
+::
+
+ [root at casio krb5kdc]# kadmin.local -r ZONE.MIT.EDU -q "cpw -randkey -keepold \
+ > krbtgt/ZONE.MIT.EDU"
+ Authenticating as principal host/admin at ATHENA.MIT.EDU with password.
+ Key for "krbtgt/ZONE.MIT.EDU at ZONE.MIT.EDU" randomized.
+
+After the maximum ticket lifetime has passed, the old database entry
+should be removed.
+
+::
+
+ [root at casio krb5kdc]# kadmin.local -r ZONE.MIT.EDU -q 'purgekeys krbtgt/ZONE.MIT.EDU'
+ Authenticating as principal root/admin at ZONE.MIT.EDU with password.
+ Old keys for principal "krbtgt/ZONE.MIT.EDU at ZONE.MIT.EDU" purged.
+
+After the KDC is restarted with the new **supported_enctypes**,
+all user password changes and application keytab updates will not
+generate DES keys by default.
+
+::
+
+ contents-vnder-pressvre:~> kpasswd zonetest at ZONE.MIT.EDU
+ Password for zonetest at ZONE.MIT.EDU: [enter old password]
+ Enter new password: [enter new password]
+ Enter it again: [enter new password]
+ Password changed.
+ contents-vnder-pressvre:~> kadmin -r ZONE.MIT.EDU -q 'getprinc zonetest'
+ [...]
+ Number of keys: 3
+ Key: vno 9, aes256-cts-hmac-sha1-96, no salt
+ Key: vno 9, aes128-cts-hmac-sha1-96, no salt
+ Key: vno 9, des3-cbc-sha1, no salt
+ [...]
+
+ [kaduk at glossolalia ~]$ kadmin -p kaduk at ZONE.MIT.EDU -r ZONE.MIT.EDU -k \
+ > -t kaduk-zone.keytab -q 'ktadd -k kaduk-zone.keytab kaduk at ZONE.MIT.EDU'
+ Authenticating as principal kaduk at ZONE.MIT.EDU with keytab kaduk-zone.keytab.
+ Entry for principal kaduk at ZONE.MIT.EDU with kvno 3, encryption type aes256-cts-hmac-sha1-96 added to keytab WRFILE:kaduk-zone.keytab.
+ Entry for principal kaduk at ZONE.MIT.EDU with kvno 3, encryption type aes128-cts-hmac-sha1-96 added to keytab WRFILE:kaduk-zone.keytab.
+ Entry for principal kaduk at ZONE.MIT.EDU with kvno 3, encryption type des3-cbc-sha1 added to keytab WRFILE:kaduk-zone.keytab.
+
Once all principals have been re-keyed, DES support can be disabled on the
KDC, and client machines can remove **allow_weak_crypto = true** from
their :ref:`krb5.conf(5)` configuration files, completing the migration.
-For completeness, the kadmin **purgekeys** command should be used to
-remove the old keylist for ``krbtgt/REALM`` which includes the single-DES
-key(s), though the KDC will only issue new tickets using the highest
-available kvno, which at this point does not have single-DES keys available.
-This procedure does not alter ``K/M at REALM``, the key used to encrypt the
-Kerberos database itself. (This is the key stored in the stash file
+Support for legacy services
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+If there remain legacy services which do not support non-DES enctypes
+(such as AFS), **allow_weak_crypto** must remain enabled on the KDC.
+Client machines need not have this setting, though---applications
+which require DES can use API calls to allow weak crypto on a per-request
+basis, overriding the system krb5.conf. However, having **allow_weak_crypto**
+set on the KDC means that any principals which have a DES key in the database
+could still use those keys. To minimize the use of DES in the realm and
+restrict it to just legacy services which require DES, it is necessary
+to remove all other DES keys. The realm has been configured such that
+at password and keytab change, no DES keys will be generated by default.
+The task then reduces to requiring user password changes and having
+server administrators update their service keytabs. Administrative
+outreach will be necessary, and if the desire to eliminate DES is
+sufficiently strong, the KDC administrators may choose to randkey
+any principals which have not been rekeyed after some timeout period,
+forcing the user to contact the helpdesk for access.
+
+The Database Master Key
+-----------------------
+
+This procedure does not alter ``K/M at REALM``, the key used to encrypt key
+material in the Kerberos database. (This is the key stored in the stash file
on the KDC if stash files are used.) However, the security risk of
a single-DES key for ``K/M`` is minimal, given that access to material
encrypted in ``K/M`` (the Kerberos database) is generally tightly controlled.
@@ -127,3 +392,9 @@ If an attacker can gain access to the encrypted database, they likely
have access to the stash file as well, rendering the weak cryptography
broken by non-cryptographic means. As such, upgrading ``K/M`` to a stronger
encryption type is unlikely to be a high-priority task.
+
+Is is possible to upgrade the master key used for the database, if
+desired. Using :ref:`kdb5_util(8)`'s **add_mkey**, **use_mkey**, and
+**update_princ_encryption** commands, a new master key can be added
+and activated for use on new key material, and the existing entries
+converted to the new master key.
More information about the cvs-krb5
mailing list