[39626] in Kerberos
Re: why is aes sha1 the default encryption type
daemon@ATHENA.MIT.EDU (Ken Hornstein via Kerberos)
Tue Jun 23 16:35:43 2026
Message-Id: <202606232034.65NKYPxG031908@hedwig.cmf.nrl.navy.mil>
To: <Kerberos@mit.edu>
In-Reply-To: <c1dc71d8-23c4-437a-a1e0-89bdf7cad1b1@mit.edu>
MIME-Version: 1.0
Date: Tue, 23 Jun 2026 16:34:25 -0400
From: Ken Hornstein via Kerberos <kerberos@mit.edu>
Reply-To: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
>I get that using SHA-1 in any capacity can run afoul of regulatory
>systems, which aren't always nuanced enough to recognize that it is
>still believed to be secure as a MAC. But changing the default doesn't
>necessarily help with compliance; as long as the system can negotiate
>down to aes-sha1 then it still has SHA-1 in its attack surface.
As long as we're talking about this ...
The specific issue we run into with aes-sha1 is not the use of SHA-1,
but the key derivation function used in that cryptosystem is not
FIPS compliant. And in our environment we have to run in FIPS mode,
which forces the use of the aes-sha2 algorithms (distros like RHEL 9
force this specifically for Kerberos when you turn on FIPS mode).
That's fine, but we're kind of being thwarted by this code in kdc/kdc_util.c:
/* Assume every server without a session_enctypes attribute supports
* aes256-cts-hmac-sha1-96. */
if (enctype == ENCTYPE_AES256_CTS_HMAC_SHA1_96)
return TRUE;
You're going to say that you can set the "session_enctypes" string in
the KDB for principals to short-circuit this check, and fair enough ...
but if there's one thing that history has taught me, it's that the fewer
places you explicitly configure a enctype, the better.
Would a patch be accepted for a KDC configuration file setting that disabled
this always-enabling of aes-sha1?
--Ken
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
