Learn Kerberos - Kerberos Encryption Types

#Introduction

In episode 10, you set up cross-realm trust and noticed one silent requirement: both KDCs must have the same enctype list so that the krbtgt shared secret produces matching keys. Episode 11 covers the foundation that makes all of that possible: encryption types — the algorithms protecting every Kerberos message, from TGT to service ticket. In the early episodes you already touched the basics of keys, passwords, and keytabs; now we trace the full enctype list, how to configure it, how negotiation works, and the migration strategy from weak encryption to pure AES.

#Encryption Types Overview

#Legacy Enctypes You Must Leave Behind

• DES — des-cbc-crc, deprecated. A 56-bit key that can be brute-forced in hours; it is no longer safe at all.
• 3DES — des3-cbc-sha1, legacy. An upgrade of DES that is now also considered obsolete and slow.
• RC4-HMAC — arcfour-hmac, legacy. Very popular in the Microsoft ecosystem because it's used for service accounts and legacy compatibility, but its cryptography has long been questioned.

#AES Enctypes

• AES128 — aes128-cts-hmac-sha1-96, AES 128-bit.
• AES256 — aes256-cts-hmac-sha1-96, AES 256-bit, the default enctype in MIT Kerberos.
• Modern AES-SHA2 — aes128-cts-hmac-sha256-128 and aes256-cts-hmac-sha384-192, SHA-256 and SHA-384 based variants that are friendlier for FIPS compliance.

#Other Enctypes

• Camellia — camellia128-cts-cmac and camellia256-cts-cmac, Japanese cryptographic standards. Rarely used in practice because of limited client support and little hardware acceleration.

#Enctype Comparison Table

#Configuring Encryption

#Enctypes Supported by the KDC

On the KDC side, the enctype list is determined by supported_enctypes in /etc/krb5kdc/kdc.conf. This list also determines which keys are derived when a principal is created — that's why changing it doesn't directly affect already-existing principals.

Enctype list in /etc/krb5kdc/kdc.conf

[realms]
    EXAMPLE.COM = {
        supported_enctypes = aes256-cts-hmac-sha1-96:normal aes128-cts-hmac-sha1-96:normal
    }

#Enctype List on the Client Side

[libdefaults] in /etc/krb5.conf manages three lists at once:

• default_tkt_enctypes — the enctypes requested for the TGT.
• default_tgs_enctypes — the enctypes requested for service tickets.
• permitted_enctypes — the enctypes allowed for both TGT and service tickets.

#Strong Encryption Only

Strong enctypes only in /etc/krb5.conf

[libdefaults]
    default_realm = EXAMPLE.COM
    default_tkt_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
    default_tgs_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
    permitted_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
    allow_weak_crypto = false

allow_weak_crypto = false rejects DES and RC4 enctypes outright. When set to true, weak enctypes are also offered during negotiation — a practice that should not be used in production.

#Encryption Negotiation

#Client Request

During kinit, the client sends its preferred enctype list (from default_tkt_enctypes) to the KDC. The KDC then picks the strongest enctype that is in that list and that the principal's key possesses.

#Server Capabilities

Service tickets are encrypted with the key of the destination principal. If the destination principal has no key for the requested enctype — for example, an old keytab containing only RC4 — then the KDC can only use the enctypes available. The intersection of default_tkt_enctypes on the client side, permitted_enctypes, and supported_enctypes on the KDC side determines what can actually be used.

#Fallback Mechanism

Kerberos tries enctypes one by one in preference order. If none match, the KDC replies with the KDC_ERR_ETYPE_NOSUPP error, and kinit fails. This is the real fallback: not downgrading to a weak enctype, but refusing when there's no common ground.

#Compatibility Issues

The classic problem appears when a client or service is outdated: a legacy application that only supports RC4 cannot talk to an AES-only KDC, and vice versa. When eliminating old enctypes, make sure all clients, servers, and keytabs are ready — or prepare a transition period with two enctype lists at once.

#Security Considerations

#Turning Off Weak Encryption

The first rule: never let DES, 3DES, or RC4 live in a realm you control. The presence of a single service using RC4 provides an attack point that can be aimed at the whole realm, especially in the Kerberoasting attack covered in episode 21. With allow_weak_crypto = false, krb5.conf closes that door.

#AES vs RC4

#Performance Implications

AES 128-bit is almost always enough for normal scale, and with AES-NI support on modern CPUs its cost is nearly zero. aes256-cts-hmac-sha384-192 is a bit heavier because of its HMAC-SHA-384, but still far lighter than 3DES. Camellia is rarely hardware accelerated, so in practice it actually feels slower — this is why it's rarely chosen.

#FIPS Compliance

In environments that require FIPS, DES, RC4, and 3DES are not accepted. AES 128-bit and 256-bit, including the newer AES-SHA2 variants, are the compliant choices. That's why for new deployments you should head straight for aes256-cts-hmac-sha1-96 or the modern AES-SHA2 variants.

#Migration Strategy

#Upgrading Enctypes

Migration is done in stages: first add the new enctype to the supported list, keep the old enctype around, then remove the old one once all parties have proven compatible. Remember, changes to supported_enctypes only apply to principals created afterward — old principals need a key reset.

#Supporting Multiple Enctypes

During the transition, run two lists at once: permitted_enctypes holds both new and old enctypes, while the KDC still issues new enctypes for principals that can handle them. For keytabs, re-export with the new enctype so services can use AES keys:

sudo kadmin.local -q "ktadd -k /etc/krb5kdc/http.keytab -e aes256-cts-hmac-sha1-96 host/www@EXAMPLE.COM"

#Testing Compatibility

Use kinit -e to force a specific enctype during testing:

kinit -e aes256-cts-hmac-sha1-96 budi
klist -e

With kinit -e aes256-cts-hmac-sha1-96 you prove that the path to a TGT works for that enctype, and klist -e verifies the result.

#Forced Migration

When all parties are ready, perform a forced migration: remove the old enctypes from all three lists, set allow_weak_crypto = false, then force principal keys to be refreshed. For password principals, use cpw -e so keys are re-derived with the new enctype list; for keytab principals, re-export the keytab. After that, clients with old enctypes can no longer connect automatically.

End state: modern AES only

[libdefaults]
    default_tkt_enctypes = aes256-cts-hmac-sha384-192 aes128-cts-hmac-sha256-128
    default_tgs_enctypes = aes256-cts-hmac-sha384-192 aes128-cts-hmac-sha256-128
    permitted_enctypes = aes256-cts-hmac-sha384-192 aes128-cts-hmac-sha256-128
    allow_weak_crypto = false

#Conclusion

In episode 11, you got to know the entire Kerberos encryption type family: the DES, 3DES, and RC4 you must leave behind; the AES family with its modern SHA-2 variants; how to set the enctype lists in kdc.conf and krb5.conf; the negotiation process from client request to server capabilities; security considerations including FIPS compliance; and migration strategies from gradual to forced migration toward pure AES.

Key takeaways:

• Legacy isn't just old-fashioned — des-cbc-crc, des3-cbc-sha1, and arcfour-hmac are real risks, not mere relics.
• Negotiation is an intersection — the KDC only uses enctypes the client requests and the destination principal's key possesses.
• Migrate gradually, then refresh keys — ktadd -e and cpw -e are the tools to refresh old keys to new enctypes.
• kinit -e aes256-cts-hmac-sha1-96 is the primary testing tool during the transition.

Strong encryption alone is not enough — in the next episode, episode 12, we lock the earliest door: preauthentication and FAST, how Kerberos proves identity before issuing tickets and wraps the entire exchange in an encrypted tunnel.