Why is a Kerberos realm's ticket-granting service itself a principal named krbtgt/REALM@REALM, and what does that make a ticket-granting ticket?
answer
- the second half is a service too
- a ticket-granting ticket is a service ticket
- reserved first name component
- one key validates every TGT in the realm
- key version numbers make changes gradual
basics
~20 sThe ticket-granting service is registered as an ordinary principal with its own long-term key, so a ticket-granting ticket is simply a service ticket whose sname is krbtgt. That one key validates every ticket-granting ticket in the realm, which makes it the realm's root of trust.
solid answer
~50 sKerberos gets its uniformity by treating the ticket-granting service as just another service. It is registered in the realm's database as `krbtgt/REALM@REALM`, holds a long-term key like any service principal, and `krbtgt` is a reserved first name component that nothing else may use. A **ticket-granting ticket** is therefore not a special object at all: it is a service ticket whose `sname` is that principal, sealed under that principal's key — which is why the client cannot read it and why the authentication service and the ticket-granting service can use one ticket format. Two consequences follow. Every ticket-granting ticket in the realm validates under that single key, so its secrecy is the realm's root of trust. And because a principal can hold more than one key version, a change to it takes effect gradually rather than at once.
code
asn1 · 22 linesTicket ::= [APPLICATION 1] SEQUENCE {
tkt-vno [0] INTEGER (5),
realm [1] Realm,
sname [2] PrincipalName,
enc-part [3] EncryptedData -- EncTicketPart
}
-- a ticket-granting ticket in the archive's realm:
-- realm = MET.EXAMPLE
-- sname = krbtgt/MET.EXAMPLE
-- enc-part = sealed under the long-term key of krbtgt/[email protected]
-- a service ticket for the archive:
-- realm = MET.EXAMPLE
-- sname = archive/store1.met.example
-- enc-part = sealed under that service principal's long-term key
EncryptedData ::= SEQUENCE {
etype [0] Int32,
kvno [1] UInt32 OPTIONAL, -- which key version sealed it
cipher [2] OCTET STRING
}go deeper
The thing to hold on to is that the ticket-granting service has a name and a key of its own, like any other service, and that the ticket you get at sign-in is addressed to it.
Explain the uniformity: one ticket format, one sealing rule, and a ticket-granting ticket that is a service ticket for krbtgt/REALM@REALM. Name which party can open each of the two ticket kinds.
Show you know the key is versioned, so a change is gradual rather than a cliff, and be able to say what the realm loses if that one key's secrecy fails — without drifting into the attack sequences themselves.
The judgment call is concentration: the estate gains one place to manage authentication and accepts one key whose exposure is realm-wide. Argue where that key's custody, versioning and rotation cadence should sit.
## The ticket-granting service is a service The tidiest thing about Kerberos V5 is how little special-casing it needs. The **key distribution centre (KDC)** has two halves — the **authentication service**, which answers `AS-REQ`, and the **ticket-granting service**, which answers `TGS-REQ` — but the second half is not a privileged mechanism bolted on beside the first. It is a **principal** in the realm's database, named `krbtgt/REALM@REALM`, with a long-term key exactly like the meteorological office's `archive/[email protected]`. The first name component `krbtgt` is **reserved**: no ordinary service may be registered under a name whose first component is `krbtgt`, which is what stops the ticket-granting service's name being squatted. Its principal name is conventionally of name type **NT-SRV-INST (2)**, the type the specification describes as a service with a unique instance. ## What that makes a ticket-granting ticket If the ticket-granting service is a service, then the credential you hold for it is a **service ticket for that service**. That is all a ticket-granting ticket is. Read the `Ticket` structure and nothing marks it out: the same `realm` and `sname` fields naming the server, the same `enc-part` sealed under that server's long-term key. So the AS exchange is better described as "the exchange that issues your first service ticket, for the ticket-granting service, using your password-derived key", and the TGS exchange as "the exchange that issues every later service ticket, using that first one instead of your password". | | which principal's key seals it | who can open it | where it is spent | |---|---|---|---| | ticket-granting ticket | `krbtgt/REALM@REALM` | the KDC only | the ticket-granting service | | archive service ticket | `archive/[email protected]` | that archive server only | the archive server, in an `AP-REQ` | | cross-realm ticket-granting ticket | the inter-realm key, held as `krbtgt/B@A` | the two realms' KDCs | the other realm's ticket-granting service | ## Why that single key is the realm's root of trust Every ticket-granting ticket issued in the realm is sealed under one key. When the ticket-granting service is handed a ticket-granting ticket, its entire check reduces to: *does this open under the `krbtgt` key, and is what comes out well-formed and unexpired?* There is no per-ticket record on the KDC's side to compare against — the seal **is** the record. That gives the key an unusual property. The blast radius of an ordinary service principal's key is that one service; the blast radius of the `krbtgt` key is the realm's whole authentication fabric, because anything able to produce a structure that opens under it is indistinguishable, to the realm's own ticket-granting service, from a ticket the KDC issued. The concrete sequences an attacker uses to exploit that are a separate subject; what belongs to the architecture is the observation that the realm's trust bottoms out in exactly one key, and in the KDC database that holds it. ## Changing that key is not instantaneous A principal's key is versioned. Sealed parts carry a **key version number** (`kvno`), and a KDC ordinarily retains the previous version so that material sealed under it can still be opened. Two things follow that regularly surprise people: - Changing the `krbtgt` key does **not** immediately invalidate outstanding ticket-granting tickets; they keep validating while the previous version is retained, and stop when it is discarded or when they expire on their own. - Rotating it while a previous version is still live means both versions are honoured at once, which is deliberate — an abrupt change would reject every ticket-granting ticket held across the realm and force every user to re-authenticate at the same moment. The operational procedure for eradicating a compromise is a different subject; the protocol fact is the key version mechanism and its gradualness. ## Three things this does not mean 1. **It is not a user.** `krbtgt/REALM@REALM` names a service, has no human behind it, and is never used to sign in. 2. **It does not seal service tickets.** Only ticket-granting tickets are sealed under it; a ticket for the archive is sealed under the archive service's own key, which is why the archive server can open its own tickets and nothing else. 3. **It is not where the client's key lives.** The client's long-term key is a separate entry in the same database; the two are used in the same reply but they are not related.
- What distinguishes the key that seals a ticket-granting ticket from the key that seals a service ticket?Only scope. Both are long-term keys of registered service principals, used the same way. The difference is who holds them: the `krbtgt` key is held by the KDC alone and covers the whole realm, while a service's key is held by that one service and covers only tickets addressed to it.
- Does it matter that a client can never read its own ticket-granting ticket?It matters that it cannot alter it — the client cannot extend the end time, add flags or change the name inside. The client does not need to read it either: everything it must know, including the session key and the ticket's times, arrives in the separately sealed part of the reply.
saying these in an interview costs you the question
- Says any service can be registered with krbtgt as its first name component.
- Believes the client decrypts its own ticket-granting ticket to read its flags.
- Thinks service tickets are also sealed under the realm's krbtgt key.
- Claims the ticket-granting service asks the authentication service to vouch for a ticket.
- Assumes changing the krbtgt key leaves every issued ticket-granting ticket working forever.