Encryption types identify which cryptographic algorithms and mode to use when cryptographic operations are performed. For a list of supported encryption types, see the krb5.conf(4) and kdb5_util(1M) man pages.
When a client requests a ticket from the KDC, the KDC must use keys whose encryption type is compatible with both the client and the server. The Kerberos protocol allows the client to request that the KDC use particular encryption types for the client's part of the ticket reply. The protocol does not allow the server to specify encryption types to the KDC.
Consider the following issues before you change the encryption types:
The KDC assumes that the first key/encryption-type associated with the server principal entry in the principal database is supported by the server.
On the KDC, you must ensure that the keys that are generated for the principal are compatible with the systems that will authenticate the principal. By default, the kadmin command creates keys for all supported encryption types. If the systems that the principal is used on do not support this default set of encryption types, then you should restrict the encryption types when creating a principal. The two recommended methods of restricting the encryption types are by using of the –e flag in kadmin addprinc or by setting the supported_enctypes parameter in the kdc.conf file to this subset. Use the supported_enctypes parameter when most of the systems in a Kerberos realm support a subset of the default set of encryption types. Setting supported_enctypes specifies the default set of encryption types kadmin addprinc uses when it creates a principal for a particular realm.
When determining the encryption types that a system supports, consider both the version of Kerberos that is running on the system as well as the cryptographic algorithms that are supported by the server application for which a server principal is being created. For example, when creating an nfs/hostname service principal, you should restrict the encryption types to the types that the NFS server on that host supports.
The master_key_enctype parameter in the kdc.conf file can be used to control the encryption type of the master key that encrypts the entries in the principal database. Do not use this parameter if the KDC principal database has already been created. The master_key_enctype parameter can be used at database creation time to change the default master key encryption type from aes256-cts-hmac-sha1-96 to a different encryption type. Make sure that all slave KDCs support the chosen encryption type and that they have an identical master_key_enctype entry in their kdc.conf file when configuring the slave KDCs. Also, make sure that the master_key_enctype is set to one of the encryption types in supported_enctypes, if supported_enctypes is set in kdc.conf. If either of these issues are not handled properly, then the master KDC might not be able to work with the slave KDCs.
On the client, you can control its encryption type requests from the KDC through parameters in the krb5.conf file. The default_tkt_enctypes parameter specifies the encryption types that the client is willing to use when the client requests a ticket-granting ticket (TGT) from the KDC. The TGT is used by the client to acquire other server tickets in a more efficient manner. The effect of setting default_tkt_enctypes is to give the client some control over the encryption types used to protect the communication between the client and KDC when the client requests a server ticket using the TGT (this is called a TGS request). Note that the encryption types that are specified in default_tkt_enctypes must match at least one of the principal key encryption types in the principal database stored on the KDC. Otherwise, the TGT request will fail. In most situations, you should not set default_tkt_enctypes because this parameter can be a source of interoperability problems. By default, the client code requests that all supported encryption types and the KDC choose the encryption types based on the keys that the KDC finds in the principal database.
The default_tgs_enctypes parameter restricts the encryption types that the client requests in its TGS requests, which are used to acquire server tickets. This parameter also restricts the encryption types the KDC uses when creating the session key that the client and server share. For example, if a client wants to only use 3DES encryption when doing secure NFS, you should set default_tgs_enctypes = des3-cbc-sha1. Make sure that the client and server principals have a des-3-cbc-sha1 key in the principal database. As with default_tkt_enctype, you should in most cases not set this parameter because it can cause interoperability problems if the credentials are not set up properly both on the KDC and the server.
On the server, you can control the encryption types that it accepts with the permitted_enctypes parameter in the kdc.conf file. In addition, you can specify the encryption types that it uses when creating keytab entries. Try to avoid using either of these methods to control encryption types and instead let the KDC determine the encryption types to use because the KDC does not communicate with the server application to determine which key or encryption type to use.