In Kerberos, how does a researcher whose principal exists only in a partner realm get a service ticket in the archive's realm?

## The problem: a name the archive's KDC cannot resolve A meteorological office runs its archive in realm `MET.EXAMPLE`. Researchers at a partner institute live in `INSTITUTE.EXAMPLE` and have no principal in the office's database at all. To the archive's key distribution centre, `[email protected]` is not a bad credential — it is a name it cannot resolve and holds no long-term key for. Nothing the researcher can present would help, because the office's KDC has no key with which to check it. Cross-realm authentication solves that without provisioning anybody. The realms share one key. ## What the trust is actually made of Two realms establish a **inter-realm key** and register it as a principal whose name states the direction it serves. For principals of `INSTITUTE.EXAMPLE` reaching services in `MET.EXAMPLE`, that principal is: `krbtgt/[email protected]` Read it as any other service principal: the *service* named is the ticket-granting service of `MET.EXAMPLE`, and the *realm* it is registered in is `INSTITUTE.EXAMPLE`. Both KDCs hold the key. That is the entire trust: one shared key, in one direction. - **Direction matters.** The reverse relationship — office principals reaching the institute's services — is a second principal, `krbtgt/[email protected]`, with its own key. Establishing one does not establish the other, which is why a partnership that "works one way" is a normal, diagnosable state rather than a bug. - **No replication happens.** Neither database learns the other's principals or keys. The archive's KDC never holds anything belonging to a researcher. ## The two hops 1. The client, holding an ordinary ticket-granting ticket for `krbtgt/[email protected]`, sends a `TGS-REQ` to its **home** ticket-granting service asking for `krbtgt/MET.EXAMPLE`. The `TGS-REP` returns a **cross-realm ticket-granting ticket** sealed under the shared inter-realm key. 2. The client sends a `TGS-REQ` to **`MET.EXAMPLE`'s** ticket-granting service, presenting that cross-realm ticket. That KDC opens it with the shared key — which is exactly what convinces it the other realm vouched for this client — and returns a service ticket for `archive/[email protected]`, sealed under the archive service's own long-term key. The researcher then runs an `AP-REQ` against the archive server as any local user would. The archive server opens the ticket with its own key, reads `crealm = INSTITUTE.EXAMPLE` and `cname = mkeita` from the sealed `EncTicketPart`, and never contacts the institute at all. ## Chains, and the transited field Where no direct key exists between two realms, the path can run through intermediate realms along a realm-name hierarchy, each hop issuing the next cross-realm ticket-granting ticket. Every realm crossed is recorded in the ticket's **`transited`** field, encoded as a `TransitedEncoding` with a registered `tr-type` and its `contents`. That field exists because a chain is only as trustworthy as its weakest hop: an intermediate realm could have put any client name into the ticket it passed on. So the list is not decoration — it is the evidence a policy decision is made against: - A KDC may check the transited path against policy when it issues, and record that it did so in the ticket's flags. - Where that has not been done, the end service should apply the check itself before trusting the name inside. - Either way, "the name is authenticated" means "authenticated by this path", and the path is part of the claim. ## What crossing a realm does not grant | the ticket proves | the ticket does not decide | |---|---| | the client is `[email protected]` | what that researcher may download | | a realm the archive trusts vouched for the name | that the name maps to any local identity | | the KDC of `MET.EXAMPLE` issued this service ticket | that the partnership works in the other direction | Authorization stays local to the archive. A cross-realm ticket hands the service a **foreign, authenticated name**; deciding what that name may read is the service's own problem, and it is the step most often skipped when a trust is first turned on and everything suddenly "works".