skip to content

After a Kerberos AP exchange, which key protects the application's later messages, and what does subkey change?

level: seniorimportance: nice to knowfreq 26%

answer

  1. the ticket's key is not per-connection
  2. optional in both messages
  3. the client proposes, the reply may override
  4. scoped to one exchange
  5. seq-number orders what follows

basics

~20 s

By default the ticket's session key, which the KDC issued and every exchange presenting that ticket shares. If the Authenticator proposes a subkey the peers may use that sub-session key instead, and when the AP-REP returns one, the service's choice governs.

solid answer

~50 s

Once an `AP-REQ` is accepted, the application still needs a key for its own integrity- or confidentiality-protected messages. The default is the ticket's **session key** — but that key was issued by the KDC with the ticket, lives as long as the ticket does, and is shared by every exchange that presents it, including concurrent connections from the same client. The `Authenticator` therefore carries an optional `subkey` in which the client may propose a **sub-session key** scoped to this exchange, and an optional `seq-number` to order the messages that follow. The `EncAPRepPart` inside the `AP-REP` carries the same two optional fields, and when the service returns a `subkey` of its own, that is the key in force. A client that keeps using its own proposal after the service has answered with one will produce messages the service cannot open.

code

asn1 · 20 lines
asn1
-- the client may propose a sub-session key
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
}

-- and the service may answer with one of its own
EncAPRepPart ::= [APPLICATION 27] SEQUENCE {
    ctime       [0] KerberosTime,
    cusec       [1] Microseconds,
    subkey      [2] EncryptionKey OPTIONAL,
    seq-number  [3] UInt32 OPTIONAL
}

go deeper

for a junior

Know that a key is still needed after authentication succeeds, and that by default it is the one that came with the ticket rather than a new one.

for a middle

Explain that subkey and seq-number are optional fields in both the Authenticator and the reply, and say what scoping a key to one exchange actually changes.

for a senior

Show the direction correctly: the client proposes, the service's returned key governs. Then describe the failure of a mismatch, which appears only after authentication has succeeded.

for a principal

The call is how much key material a single ticket lifetime should cover across many concurrent exchanges, weighed against an application protocol that must then agree on optional fields at both ends.

## Which key is in force after the exchange The AP exchange authenticates; it does not by itself protect the conversation that follows. The application protocol decides whether its messages are integrity-protected, encrypted, both or neither, and it needs a key to do it with. There are two candidates and the difference between them is the whole of this question. The **session key** comes from the KDC. It was generated when the service ticket was issued, sealed inside the ticket under the service principal's long-term key, and handed to the client in the encrypted part of the `TGS-REP`. It is the key the `Authenticator` was encrypted under, and if nothing else is negotiated it is the key the application uses afterwards. The **sub-session key** is proposed inside the AP exchange itself, by either peer, and belongs to that exchange alone. ## Session key against sub-session key | | Session key | Sub-session key | |---|---|---| | Who creates it | The KDC, when issuing the ticket | Whichever peer proposes it, during the AP exchange | | Where it is carried | Inside the ticket, and in the `TGS-REP` | `subkey` in the `Authenticator`, or in the `EncAPRepPart` | | How long it lives | As long as the ticket | As long as this exchange | | How many exchanges share it | Every one that presents that ticket | One | | Optional | No — it always exists | Yes — both fields may be absent | The row that matters is the fourth. A writer on a plant floor that keeps four connections open to the historian, and rebuilds them through the shift, is presenting the same ticket each time and therefore working under one key. Any key-usage limit, any sequence space, any keystream is shared across all of them, and compromise of key material from one connection is compromise of all of them until the ticket expires. A sub-session key gives each exchange its own. ## Who proposes and who decides - The client may place a `subkey` in the `Authenticator` it sends in the `AP-REQ`. That is a **proposal**. - The service may place a `subkey` in the `EncAPRepPart` it returns in the `AP-REP`. When it does, that key is the one in force for the messages that follow. - If neither does, the session key stands. This is a place where a plausible-sounding reversal is wrong: the client is not choosing the key for both sides. It offers one, and the reply may override it. Note also that a service can only answer with a key if it is sending a reply at all, so a one-way exchange with no `MUTUAL-REQUIRED` leaves the client's proposal, or the session key, in force. ## Sequence numbers Alongside `subkey`, both messages carry an optional `seq-number`. It is a starting value for numbering the application messages that follow, so that a receiver can detect a message delivered twice or out of order **without** consulting a timestamp window. That is a different mechanism from the freshness checks the AP exchange itself performs, and it operates over the whole conversation rather than over the one authentication event. The two together are why the specification scopes the replay-cache obligation the way it does: the cache exists to stop an `AP-REQ` being replayed, and where the application binds and orders its own messages with a sub-session key and sequence numbers, less of the burden rests on that cache alone. ## What a sub-session key does not buy you - **It does not hide anything from the service principal.** The peer that opened the ticket knows the session key; a key proposed inside a message encrypted under that session key is visible to it. The point is scoping, not secrecy from the counterparty. - **It does not re-authenticate anyone.** Identity was settled by the `AP-REQ` and, if requested, the `AP-REP`. - **It does not extend or shorten the ticket's lifetime.** The ticket's validity interval is set by the KDC and is untouched by anything the peers negotiate. - **It does not remove the clock and replay checks** on the `AP-REQ` that carried it. ## When it is worth using Where a single client holds many concurrent exchanges with one service, where the application will move a large volume under one key, or where an exchange is long-lived and you would rather its key material did not outlive it. Where a client opens one short exchange, sends one message and closes, the session key is adequate and the extra field is noise. Because both fields are optional, an application protocol has to state which it uses — an implementation that proposes a sub-session key against a peer that ignores the field will find its messages unreadable, and that failure surfaces after authentication has already succeeded, which makes it an awkward one to read.

  • Why not simply use the ticket's session key for every connection to the service?
    Because it is one key for the ticket's whole lifetime and for every exchange that presents that ticket. Key-usage limits, keystreams and sequence spaces all have to be coordinated across those exchanges, and key material recovered from one of them covers the rest until the ticket expires. A sub-session key confines that to a single exchange.
  • If both the Authenticator and the AP-REP carry a subkey, which one governs?
    The one the service returned in the `AP-REP`. The client proposes and the service may answer with a key of its own, and when it does, that key protects the messages that follow. A client that keeps encrypting under its own proposal produces messages the service cannot open, and the failure appears after authentication has already succeeded.

saying these in an interview costs you the question

  • Thinks a sub-session key is mandatory in every AP exchange.
  • Says the KDC issues the sub-session key along with the ticket.
  • Believes the session key changes each time the ticket is presented.
  • Assumes the client's proposed subkey always overrides the service's.
  • Thinks a sub-session key hides application data from the service principal.