In Kerberos, which exchange does AS-REP roasting draw on, which does Kerberoasting use, and what does each reply seal?

seniormust knowfreq 52%

answer

two roasts, two different exchanges
one needs nothing, one needs a TGT
the missing padata on one side
ticket enc-part, not reply enc-part
sealed under a password-derived long-term key

basics

~20 s

AS-REP roasting takes the AS-REP enc-part of a principal that does not require Kerberos pre-authentication, sealed under that client's long-term key. Kerberoasting takes the TGS-REP ticket's enc-part, sealed under the named service principal's long-term key.

solid answer

~40 s

Two different exchanges, and two different sealed parts. AS-REP roasting rides the AS exchange: if a principal is not required to send pa-enc-timestamp (padata-type 2), the KDC answers a bare AS-REQ with an AS-REP whose own enc-part is sealed under that client's long-term key — handed to an unauthenticated requester who only had to guess a principal name. Kerberoasting rides the TGS exchange: any holder of a ticket-granting ticket sends an ordinary TGS-REQ naming a service in sname, and the TGS-REP carries a ticket whose enc-part is sealed under that service principal's long-term key. The reply's own enc-part is not the prize — it is sealed under the session key the requester legitimately holds. Where a long-term key came from a human-chosen password through string-to-key, the sealed blob is guessable offline.

Two different exchanges, and two different sealed parts. **AS-REP roasting** rides the AS exchange: if a principal is not required to send `pa-enc-timestamp (padata-type 2)`, the KDC answers a bare `AS-REQ` with an `AS-REP` whose own `enc-part` is sealed under **that client's long-term key** — handed to an unauthenticated requester who only had to guess a principal name. **Kerberoasting** rides the TGS exchange: any holder of a ticket-granting ticket sends an ordinary `TGS-REQ` naming a service in `sname`, and the `TGS-REP` carries a `ticket` whose `enc-part` is sealed under **that service principal's long-term key**. The reply's *own* `enc-part` is not the prize — it is sealed under the session key the requester legitimately holds. Where a long-term key came from a human-chosen password through `string-to-key`, the sealed blob is guessable offline.

code

asn1 · 15 lines

asn1

KDC-REP ::= SEQUENCE {
        pvno     [0] INTEGER (5),
        msg-type [1] INTEGER,
        padata   [2] SEQUENCE OF PA-DATA OPTIONAL,
        crealm   [3] Realm,
        cname    [4] PrincipalName,
        ticket   [5] Ticket,
              -- Kerberoasting takes ticket.enc-part from a TGS-REP:
              -- sealed under the service principal's long-term key
        enc-part [6] EncryptedData
              -- AS-REP roasting takes THIS field from an AS-REP:
              -- sealed under the client principal's long-term key.
              -- In a TGS-REP the same field is sealed under the
              -- ticket-granting session key the requester holds.
}

go deeper

for a junior

Hold on to the shape: a Kerberos reply carries parts sealed under different keys, and an attacker keeps whichever part is sealed under a key derived from somebody's password.

for a middle

Be able to name the exchange for each roast and the precondition for each - no pre-authentication demanded for one, a valid ticket-granting ticket held for the other - and say which field of the reply is the sealed prize.

for a senior

Demonstrate that both are conformant exchanges rather than protocol failures, and be precise that the prize in a TGS-REP is the ticket's enc-part and not the reply's own, which is sealed under a session key the requester already holds.

for a principal

The interesting question is what a protocol can do when its normal traffic is the attack. Tickets are sealed to their consumer by design, so the lever is key material and key derivation, not refusing requests the specification says to answer.

Two roasts, two exchanges, two sealed parts

The names are similar enough that candidates run them together, and the distinction an interviewer is listening for is mechanical: which exchange produced the material, and which key seals it.

	AS-REP roasting	Kerberoasting
Exchange	AS exchange (`AS-REQ` / `AS-REP`)	TGS exchange (`TGS-REQ` / `TGS-REP`)
What the requester must already hold	nothing at all	a valid ticket-granting ticket
The sealed part taken	the reply's own `enc-part`	the reply's `ticket` field, its `enc-part`
Sealed under	the named client principal's long-term key	the service principal's long-term key
Precondition	that principal does not require Kerberos pre-authentication	`sname` resolves to a principal whose long-term key is password-derived

Both are legal exchanges. Neither breaks anything: in each case the KDC does exactly what RFC 4120 says it should, and hands the result to whoever asked.

AS-REP roasting: the padata that was never demanded

