Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Channel Binding Hash Agility
updates
- rfc-4121 — The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2
Extracted elements (12)
MD5 weaknesses (documented in RFC 6151) motivate this update. RFC 4121 used MD5 to calculate channel binding verifiers, but newly discovered vulnerabilities require the ability to use stronger hash algorithms negotiated via the Kerberos crypto framework (RFC 3961).
The update makes use of the last extensible field (Exts) in the Kerberos client-server exchange message, and additionally defines an extension framework to allow future protocol extensions without breaking interoperability with older implementations.
If multiple extensions are present in the Exts field, there MUST be at most one instance of a given extension type.
Initiators MUST populate the Bnd field in order to maintain interoperability with existing acceptors.
Initiators MUST populate the extension field (Exts) defined in this document when generating a channel binding verifier.
Initiators that are unwilling to use an MD5 hash of the channel bindings MUST set the Bnd field to sixteen octets of hex value FF.
When channel binding is used, the Exts field MUST include the channel binding extension with data-type 0x00000000.
The Channel Binding Extension (data-type 0x00000000) carries the output of applying the Kerberos V get_mic operation (RFC 3961) with key usage number 43 to the channel binding data. The key used is the sub-session key from the authenticator if present; otherwise the session key from the ticket. The get_mic algorithm is the 'required checksum mechanism' for the encryption type of the key used.
IANA created a new top-level registry 'Kerberos V GSS-API Mechanism Parameters' with a sub-registry 'Kerberos V GSS-API Mechanism Extension Types' (fields: Type Number, Type Name, Description, Reference). Initial registration: 0x00000000 'Channel Binding MIC'. Ranges: 0x00000000-0x000003FF (IETF Review), 0x00000400-0xFFFFF3FF (Specification Required), 0xFFFFF400-0xFFFFFFFF (Private Use).
With this mechanism, initiators get no indication as to whether the acceptors check or ignore channel bindings. It is up to the application whether or not to enforce the use of channel bindings.
Each individual extension within the Exts field is encoded as: type (big-endian unsigned 32-bit integer), length (big-endian unsigned 32-bit integer, length of data in octets), and data (octet string). Extensions are concatenated sequentially.
The 0x8003 GSS checksum structure consists of: Lgth (octets 0-3, little-endian, value 0x10000000), Bnd (octets 4-19, channel binding info), Flags (octets 20-23, little-endian), optional DlgOpt (octets 24-25), optional Dlgth (octets 26-27), optional Deleg (octets 28 to n-1), and Exts (octets n to last). This extends the RFC 4121 structure by formally defining the Exts field.