skip to content

What does the PA-TGS-REQ padata in a Kerberos TGS-REQ contain, and what does its Authenticator prove?

level: middleimportance: must knowfreq 48%

answer

  1. the TGS is itself a service
  2. pre-authentication data, not a new password
  3. a whole message nested inside a field
  4. checksum binds proof to this body
  5. sealed under the ticket-granting session key

basics

~20 s

PA-TGS-REQ (padata-type 1) carries a DER-encoded AP-REQ: the ticket-granting ticket plus an Authenticator sealed under that ticket's session key, whose cksum covers the KDC-REQ-BODY. It proves the sender holds the session key and sent this exact request body.

solid answer

~40 s

A `TGS-REQ` authenticates itself the same way any Kerberos client authenticates to any service, because the ticket-granting service *is* a service — the one named `krbtgt/REALM@REALM`. The request's `padata` therefore carries a `PA-TGS-REQ` element (`padata-type` 1) whose `padata-value` is a **DER-encoded `AP-REQ`**: the ticket-granting ticket itself, plus an `Authenticator` encrypted under that ticket's **session key**. The `Authenticator`'s `cksum` is computed over the request's `KDC-REQ-BODY`, so it binds the proof to *this* body — this `sname`, these `kdc-options`, this `till` and `nonce`. What it proves is **possession of the ticket-granting session key**, i.e. that the sender is the party the ticket was issued to and that the body was not rewritten in flight. It does **not** re-prove knowledge of the password: no long-term key is used anywhere in this request.

code

asn1 · 12 lines
asn1
PA-DATA ::= SEQUENCE {
    padata-type  [1] Int32,          -- 1 = PA-TGS-REQ
    padata-value [2] OCTET STRING    -- DER encoding of the AP-REQ below
}

AP-REQ ::= [APPLICATION 14] SEQUENCE {
    pvno          [0] INTEGER (5),
    msg-type      [1] INTEGER (14),
    ap-options    [2] APOptions,
    ticket        [3] Ticket,         -- the ticket-granting ticket
    authenticator [4] EncryptedData   -- under the TGT session key;
}                                     -- its cksum covers KDC-REQ-BODY

go deeper

for a junior

Recall that no password is sent when a client asks for a service ticket; it presents a ticket it already holds. That single fact is most of what a first screen wants here.

for a middle

Explain the nesting: padata-type 1 holds a DER-encoded AP-REQ, which holds the ticket-granting ticket and an Authenticator sealed under that ticket's session key, whose cksum covers the request body.

for a senior

Reason about what the proof does and does not cover, and connect the clock-dependent failures — a skewed ctime or an expired ticket — to the symptom an application actually reports.

for a principal

Treat the ticket-plus-session-key pair as the real long-lived credential in the estate and reason about what containment means when the password is no longer part of any subsequent exchange.

