How Kerberos Works, Message by Message

A Kerberos login is three request and reply pairs between a client, the Key Distribution Center (KDC) and a service: the AS exchange gets a ticket-granting ticket (TGT), the TGS exchange turns it into a service ticket, and the AP exchange presents that ticket to the service. Every message is ASN.1 defined in RFC 4120 §5. This page decodes each one with fake values, ties the fields to their sections, and lists what each party must check. For what Kerberos is and where it fits, see the Kerberos standard page.

All examples use the realm EXAMPLE.COM, user ada@EXAMPLE.COM and service HTTP/app.example.com@EXAMPLE.COM. Encrypted parts are shown as their decrypted structure, which only the party holding the key can see.

The sequence at a glance

Messages 1 to 3: AS-REQ and pre-authentication

AS-REQ ::= [APPLICATION 10] {
  pvno      5,
  msg-type  10,
  padata    [ PA-ENC-TIMESTAMP (2): EncryptedData {
                etype 18, cipher <PA-ENC-TS-ENC { patimestamp 20261105140211Z,
                                                  pausec 412 } encrypted with ada's key> },
              PA-PAC-REQUEST (128): include-pac TRUE ],
  req-body {
    kdc-options  forwardable, renewable, canonicalize,
    cname        { name-type NT-PRINCIPAL (1), name-string ["ada"] },
    realm        "EXAMPLE.COM",
    sname        { name-type NT-SRV-INST (2), name-string ["krbtgt", "EXAMPLE.COM"] },
    till         20261106000211Z,
    rtime        20261112140211Z,
    nonce        1953746982,
    etype        [ 18, 17, 20, 19 ] } }

The first attempt (message 1) is the same without padata. A KDC that requires pre-authentication answers with KRB-ERROR code 25 and a PA-ETYPE-INFO2 hint listing the encryption type and salt to use, and the client retries. The default salt is the realm followed by the name components with no separator, here EXAMPLE.COMada (RFC 4120 §4).

Message 4: AS-REP

AS-REP ::= [APPLICATION 11] {
  pvno 5, msg-type 11,
  crealm "EXAMPLE.COM",
  cname  { NT-PRINCIPAL, ["ada"] },
  ticket {                                   -- the TGT, opaque to the client
    tkt-vno 5, realm "EXAMPLE.COM", sname krbtgt/EXAMPLE.COM,
    enc-part { etype 18, kvno 2, cipher <EncTicketPart encrypted with the krbtgt key> } },
  enc-part { etype 18, kvno 7, cipher <EncASRepPart encrypted with ada's key> } }

EncASRepPart (decrypted by the client) {
  key        { keytype 18, keyvalue <TGT session key> },
  last-req   [...],
  nonce      1953746982,
  flags      forwardable, renewable, initial, pre-authent,
  authtime   20261105140211Z,
  endtime    20261106000211Z,
  renew-till 20261112140211Z,
  srealm     "EXAMPLE.COM",
  sname      krbtgt/EXAMPLE.COM }

Messages 5 and 6: TGS-REQ and TGS-REP

TGS-REQ ::= [APPLICATION 12] {
  pvno 5, msg-type 12,
  padata [ PA-TGS-REQ (1): AP-REQ { ticket <the TGT>,
             authenticator <Authenticator encrypted with the TGT session key> } ],
  req-body {
    kdc-options forwardable, canonicalize,
    realm  "EXAMPLE.COM",
    sname  { NT-SRV-INST, ["HTTP", "app.example.com"] },
    till   20261106000211Z,
    nonce  287364510,
    etype  [ 18, 17 ] } }

The TGS-REP has the same shape as the AS-REP, but its ticket is the service ticket, encrypted with the key of HTTP/app.example.com, and its enc-part is encrypted with the TGT session key rather than the user's password key (§3.3.3). In Active Directory the service key is derived from the password of whichever account holds that SPN. That single fact is Kerberoasting: any authenticated user can request this ticket and attack the service account's password offline.

Messages 7 and 8: AP-REQ and AP-REP

AP-REQ ::= [APPLICATION 14] {
  pvno 5, msg-type 14,
  ap-options mutual-required,
  ticket { tkt-vno 5, realm "EXAMPLE.COM", sname HTTP/app.example.com,
           enc-part { etype 18, kvno 4, cipher <EncTicketPart> } },
  authenticator { etype 18, cipher <Authenticator encrypted with the service session key> } }

EncTicketPart (decrypted by the service with its own key) {
  flags forwardable, pre-authent,
  key   { keytype 18, keyvalue <service session key> },
  crealm "EXAMPLE.COM", cname { NT-PRINCIPAL, ["ada"] },
  transited { tr-type 1, contents "" },
  authtime 20261105140211Z, starttime 20261105140230Z, endtime 20261106000211Z,
  authorization-data [ AD-IF-RELEVANT [ AD-WIN2K-PAC (128): <PAC> ] ] }

Authenticator (decrypted with the session key) {
  authenticator-vno 5,
  crealm "EXAMPLE.COM", cname { NT-PRINCIPAL, ["ada"] },
  cksum  <checksum binding the application request, if any>,
  cusec  418211, ctime 20261105140230Z,
  subkey { keytype 18, keyvalue <optional subkey> },
  seq-number 1093845021 }

Over HTTP this AP-REQ travels inside a SPNEGO token: Authorization: Negotiate YIIH... (RFC 4559 §4). With mutual-required, the service replies with an AP-REP whose encrypted part repeats ctime and cusec, proving it could decrypt the ticket (§5.5.2).

The checks each party must run

Client, on AS-REP (§3.1.5)

1. cname and crealm in the reply match the request; the decrypted nonce equals the one sent; sname and srealm are the expected TGS.
2. A host that uses a password login to grant local access must not trust the AS-REP alone. RFC 4120 §3.1.5 says decrypting it "is not sufficient for the host to verify the identity of the user"; the host must also get and verify a ticket for its own service key, or a spoofed KDC can log anyone in.

KDC

3. Require pre-authentication for every account (§5.2.7.2). Without it, anyone can request an AS-REP for that user and crack the encrypted part offline.
4. Issue only strong encryption types and never RC4 or DES for new keys (RFC 8429 §7, RFC 6649).

Service, on AP-REQ (§3.2.3)

5. Decrypt the ticket with its own key at the kvno indicated (KRB_AP_ERR_BADKEYVER, KRB_AP_ERR_BAD_INTEGRITY on failure), then decrypt the authenticator with the ticket's session key.
6. cname and crealm in the authenticator match the ticket (KRB_AP_ERR_BADMATCH), and client addresses match if present.
7. Client time within the allowable clock skew (KRB_AP_ERR_SKEW, RFC 4120 uses 5 minutes as its example), and the authenticator is not in the replay cache (KRB_AP_ERR_REPEAT); ticket not yet valid or expired gives KRB_AP_ERR_TKT_NYV or KRB_AP_ERR_TKT_EXPIRED.
8. Authorize separately. Passing these checks "provides only authentication of the named principal" (§3.2.3). In Active Directory, validate the PAC signatures as MS-PAC describes before trusting group SIDs.

Common implementation mistakes, with the CVEs and techniques behind them

Try it locally

There is no browser tool for Kerberos, which runs over raw TCP and UDP to the KDC. On a test realm, MIT Kerberos's kinit runs the AS exchange and klist shows the result: klist -e -f prints each ticket's encryption type and flags, so you can confirm no ticket uses etype 23 and that the pre-authent flag is set. A packet capture on port 88 shows messages 1 to 6 in clear structure, with the encrypted parts opaque.

Related

Kerberos standard page, how LDAP works, message by message, how RADIUS works, message by message. Glossary: Kerberos, NTLM, Active Directory.