Summary

  • draft-ietf-kitten-sasl-ht-02 specifies a two-message SASL family for quick re-authentication with a short-lived shared token. The initiator and responder each compute a role-separated HMAC over the token, selected channel-binding data and optional authenticated values.
  • The draft is an active KITTEN Working Group Internet-Draft in Working Group Last Call, intended as Proposed Standard and expiring on 24 December 2026. It is not an RFC, implementation report or deployment result.
  • A matching initiator HMAC proves possession for one exchange. It does not prove how the token was minted, whether the serving set agrees that it remains unused, whether current privileges still apply, or whether an application session was restored.
  • Safe operation requires separate receipts for predecessor authentication, token issuance and mechanism pinning, channel-binding selection, atomic replay/use-count state, responder verification, durable revocation, current authorization and observed application outcome.

The proof is local to a token record

The attraction of Hashed Token authentication is concrete. A client that has already completed a stronger authentication can request an ephemeral secret, lose its connection and later prove possession of that secret in one round trip. The server does not need to repeat the entire stronger ceremony merely because Wi-Fi gave way to mobile data or a transport path disappeared.

The proof is also narrower than the phrase “session resumed” suggests. The responder receives an authentication identity, optional values and an HMAC. It calculates the expected HMAC from the stored token and the selected channel-binding input. Equality establishes that the sender knew the shared secret used for that calculation. Nothing inside that equality states which stronger login created the record, which application-state generation the record names, or whether another node already accepted the same token.

That distinction matters whenever token state is distributed. Entropy can make guessing infeasible without making consumption atomic. A token can be random, unexpired and correctly bound to a mechanism while two replicas disagree about its use counter. The first successful proof then creates an operational obligation: record the use or revoke the token in a state that every eligible verifier will observe before it can grant a second success.

The draft's example sequence ends with the service revoking a successfully used token. Its normative requirements recommend that an application extension provide rotation or revocation and that tokens have limited lifetimes. Those are essential design signals. They are not a database receipt. An operator still has to define the write, its consistency boundary, its failure result and the evidence that convergence occurred.

Two HMACs establish two directions

The initiator HMAC covers the literal role string Initiator, the channel-binding data and the initiator's optional values. The responder HMAC uses the distinct role string Responder, the channel-binding data and the responder's optional values. Role separation prevents one direction's authenticator from being treated casually as the other direction's authenticator.

The responder authenticates the initiator by recomputing and comparing the first value. The initiator must verify the responder message to achieve mutual authentication. A server log that says “client proof valid” therefore records only one side of the exchange. If the client disconnects before verifying the responder HMAC, the server may believe authentication completed while the client has no proof that the peer possessed the same token.

Mutual authentication remains authentication. SASL-HT cannot carry an authorization identity string, does not protect an authorization identity and provides channel binding rather than a SASL security layer. A verified authcid still needs a current account mapping and current authorization policy. It cannot authorize a purchase, configuration change, mailbox action or restored workflow merely because both HMACs were correct.

Authenticated bytes do not acquire authorized meaning

Both messages may include arbitrary key/value pairs. Because those bytes enter the HMAC input, a verifier can detect alteration and attribute them to a party possessing the token. That is useful. It may protect a downgrade hash or another application-defined negotiation value within the exchange.

Integrity is not a schema. The protocol does not make every key known, every value well typed, every combination safe, or every authenticated request permissible. An application still needs an allowlist, parsing rules, conflict handling, versioning and a policy that says which authenticated identity may assert which field. Otherwise an extensibility surface can carry an authentic request for an unauthorized state transition.

The receipt should therefore say more than “HMAC valid”. It should preserve the exact key/value octets, their negotiated schema, the policy version that admitted them and the downstream state change, if any. A later reviewer must be able to distinguish “Alice authenticated this value” from “the service accepted this value as authority to act”.

Channel binding is a selected fact, including when it is empty

Mechanism names encode both a hash and a channel-binding choice. ENDP, UNIQ and EXPR identify different TLS-derived inputs. NONE deliberately supplies an empty binding value. The HMAC can still be valid in that variant; it simply has not proved the token exchange was bound through one of those channel-binding constructions.

