Summary

  • RFC 1964 places channel-binding data, context-service flags and optional KRB_CRED delegation inside the initiator’s authenticator checksum, while the mechanism OID and TOK_ID identify the envelope and token class.
  • Sixteen zero binding bytes mean no bindings were supplied; a one-way KRB_AP_REQ has no acceptor confirmation; KRB_CRED transfer, MIC, Wrap and sequence state each require separate downstream evidence before anyone can claim authorization or application success.

A security trace can be full of objects that look like receipts. It may show the Kerberos V5 GSS-API object identifier, 01 00, a valid ticket, six service bits and a sequence number. Yet the decisive question is not whether the trace contains impressive cryptographic structure. It is what each structure was designed to prove.

RFC 1964, published in June 1996, defines the protocol-visible mechanism placed above Kerberos V5. Its original Proposed Standard mechanism OID is 1.2.840.113554.1.2.2. The initial context token frames a KRB_AP_REQ and prefixes it with the two-byte token identifier 01 00. A response KRB_AP_REP uses 02 00; KRB_ERROR uses 03 00. The same framing discipline extends to per-message and deletion tokens. The type code gives a parser a safe first answer—what grammar should be applied—without answering whether the token is authentic, current, connected to the expected context or accepted by an application.

The checksum is a compact context proposal

Inside the KRB_AP_REQ authenticator, RFC 1964 assigns checksum type 0x8003 a special job. Its value begins with a little-endian length of 16, followed by a 16-byte MD5 digest computed over the non-null elements of the caller’s channel-binding structure. Length fields participate even when zero. If the caller supplies GSS_C_NO_BINDINGS, the digest field is not a fingerprint of a mysterious default channel: it is sixteen zero bytes.

That negative meaning matters. Zero does not identify TLS, an address pair, a socket, a host or a protected tunnel. It records that the caller provided no bindings for this mechanism exchange. Later work on channel binding made the application obligation clearer: peers must know in advance which binding they intend to use. The 1996 field can carry a comparison value; it cannot invent channel identity when its input is absent.

Four more bytes carry context flags. Delegation, mutual authentication, replay detection and sequencing are set as the logical AND of what the initiator requested and what the mechanism can make available to the caller. Confidentiality and integrity bits indicate that those per-message services are available. This is a carefully limited vocabulary. A mutual bit is a request for a two-way exchange, not the returned exchange. An integrity bit says a service can be used, not that a particular business message was verified. A replay bit is not evidence that a replay window remained enabled throughout an application session.

Mutual authentication has a visible return path

RFC 1964 makes the one-way case unusually easy to identify. When mutual_req is not set, the target sends no confirmation token in response to the KRB_AP_REQ. The initiator has sent an authenticated request, but it has not received the target’s confirmation that the authentication succeeded.

An application that needs confirmation requests mutual authentication. The request appears both as mutual-required in the KRB_AP_REQ options and as the mutual flag in the authenticator checksum. The target then returns a framed KRB_AP_REP or KRB_ERROR. These alternatives must never be collapsed into “a response was received”. A valid KRB_AP_REP completes the successful mutual context-establishment exchange; KRB_ERROR reports failure. Even the successful reply remains a context receipt. It does not prove that an application parsed a subsequent command, authorized it or committed a state change.

Delegation transfers capacity, not permission

When delegation is active, the checksum grows beyond its 24-byte base. It carries delegation option 1, a length and a Kerberos KRB_CRED message. RFC 1964 specifies that a transferred ticket-granting ticket has its FORWARDABLE flag set.

This can move real operating power. An acceptor holding a usable delegated credential may seek service tickets and act along another path. But transport and authority are different facts. The delegation flag should be joined to the option, length, decrypted KRB_CRED, credential-cache handling and the later service-ticket request. The downstream service then applies its own authorization policy. A forwardable TGT may enable that attempt; it does not predetermine the result.

This is the sharpest operational boundary in the mechanism. If a trace stops at KRB_CRED receipt, it can support a claim about credential transfer. It cannot support a claim that a file was opened, an account was changed or an administrator approved impersonation.

Message protection is another ledger

RFC 1964 assigns 01 01 to MIC and 02 01 to Wrap. A MIC token protects the integrity of separate user data. Wrap carries data with integrity and, when selected, confidentiality. Both carry protected sequence state and a repeated direction indicator. Replay and out-of-sequence detection, however, are optional services and may be disabled at the caller’s request.

The result is useful but narrow evidence. A verified MIC connects bytes to a context and checksum. A successfully unwrapped token establishes the mechanism’s protection result for those bytes. Sequence processing can identify duplicate, old or unordered tokens when that service is active. None shows that the application understood the message, accepted the principal’s authority, wrote the intended record or returned a successful business response.

RFC 4121 later replaced important parts of the per-message format, while RFC 6649 deprecated weak legacy algorithms. Those updates are essential to present-day security assessment. They do not change the historical lesson: token class, cryptographic validation, context service, credential delegation, authorization and application effect are adjacent layers, not synonyms.

Heng Lu’s Running-Code Primacy is useful here as an editorial discipline rather than a protocol source. Read every symbol through the executable transition it can actually support. The OID selects a mechanism. TOK_ID selects a grammar. The binding digest records an input. Flags report requested-and-available services. KRB_AP_REP closes a mutual exchange. KRB_CRED transfers a credential. MIC and Wrap protect messages. Only the next system can issue the next receipt.

Sources