Kerberos tickets, authenticators and replay checks

Ten services that may all need to talk to one another need 45 shared keys. A hundred need 4,950, and a thousand need 499,500. Kerberos avoids that growth by giving each party one key, shared only with a central server, which introduces any two parties who want to talk. Kerberos tickets carry the introduction, and authenticators prove that whoever shows a ticket holds its key right now.

Replay checks decide whether that proof can be trusted, because a service that does not refuse replays accepts a recorded authenticator every time an attacker sends it. This lesson follows the three exchanges, runs a teaching realm that applies the replay, clock and expiry checks, rebuilds the key derivation of RFC 8009 against its vectors, and ends with the encryption types that current guidance retires.

A key distribution centre replaces pairwise keys with one key for each party

If every pair among n parties needs its own secret key, each party holds n - 1 keys and the whole system holds n(n - 1)/2. The Handbook of Applied Cryptography calls this the n² key distribution problem. Its answer for symmetric keys is a trusted server at the centre of a star, the key distribution centrekey distribution centre: A trusted online server that shares one long-term key with every party and introduces any two of them by issuing a session key. In Kerberos it runs the authentication service and the ticket-granting service.: every party shares one long-term key with it, and it hands out a fresh session key whenever two parties want to talk.

Parties	Keys if every pair has one	Keys with a KDC
10	45	10
100	4,950	100
1,000	499,500	1,000

The Handbook names the cost: an online server that must be trusted, an attractive target, a bottleneck, and a single point of failure. Needham-Schroeder with shared keys, the protocol that Kerberos builds on, has the server return a session key sealed for the first party, with a copy inside it sealed for the second. Its weakness is freshness. The second party cannot tell whether the key is fresh, so if a session key is ever stolen, an attacker can resend the old copy and pose as the first party. Kerberos limits this with a lifetime in the ticket, the Handbook says, and uses timestamps where Needham-Schroeder uses nonces.

Kerberos tickets are sealed under the key of the party they are meant for, so a client carries one without being able to read or change it. Authenticators are the second piece: each is a name and a timestamp sealed under the session key, and a fresh one goes with every use of a ticket. The ticket says whom the KDC introduced, and the authenticator says that the sender holds the session key now. The replay checks that make this proof hold up are the rest of the lesson: a cache of recent authenticators, a window around the clock, and an end time on every ticket. Without them a recorded request is simply sent again, and a service cannot tell replays from the real thing.

The AS, TGS and AP exchanges, and the key that protects each message Pro: opens with a Pro, Premium or Ultimate pass

In this part:

• A service checks the ticket and the authenticator in a fixed order
• Pre-authentication keeps the KDC from handing out ciphertext to guess against
• The AES-SHA2 encryption types of RFC 8009, rebuilt and checked against its vectors
• Retire the weak encryption types, and turn them off
• Practise: write the service’s checks
  • The checks a service makes on a ticket and an authenticator
• Interview questions
  • An attacker records a user's Kerberos service ticket from the network. Why can it not be used to log in to the service as that user?
  • After a failure of the time source, users of a Kerberos realm get clock skew errors from several services. A colleague proposes to set the allowed skew to one hour on every client and server. Evaluate the proposal and say what you would do instead.
  • A review finds that several service principals have keys made from passwords that people chose, and that RC4 is still allowed in the realm. Explain the risk, rank the fixes, and describe how to migrate without breaking existing clients.
  • A file service in a Kerberos realm crashes and restarts, and its replay cache lived in memory. Describe the window that this opens, what the service must do after the restart, and how you would design the service so that a restart is not an opening for an attacker.
• Key takeaways

2 diagrams · 3 runnable examples (JavaScript) · 1 exercise with sample tests · 3 interview answers · about 40 minutes

Opening this part with your pass…

This part opens with any MySmartCoPilot pass.

• Pro pass · 1 week · ₹79 · $2.99
• 30 days · ₹179 · $5.99
• 1 year · ₹1,699 · $45

One payment; a pass never renews. The price shown is the total you pay: no fees or charges are added at checkout.

Choose a passI have a licence key

It also opens every other in-depth part in Learn and every Pro tool. Sales are final, except where the law gives you a right to withdraw, for example in the EU and the UK (refund policy).

Terms in this lesson

authenticator

In Kerberos, a short message with the client's name and the current time, sealed under the session key from a ticket. It shows that the sender holds the key now, and a service refuses one that is outside the clock skew or that it has seen.

ciphertext stealing

A way to run CBC mode on data whose length is not a multiple of the block size without padding: the last two ciphertext blocks swap places and the final one is cut short, so the ciphertext is as long as the plaintext.

confounder

A random block put in front of the plaintext before a Kerberos encryption, so that the same plaintext seals to a different ciphertext each time. RFC 8009 uses 16 bytes and the receiver discards them.

key distribution centre

A trusted online server that shares one long-term key with every party and introduces any two of them by issuing a session key. In Kerberos it runs the authentication service and the ticket-granting service.

key usage number

A number that Kerberos assigns to each purpose of a sealed message. The keys of an encryption type are derived from the base key and the usage, so a message sealed for one purpose does not open for another.

pre-authentication

A proof the client gives with its first Kerberos request, such as the current time sealed under its key, so that the KDC does not hand a reply sealed under a password-derived key to just anyone.

ticket

A Kerberos credential sealed under the long-term key of the party it is for. It names the client, holds a session key and has a start and an end time, and it proves nothing without an authenticator made under that session key.

ticket-granting ticket

The ticket that a Kerberos client receives at login. It is sealed under the KDC's own key, so the client cannot read it, and the client presents it with an authenticator to ask for tickets to services.