From hedrick at rutgers.edu  Tue Jun 23 08:43:20 2026
From: hedrick at rutgers.edu (Charles Hedrick)
Date: Tue, 23 Jun 2026 12:43:20 +0000
Subject: why is aes sha1 the default encryption type
Message-ID: <PH0PR14MB54932589DD184BAE4A07A48BAAEE2@PH0PR14MB5493.namprd14.prod.outlook.com>

When there's a perfectly good aes sha2 type?

From ghudson at mit.edu  Tue Jun 23 16:12:38 2026
From: ghudson at mit.edu (Greg Hudson)
Date: Tue, 23 Jun 2026 16:12:38 -0400
Subject: why is aes sha1 the default encryption type
In-Reply-To: <PH0PR14MB54932589DD184BAE4A07A48BAAEE2@PH0PR14MB5493.namprd14.prod.outlook.com>
References: <PH0PR14MB54932589DD184BAE4A07A48BAAEE2@PH0PR14MB5493.namprd14.prod.outlook.com>
Message-ID: <c1dc71d8-23c4-437a-a1e0-89bdf7cad1b1@mit.edu>

On 6/23/26 08:43, Charles Hedrick via Kerberos wrote:
> When there's a perfectly good aes sha2 type?

1. It is highly interoperable.  Every Kerberos implementation of 
significance implements aes-sha1, going back many years.  Microsoft 
either hasn't implemented aes-sha2 or only implemented it in 2025 (I 
can't easily tell which), so the clock has at best barely started on 
that kind of reach for aes-sha2.

2. The known flaws in SHA-1 do not affect its use as a MAC.

3. Kerberos enctype negotation isn't perfect.  It works well enough for 
client interoperability, but when provisioning keytabs for servers you 
have to select an enctype that the server software supports.  There is 
also this edge case if it hasn't been fixed on the Microsoft side:
https://krbdev.mit.edu/rt/Ticket/Display.html?id=9089

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.


From hedrick at rutgers.edu  Tue Jun 23 16:16:06 2026
From: hedrick at rutgers.edu (Charles Hedrick)
Date: Tue, 23 Jun 2026 20:16:06 +0000
Subject: why is aes sha1 the default encryption type
In-Reply-To: <c1dc71d8-23c4-437a-a1e0-89bdf7cad1b1@mit.edu>
References: <PH0PR14MB54932589DD184BAE4A07A48BAAEE2@PH0PR14MB5493.namprd14.prod.outlook.com>
 <c1dc71d8-23c4-437a-a1e0-89bdf7cad1b1@mit.edu>
Message-ID: <PH0PR14MB54930D68C9207E773F2CD923AAEE2@PH0PR14MB5493.namprd14.prod.outlook.com>

does the encrypt affect the way user passwords are hashed in the KDC. (I assume password hashses are stored, not passwords in the clear?)


________________________________________
From: Greg Hudson <ghudson at mit.edu>
Sent: Tuesday, June 23, 2026 4:12 PM
To: Charles Hedrick; Kerberos at mit.edu
Subject: Re: why is aes sha1 the default encryption type

On 6/23/26 08:43, Charles Hedrick via Kerberos wrote:
> When there's a perfectly good aes sha2 type?

1. It is highly interoperable.  Every Kerberos implementation of
significance implements aes-sha1, going back many years.  Microsoft
either hasn't implemented aes-sha2 or only implemented it in 2025 (I
can't easily tell which), so the clock has at best barely started on
that kind of reach for aes-sha2.

2. The known flaws in SHA-1 do not affect its use as a MAC.

3. Kerberos enctype negotation isn't perfect.  It works well enough for
client interoperability, but when provisioning keytabs for servers you
have to select an enctype that the server software supports.  There is
also this edge case if it hasn't been fixed on the Microsoft side:
https://krbdev.mit.edu/rt/Ticket/Display.html?id=9089

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.



From simo at redhat.com  Tue Jun 23 16:27:03 2026
From: simo at redhat.com (Simo Sorce)
Date: Tue, 23 Jun 2026 16:27:03 -0400
Subject: why is aes sha1 the default encryption type
In-Reply-To: <PH0PR14MB54930D68C9207E773F2CD923AAEE2@PH0PR14MB5493.namprd14.prod.outlook.com>
References: <PH0PR14MB54932589DD184BAE4A07A48BAAEE2@PH0PR14MB5493.namprd14.prod.outlook.com>
 <c1dc71d8-23c4-437a-a1e0-89bdf7cad1b1@mit.edu>
 <PH0PR14MB54930D68C9207E773F2CD923AAEE2@PH0PR14MB5493.namprd14.prod.outlook.com>
Message-ID: <d23124f337123fc2a2e6520b10335e1df1c67eef.camel@redhat.com>

Charles,
That is actually a KDC implementation detail, but the MIT KDC generates
a key from the password at password change time (using a derivation
function specific to each enctype and saves a key for each enctype,
togteher with a key version number).
As a data point this is the same data you obtain in a keytab.

A KDC cannot really store *a* hash, because clients do not send
passwords for authentication.


HTH,
Simo.

