Realms, principals, and the interrealm scaling problem

A realm is defined by two registration requirements

A Kerberos realm is a complete Kerberos environment, and it is defined not by geography or by a domain name but by two facts that must both hold:

1. Every user is registered with the Kerberos server — the server holds the user's ID and a hashed password.
2. Every application server is registered with the Kerberos server, and shares with it a distinct secret key, distributed physically or by some other secure means.

Networks run by different administrative organisations normally form different realms, and the reason is administrative rather than technical: registering every one of your servers with someone else's Kerberos server is impractical, and usually against policy.

A principal is the entity; a realm is the domain it lives in

A principal is a named entity known to Kerberos — a user or a service — identified by its principal name. anwar@CS.EXAMPLE.CA is a principal; so is host/prn1.cs.example.ca@CS.EXAMPLE.CA. The realm is the administrative domain (CS.EXAMPLE.CA); the principal is a thing inside it. A ticket is a credential issued to a principal; a key is the secret that protects it. Four nouns, four different kinds of thing, and the exam separates them by asking you to name one from its definition.

The word "principal" is worth flagging: it is standard Kerberos vocabulary from the protocol specification, but it is not a term the current course textbook introduces. See the callout.

Crossing realms — three requirements and four steps

For a user in realm A to reach a server in realm B, three things must be arranged in advance:

1. The two Kerberos servers must share a secret key and be registered with each other.
2. Each must trust the other to authenticate its own users.
3. The application servers in realm B must be willing to trust realm A's Kerberos server.

Then the request runs in four steps. The client (a) gets a normal TGT from its local AS, (b) uses it at the local TGS to obtain a ticket-granting ticket for the remote TGS, (c) presents that at the remote TGS to obtain a service ticket for the remote server, and (d) presents the service ticket to that server. The ticket that finally arrives names the realm in which the user was originally authenticated, and the remote server decides for itself whether to honour it. That last point matters: trust is not transitive by accident, it is granted deliberately.

Worked example — the arithmetic behind "it does not scale"

The requirement is pairwise: every two realms that want to interoperate need their own shared secret key, arranged out of band. With $N$ realms, that is one key per unordered pair:

$$\text{key exchanges}=\frac{N(N-1)}{2}$$

Two realms need 1. Five realms need $\frac{5\times 4}{2}=10$. Ten realms need 45. Fifty realms — a large university system, or a consortium — need 1,225 secure key exchanges, each of which is a human process with a human failure rate. Double the number of realms and the work roughly quadruples, because the expression is quadratic in $N$ while your administrative staff is not.

That is what "does not scale" means, stated as a number instead of a complaint. It is also the reason PKI exists in the shape it does: a certificate hierarchy replaces $O(N^2)$ pairwise arrangements with $O(N)$ relationships to a common root.

Version 4 to version 5 — three improvements

Version 4 was the first widely deployed Kerberos, from the late 1980s. Version 5 arrived in 1993, was revised in 2005, and is what ships today in Active Directory, most Linux and UNIX systems, and macOS. Three improvements are the examinable ones:

• Encryption algorithm agility. v4 was welded to DES. In v5 every encrypted message is tagged with an algorithm identifier, so the algorithm is a parameter rather than a constant — AES is the default now, and the next replacement will not require a new protocol version.
• Authentication forwarding. v4 does not let credentials issued to one client be forwarded to another host. v5 does, so a print server can fetch the file you asked it to print from the file server, using your credentials, instead of needing its own privileged access to everyone's files.
• Cheaper interrealm authentication. v5 needs fewer secure key exchanges between realms than v4's strictly pairwise arrangement.

A fourth difference is worth knowing because it appears as a distractor: v4 used the PCBC cipher mode, which v5 replaced with standard CBC plus an explicit checksum.