Key distribution centres and the key hierarchy

A KDC relies on a key hierarchy with, at minimum, two levels. Communication between end systems is protected by a session key: a temporary key used for the duration of one logical connection (a transport-layer connection, say) and then discarded. Each session key is obtained from the KDC over the same network facilities used for the actual communication, so it must itself be transmitted encrypted. It is encrypted under a master key, a long-term key shared by the KDC and one end system or user. Master keys are distributed non-cryptographically: physical delivery is the notes’ own example, such as an IT department copying the key onto a laptop during setup, or in practice, deriving the key from a strong password.

A KDC generates and distributes session keys. It is always online, and holds a long-term master key with every member it serves; these are pre-configured by administrators or derived from a strong password in practice. At its simplest: A asks the KDC for a session key to talk to B. The KDC generates one and encrypts it twice, once under the master key it shares with A, once under the master key it shares with B, either sending both to A for A to forward B’s copy on, or sending each party its own copy directly. KDCs are, per the notes, some of the most important technologies in use: even OpenID and OAuth fall into this category, and KDCs are the basis for Kerberos, deployed across Windows, Linux, UNIX, macOS and more.

The notes work through a full scenario. Each user shares a unique master key with the KDC: A holds $K_a$, B holds $K_b$, known only to that user and the KDC. A wants a one-time session key to talk to B.

1. A requests a session key. A sends the KDC a message including the identities of A and B, and a nonce $N_1$, a unique per-transaction identifier, ideally a random number, since it should be hard for an opponent to guess.
2. The KDC replies, encrypted under $K_a$. Only A can read it, and because it decrypts correctly under $K_a$, A knows it came from the KDC. The reply carries the new session key $K_s$ and A’s original request including $N_1$, which lets A both match the reply to its request and confirm the request was not altered or replayed. The same reply also carries a second payload meant for B: $K_s$ and A’s identifier $ID_A$, this time encrypted under $K_b$, the master key the KDC shares with B, so A cannot read it.
3. A forwards B’s payload. A stores its own copy of $K_s$ and passes on the $K_b$-encrypted piece unopened. Because it is protected under $K_b$, B can decrypt it, and doing so tells B three things at once: the session key $K_s$, that the other party is A (from $ID_A$), and that this information really came from the KDC (because only the KDC and B share $K_b$).

At this point the session key has been securely delivered to both sides. Two further steps add something the first three do not:

4. B sends a fresh nonce. Using the new $K_s$, B sends A a nonce $N_2$.
5. A proves it holds $K_s$. A replies using $K_s$ with $f(N_2)$, some agreed transformation of $N_2$, such as incrementing it.

Steps 1–3 alone move the key; steps 4 and 5 are an authentication function layered on top, giving B assurance that the message it received in step 3 is not a replay of an old one, since only whoever actually holds the fresh $K_s$ can produce $f(N_2)$ for this specific $N_2$.