Installing, Configuring and Administering the Kerberos Server V 2.0 on HP-UX 11i

Overview
DES vs 3DES Key Type Settings
Chapter 132
DES vs 3DES Key Type Settings
In the processes outlined above, what happens if the user principal and
the service principal do not use the same key type? The answer is - the
process continues as described. Here’s why.
There is no step in which the client or the service accepts a message
encrypted by the other’s key. The Kerberos Server acts as the only
trusted party. Both the client application and the service share a secret
with only the server.
The authenticator data that must be encrypted or decrypted by both the
service and the client is encrypted in session keys. The server sends the
required session keys to the client and service in packets that are
encrypted with their respective keys. The Kerberos Server determines
the strongest encryption allowed for the session key by checking the key
type settings for the user and service principals. If both have a 3DES key
stored in the database, the session key type that is returned is of type
3DES. If only one has a 3DES key and the other has a DES key, then the
session key that is returned is of type DES.
Note that the server will never return a session key in the service ticket
packet that uses stronger encryption than the session key included with
a TGT packet. If a user principal has both a 3DES and DES key, and uses
the DES key to obtain a TGT - all service tickets obtained using this TGT
will contain DES session keys.
WARNING The krbtgt/<REALM NAME> is the ticket-granting principal. This is
a reserved principal that is automatically created when a realm
is added to the database. The krbtgt/<REALM NAME>principal
must be assigned a key type or default keys issued by the
Kerberos Server will use the 3DES encryption type.