skip to content

Besides the Kerberos service ticket, what does an AP-REQ carry, and why is the ticket alone not proof?

level: middleimportance: must knowfreq 58%

answer

  1. possession, not presentation
  2. a ticket can be copied
  3. session key the client also holds
  4. Authenticator: cname, ctime, cusec, cksum
  5. encrypted under the ticket's session key

basics

~20 s

An AP-REQ carries ap-options, the service ticket and an Authenticator encrypted under the ticket's session key. Anyone can copy a ticket; only the holder of its session key can mint a fresh Authenticator carrying cname, ctime and cusec.

solid answer

~50 s

An `AP-REQ` (`[APPLICATION 14]`) carries a protocol version, a message type, `ap-options`, the `Ticket` itself, and an `authenticator` field that is `EncryptedData`. The service ticket is sealed under the service principal's long-term key, so the client cannot read or alter it — it only forwards it, and anything that can copy it can forward it too. What proves the presenter is the party the ticket names is the `Authenticator` (`[APPLICATION 2]`), encrypted under the session key the KDC put both inside the ticket and in the part of the `TGS-REP` the client could decrypt. It carries `crealm` and `cname`, a `ctime`/`cusec` timestamp, an optional `cksum` over the accompanying application data, and optional `subkey` and `seq-number`. The service decrypts the ticket with its own key, recovers the session key, opens the Authenticator with it, and checks the names agree and the timestamp is current.

code

asn1 · 19 lines
asn1
AP-REQ ::= [APPLICATION 14] SEQUENCE {
    pvno            [0] INTEGER (5),
    msg-type        [1] INTEGER (14),
    ap-options      [2] APOptions,
    ticket          [3] Ticket,
    authenticator   [4] EncryptedData -- Authenticator
}

Authenticator ::= [APPLICATION 2] SEQUENCE {
    authenticator-vno   [0] INTEGER (5),
    crealm              [1] Realm,
    cname               [2] PrincipalName,
    cksum               [3] Checksum OPTIONAL,
    cusec               [4] Microseconds,
    ctime               [5] KerberosTime,
    subkey              [6] EncryptionKey OPTIONAL,
    seq-number          [7] UInt32 OPTIONAL,
    authorization-data  [8] AuthorizationData OPTIONAL
}

go deeper

for a junior

Recall the two pieces a caller presents: a service ticket it cannot read, and a freshly built Authenticator it can. The proof is possession of the session key, not the ticket.

for a middle

Name the Authenticator's fields, say which key encrypts it, and walk the service's side: decrypt the ticket with its own key, recover the session key, open the Authenticator, compare the names.

for a senior

Show that the exchange needs no KDC round trip, and what that buys during a KDC outage — and what it costs when a credential has to be invalidated before it expires.

for a principal

The trade-off worth naming is a proof-of-possession credential against a copyable one. It removes copy-and-present, at the price of every service keeping a clock and a key in step with the realm.

