Kerberos can use a variety of cipher algorithms to protect data. A
Kerberos encryption type (also known as an enctype) is a
specific combination of a cipher algorithm with an integrity algorithm
to provide both confidentiality and integrity to data.

Clients make two types of requests (KDC-REQ) to the KDC: AS-REQs and
TGS-REQs. The client uses the AS-REQ to obtain initial tickets
(typically a Ticket-Granting Ticket (TGT)), and uses the TGS-REQ to
obtain service tickets.

The KDC uses three different keys when issuing a ticket to a client:

The long-term key of the service: the KDC uses this to encrypt the
actual service ticket. The KDC only uses the first long-term key in
the most recent kvno for this purpose.

The session key: the KDC randomly chooses this key and places one
copy inside the ticket and the other copy inside the encrypted part
of the reply.

The reply-encrypting key: the KDC uses this to encrypt the reply it
sends to the client. For AS replies, this is a long-term key of the
client principal. For TGS replies, this is either the session key of the
authenticating ticket, or a subsession key.

Each of these keys is of a specific enctype.

Each request type allows the client to submit a list of enctypes that
it is willing to accept. For the AS-REQ, this list affects both the
session key selection and the reply-encrypting key selection. For the
TGS-REQ, this list only affects the session key selection.

The KDC chooses the session key enctype by taking the intersection of
its permitted_enctypes list, the list of long-term keys for the
most recent kvno of the service, and the client’s requested list of
enctypes. If allow_weak_crypto is true, all services are assumed
to support des-cbc-crc.

Also starting in krb5-1.11, it is possible to set a string attribute
on a service principal to control what session key enctypes the KDC
may issue for service tickets for that principal. See
set_string in kadmin for details.

Generally, a service should have a key of the strongest
enctype that both it and the KDC support. If the KDC is running a
release earlier than krb5-1.11, it is also useful to generate an
additional key for each enctype that the service can support. The KDC
will only use the first key in the list of long-term keys for encrypting
the service ticket, but the additional long-term keys indicate the
other enctypes that the service supports.

As noted above, starting with release krb5-1.11, there are additional
configuration settings that control session key enctype selection
independently of the set of long-term keys that the KDC has stored for
a service principal.

The following [libdefaults] settings in krb5.conf will
affect how enctypes are chosen.

allow_weak_crypto

defaults to false starting with krb5-1.8. When false, removes
single-DES enctypes (and other weak enctypes) from
permitted_enctypes, default_tkt_enctypes, and
default_tgs_enctypes. Do not set this to true unless the
use of weak enctypes is an acceptable risk for your environment
and the weak enctypes are required for backward compatibility.

permitted_enctypes

controls the set of enctypes that a service will accept as session
keys.

default_tkt_enctypes

controls the default set of enctypes that the Kerberos client
library requests when making an AS-REQ. Do not set this unless
required for specific backward compatibility purposes; stale
values of this setting can prevent clients from taking advantage
of new stronger enctypes when the libraries are upgraded.

default_tgs_enctypes

controls the default set of enctypes that the Kerberos client
library requests when making a TGS-REQ. Do not set this unless
required for specific backward compatibility purposes; stale
values of this setting can prevent clients from taking advantage
of new stronger enctypes when the libraries are upgraded.

The following per-realm setting in kdc.conf affects the
generation of long-term keys.

supported_enctypes

controls the default set of enctype-salttype pairs that kadmind
will use for generating long-term keys, either randomly or from
passwords