PKINIT Algorithm Agility

This document updates PKINIT to remove protocol structures tied to specific cryptographic algorithms. The PKINIT key derivation function is made negotiable, 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 against any specific cryptographic algorithm, and allow incremental deployment of newer algorithms. In August 2004, Xiaoyun Wang's research group reported MD4 collisions generated using hand calculation , alongside attacks on later hash function designs in the MD4, MD5 and SHA family. These attacks and their consequences are discussed in . These discoveries challenged the security of protocols relying on the collision resistance properties of these hashes. The Internet Engineering Task Force (IETF) called for actions to update existing protocols to provide crypto algorithm agility so that protocols support multiple cryptographic algorithms (including hash functions) and provide clean, tested transition strategies between algorithms. This document updates PKINIT to provide crypto algorithm agility. Several protocol structures used in the protocol are either tied to SHA-1, or do not support negotiation or discovery, but are instead based on local policy. The following concerns have been addressed in this update: The checksum algorithm in the authentication request is hardwired to use SHA-1 . The acceptable digest algorithms for signing the authentication data are not discoverable. The key derivation function in Section 3.2.3 of is hardwired to use SHA-1. The acceptable digest algorithms for signing the client X.509 certificates are not discoverable. To address these concerns, new key derivation functions (KDFs), identified by object identifiers, are defined. The PKINIT client provides a list of KDFs in the request and the Key Distribution Center (KDC) picks one in the response, thus a mutually-supported KDF is negotiated. Furthermore, structures are defined to allow the client to discover the Cryptographic Message Syntax (CMS) digest algorithms supported by the KDC for signing the pre-authentication data and signing the client X.509 certificate.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

The paChecksum defined in Section 3.2.1 of provides a cryptographic binding between the client's pre-authentication data and the corresponding Kerberos request body. This also prevents the KDC body from being tampered with. SHA-1 is the only allowed checksum algorithm defined in . This facility relies on the collision resistance properties of the SHA-1 checksum . When the reply key delivery mechanism is based on public key encryption as described in Section 3.2.3. of , the asChecksum in the KDC reply provides the binding between the pre- authentication and the ticket request and response messages, and integrity protection for the unauthenticated clear text in these messages. However, if the reply key delivery mechanism is based on the Diffie-Hellman key agreement as described in Section 3.2.3.1 of , the security provided by using SHA-1 in the paChecksum is weak. In this case, the new KDF selected by the KDC as described in Section 6 provides the cryptographic binding and integrity protection.

When the KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error is returned as described In section 3.2.2 of , implementations comforming to this specification can OPTIONALLY send back a list of supported CMS types signifying the digest algorithms supported by the KDC, in the decreasing preference order. This is accomplished by including a TD_CMS_DATA_DIGEST_ALGORITHMS typed data element in the error data.

The corresponding data for the TD_CMS_DATA_DIGEST_ALGORITHMS contains the ASN.1 Distinguished Encoding Rules (DER) encoded TD-CMS-DIGEST-ALGORITHMS-DATA structure defined as follows:

The algorithm identifiers in the TD-CMS-DIGEST-ALGORITHMS identifiy digest algorithms supported by the KDC. This information sent by the KDC via TD_CMS_DATA_DIGEST_ALGORITHMS can facilitate trouble-shooting when none of the digest algorithms supported by the client is supported by the KDC.

When the client's X.509 certificate is rejected and the KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error is returned as described in section 3.2.2 of , conforming implementations can OPTIONALLY send a list of digest algorithms acceptable by the KDC for use by the Certificate Authority (CA) in signing the client's X.509 certificate, in the decreasing preference order. This is accomplished by including a TD_CERT_DIGEST_ALGORITHMS typed data element in the error data. The corresponding data contains the ASN.1 DER encoding of the structure TD-CERT-DIGEST-ALGORITHMS-DATA defined as follows:

The KDC fills in allowedAlgorithm field with the list of algorithm identifiers that identify digest algorithms that are used by the CA to sign the client's X.509 certificate and acceptable by the KDC in the process of validating the client's X.509 certificate, in the order of decreasing preference. The rejectedAlgorithm field identifies the signing algorithm for use in signing the client's X.509 certificate that has been rejected by the KDC in the process of validating the client's certificate .

Based on and , Section 3.2.3.1 of defines a Key Derivation Function (KDF) that derives a Kerberos protocol key based on the secret value generated by the Diffie-Hellman key exchange. This KDF requires the use of SHA-1 . New KDFs defined in this document based on can be used in conjunction with any hash functions. A new KDF is identified by an object identifier. The following KDF object identifiers are defined:

