Why is a renewable Kerberos service ticket with a distant renew-till not an immortal ticket?

seniorshould knowfreq 34%

answer

two deadlines, not one
the window slides, the wall does not
renewal is a round trip
endtime moves, renew-till is copied
each renewal is a checkpoint, not a recall

basics

~20 s

Because renewal is a fresh TGS exchange the KDC must agree to. Each renewal moves endtime forward but copies renew-till unchanged, so renew-till is a hard ceiling, and every renewal is a checkpoint the KDC can refuse.

solid answer

~50 s

A renewable ticket carries two deadlines. endtime is when this copy stops being accepted; renew-till is the absolute wall past which no copy will ever be issued. Renewal is not automatic and not local: the client sends a TGS-REQ with the renew option, presenting the ticket to be renewed, and the ticket-granting service issues a replacement whose endtime is the earlier of now plus the maximum ticket life and the original renew-till — while copying renew-till unchanged. So the window slides but the wall does not move, and the ticket dies at renew-till regardless of how many renewals happened. The second half of the answer is the operationally interesting one: because each renewal is a round trip to the KDC, it is a recurring point at which a principal that has been disabled stops being renewed.

A renewable ticket carries **two** deadlines. `endtime` is when this copy stops being accepted; `renew-till` is the absolute wall past which no copy will ever be issued. Renewal is not automatic and not local: the client sends a `TGS-REQ` with the `renew` option, presenting the ticket to be renewed, and the ticket-granting service issues a replacement whose `endtime` is the earlier of *now plus the maximum ticket life* and the original `renew-till` — while **copying `renew-till` unchanged**. So the window slides but the wall does not move, and the ticket dies at `renew-till` regardless of how many renewals happened. The second half of the answer is the operationally interesting one: because each renewal is a round trip to the KDC, it is a recurring point at which a principal that has been disabled stops being renewed.

code

pseudocode · 14 lines

pseudocode

on TGS-REQ where kdc-options contains renew:
    old <- ticket presented in the PA-TGS-REQ

    if not old.flags contains renewable      -> reject
    if now > old.renew-till                  -> reject
    if principal no longer permitted         -> reject
    // note: old.endtime may already have passed; that is allowed

    new.starttime  <- now
    new.endtime    <- minimum(now + max_ticket_life, old.renew-till)
    new.renew-till <- old.renew-till          // copied, never extended
    new.authtime   <- old.authtime            // original authentication time

    return TGS-REP carrying new

go deeper

for a junior

Recall that a renewable ticket has two deadlines: one for the copy in hand and one for the whole chain. Renewing asks the KDC for a fresh copy.

for a middle

Explain that endtime moves on renewal while renew-till is copied, and that the new endtime is the earlier of the maximum ticket life and that unchanged ceiling.

for a senior

Diagnose both failure shapes — a job that never renews and dies mid-window, and one that renews correctly and dies at the wall — and state plainly that renewal is a checkpoint, not a recall of tickets already issued.

for a principal

Weigh the ceiling against the estate: a short maximum life limits the value of a stolen ticket but makes renewal machinery load-bearing, and an outage then becomes an authentication outage for everything long-running.

Two deadlines, not one

A renewable ticket's EncTicketPart carries authtime, an optional starttime, endtime and an optional renew-till. Only the last two matter for this question:

field	meaning	moves on renewal?
`endtime`	when this ticket stops being accepted	yes — a replacement is issued with a later one
`renew-till`	the absolute latest `endtime` any replacement may carry	no — it is copied unchanged
`authtime`	when the client originally authenticated	no — provenance, carried forward

The common wrong model is a single sliding expiry that the client keeps pushing outward. The protocol deliberately gives two: a short one that limits how long a stolen copy is useful, and a long one that limits how far the whole chain can run from the original authentication.

Renewal is an exchange, not a local operation

Renewal happens through the same machinery as everything else on this leaf: a TGS-REQ with the renew option set in kdc-options, presenting the renewable ticket. The ticket-granting service then decides:

Does the presented ticket carry renewable(8)? If not, refuse.
Is now still before its renew-till? If not, refuse — and note that the ticket may be past its endtime and still renewable, which is the point of the two deadlines.
Is the principal still in good standing under current policy? This is where a disabled principal is caught.
Issue a replacement with starttime around now, endtime = min(now + maximum ticket life, renew-till), and renew-till copied verbatim.

Step 4 is the whole answer to the question. No renewal can produce a ticket that outlives renew-till, and the last renewal before the wall produces a ticket whose endtime is the wall.

What this buys, and what it does not

What it buys:

A recurring checkpoint. A long-lived workload holding an eight-hour ticket presents itself to the KDC repeatedly instead of once. Between renewals, policy can change and the next renewal reflects it.
A short useful life for a stolen copy. Copying a ticket out of a cache yields something that expires at the current endtime, not at renew-till, unless the thief also renews it — which requires the session key and a reachable KDC, and leaves a request behind.
Survival across a KDC outage shorter than endtime. Work in flight does not stop the moment the KDC does.

What it does not buy:

Recall. Renewal is a checkpoint, not revocation. Disabling a principal does not shorten a ticket already issued; that ticket keeps working at services until its endtime, because a service validates it offline with its own long-term key and asks nobody.
Indefinite life. At renew-till the chain ends and a fresh authentication is required.
Anything automatic. If nothing in the workload renews, the ticket simply expires at endtime with plenty of renew-till left.

The failure this produces in practice

