The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2
updated by
- rfc-5896 — Generic Security Service Application Program Interface (GSS-API): Delegate if Approved by Policy
- rfc-6112 — Anonymity Support for Kerberos
- rfc-6542 — Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Channel Binding Hash Agility
- rfc-6649 — Deprecate DES, RC4-HMAC-EXP, and Other Weak Cryptographic Algorithms in Kerberos
- rfc-8062 — Anonymity Support for Kerberos
updates
- rfc-1964 — The Kerberos Version 5 GSS-API Mechanism
Extracted elements (26)
The QOP value in per-message tokens is ignored under this mechanism because the encryption and checksum algorithms are now implicitly defined by the session key or subkey's crypto profile, making explicit algorithm identifiers (as used in RFC 1964) unnecessary. This avoids the risk of using an algorithm mismatched to the key type.
The RRC (Right Rotation Count) field was added specifically to allow in-place encryption by SSPI applications that only provide a single buffer without separate header and trailer regions. This is an SSPI-compatibility accommodation rather than a cryptographic requirement.
GSS_Unwrap() and GSS_VerifyMIC() implementations can distinguish token formats by inspecting the first octet: if it is 0x60, the token carries generic GSS-API pseudo-ASN.1 framing (RFC 1964 style); otherwise the first two octets are the TOK_ID identifying the new RFC 4121 token format.
The new token formats defined in RFC 4121 are only recognized by new implementations. For backward compatibility with RFC 1964 peers, it is RECOMMENDED that new token formats SHOULD be used only when both peers are known to support the new mechanism—for example, when 'newer' enctypes are in use—to avoid requiring out-of-band negotiation or retry logic.
All implementations MUST be capable of accepting input buffers of at least 16K octets for GSS_GetMIC(), GSS_VerifyMIC(), and GSS_Wrap(), and MUST accept the GSS_Wrap() output token for a 16K input as input to GSS_Unwrap(). Implementations SHOULD support 64K input buffers and MAY support larger sizes.
If an unknown TOK_ID is received in the initial context establishment token, the receiver MUST return GSS_S_CONTINUE_NEEDED major status, and the returned output token MUST contain a KRB_ERROR message with error code KRB_AP_ERR_MSG_TYPE.
If the context acceptor asserts a subkey in the AP-REP message, that subkey becomes the base key and all subsequent per-message tokens MUST be flagged with 'AcceptorSubkey'. If no acceptor subkey is asserted, the base key is the initiator's subkey from AP-REQ, or the session key from the service ticket if the initiator also asserts no subkey.
Initiators that do not support checksum extensions MUST NOT include more than 24 octets (no delegation) or more than 28 octets plus KRB_CRED (with delegation) in the checksum field. Acceptors that do not understand extensions MUST ignore octets past the Flags field (no delegation) or past the Deleg field (with delegation).
The checksum type in the authenticator MUST be 0x8003. When delegation is used, the KRB_CRED message's EncryptedData field MUST be encrypted in the session key of the ticket used to authenticate the context, and the forwarded TGT SHOULD have its forwardable flag set.
The new token formats specified in this document MUST be used with all 'newer' encryption types (as defined in RFC 4120 section 3.1.3) and MAY be used with non-newer encryption types if both initiator and acceptor have negotiated support.
Token identifiers (TOK_ID) in the range 0x60 0x00 through 0x60 0xFF inclusive are reserved and SHALL NOT be assigned. This enables unambiguous detection of the generic GSS-API pseudo-ASN.1 framing by inspecting the first two octets: a leading 0x60 byte indicates the outer GSS-API wrapper is present.
Channel bindings are conveyed in the 16-octet Bnd field as an MD5 hash over all non-null components of the gss_channel_bindings_struct in declaration order, with integer and length fields encoded as 4-octet little-endian values. If GSS_C_NO_BINDINGS is passed, Bnd is set to 16 zero octets. If the acceptor passes GSS_C_NO_CHANNEL_BINDINGS, it MAY ignore bindings from the initiator.
Context deletion tokens are empty in this mechanism. Both peers independently invoke GSS_Delete_sec_context() with a null output_context_token buffer, signaling that no deletion token is emitted or consumed. Implementations should delete locally stored context information.
For Wrap tokens with confidentiality, the 16-octet token header is appended to plaintext before encryption: the layout is {'header' | encrypt(plaintext-data | filler | 'header')}. For Wrap tokens without confidentiality: {'header' | plaintext-data | get_mic(plaintext-data | 'header')}. MIC checksums cover plaintext then the 16-octet token header.
Four key usage values are defined for deriving per-message keys from the session key or subkey: KG-USAGE-ACCEPTOR-SEAL (22) and KG-USAGE-ACCEPTOR-SIGN (23) for the acceptor, KG-USAGE-INITIATOR-SEAL (24) and KG-USAGE-INITIATOR-SIGN (25) for the initiator. Sign usages apply to MIC tokens; Seal usages apply to Wrap tokens regardless of confidentiality.
Per-message tokens use a 64-bit big-endian sequence number (SND_SEQ) to distinguish intentionally repeated messages from replays. After each GSS_GetMIC() or GSS_Wrap() call, the sender's sequence number SHALL be incremented by one.
Channel bindings are validated only by the acceptor. If the acceptor does not use channel bindings in GSS_Accept_sec_context, it can ignore the bindings carried in the authenticator checksum without proving to the initiator that it holds the same bindings—even when mutual authentication was requested. Application designers using channel bindings to scope contexts to specific network addresses or to bind secure channels must account for this limitation.
Session key encryption types are selected unilaterally by the KDC with no GSS-API-level algorithm negotiation. Administrators must control acceptable session key enctypes through KDC policy per acceptor principal. Sharing a service principal (e.g., 'host') between GSSAPI and non-GSSAPI services can force weaker enctype selection if the GSSAPI implementation does not support newer algorithms such as AES.
Context establishment tokens use a two-octet big-endian TOK_ID field followed by a Kerberos message: KRB_AP_REQ=0x01 0x00, KRB_AP_REP=0x02 0x00, KRB_ERROR=0x03 0x00. The outer wrapper follows RFC 2743 section 3.1 GSS-API framing with MechType OID and innerToken.
MIC tokens (TOK_ID=0x04 0x04) have a 16-octet fixed header: octets 0–1 TOK_ID, octet 2 Flags, octets 3–7 Filler (0xFF×5), octets 8–15 SND_SEQ (64-bit big-endian), octets 16–last SGN_CKSUM (checksum over signed data and octets 0–15). The filler is included in checksum calculation.
The authenticator checksum field in KRB_AP_REQ has a structured layout: octets 0–3 Lgth (little-endian, value 16), octets 4–19 Bnd (MD5 of channel bindings), octets 20–23 Flags (little-endian context flags), and optional octets 24–25 DlgOpt (=1), 26–27 Dlgth, 28..(n-1) Deleg (KRB_CRED), n..last Exts. Minimum length is 24 octets without delegation and 28 + Dlgth with delegation.
The checksum Flags field (octets 20–23, little-endian) encodes context-establishment options: GSS_C_DELEG_FLAG=1, GSS_C_MUTUAL_FLAG=2, GSS_C_REPLAY_FLAG=4, GSS_C_SEQUENCE_FLAG=8, GSS_C_CONF_FLAG=16, GSS_C_INTEG_FLAG=32. Bits 12–19 (values 4096–524288) are reserved for legacy vendor extensions; all other undefined bits MUST be cleared by the sender and MUST be ignored by the receiver.
The EC (Extra Count) field is a two-octet big-endian integer. In Wrap tokens with confidentiality it encodes the number of filler octets appended to plaintext before encryption; in Wrap tokens without confidentiality it encodes the number of octets in the trailing checksum.
The per-message Flags field is a one-octet integer: bit 0 (SentByAcceptor) indicates the sender is the context acceptor; bit 1 (Sealed) indicates Wrap token confidentiality (SHALL NOT be set in MIC tokens); bit 2 (AcceptorSubkey) indicates an acceptor-asserted subkey protects the message. All other bits are reserved, MUST be cleared by sender, and MUST be ignored by receiver.
The RRC (Right Rotation Count) field is a two-octet big-endian integer in Wrap tokens. Excluding the first 16 header octets, the token body is rotated right by RRC octets to allow in-place encryption for SSPI applications that cannot provide separate header and trailer buffers. The receiver MUST handle all rotation count values including those exceeding the token length.
Wrap tokens (TOK_ID=0x05 0x04) have a 16-octet header: octets 0–1 TOK_ID, octet 2 Flags, octet 3 Filler (0xFF), octets 4–5 EC (big-endian), octets 6–7 RRC (big-endian), octets 8–15 SND_SEQ (64-bit big-endian), octets 16–last Data (encrypted ciphertext or plaintext+checksum).