Ticket-Based Authentication

The previous lesson counted 609 account logins stalling across 13 systems during the central repository’s outage. The source of this dependency is that every system asks the repository on every login and the password crosses the network every time. On enterprise networks, a time-limited proof is produced from a single verification instead, and that proof is presented in place of the password on subsequent accesses. The proof is called a ticket; the open specification of the mechanism that produces it is known by the name Kerberos.

This lesson does not measure how the ticket works, but what the ticket rests on. How many steps the flow takes, which claim is proven at which step, how many key items must be correct at the same time, how many items drop if which key is compromised, and how many rounds renewing that key takes.

The Proof That Replaces the Password

EI5: in ticket-based authentication, the password is used only in the first step; what is presented at every access after that is a time-limited ticket, and the ticket does not carry the password. EI6: whoever can produce a ticket can produce all the claims that ticket carries; this is why the ticket-granting service’s key is the domain’s trust root. EI7: renewing a key does not retroactively invalidate valid proofs produced with that key; the renewal window lasts as long as the longest-lived proof.

EI5 is a two-way gain. The password crossing the network only once, and not directly but with a derived key, makes the password unreachable to anyone listening on the wire. The same design also brings a cost: the proof is now an independent object, it can be copied, and until it expires no one asks whose hand it is in. What needs to be measured is not the ticket’s power, but the scope of the key that produces the ticket and the ticket’s lifetime.

Six Steps, Five Keys

The flow below is a model: in the fictional regional measurement network domain there are 214 user principals and 21 service principals. There is no real domain, real principal, or real key.

// ticket/flow.mjs — the steps of ticket-based authentication and the keys they rest on (model):
// in the fictional regional measurement network domain there are 214 user principals and 21
// service principals. There is no real domain, real principal, or real key. No randomness.

// EI5: in ticket-based authentication the password is used only in the first step; what is presented at every access after that
// is a time-limited ticket. EI6: whoever can produce a ticket can produce all the claims it carries; the ticket-granting service's
// key is therefore the domain's trust root.
export const STEP = `
  1  pre-auth request          I know the password                  user             identity-service
  2  ticket-granting ticket    the center issued this ticket        ticket-service   client
  3  ticket and authenticator  I received this ticket               session-1        ticket-service
  4  service ticket            the center issued this ticket        service-account  client
  5  ticket and authenticator  I received this ticket               session-2        target-service
  6  mutual authentication     the far end really is that service   service-account  client`
  .trim().split("\n").map((r) => {
    const p = r.trim().split(/\s{2,}/);
    return { no: +p[0], message: p[1], claim: p[2], key: p[3], verifier: p[4] };
  });

// Key inventory: count = number of items in the domain, principal = principals dropped directly
// if the key is compromised, service = services dropped, round = how many rounds renewal takes.
export const KEY = {
  "user":            { count: 214, principal: 1,   service: 0,  round: 1, lifeHours: 2160 },
  "service-account": { count: 21,  principal: 214, service: 1,  round: 1, lifeHours: 8760 },
  "session-1":       { count: 214, principal: 1,   service: 0,  round: 0, lifeHours: 10 },
  "session-2":       { count: 21,  principal: 1,   service: 1,  round: 0, lifeHours: 10 },
  "ticket-service":  { count: 1,   principal: 214, service: 21, round: 2, lifeHours: 8760 },
};

export const TICKET_LIFE = 10;      // hours
export const RENEWAL_LIFE = 168;    // hours
export const COPY = 3;
export const PROPAGATION = 4;       // hours for a key change to reach the copies

// ticket/tally.mjs — how many steps the flow takes, which claim is proven at which step, how many
// items drop if which key is compromised, and how many steps renewing the ticket-granting service's key takes.
import { STEP, KEY, TICKET_LIFE, RENEWAL_LIFE, COPY, PROPAGATION } from "./flow.mjs";

const print = (g, ...s) => console.log(s.map((v, i) =>
  (g[i] < 0 ? String(v).padEnd(-g[i]) : String(v).padStart(g[i]))).join(""));
const type = Object.keys(KEY);
const item = type.reduce((a, t) => a + KEY[t].count, 0);

console.log(`${STEP.length} steps, ${type.length} key types, ${item} key items; ` +
  `ticket life ${TICKET_LIFE} hours, renewal window ${RENEWAL_LIFE} hours`);

const A = [-3, -26, -40, 18];
console.log("\n1. claim proven per step and the key it rests on");
print(A, "no", "message", "proven claim", "key it rests on");
for (const a of STEP) print(A, a.no, a.message, a.claim, a.key);