## The exchange this message belongs to Kerberos version 5 runs three exchanges. The AS exchange obtains a **ticket-granting ticket**; the TGS exchange spends that ticket-granting ticket for a **service ticket**; the **AP exchange** is the only one the application service itself takes part in. By the time an `AP-REQ` arrives, the KDC has finished its work and is out of the picture. A plant-historian server that records tank temperatures on a factory floor never calls the KDC to check the caller in front of it. The client holds exactly two relevant things at that moment: - the **service ticket** for the historian's service principal — an opaque structure whose `enc-part` is sealed under that service principal's long-term key. The client cannot read it, cannot modify it without detection, and cannot tell what is inside it. - the **session key** the KDC generated for that ticket. The KDC placed one copy inside the sealed ticket and handed a second copy to the client inside the encrypted part of the `TGS-REP`, which the client could open. That asymmetry is the whole design: the ticket is the part the client carries but cannot use, and the session key is the part it can use but cannot show. ## What an AP-REQ actually contains - `pvno` and `msg-type` — the version and the message identifier. - `ap-options` — the flag field in which the client may set `MUTUAL-REQUIRED` to ask the service to prove itself in return. - `ticket` — the service ticket, forwarded verbatim. - `authenticator` — `EncryptedData`, and the plaintext inside it is an `Authenticator` (`[APPLICATION 2]`) encrypted under the ticket's session key. The `Authenticator` carries `authenticator-vno`, `crealm` and `cname` (who the presenter claims to be), `cusec` and `ctime` (the moment it was built, to the microsecond), an optional `cksum` over the application data travelling with the request, and optional `subkey`, `seq-number` and `authorization-data`. ## Why the ticket alone establishes nothing about the presenter A service ticket is not a secret in the presenter's hands — it is a statement by the KDC, addressed to the service. It travels across the network, sits in a credential cache, and is readable to anything that can watch the segment on which it was first presented. If the historian accepted a ticket on its own, it would be treating a copyable string as proof, which is the property that makes a bearer credential a bearer credential. | What the service observes | What that establishes | What it still does not establish | |---|---|---| | The ticket decrypts under my own long-term key | A KDC issued this credential, for this service, naming that client, valid over this interval | That the party presenting it is that client | | The Authenticator decrypts under the session key found inside that ticket | The presenter holds the session key, which only the named client received | Nothing about when the presenter obtained it | | `ctime` and `cusec` fall inside the allowed window | The presenter built this Authenticator recently, not replayed an old one | That the same Authenticator was not already seen | | `cname` and `crealm` match the ticket's | The Authenticator belongs to this ticket | Anything about what the client may do | The second row is the answer to the question. Building an `Authenticator` requires encrypting under the session key, and the session key reached the client inside a `TGS-REP` part that only the client's own credentials could open. A copier of the ticket has the envelope and not the pen. ## The service's side, in order 1. Decrypt the ticket's `enc-part` with the service principal's long-term key. Failure here means the ticket was not for this service, or was altered. 2. Recover the session key from the decrypted ticket. 3. Decrypt the `authenticator` field with that session key. 4. Compare `cname` and `crealm` in the Authenticator against the ones in the ticket; they must be the same principal. 5. Check freshness — the timestamp window and the record of authenticators already accepted. No step contacts the KDC. That is why an application service keeps authenticating callers through a KDC outage, and also why a ticket cannot be withdrawn mid-lifetime by the KDC alone. ## What a validated AP-REQ still does not give you - It says nothing about the **health of the client host** — a compromised machine authenticates perfectly with its own credentials. - It does not decide **what the caller may do**; that is the service's own decision after identity is settled. - It does not protect the application data that follows unless the exchange goes on to use the session key or a negotiated sub-session key. - It does not tell the **client** anything about the service. For that the client must set `MUTUAL-REQUIRED` and get an `AP-REP` back.

  • Which key encrypts the Authenticator, and how did the client come to hold it?
    The ticket's session key. The KDC generated it, placed one copy inside the service ticket sealed under the service principal's long-term key, and a second copy in the encrypted part of the `TGS-REP` that the client could open with its ticket-granting ticket's session key. The client therefore holds the session key while remaining unable to read the ticket.
  • What does the Authenticator's cksum cover, and why does that matter for the first application message?
    `cksum` is a checksum over the application data accompanying the `AP-REQ`. Because it sits inside the Authenticator, which is encrypted under the session key, it binds that data to the authenticated exchange: a party that alters the data in flight cannot recompute the checksum, and the service can answer `KRB_AP_ERR_MODIFIED`.
  • Why does the service not contact the KDC to validate an AP-REQ?
    Everything it needs is in the message. It decrypts the ticket with its own long-term key, which yields the session key, and decrypts the Authenticator with that. The KDC took part when the ticket was issued and plays no role here — which is why a service keeps authenticating callers while the KDC is unreachable, and why a ticket already issued cannot be pulled back by the KDC alone.

A cloakroom ticket proves only that someone left a coat. Being able to describe, on the spot, what is in the pockets proves you are the person who left it.

saying these in an interview costs you the question

  • Thinks the client decrypts the service ticket to read its contents.
  • Treats the service ticket as sufficient proof, like a bearer credential.
  • Says the client's password or long-term key is sent to the service.
  • Believes the service calls the KDC to verify every AP-REQ.
  • Thinks one Authenticator can be reused while the ticket is unexpired.