Summary

  • RFC 9588 uses SPAKE and transcript-bound key derivation so an impostor KDC cannot normally turn one exchange into an offline password test. That is a property of the completed path, not of the PA-SPAKE label alone.
  • If SPAKE fails and the client falls back to encrypted timestamp, a passive observer may test the entered password offline. Even successful pre-authentication proves neither application authorization nor service access.

A client tries the stronger method. It receives a failure, quietly switches to an older Kerberos pre-authentication mechanism and asks the user to try again. On the dashboard, the sequence looks resilient: login continued instead of stopping. To an attacker recording packets, the same recovery step can be the useful event.

That is the uncomfortable boundary in RFC 9588. SPAKE is designed to prevent an active attacker posing as the KDC from learning whether an offline password guess is correct. Yet Section 10.5 warns that the attacker may steer the client toward encrypted timestamp. If a wrong password caused the SPAKE failure and the client then falls back, a passive observer can attack that wrong value offline. A near miss may reveal almost as much human structure as the correct password.

The protocol has not contradicted itself. The deployment path has changed the security claim.

The receipt starts later than the advertisement

IANA records PA-SPAKE as pre-authentication type 151, and RFC 9588 defines support, challenge, response and encrypted factor messages. A KDC can advertise support; a client can offer preferred groups; the KDC can choose one. None of those acts proves that the exchange reached verification.

Early messages also have deliberate limits. Support and challenge material contains unauthenticated plaintext. Without FAST, the offered factor list is visible and is not integrity-protected until the response has been verified. A PA-SPAKE-HINT can help a client choose an authentication set, but the hint sits outside the transcript and replaces no protocol step.

The decisive receipt comes when both parties derive transcript-bound keys, the KDC successfully decrypts the factor response and validates the required factors. Only then is the reply key strengthened to K'[0]. There is no final PA-SPAKE confirmation from the KDC; the encrypted KDC reply continues to provide the existing KDC-authentication property.

One failure can select a different threat model

Fallback is often treated as availability plumbing. Here it changes what a captured packet permits. SPAKE failure followed by another SPAKE attempt keeps the exchange inside one set of assumptions. SPAKE failure followed by encrypted timestamp may create an offline verifier for the entered password.

The RFC therefore recommends a per-realm control to disable encrypted timestamp. That recommendation is operationally sharper than a generic instruction to “support SPAKE.” A realm can advertise the new mechanism while a client fleet preserves the old exposure through recovery logic. Capability inventory and effective-path inventory are different records.

The same discipline applies to online attacks. RFC 9588 does not stop online password guessing; it lets the KDC observe failures and apply rate limits. A security report that counts SPAKE handshakes but omits fallback attempts, online failures and rate-limit decisions has measured the preferred lane while ignoring the lane an attacker wants.

Cryptographic completion is not application authority

A successful exchange establishes that the client knew the original reply key and, where applicable, supplied a validated second factor. SF-NONE is explicitly a valid factor type that means no second factor. Calling every SPAKE exchange “MFA” would therefore invent a property the registry does not supply.

After reply-key strengthening, more receipts remain: the client must authenticate the KDC reply, obtain and use service credentials, reach the application and pass the application's authorization policy. The transcript binds the Kerberos request body; it does not grant a role in a database, release a payment or prove that a protected resource was delivered.

This is the reality-layer distinction in operational form. A coordinated identifier is not a deployed mechanism. A negotiated mechanism is not a verified exchange. A verified exchange is not a used ticket. A used ticket is not authorization. Compressing those states into “login secure” removes exactly the evidence needed when the fallback path becomes material.

Implementation details remain security inputs

RFC 9588 also makes the cryptographic custody explicit. Public points must be valid group elements. Private scalars must be uniform and must not be reused across different reply keys. The masking points must not have known discrete logarithms. Timing and other side channels must not reveal the long-term key.

For a stateless KDC, PA-FX-COOKIE may carry the private scalar and transcript state. That cookie needs confidentiality, integrity, a short replay window and binding to the principal and mechanism. During its valid period, replaying a final message can make the client appear authenticated to another KDC in the realm. Cookie-key custody is therefore part of the evidence chain, not an internal storage detail.

Nor should the mechanism be sold as blanket forward secrecy. The RFC says it was not designed to provide it. Some implementation choices may protect past ticket keys after a later password compromise, but compromise of the password together with a cookie-encryption key can change the outcome.

Sources