Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Algorithm Agility
updates
- rfc-4556 — Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)
Extracted elements (23)
RFC 4556 hardwired SHA-1 in multiple places (paChecksum, KDF, CMS digest) without negotiation or discovery mechanisms. Following Wang et al.'s 2004 collision attacks on MD4/MD5/SHA-1 and IETF's BCP 201 call for algorithm agility, this document removes those hardwired dependencies to allow incremental deployment of newer algorithms.
The KDF negotiation embeds the client principal name (partyUInfo) and TGS name (partyVInfo) plus the full AS-REQ and PA-PK-AS-REP in PkinitSuppPubInfo, providing cryptographic binding between pre-authentication data and ticket exchange that addresses the paChecksum weakness when Diffie-Hellman is used.
An old client receiving a new KDC error containing TD-CMS-DIGEST-ALGORITHMS-DATA or TD-CERT-DIGEST-ALGORITHMS-DATA typed data will silently ignore those unknown elements, since typed data encoding allows unknown elements to be skipped.
An old KDC receiving a new client's AuthPack with the supportedKDFs extension will ignore it as an unknown extension and respond without the kdf field, falling back to the RFC 4556 KDF; new clients must detect this and apply local policy on whether to accept the old KDF.
A new client interoperating with an old KDC MUST use the RFC 4556 KDF or reject the reply if local policy forbids the use of the old KDF when the kdf field is absent in the reply.
If none of the KDFs supported by the client is acceptable to the KDC, the KDC MUST reply with the new error code KDC_ERR_NO_ACCEPTABLE_KDF (100).
If the supportedKDFs field is absent in the request, the KDC MUST omit the kdf field in the reply and use the key derivation function from Section 3.2.3.1 of RFC 4556.
If the supportedKDFs field is present in the client request, a KDC conforming to this specification MUST choose one of the KDFs supported by the client and indicate its selection in the kdf field in the reply.
Implementations conforming to this specification MUST support id-pkinit-kdf-ah-sha256 as a KDF algorithm.
When a KDC conforming to this specification returns KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED, it MAY include a TD_CERT_DIGEST_ALGORITHMS typed data element listing acceptable digest algorithms for the client's X.509 certificate in decreasing order of preference.
Four KDF OIDs are defined under id-pkinit-kdf: id-pkinit-kdf-ah-sha1 (sha1(1)), id-pkinit-kdf-ah-sha256 (sha256(2)), id-pkinit-kdf-ah-sha512 (sha512(3)), and id-pkinit-kdf-ah-sha384 (sha384(4)), each using the SP800-56A one-step ASN.1 hash-based KDF with the respective hash function.
KDFAlgorithmId is a new ASN.1 SEQUENCE containing kdf-id ([0] OBJECT IDENTIFIER) that identifies a specific KDF algorithm for PKINIT use.
The AuthPack structure from RFC 4556 is extended with a new optional field supportedKDFs ([4] SEQUENCE OF KDFAlgorithmId), which carries an unordered set of KDF object identifiers supported by the PKINIT client.
The DHRepInfo structure from RFC 4556 is extended with a new optional field kdf ([2] KDFAlgorithmId), which identifies the KDF selected by the KDC for Diffie-Hellman key derivation.
The KDF uses a counter-based construction: reps = ceiling(L/H_outputBits), iterating Hashi = H(counter || Z || OtherInfo) with a 32-bit big-endian counter, then concatenating hash outputs and truncating to L bits, with the result fed into random-to-key() per RFC 3961.
IANA assigned two new entries in the Kerberos 'Pre-authentication and Typed Data' registry (created by RFC 6113 Section 7.1): TD-CMS-DIGEST-ALGORITHMS = 111 and TD-CERT-DIGEST-ALGORITHMS = 112, both referencing RFC 8636.
For anonymous PKINIT (RFC 8062), the AuthPack is unsigned, so an attacker can trivially remove the supportedKDFs field and force a downgrade to the old RFC 4556 KDF. The kdf field in DHRepInfo is also unauthenticated and could be altered, though this typically causes a decryption failure rather than a silent downgrade.
The paChecksum remains fixed at SHA-1 in this update; if an attacker mounts a second-preimage attack on SHA-1 to substitute the request body, the KDC will not detect it, but a client that negotiated a new KDF will detect the substitution via decryption failure.
The TD_CMS_DATA_DIGEST_ALGORITHMS and TD_CERT_DIGEST_ALGORITHMS discovery mechanisms use unauthenticated Kerberos error messages; an attacker can forge these errors to attempt a downgrade to weaker digest algorithms. Local policy governs whether clients accept such downgrades.
OtherInfo is an ASN.1 SEQUENCE containing algorithmID (AlgorithmIdentifier), partyUInfo ([0] OCTET STRING), partyVInfo ([1] OCTET STRING), suppPubInfo ([2] OCTET STRING OPTIONAL), and suppPrivInfo ([3] OCTET STRING OPTIONAL), used as input to the PKINIT KDF.
PkinitSuppPubInfo is an ASN.1 SEQUENCE with enctype ([0] Int32), as-REQ ([1] OCTET STRING containing DER-encoded AS-REQ without 4-octet TCP length prefix), and pk-as-rep ([2] OCTET STRING containing DER-encoded PA-PK-AS-REP), providing cryptographic binding between pre-authentication data and ticket exchange.
TD-CERT-DIGEST-ALGORITHMS-DATA is an ASN.1 DER-encoded SEQUENCE with allowedAlgorithms ([0] SEQUENCE OF AlgorithmIdentifier) and optional rejectedAlgorithm ([1] AlgorithmIdentifier), carried in typed data value 112 (td-cert-digest-algorithms).
TD-CMS-DIGEST-ALGORITHMS-DATA is a SEQUENCE OF AlgorithmIdentifier, ASN.1 DER-encoded, carried in typed data value 111 (td-cms-digest-algorithms), listing CMS digest algorithms acceptable to the KDC in decreasing preference order.