When Kerberos pre-authentication is required for a principal, an AS-REQ arriving with no padata is refused with a KRB-ERROR ([APPLICATION 30]) carrying KDC_ERR_PREAUTH_REQUIRED (25), and METHOD-DATA in e-data lists what would be acceptable — typically pa-enc-timestamp (padata-type 2), alongside pa-etype-info2 (padata-type 19) telling the client which salt and encryption type to use. The client then resends with a PA-ENC-TS-ENC (patimestamp, pausec) structure sealed under its long-term key, and that seal is the proof it knows the key.

Where pre-authentication is not required, that refusal never happens. The KDC answers the first AS-REQ with an AS-REP. Its ticket field is a ticket-granting ticket sealed under the krbtgt key and useless to the requester. Its own enc-part, however, carries EncASRepPart — including the session key — and is sealed under the client principal's long-term key. Anyone at all, holding no credential, can name a principal and be handed a blob encrypted under that principal's password-derived key. The single protocol condition is the absence of a demanded padata.

Kerberoasting: a request the ticket-granting service has no grounds to refuse

Here the attacker must already be inside the realm to the extent of holding a TGT. It sends an ordinary TGS-REQ with the TGT as pa-tgs-req (padata-type 1) padata, an Authenticator sealed under the TGT's session key, and a sname naming some registered service principal. The ticket-granting service validates the TGT and issues — because issuing is what it is for.

The TGS-REP contains two sealed regions, and confusing them is the classic error:

the reply's own enc-part is sealed under the ticket-granting session key, which the requester legitimately holds, so it contains nothing the requester did not already have rights to;
the ticket inside it has an enc-part sealed under the service principal's long-term key, which the requester does not hold and is not meant to read.

That second blob is the material. If the service principal's key was derived by string-to-key from a password a person chose, the blob can be attacked offline for as long as the attacker likes, with no further traffic to the realm at all. Nothing in the exchange asks whether the requester will ever contact that service; the TGS has no notion of intent.

What the pair tells you about the protocol

A ticket is sealed to the party that will consume it, which is what lets the requester carry it — and what makes it offline material when that party's key is weak.
Pre-authentication proves the client knows its own long-term key. Its absence is what makes an AS-REP obtainable by anyone; it has no bearing at all on the TGS exchange.
The sealed part that matters is not always the one named enc-part at the top level of the reply. Say which structure you mean.
Neither attack needs a malformed message, an implementation bug, or elevated rights in the realm. A protocol that refused these requests would be refusing its own normal traffic.

Boundaries

Neither of these is an attack on Kerberos's design in the sense of a flaw: they are consequences of two deliberate properties — that anyone may ask, and that tickets are sealed to their consumer. What turns the handed-over blob into a recovered key is the strength of the key derivation behind it, which is a separate subject from which message carried it.

