]> Red Hat, Inc.

23-25 rue Delarivière Lefoullon Puteaux 92800 France jrische@redhat.com

Security Common Authentication Technology Next Generation Kerberos PKINIT cryptographic deprecation SHA-1 Diffie-Hellman MODP RSA This document deprecates several outdated cryptographic algorithms and parameters from the Kerberos PKINIT specification (RFC 4556) and its extensions (RFC 5349, RFC 8636). Specifically, it deprecates the RSA key transport mechanism for reply key delivery, the Diffie-Hellman MODP group 2 (1024-bit) parameter, the SHA-1-based octetstring2key key derivation function, and the sha1WithRSAEncryption CMS signature algorithm. It also defines a new paChecksum2 field in the PKAuthenticator structure to provide checksum algorithm agility. This document updates RFC 4556, RFC 5349, and RFC 8636. Discussion Venues Discussion of this document takes place on the Common Authentication Technology Next Generation Working Group mailing list (kitten@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction Since the publication of the initial PKINIT specification in , significant advances in cryptanalysis and computing power have rendered several of its cryptographic elements inadequate for current use. BCP 201 stresses the importance of proactively deprecating weakened algorithms. This document addresses five such elements. The RSA key transport mechanism defined in Section 3.2.3.2 relies on RSAES-PKCS-v1_5, which has been subject to Bleichenbacher- style adaptive chosen-ciphertext attacks since 1998 and to numerous side-channel attacks documented in . It also prevents the client from contributing entropy to the session key. The 1024-bit Diffie-Hellman MODP group 2 ( Section 6.2, Appendix E.2), mandatory in , provides at most approximately 80 bits of security strength. NIST has deprecated 1024-bit discrete-logarithm key sizes and major cryptographic libraries such as OpenSSL no longer support this group, creating practical interoperability failures in PKINIT deployments. SHA-1 has been demonstrably broken for collision resistance since 2017. NIST disallowed SHA-1 for digital signature generation in 2013, and formally deprecated it in TLS 1.2. Three elements of the PKINIT protocol depend on SHA-1: the sha1WithRSAEncryption CMS signature algorithm mandated in Section 3.2.2, the octetstring2key() key derivation function in Section 3.2.3.1, and the hardwired SHA-1 checksum in the paChecksum field of PKAuthenticator. introduced negotiable KDFs and acknowledged the paChecksum limitation but left both the KDF negotiation and the checksum algorithm as optional. This specification:

1. Deprecates the RSA key transport mechanism ().
2. Deprecates MODP group 2 ().
3. Makes the supportedKDFs field mandatory and deprecates the SHA-1 KDF ().
4. Deprecates sha1WithRSAEncryption and ecdsa-with-SHA1 in CMS signatures ().
5. Defines paChecksum2 for checksum algorithm agility ().

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

RSA Key Transport Implementations conforming to this specification MUST NOT use the RSA key transport mechanism (the encKeyPack choice of PA-PK-AS-REP) defined in Section 3.2.3.2. Clients conforming to this specification:

• MUST include the clientPublicValue field in the AuthPack structure, containing a Diffie-Hellman or ECDH public key.
• MUST NOT omit clientPublicValue in order to request RSA key transport.

KDCs conforming to this specification:

• MUST reply using the dhInfo choice in PA-PK-AS-REP (the Diffie-Hellman key delivery method described in Section 3.2.3.1 or the ECDH method described in ).
• MUST NOT reply using the encKeyPack choice in PA-PK-AS-REP.
• SHOULD return KDC_ERR_PREAUTH_FAILED if a client request omits the clientPublicValue field.

MODP Group 2 Implementations conforming to this specification MUST NOT use Diffie-Hellman MODP group 2 (the Second Oakley Group, 1024-bit prime). The requirements from Section 3.2.3.1 are updated as follows:

• Implementations MUST support MODP group 14 (2048-bit prime, Section 3).
• Implementations SHOULD support MODP group 16 (4096-bit prime, Section 5).
• Implementations MAY support additional MODP groups defined in with a modulus size of 2048 bits or larger.

When a client sends a clientPublicValue using a deprecated group, a KDC conforming to this specification MUST reject the request and SHOULD reply with TD-DH-PARAMETERS containing only groups that meet the minimum strength requirements defined above.

SHA-1-Based octetstring2key() KDF The supportedKDFs field defined in is now REQUIRED. Clients conforming to this specification:

• MUST include the supportedKDFs field in the AuthPack structure.
• MUST include id-pkinit-kdf-ah-sha256 in the supportedKDFs set.
• SHOULD include id-pkinit-kdf-ah-sha384 and id-pkinit-kdf-ah-sha512 in the supportedKDFs set.
• MUST NOT include id-pkinit-kdf-ah-sha1 in the supportedKDFs set.

KDCs conforming to this specification:

• MUST select a KDF from the supportedKDFs field in the request.
• MUST NOT select id-pkinit-kdf-ah-sha1.
• If the supportedKDFs field is absent from the request, the KDC SHOULD reject the request and reply with KDC_ERR_NO_ACCEPTABLE_KDF (error code 100, ). Alternatively, the KDC MAY fall back to the octetstring2key() KDF if local policy permits interoperability with legacy clients.

CMS Signature Algorithms Implementations conforming to this specification MUST NOT use sha1WithRSAEncryption for generating CMS signatures in PKINIT messages. For RSA signatures, the following requirements apply:

• Implementations MUST support sha256WithRSAEncryption .
• Implementations SHOULD support sha384WithRSAEncryption and sha512WithRSAEncryption .

For ECDSA signatures, the requirements from Section 3 are updated as follows:

• Implementations MUST support ecdsa-with-SHA256.
• Implementations SHOULD support ecdsa-with-SHA384 and ecdsa-with-SHA512.
• Implementations SHOULD NOT use ecdsa-with-SHA1. The SHOULD requirement for ecdsa-with-SHA1 in is downgraded.

For CMS digest algorithms, the corresponding requirements apply:

• Implementations MUST support id-sha256.
• Implementations SHOULD support id-sha384 and id-sha512.
• Implementations MUST NOT use id-sha1 for generating CMS signatures in PKINIT messages.

When a KDC receives a CMS SignedData from a client that uses sha1WithRSAEncryption, ecdsa-with-SHA1, or id-sha1 as the digest algorithm, the KDC SHOULD reject the request. A KDC MAY accept SHA-1-based signatures from legacy clients if local policy permits, but this is NOT RECOMMENDED.

paChecksum2 Extension This specification defines a new PAChecksum2 type and extends the PKAuthenticator structure from with a paChecksum2 field at tag [5]. The checksum field contains the digest computed over KDC-REQ-BODY using the algorithm identified by algorithmIdentifier. The parameters field of the AlgorithmIdentifier MUST be absent. The PKAuthenticator structure from is extended as follows: The following digest algorithms are defined for use with paChecksum2:

• Implementations MUST support SHA-256 (OID 2.16.840.1.101.3.4.2.1, ).
• Implementations MAY support SHA-384 (OID 2.16.840.1.101.3.4.2.2, ) and SHA-512 (OID 2.16.840.1.101.3.4.2.3, ).

Client behavior:

A client constructing a PKINIT request conforming to this specification MUST include the paChecksum2 field and SHOULD include the paChecksum field (SHA-1, per ). Both checksums, when present, are computed over the same KDC-REQ-BODY input.

KDC validation:

A KDC conforming to this specification MUST require paChecksum2 to be present in the request. If paChecksum2 is absent, the KDC returns KDC_ERR_PA_CHECKSUM_MUST_BE_INCLUDED (error code 79, ). The KDC MUST validate paChecksum2. If paChecksum is also present, the KDC MUST validate it as well. The KDC returns the following errors:

• KDC_ERR_SUMTYPE_NOSUPP (error code 15, ): if the digest algorithm in paChecksum2.algorithmIdentifier is not supported by the KDC.
• KRB_AP_ERR_MODIFIED (error code 41, ): if verification of paChecksum2 fails, or if paChecksum is present and its verification fails.

IANA Considerations This document has no IANA actions.

Security Considerations KDCs and clients MAY accept legacy algorithm choices from peers that have not been updated to conform to this specification, subject to local policy. Implementations SHOULD log such fallback events. Deployments are encouraged to coordinate a phased rollout in which the KDC accepts (but does not yet require) the new fields before enforcement is enabled.

References Normative References This document defines new Modular Exponential (MODP) Groups for the Internet Key Exchange (IKE) protocol. It documents the well known and used 1536 bit group 5, and also defines new 2048, 3072, 4096, 6144, and 8192 bit Diffie-Hellman groups numbered starting at 14. The selection of the primes for theses groups follows the criteria established by Richard Schroeppel. [STANDARDS-TRACK] This document provides an overview and specification of Version 5 of the Kerberos protocol, and it obsoletes RFC 1510 to clarify aspects of the protocol and its intended use that require more detailed or clearer explanation than was provided in RFC 1510. This document is intended to provide a detailed description of the protocol, suitable for implementation, together with descriptions of the appropriate use of protocol messages and fields within those messages. [STANDARDS-TRACK] This document describes protocol extensions (hereafter called PKINIT) to the Kerberos protocol specification. These extensions provide a method for integrating public key cryptography into the initial authentication exchange, by using asymmetric-key signature and/or encryption algorithms in pre-authentication data fields. [STANDARDS-TRACK] This document describes the use of Elliptic Curve certificates, Elliptic Curve signature schemes and Elliptic Curve Diffie-Hellman (ECDH) key agreement within the framework of PKINIT -- the Kerberos Version 5 extension that provides for the use of public key cryptography. This memo provides information for the Internet community. This document describes the conventions for using the Secure Hash Algorithm (SHA) message digest algorithms (SHA-224, SHA-256, SHA-384, SHA-512) with the Cryptographic Message Syntax (CMS). It also describes the conventions for using these algorithms with the CMS and the Digital Signature Algorithm (DSA), Rivest Shamir Adleman (RSA), and Elliptic Curve DSA (ECDSA) signature algorithms. Further, it provides SMIMECapabilities attribute values for each algorithm. [STANDARDS-TRACK] This document updates the Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) standard (RFC 4556) to remove protocol structures tied to specific cryptographic algorithms. The PKINIT key derivation function is made negotiable, and the digest algorithms for signing the pre-authentication data and the client's X.509 certificates are made discoverable. These changes provide preemptive protection against vulnerabilities discovered in the future in any specific cryptographic algorithm and allow incremental deployment of newer algorithms. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This memo describes a hybrid protocol. The purpose is to negotiate, and provide authenticated keying material for, security associations in a protected manner. [STANDARDS-TRACK] This document describes a protocol, named OAKLEY, by which two authenticated parties can agree on secure and secret keying material. The basic mechanism is the Diffie-Hellman key exchange algorithm. This memo provides information for the Internet community. Many IETF protocols use cryptographic algorithms to provide confidentiality, integrity, authentication, or digital signature. Communicating peers must support a common set of cryptographic algorithms for these mechanisms to work properly. This memo provides guidelines to ensure that protocols have the ability to migrate from one mandatory-to-implement algorithm suite to another over time. This document describes how to further extend the Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) extension (defined in RFC 4556) to exchange an opaque data blob that a Key Distribution Center (KDC) can validate to ensure that the client is currently in possession of the private key during a PKINIT Authentication Service (AS) exchange. The MD5 and SHA-1 hashing algorithms are increasingly vulnerable to attack, and this document deprecates their use in TLS 1.2 and DTLS 1.2 digital signatures. However, this document does not deprecate SHA-1 with Hashed Message Authentication Code (HMAC), as used in record protection. This document updates RFC 5246. Red Hat, Inc. Microsoft Corporation

Acknowledgements The paChecksum2 extension is based on the PAChecksum2 structure first defined in Microsoft's specification.