skip to content

What does Kerberos FAST armoring protect that plain PA-ENC-TIMESTAMP pre-authentication leaves exposed?

level: seniorimportance: nice to knowfreq 22%

answer

  1. pre-auth data is itself a target
  2. wrap the conversation, not just the ticket
  3. the armor key comes from a ticket
  4. FX_FAST_ARMOR_AP_REQUEST carries an AP-REQ
  5. PA-FX-COOKIE carries state between round trips

basics

~10 s

FAST encrypts the pre-authentication conversation itself under an armor key that is not derived from the user's password, so the encrypted-timestamp ciphertext and the KDC's error replies stop being an observable, guessable, spoofable channel.

solid answer

~40 s

Plain Kerberos pre-authentication sends `PA-ENC-TIMESTAMP`: a timestamp encrypted under the client's password-derived long-term key. An observer who captures it can test candidate passwords offline, and the `KRB-ERROR` replies that steer the exchange are unprotected. **FAST** (RFC 6113) wraps the whole request and reply in `PA-FX-FAST (padata-type 136)`, encrypted and integrity-protected under an **armor key** derived from an armor ticket — with `FX_FAST_ARMOR_AP_REQUEST`, whose `armor-value` is an AP-REQ built from a ticket the requester already holds. Because the armor key comes from a ticket rather than the user's password, the inner pre-authentication is no longer an offline oracle and errors cannot be forged or downgraded. FAST also supports multi-round-trip pre-authentication, carrying KDC state in `PA-FX-COOKIE (padata-type 133)` alongside `KDC_ERR_MORE_PREAUTH_DATA_REQUIRED`.

code

asn1 · 14 lines
asn1
PA-FX-FAST-REQUEST ::= CHOICE {
    armored-data    [0] KrbFastArmoredReq
}

KrbFastArmoredReq ::= SEQUENCE {
    armor           [0] KrbFastArmor OPTIONAL,
    req-checksum    [1] Checksum,
    enc-fast-req    [2] EncryptedData
}

KrbFastArmor ::= SEQUENCE {
    armor-type      [0] Int32,
    armor-value     [1] OCTET STRING
}

go deeper

for a junior

Recall that ordinary Kerberos pre-authentication sends a timestamp encrypted with the user's password-derived key, and that FAST puts that whole exchange inside another layer of protection.

for a middle

Explain why an observable password-derived ciphertext is an offline oracle, and that the armor key comes from an existing ticket rather than from the password.

for a senior

Show the deployment consequence: armoring needs an armor ticket, the anonymous ticket exists to bootstrap it, and both ends must implement the framework.

for a principal

Judge where armoring is worth the dependency it adds, and be clear that it addresses the pre-authentication conversation while service-key strength remains a separate programme.

