Summary

  • RFC 1510, published in September 1993, connected Kerberos realms through inter-realm keys and ticket-granting tickets. Its transited field listed intermediate realms as an unordered set; the client and service realms appeared elsewhere in the ticket.
  • A direct, one-hop exchange can therefore have an empty transited field while still crossing between realms. RFC 4120, which replaced RFC 1510 in 2005, made the trust check explicit: the application server must check the path itself or reject a cross-realm ticket lacking the KDC's policy-checked flag.

Analysis

The map starts with two names outside it

A schematic example with invented names: a user registered in ALPHA.EXAMPLE asks for a ticket to a file service in BETA.EXAMPLE. If the two realms share the required inter-realm key and no third realm lies between them, the ticket can carry an empty transited field. Separate ticket fields still identify both endpoints. The empty value records a direct hop with no intermediate realm.

Read transited as a compact record of the intermediate realms. The endpoints sit in separate fields, and a direct hop leaves no middle entry.

RFC 1510 describes a realm as an administrative domain with its own Kerberos service. The realm name is part of a client's principal name, and a receiving service can use it when deciding whether to honor a request. To cross into another realm, the administrators can establish an inter-realm key. They may use a separate key for each direction. The remote realm registers the other realm's ticket-granting service as a principal, and its own ticket-granting service can decrypt the ticket sent from that partner.

One local principal can carry the client into a destination realm: it first obtains a ticket-granting ticket for the remote realm’s ticket-granting service, then presents it to obtain a ticket for the target application. The shared inter-realm key is the cryptographic bridge. Installing and maintaining that bridge is an administrative choice.

The field keeps the middle, with order stripped

The path could involve more than two realms. RFC 1510 says realms were typically organized in hierarchies, with a realm sharing keys with its parent and separate keys with its children. A hierarchy offered a way to assemble a path when the two endpoints had no direct key. The specification also allowed alternate paths that bypassed intermediate realms, including paths chosen to make communication more efficient. In a non-hierarchical arrangement, constructing the route could require another database.

RFC 1510 stores the intermediate realm names as an unordered set and compresses common hierarchical names to keep the field shorter. Sequence is absent by design. The service can read the reported intermediaries, while a chronological audit trail has to come from another record.

The ticket-granting service adds the realm that issued the ticket it received; its own realm remains outside the field. RFC 1510 gives the security reason: a server cannot conceal its own participation merely by leaving its name unwritten. The rule has a stated limit because a malicious server could still omit other realms. The remaining entries still depend on trust in the KDCs that supplied them.

The ticket carries path evidence under the system's key relationships and update rules. The receiving service compares that evidence with its own trust policy. RFC 1510 already placed the decision where the consequence lands: the end service uses the realm information to decide how much faith to place in the authentication.

The server owns the last gate

In July 2005, RFC 4120 replaced RFC 1510 and described the checking job more sharply. The application server remains ultimately responsible for accepting or rejecting the authentication. It should check that the KDCs involved are trusted to authenticate the named principal. The KDC in the destination realm may perform a realm-specific check and set TRANSITED-POLICY-CHECKED on the service ticket when it accepts the cross-realm credentials.

If the KDC did not perform that check, RFC 4120 gives the application server two choices: check the transited realms itself or reject a cross-realm ticket whose policy-checked flag is absent. The standard also warns that even a list containing trusted KDCs is no guarantee by itself; an untrusted KDC may have fabricated the list. A realm name is an input to that evaluation; the receiving service retains policy responsibility.

This division is the real control surface. Realm administrators decide which key relationships exist. KDCs decide whether to issue and mark tickets under local policy. Application services decide which paths they will accept. A new trust edge can shorten the route and reduce operational friction; it can also make more identities acceptable to services downstream. The party that writes a key into a configuration file is choosing a future service-access relationship.

The September 1993 memo said the protocol was under review and was not then being submitted for Internet-standard consideration. RFC 4120 entered the Standards Track in 2005 and stated implementation duties more explicitly. The missing evidence is a 1990s deployment record showing which application servers checked transited; that record would establish whether this control appeared in running systems, while the RFCs document the protocol design.

The useful reading rule is exact: an empty transited field can describe a direct cross-realm hop; a non-empty field is an unordered list of reported intermediaries; and the service's trust policy supplies the verdict. Kerberos carried authentication across borders and left each receiving institution with its own trust decision.

Sources