const B = [-16, 7, 10, 10, 9, 6];
console.log("\n2. what drops if a key type is compromised");
print(B, "key", "count", "drop pr", "drop svc", "life hr", "rnd");
for (const t of type) {
  const k = KEY[t];
  print(B, t, k.count, k.principal, k.service, k.lifeHours, k.round);
}
const root = KEY["ticket-service"];
console.log(`single-item drop ratio: principal ${root.principal}/${KEY["user"].count}, ` +
  `service ${root.service}/${KEY["service-account"].count}`);

const C = [-4, -30, 7, 27];
console.log("\n3. renewal plan for the ticket-granting service's key");
const plan = [
  ["first key change", 0, "old tickets still decrypt"],
  ["propagation to replicas", PROPAGATION, `${COPY} replicas`],
  ["end of open tickets", TICKET_LIFE, "new ticket obtained"],
  ["second key change", 0, "old key drops"],
  ["propagation to replicas", PROPAGATION, `${COPY} replicas`],
  ["end of renewal tickets", RENEWAL_LIFE - TICKET_LIFE, "re-login"],
];
print(C, "no", "step", "hour", "result");
let elapsed = 0;
plan.forEach((p, i) => { elapsed += p[1]; print(C, i + 1, p[0], p[1], p[2]); });
console.log(`total window ${elapsed} hours, manually touched items ` +
  `${root.round + KEY["service-account"].count}`);

const D = [-18, 14, 20, 18];
console.log("\n4. legitimate work stalled when renewing a key type");
print(D, "key", "manual items", "principals stopped", "services stopped");
for (const t of type.filter((x) => KEY[x].round > 0)) {
  const k = KEY[t];
  print(D, t, k.count * k.round, k.principal, k.service);
}

6 steps, 5 key types, 471 key items; ticket life 10 hours, renewal window 168 hours

1. claim proven per step and the key it rests on
no message                   proven claim                               key it rests on
1  pre-auth request          I know the password                                   user
2  ticket-granting ticket    the center issued this ticket               ticket-service
3  ticket and authenticator  I received this ticket                           session-1
4  service ticket            the center issued this ticket              service-account
5  ticket and authenticator  I received this ticket                           session-2
6  mutual authentication     the far end really is that service         service-account

2. what drops if a key type is compromised
key               count   drop pr  drop svc  life hr   rnd
user                214         1         0     2160     1
service-account      21       214         1     8760     1
session-1           214         1         0       10     0
session-2            21         1         1       10     0
ticket-service        1       214        21     8760     2
single-item drop ratio: principal 214/214, service 21/21

3. renewal plan for the ticket-granting service's key
no  step                             hour                     result
1   first key change                    0  old tickets still decrypt
2   propagation to replicas             4                 3 replicas
3   end of open tickets                10        new ticket obtained
4   second key change                   0              old key drops
5   propagation to replicas             4                 3 replicas
6   end of renewal tickets            158                   re-login
total window 176 hours, manually touched items 23

4. legitimate work stalled when renewing a key type
key                 manual items  principals stopped  services stopped
user                         214                   1                 0
service-account               21                 214                 1
ticket-service                 2                 214                21

The numbers are of the measurement class; their inputs are EI5–EI7 and the key inventory.

Which Claim Is Proven at Which Step

The first table gives the six steps and the single claim each step proves. Step 1 proves who the party that knows the password is, and this is the only password use in the flow. Steps 2 and 4 carry the same claim — that the ticket came from the center — but rest on different keys: the first on the ticket-granting service’s key, the second on the target service’s account key. Steps 3 and 5 prove that the one presenting the ticket is the party that received it; the proof is a verifier produced with the session key and carrying a timestamp.

The timestamp is this lesson’s counterpart to the clock agreement that stayed outside the chain in the previous lesson. The verifier’s freshness rests only on the clock; when the two sides’ clocks drift apart by more than the accepted window, login stalls even though no account has changed. Beneath one trust root sits another service that has nothing to do with security.

The sixth step is the list’s only reverse-direction proof: the client verifies that the other end really is that service. This step is optional, and the flow keeps working when it is skipped; the one claim left unproven is the identity of the end the client connected to. A working flow can leave an unproven claim, and no error message will say so.

The Chain of One Access

The course’s second column is here fully occupied by all five key types. For a single principal to access a single service, all five of the five types must be correct at the same time: the user key holds the first step, the root key the second, the first session key the third, the service account key the fourth, and the second session key the fifth. Two more items are added alongside these — the clock window and the resolution of the name to a principal.

The second item is not visible at first glance. When a client connects to a service, it requests a ticket via the name it holds; the ticket-granting service resolves that name to a principal and produces the ticket with that principal’s account key. The mapping between name and principal sits in the directory, and its correctness is never tested anywhere within this flow. A wrongly mapped name carries a correctly produced ticket to the wrong service. Of the chain’s seven items, only five are cryptographic; the remaining two are a record and a clock.