On Tue, 2026-06-23 at 20:16 +0000, Charles Hedrick via Kerberos wrote:
> does the encrypt affect the way user passwords are hashed in the KDC. (I assume password hashses are stored, not passwords in the clear?)
> 
> 
> ________________________________________
> From: Greg Hudson <ghudson at mit.edu>
> Sent: Tuesday, June 23, 2026 4:12 PM
> To: Charles Hedrick; Kerberos at mit.edu
> Subject: Re: why is aes sha1 the default encryption type
> 
> On 6/23/26 08:43, Charles Hedrick via Kerberos wrote:
> > When there's a perfectly good aes sha2 type?
> 
> 1. It is highly interoperable.  Every Kerberos implementation of
> significance implements aes-sha1, going back many years.  Microsoft
> either hasn't implemented aes-sha2 or only implemented it in 2025 (I
> can't easily tell which), so the clock has at best barely started on
> that kind of reach for aes-sha2.
> 
> 2. The known flaws in SHA-1 do not affect its use as a MAC.
> 
> 3. Kerberos enctype negotation isn't perfect.  It works well enough for
> client interoperability, but when provisioning keytabs for servers you
> have to select an enctype that the server software supports.  There is
> also this edge case if it hasn't been fixed on the Microsoft side:
> https://krbdev.mit.edu/rt/Ticket/Display.html?id=9089
> 
> 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.
> 
> 
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos

-- 
Simo Sorce
Distinguished Engineer
RHEL Crypto Team
Red Hat, Inc



From kenh at cmf.nrl.navy.mil  Tue Jun 23 16:34:25 2026
From: kenh at cmf.nrl.navy.mil (Ken Hornstein)
Date: Tue, 23 Jun 2026 16:34:25 -0400
Subject: why is aes sha1 the default encryption type
In-Reply-To: <c1dc71d8-23c4-437a-a1e0-89bdf7cad1b1@mit.edu>
References: <PH0PR14MB54932589DD184BAE4A07A48BAAEE2@PH0PR14MB5493.namprd14.prod.outlook.com>
 <c1dc71d8-23c4-437a-a1e0-89bdf7cad1b1@mit.edu>
Message-ID: <202606232034.65NKYPxG031908@hedwig.cmf.nrl.navy.mil>

>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

From nico at cryptonector.com  Tue Jun 23 18:13:08 2026
From: nico at cryptonector.com (Nico Williams)
Date: Tue, 23 Jun 2026 17:13:08 -0500
Subject: why is aes sha1 the default encryption type
In-Reply-To: <PH0PR14MB54930D68C9207E773F2CD923AAEE2@PH0PR14MB5493.namprd14.prod.outlook.com>
References: <PH0PR14MB54932589DD184BAE4A07A48BAAEE2@PH0PR14MB5493.namprd14.prod.outlook.com>
 <c1dc71d8-23c4-437a-a1e0-89bdf7cad1b1@mit.edu>
 <PH0PR14MB54930D68C9207E773F2CD923AAEE2@PH0PR14MB5493.namprd14.prod.outlook.com>
Message-ID: <ajsE9DvlSNai1okP@ubby>

On Tue, Jun 23, 2026 at 08:16:06PM +0000, Charles Hedrick via Kerberos wrote:
> does the encrypt affect the way user passwords are hashed in the KDC.
> (I assume password hashses are stored, not passwords in the clear?)

Kerberos supports multiple "pre-authentication" mechanisms.  The most
commonly used ones are password-based and -here you are about to be sad-
the KDC stores a password-equivalent.

There is a PAKE now for Kerberos, but it's symmetric, so once again the
KDC stores a password-equivalent.

Lastly there is PKINIT, where you use a client certificate to
authenticate the user.  A KDC that supports PKINIT can avoid storing
password equivalents when all the clients support it _and_ you have a
way to provision all users with private keys and certificates.

Nico
-- 

From nico at cryptonector.com  Tue Jun 23 18:25:27 2026
From: nico at cryptonector.com (Nico Williams)
Date: Tue, 23 Jun 2026 17:25:27 -0500
Subject: why is aes sha1 the default encryption type
In-Reply-To: <ajsE9DvlSNai1okP@ubby>
References: <PH0PR14MB54932589DD184BAE4A07A48BAAEE2@PH0PR14MB5493.namprd14.prod.outlook.com>
 <c1dc71d8-23c4-437a-a1e0-89bdf7cad1b1@mit.edu>
 <PH0PR14MB54930D68C9207E773F2CD923AAEE2@PH0PR14MB5493.namprd14.prod.outlook.com>
 <ajsE9DvlSNai1okP@ubby>
Message-ID: <ajsH18O56saGzr/t@ubby>

On Tue, Jun 23, 2026 at 05:13:08PM -0500, Nico Williams wrote:
> On Tue, Jun 23, 2026 at 08:16:06PM +0000, Charles Hedrick via Kerberos wrote:
> > does the encrypt affect the way user passwords are hashed in the KDC.
> > (I assume password hashses are stored, not passwords in the clear?)
> 
> Kerberos supports multiple "pre-authentication" mechanisms.  The most
> commonly used ones are password-based and -here you are about to be sad-
> the KDC stores a password-equivalent.
> 
> There is a PAKE now for Kerberos, but it's symmetric, so once again the
> KDC stores a password-equivalent.

I should add that these password equivalents are derived from the
password and a salt using PBKDF2, which is a compute-hard but not
memory-hard PBKDF, and the default round count count for it is set as of
some 20 years ago, so it's too low (in principle it can be raised), so
it's not all that compute-hard either.