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:
aes128-ctsbut 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.
So, here we go:
|Encryption type||Aliases||etype value (dec, hex)||SSF||Description||RFC||Windows support||MIT Kerberos support||Notes|
|des-cbc-crc||1, 0x0001||56||DES cbc mode with CRC-32||RFC 3961 section 6.2.3||Windows 2000 Server+, disabled by default as of Windows 2008R2 Server||All versions before 1.18||Weak & deprecated|
|des-cbc-md4||2, 0x0002||56||DES cbc mode with RSA-MD4||RFC 3961 section 6.2.2||Not supported||All versions before 1.18||Weak & deprecated|
|des-cbc-md5||des||3, 0x0003||56||DES cbc mode with RSA-MD5||RFC 3961 section 6.2.1||Windows 2000 Server+, disabled by default as of Windows 2008R2 Server||All versions before 1.18||Weak & deprecated|
|des-cbc-raw||4, 0x0004||56||DES cbc mode raw||RFC 3961 marked as "reserved"||Not supported||Unknown but definitely removed as of 1.18||Weak & deprecated, not defined in any RFC|
|des3-cbc-raw||6, 0x0006||112||Triple DES cbc mode raw||RFC 3961 marked as "reserved"||Not supported||Unknown||Weak & deprecated, not defined in any RFC|
|des3-cbc-sha1||des3-hmac-sha1, des3-cbc-sha1-kd||16, 0x0010||112||Triple DES cbc mode with HMAC/sha1||RFC 3961, section 6.3||Not supported||1.1|
|aes128-cts-hmac-sha1-96||aes128-cts, aes128-sha1||17, 0x0011||128||AES-128 CTS mode with 96-bit SHA-1 HMAC||RFC 3962||Windows 2008 Server+||1.3|
|aes256-cts-hmac-sha1-96||aes256-cts, aes256-sha1||18, 0x0012||256||AES-256 CTS mode with 96-bit SHA-1 HMAC||RFC 3962||Windows 2008 Server+||1.3|
|aes128-cts-hmac-sha256-128||aes128-sha2||19, 0x0013||128||AES-128 CTS mode with 128-bit SHA-256 HMAC||RFC 8009||Not supported||1.15||RFC was only published in October 2016|
|aes256-cts-hmac-sha384-192||aes256-sha2||20, 0x0014||256||AES-256 CTS mode with 192-bit SHA-384 HMAC||RFC 8009||Not supported||1.15||RFC was only published in October 2016|
|arcfour-hmac||rc4-hmac, arcfour-hmac-md5||23, 0x0017||64||ArcFour with HMAC/md5||RFC 4757||Windows 2000 Server+||1.3|
|arcfour-hmac-exp||rc4-hmac-exp, arcfour-hmac-md5-exp||24, 0x0018||40||Exportable ArcFour with HMAC/md5||RFC 4757||Windows 2000 Server+||1.3||Weak & deprecated|
|camellia128-cts-cmac||camellia128-cts||25, 0x0019||128||Camellia-128 CTS mode with CMAC||RFC 6803||Not supported||1.9|
|camellia256-cts-cmac||camellia256-cts||26, 0x001a||256||Camellia-256 CTS mode with CMAC||RFC 6803||Not supported||1.9|
supported_enctypes as of MIT Krb5 1.14 (which is shipped with RedHat 7) only includes the two AES SHA1 variants.
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
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
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
According to the Kerberos RFC the following encryption types MUST be supported by all implementations:
Additionally, the following types SHOULD be supported:
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.
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!