MIT krb5 1.23: what the release notes say about PACs and legacy session keys

The repository is the upstream source, and the README is release notes

This repository is described as a mirror of the MIT krb5 repository, and its primary language is C. The README is not a project overview or a marketing page, it is the release notes for Kerberos Version 5, Release 1.23, credited to the MIT Kerberos Team. That shape matters for how you should read it. The copyright statement covers 1985 to 2026 by the Massachusetts Institute of Technology and its contributors, with a NOTICE file holding additional notices, and the unified documentation for Kerberos V5 is published separately in HTML and PDF. The HTML table of contents sits at doc/html/index.html and the PDF versions live in the doc/pdf directory, with copies online for the most recent supported release and separately for the release under development. The tree itself is small and predictable, a doc directory, a src directory, a NOTICE file and the README, with no packaging scripts in view.

PAC changes since 1.20 and 1.21 will break a partially upgraded deployment

The most operationally important section of the notes is the one on PAC transitions, and it describes a compatibility hazard rather than a feature. Beginning with release 1.20, the KDC includes minimal PACs in tickets instead of AD-SIGNEDPATH authdata, and S4U requests, which covers protocol transition and constrained delegation, must now contain valid PACs in the incoming tickets. Beginning with release 1.21, service ticket PACs contain a new KDC checksum buffer, which mitigates a hash collision attack against the old KDC checksum. The consequence for operators is spelled out in plain terms. If only some KDCs in a `realm` have been upgraded across versions 1.20 or 1.21, the upgraded KDCs will reject S4U requests containing tickets from non-upgraded KDCs and vice versa. A rolling upgrade therefore breaks delegated authentication in both directions, and that is a fact worth internalising before scheduling the upgrade rather than after it.

Triple-DES and RC4 session keys are now off unless you ask for them

The second transition is about encryption types, and it has been building for several releases. Beginning with krb5-1.21, the KDC will not issue tickets with triple-DES or RC4 session keys unless they are explicitly configured with the new allow_des3 and allow_rc4 variables in [libdefaults]. To make the negotiation workable, the KDC assumes that all services can handle aes256-sha1 session keys unless the service principal carries a session_enctypes string attribute. The earlier steps in the same direction are listed too. A warning has been issued since krb5-1.19 when initial credentials are acquired using the des3-cbc-sha1 encryption type, and since krb5-1.21 a warning is also issued for the arcfour-hmac type. The notes say these types will be disabled by default in future releases and eventually removed, and single-DES support was already removed entirely in krb5-1.18. For a `realm` that still has legacy clients, the session_enctypes attribute is the escape hatch, and it has to be set per service principal.

Building from the tree is documented, not scripted in the README

There is no install command in the release notes, and the project does not pretend otherwise. Build documentation is in doc/html/build/index.html or doc/pdf/build.pdf, and the installation guide is in doc/html/admin/install.html or doc/pdf/install.pdf. If you are building under Windows, the notes point you at the src/windows/README file, which is a reminder that Kerberos 5 has its own Windows build path with its own documentation. This is the shape of a mature infrastructure codebase. The README is a pointer to the documentation rather than a replacement for it, and the release notes for 1.23 themselves are a stub: a heading for major changes in 1.23 is followed by a heading for changes by ticket ID with nothing between them in the copy shown here, so the per change detail lives in the tracker and in the announcement rather than in this file. Anyone expecting a changelog in the repository will find the structure but not the content.

Bug reports go by email, and the web interface is read only

Reporting a problem is described with the same precision as the rest of the file. Problems, bugs and comments are reported by sending email to [email protected]. Bug reports can also be viewed on the web at the tracker address, using the Guest Login button, but the notes warn that the web interface to the bug database is read-only for guests and that the primary way to interact with the database is via email. That is a small operational detail with a real consequence. A read-only web view means triage, search and any follow-up discussion have to happen over email, which is an unusual constraint in a project that otherwise looks entirely modern, and it is worth knowing before you file something against the tracker and expect to see the conversation there. The project also lists a long tail of past sponsors, from Apple and Google to Red Hat and Oracle, and a substantial roster of current and past team members at MIT, which is a fair proxy for how much institutional attention the codebase receives.

What this repository is not, and where to get the real documentation

Two practical cautions for anyone landing here from a search. First, this is a mirror, so it is a place to read the source and the release notes, and the canonical project pages are elsewhere. The Kerberos project page is at web.mit.edu/kerberos/, and the MIT Kerberos Consortium site is at kerberos.org. Second, and more usefully, the documentation URLs in the notes are split into two tracks, one for the most recent supported release and one for the release under development. That distinction matters when you are chasing a behaviour, because a document describing a development build may describe behaviour that has not shipped in a supported release. The same applies to the release notes themselves. Read the notes for the version you actually run. There is no GitHub release history attached to this repository, so the tag and version you care about are the ones named in the release notes, and the current one is 1.23.

Maintenance signals: a current push on an unversioned mirror

The repository is not archived and its last push was on 2026-09-05, so the mirror is being kept in step with upstream. There are no GitHub releases attached, which is what you would expect from a mirror rather than a release-publishing repository, and it means version tracking happens through the release notes in the README and the upstream project rather than through tags on this copy. Licensing is not stated in the repository listing, and the copyright notice attributes everything to the Massachusetts Institute of Technology and its contributors under the terms in the accompanying NOTICE file, so the permissions you rely on come from that file and from upstream rather than from a licence identifier here. If your organisation has a policy that tracks open source dependencies by licence identifier, this entry will need to be resolved against the upstream project before it can be cleared.

Editorial conclusion

The MIT krb5 repository suits an administrator who needs the authoritative text on how a KDC upgrade changes ticket behaviour, because the release notes spell out the mixed version failure modes that generic Kerberos guides gloss over. It does not suit a developer looking for a quick start, since the repository is a source tree and the build instructions live in separate documentation files, and the 1.23 release notes themselves are a stub with the ticket by ticket list filled in elsewhere. Before you plan an upgrade, read the PAC transitions section in full, confirm that every KDC in your Kerberos `realm` will move to the same release, and inventory your service principals for a session_enctypes attribute before relying on the new aes256-sha1 default assumption.

Frequently asked questions

Official sources

1. Issues
2. krb5/krb5 on GitHub
3. README