An observability system that collapses every HT2-* success into “channel-bound authentication” discards the most important field. The mechanism name, TLS peer identity, binding type and binding value or explicit absence need to be retained together. A control that requires exporter binding must reject or separately classify NONE; it cannot recover that evidence from a successful HMAC later.

The same care applies to issuance. The application extension is recommended to let a client name the intended SASL mechanism. If the token is later used with a different mechanism, authentication must fail. That rule prevents a class of downgrade across mechanism choices only when the minting record preserved the declared mechanism and every verifier consults it. A token stored without that attribute cannot gain mechanism pinning from the exchange name alone.

Early authentication can be replayable without authorizing early action

The draft permits the initiator message in TLS 1.3 early data. It also draws a bright boundary: the early data must not contain further application payload beyond the SASL-HT message and required profile framing, and the responder must abort authentication if more is present. The reason is replay.

That design allows the authentication message to be handled as an idempotent early operation. It does not make arbitrary application work idempotent. A replayed proof might be acceptable only if token-state handling ensures that repeated evaluation cannot create repeated authority, repeated session mutation or repeated downstream action. The safest receipt distinguishes seeing the proof, reserving its use, accepting authentication, emitting the responder proof, committing token consumption and admitting application commands.

The responder may send application-specific data alongside a successful reply after it verifies the early data. That possibility raises another boundary rather than erasing one. The server must know which response data are safe, while the client must still verify the responder authenticator before treating the exchange as mutually authenticated. Fast-path latency is a property of message placement; it is not a verdict about exactly-once execution.

“Short-lived” needs a clock and a counter

The application extension must return a newly generated token with at least 128 bits of entropy. Tokens should have a limited lifetime, based on elapsed time or usage count. Implementations should periodically require a full authentication using a strong SASL mechanism that does not use the HT token.

Each phrase becomes operational only after policy supplies its missing dimensions. Which clock sets issuance and expiry? Is the use counter global, per region or per verifier? What happens during a partition? Does a successful proof reserve a count before the responder message is emitted or consume it afterward? If a node crashes between those events, may the client retry, and how is the earlier result classified?

The answer cannot be inferred from token entropy. Randomness protects against guessing; it does not define lifespan, lineage or revocation. Similarly, the HMAC construction is intentionally unsuitable for long-lived passwords because the token is unsalted and processed with one hash iteration. Treating a SASL-HT token store as a password store would change the object while keeping the label.

Session continuity is a separate state transition

The draft describes re-authentication of a previous session. The application protocol must decide what “previous” means. It may refer to a server-side state object, a client-visible stream position, a mailbox selection, a messaging queue, a device control context or another application epoch. The SASL exchange does not serialize that state.

A valid token can therefore accompany the wrong state generation. The identity may be correct while the server restores an earlier snapshot, a parallel session or no prior state at all. Conversely, an application may deliberately create a fresh session after successful authentication rather than recover the old one. Neither outcome contradicts the HMAC.

The resume receipt should name the application session identifier, predecessor generation, restoration policy, conflict decision and resulting state hash. Only an application-level observation can establish that expected work continued. The protocol-level proof should remain labelled “token possession authenticated”, not “session recovered”.

What a defensible receipt contains

A compact but reviewable record contains the token-record identifier rather than the secret; minting time and issuer; predecessor-authentication class; subject and service; intended mechanism; channel-binding type and a safe digest of its input; TLS peer identity; initiator and responder transcript digests; exact auxiliary-field schema version; replay/use-count reservation; revocation or rotation commit; serving-set convergence; authorization-policy version; restored session generation; admitted operation; and observed result.

Sensitive material should not be copied merely to make the log feel complete. The token, raw exporter and reusable authenticators require careful custody. The objective is a linked set of non-secret receipts that can show where the chain stopped without creating a second authentication database.

That structure also preserves honest failure language. “Unknown user”, “invalid token” and a deliberately substituted “other error” are protocol responses with disclosure trade-offs. They are not automatically incident causes. Operations can retain a protected internal reason while emitting a less specific peer-visible description.

Sources