Why does a Kerberos service send an AP-REP at all, and what does that reply prove?
answer
- one-way leaves the client blind
- the client has to ask for it
- ap-options bit 2
- the reply echoes ctime and cusec
- only the service key opens the ticket
basics
~20 sA service returns an AP-REP only when the client set MUTUAL-REQUIRED in ap-options. The reply echoes the client's own ctime and cusec sealed under the ticket's session key, which only a party holding the service principal's long-term key could produce.
solid answer
~40 sWithout a reply, the AP exchange is one-way: the client has proved who it is and has learned nothing about the peer. Anything sitting on that network segment can accept an `AP-REQ` and behave as though it validated. A client that wants more sets `MUTUAL-REQUIRED` in the `AP-REQ`'s `ap-options`, and the service answers with an `AP-REP` (`[APPLICATION 15]`) whose `enc-part` is an `EncAPRepPart` encrypted under the ticket's session key, carrying the `ctime` and `cusec` the client just sent, plus an optional `subkey` and `seq-number`. To produce it the peer had to recover the session key, and the session key lives inside the ticket, sealed under the service principal's long-term key. So the reply proves the peer holds that key and is therefore the named service principal. It proves nothing about the host's integrity.
code
asn1 · 12 linesAP-REP ::= [APPLICATION 15] SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (15),
enc-part [2] EncryptedData -- EncAPRepPart
}
EncAPRepPart ::= [APPLICATION 27] SEQUENCE {
ctime [0] KerberosTime, -- echoed from the Authenticator
cusec [1] Microseconds, -- echoed from the Authenticator
subkey [2] EncryptionKey OPTIONAL,
seq-number [3] UInt32 OPTIONAL
}go deeper
Remember that the reply is optional and that the client asks for it. Its job is to prove the peer is the service, not to confirm the client was accepted.
Explain the chain: the session key lives inside a ticket only the service principal's key opens, so anything sealed under that session key came from the key holder. Name the echoed ctime and cusec.
The failure worth describing is the client that sets the flag and never checks the echoed values. Say what you would look for to tell a real mutual exchange from a decorative one.
Frame the choice as a round trip per exchange against the class of peer-impersonation you keep. For short one-message exchanges at high rate, that cost is real and worth stating out loud.
## What one-way authentication leaves open An `AP-REQ` validated on its own settles one direction only. The historian on a plant floor now knows which principal is writing tank temperatures into it. The writer knows nothing: it opened a connection to a name, sent a service ticket and an `Authenticator`, and got on with the application protocol. Something that has been sitting on that segment all shift, answering on that address, can accept the `AP-REQ` without being able to read a byte of it and simply reply as though all was well. What that costs is not usually the confidentiality of the first message — it is everything after it. The writer will believe readings were accepted that were never stored, and will accept instructions from a peer it never authenticated. ## Asking for the reply Mutual authentication in Kerberos is **requested per exchange, by the client**, not configured globally in the protocol. The client sets `MUTUAL-REQUIRED`, which is bit 2 of the `ap-options` field in the `AP-REQ`. Two consequences follow: - a client that forgets to set it gets no reply and has no way to ask afterwards — the request is part of the message already sent; - a service cannot make itself prove anything to a client that did not ask, though it can of course refuse clients that do not. ## What comes back The `AP-REP` (`[APPLICATION 15]`) is a small message: `pvno`, `msg-type`, and `enc-part`, an `EncryptedData` whose plaintext is an `EncAPRepPart`. Inside are: - `ctime` and `cusec` — **the client's own timestamp, echoed**, not a new one taken from the service's clock; - `subkey` — optionally, a sub-session key the service proposes for the messages that follow; - `seq-number` — optionally, the starting sequence number the service will use. The whole part is encrypted under the ticket's session key. ## Why that is proof, and exactly how far it goes The chain is short and worth being able to state in one breath. The session key exists in two places: inside the service ticket, sealed under the service principal's long-term key, and in the client's own hands. A peer that can encrypt anything under that session key must have opened the ticket. Opening the ticket requires the service principal's long-term key. Therefore the peer holds that key. | The client concludes | Because | It does not follow that | |---|---|---| | The peer holds the service principal's long-term key | Only that key opens the ticket that carries the session key | The host running the service is uncompromised | | This reply belongs to this request | The echoed `ctime` and `cusec` are the ones the client just generated | Later messages are authenticated unless they are protected too | | The service is the principal the client asked the KDC for | The ticket was issued for that principal name, and the reply proves its key | The name maps to the machine the client intended | That last row is the honest limit. Kerberos authenticates **principal names**. If a client asked for a ticket for the wrong service principal, a perfect mutual authentication to the wrong service is the result. ## Why an echo rather than a fresh timestamp Echoing binds the reply to this exchange. The client compares the returned `ctime` and `cusec` with the values it placed in its own `Authenticator` moments earlier. A reply captured from any earlier exchange carries an earlier timestamp and fails that comparison, and it is in any case sealed under a different ticket's session key. A fresh server timestamp would prove the service was alive but not that it was answering **this** request, and it would drag the client into judging the service's clock. ## What it costs 1. **A round trip.** For a short-lived connection carrying one message, that is the dominant cost of enabling it. 2. **A key in the right place.** The service must actually hold its own long-term key at request time; a service that cannot decrypt the ticket cannot reply, and the client sees a `KRB-ERROR` rather than an `AP-REP`. 3. **Client-side discipline.** The client has to check the echoed values. Treating the mere arrival of an `AP-REP` as success reintroduces the hole that mutual authentication was meant to close, because an unopenable reply and a correct one both arrive as bytes. That third point is the one that fails in practice: the flag gets set, the reply gets received, and nothing compares the timestamps.
- What stops an AP-REP captured from an earlier exchange from convincing a client?Two things. The reply echoes the `ctime` and `cusec` from the Authenticator the client has just sent, so an older capture carries the wrong pair and fails the comparison. It is also sealed under the session key of the ticket used at the time, which is not the session key in force now.
- If the client did not set MUTUAL-REQUIRED, what does the service send on success?Nothing at the Kerberos layer — it simply proceeds with the application protocol. The client learns only that it was not rejected. A failure would come back as a `KRB-ERROR` carrying a code such as `KRB_AP_ERR_SKEW` or `KRB_AP_ERR_TKT_EXPIRED`.
- Does a validated AP-REP tell the client it is talking to the right machine?It tells the client it is talking to the holder of a named service principal's long-term key. If the client obtained a ticket for the wrong service principal, mutual authentication succeeds against the wrong service. The name the ticket was requested for is the thing being authenticated, so getting that name right is the client's responsibility.
saying these in an interview costs you the question
- Says mutual authentication is always on in Kerberos.
- Thinks the AP-REP proves the service host is not compromised.
- Believes the AP-REP carries a fresh server timestamp rather than the client's.
- Says the AP-REP is encrypted under the service's long-term key.
- Thinks a client can request mutual authentication after sending the AP-REQ.
- Counts the arrival of an AP-REP as success without decrypting it.