An overnight render is submitted at 18:00 and needs storage access until 06:00. The ticket is renewable with renew-till twelve hours out, and the operator reads that as "good until morning". Maximum ticket life is four hours and nothing in the job renews. At 22:00 every write fails, and the ticket is still renewable — nobody asked. The symptom is indistinguishable from an outage, and the evidence is a ticket whose endtime passed hours before its renew-till.

The mirror-image failure is a job that renews correctly and dies at exactly renew-till anyway, with an operator convinced something changed. Nothing changed: the wall was always there, copied into every replacement from the first ticket onwards.

Reading the two values together

The honest one-sentence model: endtime is how long this copy lives; renew-till is how long the original authentication is allowed to echo. A ticket with a distant renew-till is not a durable credential — it is a credential that may be re-issued until that moment, by a party that gets to say no each time.

## Two deadlines, not one A renewable ticket's `EncTicketPart` carries `authtime`, an optional `starttime`, `endtime` and an optional `renew-till`. Only the last two matter for this question: | field | meaning | moves on renewal? | |---|---|---| | `endtime` | when **this** ticket stops being accepted | yes — a replacement is issued with a later one | | `renew-till` | the absolute latest `endtime` any replacement may carry | **no** — it is copied unchanged | | `authtime` | when the client originally authenticated | no — provenance, carried forward | The common wrong model is a single sliding expiry that the client keeps pushing outward. The protocol deliberately gives two: a short one that limits how long a stolen copy is useful, and a long one that limits how far the whole chain can run from the original authentication. ## Renewal is an exchange, not a local operation Renewal happens through the same machinery as everything else on this leaf: a `TGS-REQ` with the `renew` option set in `kdc-options`, presenting the renewable ticket. The ticket-granting service then decides: 1. Does the presented ticket carry `renewable(8)`? If not, refuse. 2. Is `now` still before its `renew-till`? If not, refuse — and note that the ticket may be **past its `endtime`** and still renewable, which is the point of the two deadlines. 3. Is the principal still in good standing under current policy? This is where a disabled principal is caught. 4. Issue a replacement with `starttime` around now, `endtime` = min(now + maximum ticket life, `renew-till`), and `renew-till` copied verbatim. Step 4 is the whole answer to the question. No renewal can produce a ticket that outlives `renew-till`, and the last renewal before the wall produces a ticket whose `endtime` *is* the wall. ## What this buys, and what it does not **What it buys:** - **A recurring checkpoint.** A long-lived workload holding an eight-hour ticket presents itself to the KDC repeatedly instead of once. Between renewals, policy can change and the next renewal reflects it. - **A short useful life for a stolen copy.** Copying a ticket out of a cache yields something that expires at the *current* `endtime`, not at `renew-till`, unless the thief also renews it — which requires the session key and a reachable KDC, and leaves a request behind. - **Survival across a KDC outage shorter than `endtime`.** Work in flight does not stop the moment the KDC does. **What it does not buy:** - **Recall.** Renewal is a checkpoint, not revocation. Disabling a principal does not shorten a ticket already issued; that ticket keeps working at services until its `endtime`, because a service validates it offline with its own long-term key and asks nobody. - **Indefinite life.** At `renew-till` the chain ends and a fresh authentication is required. - **Anything automatic.** If nothing in the workload renews, the ticket simply expires at `endtime` with plenty of `renew-till` left. ## The failure this produces in practice An overnight render is submitted at 18:00 and needs storage access until 06:00. The ticket is renewable with `renew-till` twelve hours out, and the operator reads that as "good until morning". Maximum ticket life is four hours and nothing in the job renews. At 22:00 every write fails, and the ticket is still renewable — nobody asked. The symptom is indistinguishable from an outage, and the evidence is a ticket whose `endtime` passed hours before its `renew-till`. The mirror-image failure is a job that renews correctly and dies at exactly `renew-till` anyway, with an operator convinced something changed. Nothing changed: the wall was always there, copied into every replacement from the first ticket onwards. ## Reading the two values together The honest one-sentence model: **`endtime` is how long this copy lives; `renew-till` is how long the original authentication is allowed to echo.** A ticket with a distant `renew-till` is not a durable credential — it is a credential that may be *re-issued* until that moment, by a party that gets to say no each time.

Can a ticket whose endtime has already passed still be renewed?
Yes, provided it carries `renewable(8)` and `now` is still before `renew-till`. That is precisely why there are two deadlines: an expired-but-renewable ticket is the normal state of a workload that renews on a schedule slower than its ticket life, and the KDC will replace it.
If a principal is disabled, how long can its already-issued service ticket keep working?
Until that ticket's `endtime`. A service validates the ticket offline with its own long-term key and contacts no KDC, so nothing about the disablement reaches it. Renewal is the point at which the KDC refuses — it stops the *next* ticket, not the current one.
What is the difference between authtime and starttime on a renewed ticket?
`authtime` is carried forward from the original authentication and does not move, so it records how old the underlying sign-in is. `starttime` is set around the moment of the renewal. A service that cares how recently the human authenticated must read `authtime`, not `starttime`.

saying these in an interview costs you the question

Thinks renew-till slides forward on each renewal
Says renewal happens locally without contacting the KDC
Believes a ticket past its endtime can never be renewed
Treats renewal as revocation of the previous ticket
Assumes a distant renew-till means the ticket stays valid unattended

Why is a renewable Kerberos service ticket with a distant renew-till not an immortal ticket?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~3 min

Two deadlines, not one

Renewal is an exchange, not a local operation

What this buys, and what it does not

The failure this produces in practice

Reading the two values together

▾common follow-ups3 questions

▾red flags5 flags

Two deadlines, not one

Renewal is an exchange, not a local operation

What this buys, and what it does not

The failure this produces in practice

Reading the two values together

answer

go deeper