skip to content

A Kerberos TGS-REP carries a service ticket and an enc-part: which key seals each, and which can the client read?

level: middleimportance: must knowfreq 58%

answer

  1. two halves, two different keys
  2. one half is addressed to someone else
  3. the client is a courier, not a reader
  4. the same session key appears twice
  5. long-term key of the named service

basics

~20 s

The ticket is sealed under the target service's long-term key and is opaque to the client; the enc-part beside it is sealed under the ticket-granting session key, so the client reads it to recover the new service session key.

solid answer

~50 s

A `TGS-REP` has two encrypted parts and they are deliberately under different keys. The `ticket` field is sealed under the **long-term key of the service principal named in `sname`/`srealm`**, so only that service can open it; inside sits `EncTicketPart` with `flags`, `key`, `crealm`, `cname`, the times and `authorization-data`. The `enc-part` field is sealed under the **ticket-granting session key** the client already holds from its ticket-granting ticket — or under the `subkey` its `Authenticator` proposed — and carries the *same* session `key`, plus the granted flags, the ticket's times and the `nonce` the client sent. So the client learns the session key and the terms of the grant, but carries the ticket as opaque bytes. That asymmetry is what lets one sign-in reach many services: the client is a courier for a message addressed to someone else.

code

asn1 · 9 lines
asn1
KDC-REP ::= SEQUENCE {
    pvno     [0] INTEGER (5),
    msg-type [1] INTEGER (13),                 -- TGS-REP
    padata   [2] SEQUENCE OF PA-DATA OPTIONAL,
    crealm   [3] Realm,
    cname    [4] PrincipalName,
    ticket   [5] Ticket,        -- sealed: service principal's long-term key
    enc-part [6] EncryptedData  -- sealed: TGT session key, or the subkey
}

go deeper

for a junior

Recall that a service ticket is issued per service and that the client cannot read the ticket it carries. Knowing the reply has a part for the service and a part for the client is enough at this stage.

for a middle

Name both halves and the key on each: ticket under the service principal's long-term key, enc-part under the ticket-granting session key or the proposed subkey, with the same session key in both.

for a senior

Show what the structure buys operationally — a service that verifies offline with no call back to the KDC, and a client that can cache opaque bytes it cannot tamper with — and state the limits the ticket alone does not cover.

for a principal

Frame the asymmetry as the estate-wide property it is: services hold only their own long-term key, so compromise of one service principal exposes tickets for that service and no others.

## What the exchange is doing An artist at a post-production house signs in once in the morning and then touches shared render storage, a render queue and a review service. Each of those is a **separate service principal** that has never seen her password. The `TGS-REQ`/`TGS-REP` pair is the exchange that turns one sign-in into many reaches: holding a ticket-granting ticket, the client asks the ticket-granting service for a ticket to **one named service**, and the reply is built so that the client can use it without being able to read it. A `TGS-REP` is a `KDC-REP`, the same shape as an `AS-REP`, and its two encrypted fields are the whole subject. ## The two halves, side by side | field of `TGS-REP` | sealed under | who can open it | what is inside | |---|---|---|---| | `ticket` (field `[5]`) | the **long-term key of the service principal** named by `sname`/`srealm` | only that service | `EncTicketPart`: `flags`, `key`, `crealm`, `cname`, `transited`, `authtime`, `starttime`, `endtime`, `renew-till`, `caddr`, `authorization-data` | | `enc-part` (field `[6]`) | the **ticket-granting session key**, or the `subkey` the request's `Authenticator` proposed | only the client | the same session `key`, the granted `flags`, `authtime`/`starttime`/`endtime`/`renew-till`, `srealm`, `sname` and the `nonce` the client sent | Both halves carry **the same session key**. That single duplicated value is the mechanism: the ticket delivers the key to the service, the `enc-part` delivers it to the client, and neither party had to talk to the other beforehand. ## Why the client cannot read the ticket, and why that is a feature - The ticket is **not addressed to the client**. It is a message from the ticket-granting service to the service principal, handed over by the only party motivated to deliver it. - Because the client cannot open it, it cannot edit it either. The `flags`, `cname` and times the service will act on are outside the client's reach — the client's copy of those values in `enc-part` is informational, and the service reads its own copy from inside the ticket. - Because the ticket is opaque bytes, the client can cache and re-present it until `endtime` without understanding it at all. The client is not left in the dark, though: everything it legitimately needs to know is mirrored in `enc-part`. A ticket cache utility can show the granted flags and `renew-till` of a ticket whose body it will never decrypt, because those values arrived in the reply's client-readable half. ## What the reply does not prove - **It is not an authorization decision.** The ticket-granting service issues a ticket for any service principal it can resolve; whether the artist may write to the render queue is the service's call, made later from the ticket's `cname` and `authorization-data`. - **It is not, by itself, proof of identity to the service.** Anything that copies the ticket bytes can present them; what separates the rightful holder is possession of the session key, which is demonstrated in the later exchange with the service, not here. - **It says nothing about the service being reachable or even running.** The ticket-granting service never contacts the service principal to issue a ticket for it. ## The corner: a service with no long-term key If the "service" is another user's process — a peer with no long-term key of its own to seal a ticket under — the client sets the `ENC-TKT-IN-SKEY` option and supplies the peer's ticket-granting ticket as an additional ticket. The ticket-granting service then seals the service ticket under **the session key of that supplied ticket** instead of a long-term key. The two-halves structure is unchanged; only the key sealing the first half comes from somewhere else. ## Reading the field names precisely The encryption type used on each half is chosen from the `etype` list the client offered in the request, and which one that is is a separate subject with its own consequences. What is fixed regardless of encryption type is *which key* goes on *which half*: service long-term key on the `ticket`, ticket-granting session key (or `subkey`) on the `enc-part`. Inverting those two is the most common way this question is answered wrongly, and the inverted answer is perfectly grammatical — it just describes a protocol in which the client could mint its own tickets.

  • Which parts of a Kerberos service ticket travel in the clear?
    The `Ticket` structure exposes `tkt-vno`, the service `realm` and `sname` outside the encrypted portion — a passive observer learns which service a client asked for. Everything that matters for the decision (`flags`, the session `key`, `cname`, `authtime`/`endtime`/`renew-till`, `authorization-data`) sits inside `EncTicketPart`, under the service's long-term key.
  • What is the `ENC-TKT-IN-SKEY` option for?
    User-to-user: the peer acting as the "service" has no long-term key the ticket-granting service could seal a ticket under. The client supplies that peer's ticket-granting ticket as an additional ticket and sets `ENC-TKT-IN-SKEY`, and the service ticket comes back sealed under that ticket's session key instead.
  • Why does the reply contain the session key twice rather than once?
    Because the two recipients hold no key in common. The copy inside the ticket reaches the service under its long-term key; the copy in `enc-part` reaches the client under the ticket-granting session key. Duplicating the value is how the ticket-granting service introduces two parties that have never shared a secret.

The ticket-granting service hands the artist a sealed envelope addressed to the render service, plus a note she can read that tells her the word written inside the envelope. She can carry the envelope and quote the word; she cannot open the envelope or change what it says about her.

saying these in an interview costs you the question

  • Says the client decrypts the service ticket to read its flags
  • Says the whole TGS-REP is encrypted under the user's long-term key
  • Claims the service calls the KDC to validate a ticket it receives
  • Thinks a service ticket works at any service the client names
  • Says the client chooses the session key and sends it up