The Authorization Inside the Ticket

The ticket carries identity, but not only identity. The target service does not separately ask the directory which groups the principal belongs to; this information is placed inside the ticket and the service accepts it. This way, an access decision can be made without ever touching the directory, and the outage dependency counted in the previous lesson decreases.

The cost of this is that the authorization data is frozen for as long as the ticket lives. When a principal is removed from a group, the ticket in hand keeps stating the old membership for ten more hours; since the service holds no other item to verify the claim against, it cannot see the difference. That authentication and authorization are separate layers was measured in the Introduction to Cybersecurity course; what is seen here is that packing the two layers into the same proof object produces a freshness window. Revoking authorization is ten hours slower than revoking identity.

The Root: One Item, Two Hundred Fourteen Principals

The second table is this lesson’s center. There are 471 key items in the domain, and 428 of them carry a scope limited to a single principal or a single session. If a user key is compromised, the number of principals dropped is one; if a session key is compromised, the item dropped is also one, and it already becomes worthless on its own after ten hours.

The service account key shows the jump: a single item covers all logins made to that service; all 214 principals can be represented with a forged ticket for that service. The ticket-granting service’s key, though, is the end of the boundary — a single item, all 214 of the 214 principals and all 21 of the 21 services. The ratio is whole in both rows.

The reason for this is EI6, and it is the mechanism’s design, not its flaw. A ticket states that the claims it carries are true based on having been produced with the ticket-granting service’s key. Whoever knows that key can produce a valid ticket for any principal to any service, and doing so requires knowing no password at all. Producing such a thing without written authorization and a defined scope is both illegal and unprofessional when done; what is measured here is not how the production is done, but the number of items that drop assuming it is done.

A detail hidden in the table makes this root even more fragile. The root key is not an independent value produced in a privileged hardware unit; it is the key of an account in the domain, and it is derived from that account’s password. That is, the widest-scoped of the 471 items is an item of the same kind as the 214 user keys in the list, and its durability is bounded by the cost curve given by the password’s length and the work factor behind it. That curve was measured in the Cryptography Fundamentals topic and is a direct input here: the root’s scope is the widest, yet the mechanism protecting the root is the same as for user accounts.

The Renewal Window

The third table turns EI7 into a number. Renewing the root key is not a single change. The old key has to be kept around for a while, because tickets in circulation were produced with it; after the first change the old key is still valid. The real renewal is the second change, and it waits first for propagation to complete, then for open tickets to expire.

The window accumulates over six steps: two propagation rounds, eight hours; end of open tickets, ten hours; end of renewal tickets, 158 hours. Total 176 hours. 158 of these hours come from a single setting — the renewal ticket’s seven-day lifetime. What determines the root key’s renewal duration is not the key itself but the lifetime of the longest-lived proof; the window does not shorten without shortening the ticket’s lifetime.

The number of manually touched items is 23: two rounds of the root key plus the review of 21 service account keys. The fourth table gives the counterpart of this. Renewing user keys takes 214 manual items, but each one stops only one principal; renewing the root key takes two manual items and stops all 214 principals at once. The number of manual items and the legitimate work stopped are two inversely related measures, and the renewal plan is made according to the second.

This inverse ratio also explains why renewal gets postponed. Two manual items are a small job; a seven-day-spread outage for 214 principals is an event that stops every team in the organization. Renewing the root key is not a technical operation on its own, it is a planned outage, and it will not be done unless it is planned. The third column — what renewal holds — is therefore not a cost item but the number that determines how often the root is really renewed. An unrenewed root silently validates every ticket produced after the date it was compromised, and the 176 hours written in the table are never spent.

Summary

• In ticket-based authentication, the password is used only in the first step; what is presented in the remaining five steps is a time-limited proof, and the flow proves 6 distinct claims across 6 steps.
• When the sixth step is skipped the flow still works, but the identity of the end the client connected to stays unproven.
• 428 of the domain’s 471 key items are scoped to a single principal or a single session; the scope jump begins at the service account key and completes at the ticket-granting service’s key.
• The root key is a single item, and when compromised, 214 of 214 principals and 21 of 21 services drop; this requires knowing no password.
• Renewing the root key takes two rounds, 23 manual items, and a 176-hour window; 158 of the window’s hours come from the longest-lived proof’s lifetime.

Next Step

This lesson measured a principal accessing a service; for the access to be able to start, the client already had to be connected to the network. On enterprise networks that connection itself is also a decision point: when a cable is plugged in or a device wants to join the wireless network, the network hardware does not verify identity itself, it asks a central authentication service and opens the connection based on the answer. The next lesson measures this in terms of access decisions: how many devices ask a single service, which fallback behavior is chosen when the service is unreachable, and how many paths each of those behaviors opens.