## The exposure in plain pre-authentication Kerberos pre-authentication exists to stop a KDC handing out an `AS-REP` to anyone who merely names a principal. The ordinary mechanism is `PA-ENC-TIMESTAMP (padata-type 2)`: the client encrypts a `PA-ENC-TS-ENC` structure — a timestamp and microseconds — under its **password-derived long-term key** and sends it with the `AS-REQ`. The KDC decrypts it, checks the time is within its window, and proceeds. That works, and it leaves two things exposed: - **An offline oracle.** The ciphertext is a known plaintext structure encrypted under a key derived from a password. Anyone who observes it can guess passwords offline: derive a key, decrypt, check whether a plausible timestamp appears. Nothing is sent to the KDC while they do it. - **An unprotected conversation.** The `KRB-ERROR` replies that drive the exchange — which etype to use, which salt, what further data is required — are neither encrypted nor authenticated, so they can be observed, altered or forged to steer a client. ## What FAST wraps **FAST**, defined by **RFC 6113**, is a pre-authentication framework rather than one more padata type. The real request is placed inside `PA-FX-FAST (padata-type 136)` as a `PA-FX-FAST-REQUEST`, which carries a `KrbFastArmoredReq`: an armor specification, a checksum over the outer request, and the inner request as encrypted data. The reply is wrapped the same way. The protection comes from the **armor key**, and that is the whole idea: - the armor is described by an `armor-type` and an `armor-value`; - with `FX_FAST_ARMOR_AP_REQUEST`, the `armor-value` is an **AP-REQ**, built from a ticket the requester already holds, and the armor key is derived from that ticket's session key together with the subkey in the AP-REQ; - because that key comes from an existing ticket, it is **not derived from the user's password**, so the wrapped `PA-ENC-TIMESTAMP` inside is no longer something an observer can grind against. ## What that buys, stated exactly | exposure | plain `PA-ENC-TIMESTAMP` | inside `PA-FX-FAST` | |---|---|---| | pre-authentication ciphertext observable | yes | no, it is inside the armored request | | offline guessing of the pre-auth data | possible | not from the wire | | `KRB-ERROR` replies authenticated | no | yes, within the armored exchange | | multi-round-trip pre-authentication | not supported | supported, with `PA-FX-COOKIE (padata-type 133)` | The multi-round-trip part matters on its own: a KDC that needs another exchange answers `KDC_ERR_MORE_PREAUTH_DATA_REQUIRED` and carries its state in `PA-FX-COOKIE (padata-type 133)` rather than holding a session, and a failure still ends at `KDC_ERR_PREAUTH_FAILED`. ## The bootstrap problem Armoring needs a ticket to armor with, which raises the obvious question: what armors the very first exchange, before the user has any ticket? 1. A host that has its own ticket-granting ticket can use it to armor a user's AS exchange happening on that host. 2. Where there is no such ticket, **RFC 6112** provides the **anonymous ticket**: an exchange that obtains a ticket without asserting a named identity, which can then serve as the armor ticket. This is also the honest limit on deployment: FAST is not something a client can simply turn on alone, because the armor has to come from somewhere, and every KDC on the path has to support the framework. ## What FAST does not do Be careful with the claim here, because it is easy to overstate: - It protects the **pre-authentication conversation**. It does not change how a **service ticket** is sealed — that is still the service principal's long-term key and the etype it holds, and a service ticket obtained later is an offline target on exactly the same terms as before. - It does not remove the account's password-derived long-term key; it hides the ciphertext that would let it be guessed from the wire. - It does not replace certificate-based pre-authentication. The two address different things: one keeps the conversation from being an oracle, the other removes the password-derived key altogether, and a realm can use both. **Version note.** FAST is RFC 6113 and the anonymous-ticket bootstrap is RFC 6112; neither is implied by RFC 4120 alone, so an exchange only gets these properties where both ends implement the framework.

  • Where does the armor key come from, and why does that choice matter?
    With `FX_FAST_ARMOR_AP_REQUEST` the `armor-value` is an AP-REQ built from a ticket the requester already holds, and the armor key is derived from that ticket's session key and the AP-REQ's subkey. It matters because that key is not derived from the user's password, so wrapping the pre-authentication data under it stops the data being an offline guessing target.
  • What armors an AS exchange when the requester holds no ticket at all?
    Either a ticket belonging to the host the exchange runs on, or the anonymous ticket RFC 6112 defines — obtained without asserting a named identity and used purely as an armor ticket. Without one of these there is nothing to derive an armor key from, which is why FAST cannot be enabled unilaterally on a client.
  • Does FAST protect a service ticket from offline guessing too?
    No. FAST protects the pre-authentication conversation in the AS exchange. A service ticket is still sealed under the service principal's long-term key, and how cheaply that key can be guessed is decided by the etype and by whether the key was derived from a password — neither of which FAST touches.

saying these in an interview costs you the question

  • Says FAST encrypts tickets that were previously plaintext
  • Claims FAST ends all offline guessing in the realm
  • Thinks the armor key is derived from the user's password
  • Assumes a client can enable FAST without an armor ticket
  • Confuses FAST armoring with certificate-based pre-authentication