Extended Kerberos Version 5 Key Distribution Center (KDC) Exchanges over TCP
updates
- rfc-4120 — The Kerberos Network Authentication Service (V5)
Extracted elements (17)
A 4-octet zero value is used as the KDC's success acknowledgment because it can never be sent by a conforming RFC 4120 implementation that does not support this extension (a KRB-ERROR is always non-zero size), ensuring unambiguous signaling.
The high-order bit in the TCP length field was already reserved in RFC 4120 section 7.2.2 for future expansion. This document repurposes that reserved bit as an extension signaling mechanism, avoiding any backward-incompatible change to the base Kerberos framing.
Some TCP-capable KDC implementations (including MIT Kerberos and Heimdal at the time of writing) did not follow RFC 4120 properly with respect to the high bit, and may close the TCP connection without any response or log an error. Clients experiencing this should assume the KDC does not support the extension mechanism and may remember this on a per-realm basis.
Each extension MUST describe the structure of protocol data beyond the length field and the behavior of client and KDC. If an extension reserves multiple bits, it MUST describe how they interact.
If a KDC receives a PROBE or does not support all requested extensions, it MUST return 4 octets with the high bit set and the remaining bitmask indicating which extensions it supports, then MUST wait for the client to send a second 4-octet value.
If a KDC receives a request for a set of extensions that it supports, it MUST respond by sending a 4-octet zero value (0x00000000). The KDC MAY directly send additional data after the zero value without waiting for the client to respond.
If the client's second 4-octet value is a PROBE or requests an unsupported extension, the KDC MUST close the connection. This allows the client to shut down a session when the KDC lacks a required extension.
The client and KDC SHOULD wait for the other side to respond according to this protocol and SHOULD NOT close the connection prematurely, subject to resource availability considerations.
The client MUST begin by sending a 4-octet value with the high bit set (either a PROBE or an extension request), and MUST NOT send additional data before the server has responded.
The KDC MUST NOT support the extension mechanism if it does not support any extensions. If no extensions are supported, the KDC MUST return a KRB-ERROR with KRB_ERR_FIELD_TOOLONG and MUST close the TCP stream.
When multiple extension bits are set and the requested extensions do not specify how they interact, the KDC MUST treat the request as a PROBE or unsupported extension and proceed with the capability advertisement response.
A PROBE is a 4-octet value with only the high bit set and the extension bitmask all zeros (i.e., the value has the high bit set but no extension bits set). A client sends a PROBE to discover which extensions a KDC supports before committing to a specific extension.
The TCP extension mechanism uses the reserved high-order bit in the initial 4-octet length field. When set, the remaining 31 bits form an 'extension bitmask' where each bit requests a particular TCP-specific Kerberos extension.
IANA created a new 'Kerberos TCP Extensions' registry with 31 bits (0–30). Bits 0–29 are available for registration via IESG Approval (BCP 64); bit 30 is RESERVED and requires a Standards Action to assign.
The initial length field is unprotected, allowing an active attacker to suppress or alter the extension bitmask and mount a downgrade attack — making the client believe the KDC does not support desired extensions. This can be mitigated by client/KDC policy that rejects connections lacking required properties, or by having the negotiated extension include a cryptographic checksum of the offered extensions.
Client state: send high-bit 4-octet value (PROBE or extension request) → wait for KDC response → if KDC returns zero, extension negotiated; if KDC returns high-bit response, send second 4-octet request or close. KDC state: receive high-bit value → if supported, send zero; if PROBE/unsupported, send capability bitmask, wait for second request, then accept or close.
The initial message is a 4-octet value: bit 31 (high bit) set signals use of the extension mechanism; bits 0-30 form the extension bitmask indicating requested extensions. A successful acknowledgment from the KDC is a 4-octet zero value (0x00000000).