skip to content

What do the initial(9) and pre-authent(10) TicketFlags on a Kerberos ticket assert to a later verifier?

level: seniorimportance: nice to knowfreq 26%

answer

  1. provenance, not strength
  2. who issued it, and what was checked
  3. one survives the ticket-granting service
  4. initial means the AS exchange issued it
  5. pre-authent records verified pre-authentication data

basics

~20 s

initial(9) asserts the ticket came from the AS exchange, issued against the client's long-term key rather than derived from a ticket-granting ticket. pre-authent(10) asserts the KDC verified pre-authentication data before issuing, and it is carried forward onto later tickets while initial(9) is not.

solid answer

~40 s

Both flags live in the `TicketFlags` of the ticket the AS exchange produced, and both are set by the KDC rather than requested by the client. `initial(9)` says this ticket was issued by the authentication service directly against the principal's long-term key, not minted by the ticket-granting service from an existing ticket-granting ticket. `pre-authent(10)` says the KDC verified pre-authentication data — in the common case a `PA-ENC-TIMESTAMP` — before it issued anything. The distinction that matters is inheritance: a ticket the ticket-granting service issues from a ticket-granting ticket has `initial` clear, but carries `pre-authent` forward from that ticket-granting ticket. So a service that insists the requester recently demonstrated its long-term key checks `initial`; a service that only wants to know the original authentication was pre-authenticated checks `pre-authent`.

code

pseudocode · 15 lines
pseudocode
function verify_ticket(ticket, policy):
    part = decrypt(ticket, our_long_term_key)   # only we can open it

    if policy.requires_recent_key_use:
        if not part.flags.initial:
            reject "ticket derived from a ticket-granting ticket"

    if policy.requires_preauthenticated_origin:
        if not part.flags.pre_authent:
            reject "KDC verified no pre-authentication data"

    # note the asymmetry a service ticket shows:
    #   initial      -> clear  (issued by the ticket-granting service)
    #   pre_authent  -> carried forward from the ticket-granting ticket
    return accept

go deeper

for a junior

Recall that a ticket carries flags describing how it was obtained, and that the KDC — not the client — decides what they say.

for a middle

Explain the difference in what each asserts: one is about which exchange issued the ticket, the other about whether the KDC verified pre-authentication data before issuing.

for a senior

Demonstrate the inheritance rule and use it: know why a key-changing service demands initial, and why a service ticket normally shows pre-authent set with initial clear.

for a principal

The design angle is how much a verifier should infer from provenance metadata it did not generate, and whether requiring a fresh authentication is worth the interactive cost it imposes on automated callers.

## Where these flags live and who sets them A Kerberos ticket's `EncTicketPart` opens with a `flags` field of type `TicketFlags`. Some of those bits are things a client asked for in the request's KDC options and the KDC agreed to — `forwardable(1)`, `renewable(8)` and their relatives. Two of them are different: `initial(9)` and `pre-authent(10)` are **assertions the KDC makes about how the ticket came to exist**. A client cannot request them and cannot fake them, because the ticket is sealed under a key the client does not hold. Because the AS exchange is where tickets first come into existence, this leaf is where both flags are set. ## initial(9) `initial(9)` marks a ticket issued by the **authentication service**, in answer to an `AS-REQ`, using the principal's long-term key. Its opposite is a ticket minted by the ticket-granting service on the strength of a ticket-granting ticket the client already held. The practical reading is **recency of key possession**. A ticket-granting ticket may be hours old, and everything derived from it inherits that age. A ticket with `initial` set means the requester demonstrated its long-term key in the exchange that produced this very ticket. That is why a service which changes a principal's key — the classic example — insists on a ticket with `initial` set: it will not let someone who merely holds a stale ticket-granting ticket change the underlying secret. ## pre-authent(10) `pre-authent(10)` marks that the KDC **verified pre-authentication data before issuing**. In a realm using encrypted-timestamp pre-authentication, that means a `PA-ENC-TS-ENC` value decrypted correctly under the principal's long-term key and its `patimestamp` fell inside the allowed skew. It is evidence about the KDC's own checking, not about the requester's environment. It says the KDC did not simply hand a reply to whoever asked for one. ## What is inherited and what is not | Property | `initial(9)` | `pre-authent(10)` | |---|---|---| | Set by | the authentication service | the KDC when it verifies pre-authentication data | | On a ticket-granting ticket from an AS exchange | set | set, where pre-authentication was verified | | On a service ticket from the ticket-granting service | **clear** | **carried forward** from the ticket-granting ticket | | Answers the question | was the long-term key used for *this* ticket? | was the original authentication pre-authenticated? | That asymmetry is the whole point of asking about the pair together. Candidates routinely treat them as two names for the same fact and are then unable to say why a service would ever test one rather than the other. ## Reading them in practice A verifier's decision tends to fall into one of three shapes: - **Accept anything the KDC issued.** Neither flag is consulted; the seal is the whole check. - **Require `pre-authent`.** The service wants assurance the realm's pre-authentication policy was applied to the original authentication, whether or not that was in this exchange. - **Require `initial`.** The service wants the long-term key demonstrated in the exchange that produced the ticket it is holding, which is a much narrower claim and forces a fresh AS exchange. ## What they do not assert Being precise here matters more than the definitions: - Neither flag asserts that a **human** did anything. Both are satisfied by a process holding a key on disk. - `pre-authent(10)` does not name **which** pre-authentication method was used. It records that the KDC verified one it accepts. - `initial(9)` does not mean 'the first ticket this principal ever received'; a principal that authenticates ten times a day gets ten tickets with `initial` set. - Neither flag says anything about the strength of the key or how recently it was changed. The honest summary is that both are statements about **provenance inside the KDC**, readable only by whoever can open the ticket, and useful exactly to the extent that a verifier has a reason to care how the credential in its hand was obtained.

  • Why would a key-changing service refuse a ticket without initial(9) set?
    Because a ticket-granting ticket obtained hours ago, or copied from a host, is enough to mint ordinary service tickets, and changing a principal's long-term key is not an ordinary operation. Requiring `initial` forces a fresh AS exchange, so the requester must demonstrate the current long-term key at that moment.
  • A service ticket arrives with pre-authent(10) set but initial(9) clear. Is that consistent?
    Yes, and it is the normal case. The ticket-granting service issued it from a ticket-granting ticket, so `initial` is clear, while `pre-authent` is carried forward from that ticket-granting ticket to record that the original authentication was pre-authenticated.

saying these in an interview costs you the question

  • Says initial(9) means the first ticket the principal ever received.
  • Claims a service ticket carries initial(9) forward from the ticket-granting ticket.
  • Thinks the client sets these flags in its request.
  • Treats pre-authent(10) as proof a human authenticated.
  • Says the two flags always appear and disappear together.