In Kerberos, what does one sign-in at the KDC give a user, and why does a file archive server never see the password?
answer
- sign in once, reach many servers
- two things come back, sealed differently
- the client cannot read its own ticket
- each service opens tickets with its own key
- realm bounds which names the KDC knows
basics
~20 sOne sign-in returns a ticket-granting ticket plus a session key. The user spends that ticket at the ticket-granting service for a short-lived service ticket, and the archive server validates that ticket with its own long-term key — the password itself never reaches it.
solid answer
~40 sSigning in runs the AS exchange against the key distribution centre's authentication service, which listens on port 88 over UDP and TCP. The `AS-REP` carries two differently sealed things: a **ticket-granting ticket** sealed under the long-term key of the realm's `krbtgt/REALM@REALM` principal, which the client cannot open, and a **session key** in the reply's `enc-part` sealed under the user's own long-term key, which only the password-holder can recover. For each archive server the client then runs a `TGS-REQ`/`TGS-REP` against the ticket-granting service and gets a **service ticket** sealed under that server's long-term key. The archive server opens it with its own key. It holds no verifier for the user, so it could not check a password even if one were offered.
code
pseudocode · 21 linesat sign-in (AS exchange):
client -> KDC authentication service : AS-REQ
cname = mkeita
crealm = MET.EXAMPLE
KDC -> client : AS-REP
ticket = ticket-granting ticket for krbtgt/[email protected],
sealed under that principal's long-term key
enc-part = session key, sealed under the client's long-term key
later, once per service (TGS exchange):
client -> KDC ticket-granting service : TGS-REQ
presents the ticket-granting ticket
sname = archive/store1.met.example
KDC -> client : TGS-REP
ticket = service ticket, sealed under the archive service's long-term key
at the archive server (AP exchange):
open the service ticket with the archive service's own long-term key
read cname and crealm from inside it
check the caller holds the matching session key
note: no password appears anywhere in this sequencego deeper
Recall the two steps and the two tickets: sign in once for a ticket-granting ticket, then get one service ticket per server. The key point to be able to say out loud is that the server checks a ticket, not a password.
Explain which key seals which thing — the ticket-granting ticket under the krbtgt principal's key, the session key under the user's own — and why that pairing is what proves the holder is the right party.
Be ready for the operational edges: an expired ticket-granting ticket versus an expired service ticket, what still works when the KDC is unreachable, and the fact that an authenticated name is not an authorization decision.
The angle worth arguing is what this architecture concentrates: one realm-wide key distribution centre removes per-server password stores, and in exchange makes one component's availability and one key's secrecy an estate-level concern.
## The problem the ticket-granting service replaces A meteorological office publishes model output across several archive servers. Without a network authentication protocol, each of those servers has to satisfy itself that a caller is who they claim to be, and each ends up doing it the same bad way: holding a password verifier of its own, prompting for the password again, or trusting a network address. The password then exists in as many places as there are servers, and every one of them is somewhere it can leak. Kerberos V5 replaces that arrangement with a **key distribution centre (KDC)**: one trusted third party that already shares a long-term key with every **principal** in the **realm** — every user and every service. The KDC listens on **port 88**, over both UDP and TCP. ## What one sign-in actually returns Signing in is the **AS exchange**: the client sends an `AS-REQ` to the KDC's **authentication service** and receives an `AS-REP`. The reply carries two things, and the whole design lives in the fact that they are sealed under *different* keys: - a **ticket-granting ticket (TGT)** — an opaque structure sealed under the long-term key of `krbtgt/REALM@REALM`, the realm's ticket-granting service principal. The user's machine holds it and cannot read it. - a **session key**, returned in the reply's `enc-part`, sealed under the **user's own long-term key**. That key is derived from the password by **string-to-key**, so only someone who knows the password can recover it. The client therefore ends up holding a ticket it cannot open and a key it can. Possession of the session key is what later proves the ticket is being used by the party it was issued to. ## What happens at each archive server 1. The client sends a `TGS-REQ` to the KDC's **ticket-granting service**, presenting the ticket-granting ticket and naming the service it wants — `archive/[email protected]`. 2. The `TGS-REP` returns a **service ticket** sealed under **that service's** long-term key, together with a fresh session key shared between the client and that service. 3. The client presents the service ticket to the archive server in an `AP-REQ`. The server opens it with its own long-term key — provisioned to it in advance as a principal of the realm — and reads the client name inside. | | ticket-granting ticket | service ticket | |---|---|---| | sealed under | the `krbtgt/REALM@REALM` long-term key | the target service's long-term key | | obtained from | the authentication service, in `AS-REP` | the ticket-granting service, in `TGS-REP` | | spent at | the ticket-granting service | the application service, in an `AP-REQ` | | readable by the client | no | no | Validating the presented ticket needs no call to the KDC: the archive server already has the only key that opens it. It also has no verifier for the user, so it cannot check a password — its question is narrower and better: *does this ticket open under my key, and does the name sealed inside it match the caller in front of me?* ## What the realm bounds A **realm** is the namespace the KDC can name and the set of long-term keys it holds. Written by convention in upper case, it appears as the part after `@` in the string forms `user@REALM` and `service/host@REALM`. Two consequences follow immediately: - A principal in a different realm is not a bad password to this KDC; it is a name this KDC cannot resolve at all. - Reaching a service in another realm is therefore a naming problem before it is a credential problem, and it is solved by a key shared between the two realms rather than by copying accounts. ## What this does not do - It does not say what the user may **read**. Authorization stays with the archive service; a valid ticket is an authenticated name, not a permission. - It does not encrypt the model-output bytes by itself. The session key is available to the application for integrity or confidentiality, but only if the application asks for it. - It does not last forever. A ticket-granting ticket has an end time and, if it is renewable, a `renew-till`; when it is spent after expiry the ticket-granting service answers `KRB_AP_ERR_TKT_EXPIRED` and the AS exchange runs again. - It does not survive an unreachable KDC. Tickets already held keep working at their services until they expire, but no new service ticket can be obtained.
- Why is the session key sealed under the user's long-term key rather than sent in the clear?Because that is what binds the ticket to the person. The ticket-granting ticket is public in effect — anyone who intercepts it holds the bytes — but it is unusable without the session key beside it, and only a party that can derive the user's long-term key from the password recovers that session key.
- What has to be provisioned on the archive server in advance?One thing: the long-term key of its own service principal, shared with the realm's KDC when the principal is registered. It holds no per-user state, no password verifiers and no list of who may sign in — those live in the KDC's database, and the server learns a user's name only from the ticket it opens.
- What happens when a user's ticket-granting ticket expires in the middle of a working session?Service tickets already issued keep working until their own end times. A new `TGS-REQ` presenting the expired ticket-granting ticket is refused with `KRB_AP_ERR_TKT_EXPIRED`. If the ticket was issued renewable and its `renew-till` has not passed, it can be renewed; otherwise the AS exchange runs again and the user re-authenticates.
It is the difference between every door telephoning the personnel office and the gate handing you a dated slip that each door checks against its own seal. The door learns the slip is genuine without ever learning how you identified yourself at the gate.
saying these in an interview costs you the question
- Says the archive server checks the user's password with the KDC on each request.
- Believes the client can open and read its own ticket-granting ticket.
- Thinks one ticket-granting ticket is presented directly to every application service.
- Claims Kerberos encrypts the files an application returns by itself.
- Assumes the KDC stores plaintext passwords so it can compare them.