MIT Kerberos Encryption Types

written by Lars Francke on 2017-03-10

Changelog:

• 2020-08-17: Updated to reflect changes as of krb5 1.18.2, which means removal of single-DES encryption types and addition of the SSF column, fixed typo for arcfour-hmac-exp mode, I did not find any information about changes in Windows Server 2019, note about JCE being included by default now

In this short blog post I'm going to give a quick reference of all the different encryption types that MIT Kerberos supports (as of version 1.18.2). This is not strictly Hadoop specific but leaves out some things that are not relevant for most Hadoop installations.

The table is structured as follows:

• Encryption type: This is the main name used for this type within MIT Krb5, it's the one you'd configure in supported_enctypes
• Aliases: This was actually why I started to write this post. I'd see some configurations use aes128-cts-hmac-sha1-96 and others aes128-cts but I never knew the difference. The solution is that MIT Krb5 supports an optional list of aliases for each encryption type. These can be used interchangeably.
• etype value: This is the integer value that has been assigned this encryption type. It's used in the RPC calls and you often see these values in debug logs so it helps to have them listed.
• SSF: This is the Security Strength Factor assigned to the specific encryption type by Cyrus SASL
• Description: This is the internal long description that MIT Krb5 uses for this encryption type.
• RFC: This is a reference to the RFC where this encryption type was defined (not all of them have an RFC).
• Windows support: Most of our customers connect Hadoop to Active Directory. This column lists the Windows Server versions that support each encryption type.
• MIT Kerberos support: This lists the MIT Krb5 version that first supported this encryption type.
• Notes: Any additional information I could find.

So, here we go:

Some additional notes

Default supported_enctypes

The default supported_enctypes as of MIT Krb5 1.14 (which is shipped with RedHat 7) only includes the two AES SHA1 variants.

The supported_enctypes property actually supports a list of encryption-salt pairs. The salt was introduced in Kerberos version 5 so that the same password for two different users maps to a different key. The normal way as defined in the Kerberos RFC is to use the concatenation principal's realm and name components as the salt. The full list of supported salt types as of Krb5 1.15 is:

• normal: As described above
• v4: Kerberos 4, no salt
• norealm: Same as the default, without using realm information
• onlyrealm: Uses only realm information as the salt
• afs3: AFS version 3, only used for compatibility with Kerberos 4 in AFS
• special: Generate a random salt

These can be specified by separating them from the encryption type with a colon. So the default list in Krb5 1.15 would look like this spelled out:

supported_enctypes = aes128-cts-hmac-sha256-128:normal,aes256-cts-hmac-sha1-96:normal

As normal is the default it can be omitted so the list can be shortened to:

supported_enctypes = aes128-cts-hmac-sha256-128,aes256-cts-hmac-sha1-96

Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files

Note: This is not required anymore for modern Java versions as the JCE is included by default. See JDK-8170157 for details.

Due to export restrictions Java ships with support for limited encryptions by default. This excludes all encryption types with more than 128 bits for example. So if you want to use the AES 256 encryption you need to download JCE policy files and install them.

To check out which policies are supported in your JRE you can look for a file called local_policy.jar in your JRE directory (for me it is under lib/security), extract it and take a look at the resulting default_local.policy file.

Required encryption types

According to the Kerberos RFC the following encryption types MUST be supported by all implementations:

• AES256-CTS-HMAC-SHA1-96

  Additionally, the following types SHOULD be supported:

• AES128-CTS-HMAC-SHA1-96

• DES-CBC-MD5 (deprecated now and removed in 1.18)
• DES3-CBC-SHA1-KD

PKINIT

There are a couple more encryption types which are related to PKINIT:

PKINIT is a preauthentication mechanism for Kerberos 5 which uses X.509 certificates to authenticate the KDC to clients and vice versa.

Source: MIT Kerberos docs.

I have not listed them here because I've never seen them being used for any Hadoop based deployment.

Deprecated & weak encryption types

RFC 6649 deprecates the weak DES encryption types 1, 2 and 3, it also deprecates the export version of RC4 (type 24).

The full list of all assigned encryption types is hosted by IANA in their Kerberos Encryption Type Numbers list.

Thank you Dave Beech for the review!