From Newsgroup: comp.protocols.kerberos

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.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.protocols.kerberos

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@mit.edu>
Sent: Tuesday, June 23, 2026 4:12 PM
To: Charles Hedrick; Kerberos@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@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos

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


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.protocols.kerberos

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
--
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.protocols.kerberos

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.
--- Synchronet 3.22a-Linux NewsLink 1.2