## Two roasts, two exchanges, two sealed parts The names are similar enough that candidates run them together, and the distinction an interviewer is listening for is mechanical: **which exchange produced the material, and which key seals it**. | | AS-REP roasting | Kerberoasting | |---|---|---| | Exchange | AS exchange (`AS-REQ` / `AS-REP`) | TGS exchange (`TGS-REQ` / `TGS-REP`) | | What the requester must already hold | nothing at all | a valid ticket-granting ticket | | The sealed part taken | the reply's own `enc-part` | the reply's `ticket` field, its `enc-part` | | Sealed under | the named client principal's long-term key | the service principal's long-term key | | Precondition | that principal does not require Kerberos pre-authentication | `sname` resolves to a principal whose long-term key is password-derived | Both are legal exchanges. Neither breaks anything: in each case the KDC does exactly what RFC 4120 says it should, and hands the result to whoever asked. ## AS-REP roasting: the padata that was never demanded When Kerberos pre-authentication is required for a principal, an `AS-REQ` arriving with no `padata` is refused with a `KRB-ERROR ([APPLICATION 30])` carrying `KDC_ERR_PREAUTH_REQUIRED (25)`, and `METHOD-DATA in e-data` lists what would be acceptable — typically `pa-enc-timestamp (padata-type 2)`, alongside `pa-etype-info2 (padata-type 19)` telling the client which salt and encryption type to use. The client then resends with a `PA-ENC-TS-ENC (patimestamp, pausec)` structure sealed under its long-term key, and that seal is the proof it knows the key. Where pre-authentication is **not** required, that refusal never happens. The KDC answers the first `AS-REQ` with an `AS-REP`. Its `ticket` field is a ticket-granting ticket sealed under the `krbtgt` key and useless to the requester. Its own `enc-part`, however, carries `EncASRepPart` — including the session key — and is sealed under the **client principal's long-term key**. Anyone at all, holding no credential, can name a principal and be handed a blob encrypted under that principal's password-derived key. The single protocol condition is the absence of a demanded `padata`. ## Kerberoasting: a request the ticket-granting service has no grounds to refuse Here the attacker must already be inside the realm to the extent of holding a TGT. It sends an ordinary `TGS-REQ` with the TGT as `pa-tgs-req (padata-type 1)` padata, an `Authenticator` sealed under the TGT's session key, and a `sname` naming some registered service principal. The ticket-granting service validates the TGT and issues — because issuing is what it is for. The `TGS-REP` contains two sealed regions, and confusing them is the classic error: - the reply's own `enc-part` is sealed under the **ticket-granting session key**, which the requester legitimately holds, so it contains nothing the requester did not already have rights to; - the `ticket` inside it has an `enc-part` sealed under the **service principal's long-term key**, which the requester does not hold and is not meant to read. That second blob is the material. If the service principal's key was derived by `string-to-key` from a password a person chose, the blob can be attacked offline for as long as the attacker likes, with no further traffic to the realm at all. Nothing in the exchange asks whether the requester will ever contact that service; the TGS has no notion of intent. ## What the pair tells you about the protocol - A ticket is sealed **to the party that will consume it**, which is what lets the requester carry it — and what makes it offline material when that party's key is weak. - Pre-authentication proves the client knows its own long-term key. Its absence is what makes an AS-REP obtainable by anyone; it has no bearing at all on the TGS exchange. - The sealed part that matters is not always the one named `enc-part` at the top level of the reply. Say which structure you mean. - Neither attack needs a malformed message, an implementation bug, or elevated rights in the realm. A protocol that refused these requests would be refusing its own normal traffic. ## Boundaries Neither of these is an attack on Kerberos's design in the sense of a flaw: they are consequences of two deliberate properties — that anyone may ask, and that tickets are sealed to their consumer. What turns the handed-over blob into a recovered key is the strength of the key derivation behind it, which is a separate subject from which message carried it.

Why is the TGS-REP's own enc-part not the part an attacker keeps?
Because it is sealed under the ticket-granting session key, which the requester already holds — it decrypts immediately and reveals nothing it was not entitled to. The interesting region is one level down: `ticket.enc-part`, sealed under the service principal's long-term key, which the requester cannot open and therefore must attack offline.
Does requiring Kerberos pre-authentication protect a service principal against Kerberoasting?
No. Pre-authentication governs the AS exchange, where a client proves it knows its own long-term key before receiving an `AS-REP`. Kerberoasting happens in the TGS exchange, driven by a requester that has already authenticated and holds a valid ticket-granting ticket. The two conditions are independent, and only the AS-REP roast turns on the missing padata.
What does the KDC return if pre-authentication is required and the AS-REQ carries no padata?
A `KRB-ERROR` carrying `KDC_ERR_PREAUTH_REQUIRED (25)`, with `METHOD-DATA in e-data` listing the padata types that would be accepted — commonly `pa-enc-timestamp (padata-type 2)`, together with `pa-etype-info2 (padata-type 19)` so the client knows the salt and encryption type. The client then retries with a `PA-ENC-TS-ENC` sealed under its long-term key.

A ticket-granting service will hand anyone a strongbox closed with a particular department's own padlock. It does not care who asks, and if that department set a four-digit combination the asker can work on it at home all week.

saying these in an interview costs you the question

Says both roasts take the same field of the reply
Thinks Kerberoasting needs elevated rights in the realm
Believes the ticket-granting service refuses a ticket nobody will use
Assumes AS-REP roasting needs a valid credential first
Says pre-authentication also protects the service ticket

In Kerberos, which exchange does AS-REP roasting draw on, which does Kerberoasting use, and what does each reply seal?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

Two roasts, two exchanges, two sealed parts

AS-REP roasting: the padata that was never demanded

Kerberoasting: a request the ticket-granting service has no grounds to refuse

What the pair tells you about the protocol

Boundaries

▾common follow-ups3 questions

▾analogy~20 s

▾red flags5 flags

Two roasts, two exchanges, two sealed parts

AS-REP roasting: the padata that was never demanded

Kerberoasting: a request the ticket-granting service has no grounds to refuse

What the pair tells you about the protocol

Boundaries

answer

go deeper