## The ticket-granting service is just another service The cleanest way to remember the shape of a `TGS-REQ` is that it is not a special case. The ticket-granting service is a principal with a long-term key like any other, reserved under the first name component `krbtgt` as `krbtgt/REALM@REALM`. A ticket-granting ticket is simply a service ticket *for that principal*. So when a client spends it, it does what a client does at any service: it sends an `AP-REQ`. The only oddity is where that `AP-REQ` rides — not as a message in its own right, but inside the request's pre-authentication data. ## What is actually in the request A `TGS-REQ` is a `KDC-REQ` with three parts that matter here: 1. **`padata`** — a sequence of `PA-DATA`, of which exactly one is `PA-TGS-REQ`, `padata-type` 1. Its `padata-value` is an `OCTET STRING` holding the DER encoding of an `AP-REQ`. 2. Inside that `AP-REQ`: the **`ticket`** (the ticket-granting ticket, still sealed under the `krbtgt` key and still unreadable to the client) and an **`authenticator`**, an `EncryptedData` sealed under the **ticket-granting session key** the client learned from the reply that issued the ticket. 3. **`KDC-REQ-BODY`** — the actual ask: `kdc-options`, the target service's `realm` and `sname`, `till`, optional `rtime`, a fresh `nonce` and the `etype` list. The `Authenticator` itself carries `crealm`/`cname`, `ctime` and `cusec`, an optional `subkey`, an optional `seq-number`, and a `cksum`. ## The checksum is the load-bearing part In this exchange the `Authenticator`'s `cksum` is computed **over the `KDC-REQ-BODY`**. That is what stops the request from being a detached proof that anyone could staple to a different ask. Without it, an attacker on the path could take a valid `AP-REQ` and replace the body with one naming a different `sname` or a longer `till`, and the ticket-granting service would have no way to tell. Because the checksum covers the body, all of the following are bound together into one statement: - **which service** is being asked for (`sname`, `realm`); - **what is being asked of the grant** (`kdc-options`, `till`, `rtime`); - **which reply matches** (`nonce`). ## What it proves, stated with its limits | claim | true? | why | |---|---|---| | The sender holds the ticket-granting session key | yes | only that key decrypts the `Authenticator` correctly | | This request body is the one the sender authorised | yes | the `cksum` covers `KDC-REQ-BODY` | | The sender knows the principal's password or long-term key | **no** | no long-term key is used in a TGS exchange at all | | The sender is entitled to use the service it is asking for | **no** | the ticket-granting service issues, it does not authorise use | That third row is the one interviewers push on. The long-term key is used once, when the ticket-granting ticket is obtained. After that, the ticket plus its session key *are* the credential, and anything holding both copies can produce a perfectly valid `PA-TGS-REQ`. This is also why the exchange leaves no opportunity to re-check a password: the password is not in the conversation. ## The optional `subkey`, and why it matters here If the `Authenticator` supplies a `subkey`, the ticket-granting service encrypts the reply's `enc-part` **under that subkey** rather than under the ticket-granting session key. Nothing else changes; the service ticket in the reply is still sealed under the target service's long-term key. Candidates who have only read the happy path often assert flatly that `enc-part` always comes back under the ticket-granting session key, which is true only when no `subkey` was offered. ## Clock and freshness The `Authenticator` carries `ctime`/`cusec`, and a ticket-granting service that finds the timestamp outside its accepted skew answers `KRB_AP_ERR_SKEW`. A ticket presented after its `endtime` draws `KRB_AP_ERR_TKT_EXPIRED`. These are the everyday failures of a machine whose clock has drifted: the sign-in worked this morning, and every service lookup since lunchtime fails with an error that never mentions time in the words an application logs.

  • Why does the Authenticator's cksum cover the KDC-REQ-BODY rather than only the client's name?
    So the proof cannot be detached and reused with a different ask. The body holds `sname`, `kdc-options`, `till` and the `nonce`; covering it means a path attacker who alters the requested service or lifetime invalidates the checksum. A proof over the client name alone would authenticate the sender while leaving the request itself unprotected.
  • Which key does the client use to build the Authenticator in a TGS-REQ, and which one does it never touch?
    It uses the ticket-granting session key learned when the ticket-granting ticket was issued. It never touches its own long-term key in this exchange, and it never holds the `krbtgt` key that sealed the ticket or the target service's long-term key that will seal the reply's ticket.
  • What changes in the reply if the Authenticator supplies a subkey?
    The reply's `enc-part` is sealed under that `subkey` instead of under the ticket-granting session key. The service ticket half is unaffected — it is still sealed under the target service principal's long-term key — so only the client-readable half changes.

saying these in an interview costs you the question

  • Says the client re-sends its password to get each service ticket
  • Thinks the client decrypts its ticket-granting ticket to build the request
  • Says the checksum covers only the client's principal name
  • Believes the TGS checks whether the caller may use the service
  • Calls PA-TGS-REQ an encrypted timestamp like the initial pre-authentication