# Kerberos V5

Source: https://startwithidentity.com/standards/kerberos/
Last updated: 2026-11-05
License: content by Start with Identity. Cite the source URL.

---

## What it is

Kerberos V5 is a network authentication protocol built on a trusted third party, the **Key Distribution Center (KDC)**, that shares a secret key with every user and service in its **realm**. The KDC hands out encrypted, time-limited **tickets**; a client proves who it is to a service by presenting a ticket the service can decrypt, plus a fresh authenticator only the legitimate client could produce. Passwords never cross the network, and users sign in once per session.

The protocol is [RFC 4120](https://www.rfc-editor.org/rfc/rfc4120) (July 2005), written by C. Neuman (USC-ISI) with T. Yu, S. Hartman and K. Raeburn (MIT); it obsoletes RFC 1510. The GSS-API mechanism that applications actually call is [RFC 4121](https://www.rfc-editor.org/rfc/rfc4121). Every Active Directory domain controller is a KDC, and Windows adds its own extensions in [MS-KILE](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-kile/2a32282e-dd48-4ad9-a542-609804b02cc9) and the authorization data format [MS-PAC](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-pac/166d8064-c863-41e1-9c23-edaaa5f36962). On Linux, MIT Kerberos and Heimdal are the main implementations; [FreeIPA](https://startwithidentity.com/vendors/open-source/freeipa/) bundles MIT Kerberos, and [Keycloak](https://startwithidentity.com/vendors/open-source/keycloak/) documents a Kerberos bridge for desktop SSO (both checked on the project sites, 5 November 2026).

## Status (November 2026)

| Item | Status |
| --- | --- |
| RFC 4120 | Proposed Standard, July 2005. Updated by RFC 4537, 5021, 5896, 6111, 6112, 6113, 6649, 6806, 7751, 8062, 8129, 8429 and 8553 (per the [RFC Editor](https://www.rfc-editor.org/info/rfc4120)) |
| Pre-authentication framework and FAST | [RFC 6113](https://www.rfc-editor.org/rfc/rfc6113) |
| Certificate logon (PKINIT) | [RFC 4556](https://www.rfc-editor.org/rfc/rfc4556), Proposed Standard, June 2006 |
| Encryption types | AES with HMAC-SHA1 ([RFC 3962](https://www.rfc-editor.org/rfc/rfc3962), etypes 17 and 18) and AES with HMAC-SHA2 ([RFC 8009](https://www.rfc-editor.org/rfc/rfc8009), etypes 19 and 20). DES deprecated by [RFC 6649](https://www.rfc-editor.org/rfc/rfc6649) (BCP 179, July 2012); RC4-HMAC (23) and 3DES by [RFC 8429](https://www.rfc-editor.org/rfc/rfc8429) (BCP 218, October 2018), which also moved RFC 4757 to Historic |
| Ports | 88/tcp and 88/udp `kerberos`, 464 `kpasswd` ([IANA](https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml)) |

Kerberos is not being replaced in Windows networks any time soon, but its configuration is changing underneath: the RC4 default for service tickets in Active Directory was the subject of [CVE-2026-20833](https://startwithidentity.com/cves/cve-2026-20833/), and PAC validation enforcement has been tightened in stages since 2022 (see [CVE-2024-26248](https://startwithidentity.com/cves/cve-2024-26248/)).

## How it works

Three exchanges, each defined in RFC 4120 §3:

1. **AS exchange** ([§3.1](https://www.rfc-editor.org/rfc/rfc4120#section-3.1)). The client sends `AS-REQ` naming itself and the ticket-granting service `krbtgt/REALM`. With pre-authentication, it includes a timestamp encrypted with its long-term key (`PA-ENC-TIMESTAMP`, §5.2.7.2). The KDC replies with `AS-REP`: a **ticket-granting ticket (TGT)** encrypted with the `krbtgt` key, and a session key encrypted with the client's key.
2. **TGS exchange** ([§3.3](https://www.rfc-editor.org/rfc/rfc4120#section-3.3)). For each service, the client sends `TGS-REQ` with the TGT and an authenticator, naming a **service principal** such as `HTTP/app.example.com`. The KDC returns a **service ticket** encrypted with that service's key.
3. **AP exchange** ([§3.2](https://www.rfc-editor.org/rfc/rfc4120#section-3.2)). The client sends `AP-REQ` to the service, carried inside the application protocol (SMB, LDAP SASL `GSSAPI`, or HTTP `Negotiate` per [RFC 4559](https://www.rfc-editor.org/rfc/rfc4559)). The service decrypts the ticket with its own key, checks the authenticator, and optionally answers with `AP-REP` for mutual authentication.

Time matters: authenticators are rejected outside an allowable clock skew (RFC 4120 gives 5 minutes as the example), and servers keep a replay cache for that window. The field-by-field version of all three exchanges is in [how Kerberos works, message by message](https://startwithidentity.com/guides/protocols/kerberos-message-flow/).

## Active Directory specifics that change the security picture

- **The PAC.** Domain controllers put a Privilege Attribute Certificate in the ticket's authorization data with the user's SIDs and group memberships, signed by the KDC ([MS-PAC](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-pac/166d8064-c863-41e1-9c23-edaaa5f36962)). Services authorize from it, so PAC forgery or skipped PAC validation means privilege escalation.
- **Service keys come from passwords.** A service principal registered on a user account has a key derived from that account's password. Any domain user can request a ticket for it, and a weak password can be cracked offline: [Kerberoasting](https://startwithidentity.com/techniques/kerberoasting/).
- **Delegation.** Unconstrained, constrained and resource-based constrained delegation (S4U2self and S4U2proxy in MS-SFU) let services act as users; misconfigured delegation is a domain-compromise path: [Kerberos delegation abuse](https://startwithidentity.com/techniques/kerberos-delegation-abuse/).
- **Certificate logon.** PKINIT ties Kerberos to AD Certificate Services, so certificate template mistakes become Kerberos logons as other users: [AD CS certificate template abuse](https://startwithidentity.com/techniques/adcs-certificate-template-abuse/).
- **The krbtgt key.** Whoever holds it can mint TGTs for anyone, so a suspected domain compromise includes rotating it.

## Where Kerberos breaks in practice

On 5 November 2026 the SWI [identity CVE catalog](https://startwithidentity.com/cves/) held 14 entries tagged Kerberos and Active Directory. The recurring classes:

- **PAC and identity validation gaps:** [CVE-2024-26248](https://startwithidentity.com/cves/cve-2024-26248/), [CVE-2024-29056](https://startwithidentity.com/cves/cve-2024-29056/) (cross-forest), [CVE-2026-27912](https://startwithidentity.com/cves/cve-2026-27912/) (kpasswd ignoring `PAC_REQUESTOR_SID`).
- **Protocol extension logic:** [CVE-2025-60704](https://startwithidentity.com/cves/cve-2025-60704/) (S4U missing a cryptographic step), [CVE-2025-26647](https://startwithidentity.com/cves/cve-2025-26647/) (PKINIT and NTAuth), [CVE-2022-26923](https://startwithidentity.com/cves/cve-2022-26923/) (Certifried).
- **KDC impersonation and reflection:** [CVE-2024-20674](https://startwithidentity.com/cves/cve-2024-20674/), [CVE-2025-33073](https://startwithidentity.com/cves/cve-2025-33073/) and [CVE-2025-58726](https://startwithidentity.com/cves/cve-2025-58726/) (Kerberos reflection over SMB).
- **Weak defaults and naming:** [CVE-2026-20833](https://startwithidentity.com/cves/cve-2026-20833/) (RC4 service tickets), [CVE-2026-25177](https://startwithidentity.com/cves/cve-2026-25177/) (look-alike SPNs with invisible Unicode).

## When to use it

Kerberos is the right protocol for authentication **inside a managed network**: Windows domains, Linux hosts joined to a realm, file and database services, and LDAP binds via SASL `GSSAPI`. It is a poor fit across the internet or into SaaS, where it needs direct reachability to the KDC; [SAML 2.0](https://startwithidentity.com/standards/saml-2-0/) and [OpenID Connect](https://startwithidentity.com/standards/openid-connect/) federate from the same directory instead. Where an application can do Kerberos, prefer it over NTLM and over [LDAP](https://startwithidentity.com/standards/ldap/) simple binds with passwords.

## Pitfalls

- Service accounts with SPNs, weak passwords and RC4 still enabled.
- Unconstrained delegation on servers that are not domain controllers.
- Clock drift between clients, servers and KDCs, which breaks logons and tempts admins to widen the skew.
- Clients connecting by IP address or a name with no matching service principal, which can fall back to NTLM without anyone noticing.
- Treating a decrypted ticket as authorization. RFC 4120 §3.2.3 says passing the checks "provides only authentication of the named principal"; the application must still decide what that principal may do.

## How it works, message by message

The [Kerberos message-flow walkthrough](https://startwithidentity.com/guides/protocols/kerberos-message-flow/) decodes AS-REQ with pre-authentication, AS-REP, TGS-REQ, TGS-REP and AP-REQ field by field, shows what is inside a ticket and an authenticator, ties every field to RFC 4120 section 5, and lists the checks the client, the KDC and the service must each run.

## Related

Walkthrough: [how Kerberos works, message by message](https://startwithidentity.com/guides/protocols/kerberos-message-flow/). Standards: [LDAP](https://startwithidentity.com/standards/ldap/), [RADIUS](https://startwithidentity.com/standards/radius/). Glossary: [Kerberos](https://startwithidentity.com/glossary/kerberos/), [NTLM](https://startwithidentity.com/glossary/ntlm/), [Active Directory](https://startwithidentity.com/glossary/active-directory/). Guides: [what is ITDR](https://startwithidentity.com/guides/fundamentals/what-is-itdr/), [identity threat detection and response](https://startwithidentity.com/guides/security/identity-threat-detection-response-guide/).