Where id-pkinit is defined in . The id-pkinit-kdf-ah-sha1 KDF is the ASN.1 structured hash based KDF (HKDF) that uses SHA-1 as the hash function. Similarly id-pkinit-kdf-ah-sha256 and id-pkinit-kdf-ah-sha512 are the ASN.1 structured HKDF using SHA-256 and SHA-512 respectively. To name the input parameters, an abbreviated version of the ASN.1 version of the KDF from is described below, use for the full reference. reps = ceiling (keydatalen/hash length (H)) Initialize a 32-bit, big-endian bit string counter as 1. For i = 1 to reps by 1, do the following: Compute Hashi = H(counter || Z || OtherInfo). Increment counter (modulo 2^32) Set key_material = Hash1 || Hash2 || ... so that length of key is K bits. The above ASN.1 structured HKDF produces a bit string of length K in bits as the keying material, and then the AS reply key is the output of random-to-key() using that returned keying material as the input. The input parameters for these KDFs are provided as follows: The key data length (K) is the key-generation seed length in bits for the Authentication Service (AS) reply key. The enctype of the AS reply key is selected according to . The hash length (H) is 160 bits for id-pkinit-kdf-ah-sha1, 256 bits for id-pkinit-kdf-ah-sha256, 384 bits for id-pkinit-kdf-ah-sha384 and 512 bits for id-pkinit-kdf-ah-sha512. The secret value (Z) is the shared secret value generated by the Diffie-Hellman exchange. The Diffie-Hellman shared value is first padded with leading zeros such that the size of the secret value in octets is the same as that of the modulus, then represented as a string of octets in big-endian order. The algorithm identifier (algorithmID) input parameter is the identifier of the respective KDF. For example, this is id-pkinit-kdf-ah-sha1 if the KDF is the ASN.1 structured HKDF using SHA-1 as the hash. The initiator identifier (partyUInfo) contains the ASN.1 DER encoding of the KRB5PrincipalName that identifies the client as specified in the AS-REQ in the request. The recipient identifier (partyVInfo) contains the ASN.1 DER encoding of the KRB5PrincipalName that identifies the TGS as specified in the AS-REQ in the request. The supplemental public information (suppPubInfo) is the ASN.1 DER encoding of the structure PkinitSuppPubInfo as defined later in this section. The supplemental private information (suppPrivInfo) is absent. The maximum hash input length is 2^64 in bits. The structure for OtherInfo is defined as follows:

The structure PkinitSuppPubInfo is defined as follows:

The PkinitSuppPubInfo structure contains mutually-known public information specific to the authentication exchange. The enctype field is the enctype of the AS reply key as selected according to . The as-REQ field contains the DER encoding of the type AS-REQ in the request sent from the client to the KDC. Note that the as-REQ field does not include the wrapping 4 octet length field when TCP is used. The pk-as-rep field contains the DER encoding of the type PA-PK-AS-REP in the KDC reply. The PkinitSuppPubInfo provides a cryptographic bindings between the pre-authentication data and the corresponding ticket request and response, thus addressing the concerns described in Section 3. The KDF is negotiated between the client and the KDC. The client sends an unordered set of supported KDFs in the request, and the KDC picks one from the set in the reply. To acomplish this, the AuthPack structure in is extended as follows:

The new field supportedKDFs contains an unordered set of KDFs supported by the client. The KDFAlgorithmId structure contains an object identifier that identifies a KDF. The algorithm of the KDF and its parameters are defined by the corresponding specification of that KDF. The DHRepInfo structure in is extended as follows:

The new field kdf in the extended DHRepInfo structure identifies the KDF picked by the KDC. This kdf field MUST be filled by the comforming KDC if the supportedKDFs field is present in the request, and it MUST be one of the KDFs supported by the client as indicated in the request. Which KDF is chosen is a matter of the local policy on the KDC. If the supportedKDFs field is not present in the request, the kdf field in the reply MUST be absent. If the client fills the supportedKDFs field in the request, but the kdf field in the reply is not present, the client can deduce that the KDC is not updated to conform with this specification. In that case, it is a matter of local policy on the client whether to reject the reply when the kdf field is absent in the reply. Implementations comforming to this specification MUST support id-pkinit-kdf-ah-sha256. This document introduces the following new PKINIT error code: KDC_ERR_NO_ACCEPTABLE_KDF 100 If no acceptable KDF is found, the error KDC_ERR_NO_ACCEPTABLE_KDF (100) will be returned..

This section contains test vectors for the KDF defined above.

This document describes negotiation of checksum types, key derivation functions and other cryptographic functions. If negotiation is done unauthenticated, care MUST be taken to accept only acceptable values.

Jeffery Hutzelman, Shawn Emery, Tim Polk and Kelley Burgin reviewed the document and provided suggestions for improvements.

IANA is requested to update the following registrations in the Kerberos Pre-authentication and Typed Data Registry created by section 7.1 of RFC 6113 to refer to this specification. These values were reserved for this specification in the initial registrations.