The conditions for this vulnerability are:

• KDC service running on a Fedora, CentOS, or RHEL host where the RC4 HMAC-MD5 encryption type is allowed
• Server host principal has a RC4 HMAC-MD5 key in the KDC database
• Client host configured with RC4 HMAC-MD5 preferred over an AES HMAC-SHA1 encryption type, or preferred over any key type available for the server principal in the KDC database

None of the MIT krb5 client-side configurations provided by the crypto-policy system on Fedora, CentOS, and RHEL are fulfilling these conditions.

If all the conditions listed above are fulfilled, the client could obtain a RC4 HMAC-MD5 session key. As demonstrated in "The problem with RC4-HMAC" section of this document[1], the design of the checksum function for the RC4 HMAC-MD5 encryption type from RFC4757 is vulnerable to MD5 collision-based attacks.

In practice, this could be used to spoof the content of messages protected by GSSAPI's message integrity codes. This includes messages with an MIC generated by the gss_get_mic(), and gss_wrap() functions (if the encryption option is not enabled). An attacker could sniff a packet on the network and try to take advantage of MD5 collision to assemble a packet with a different content, but with the same MIC. This risk increases if the data format used in the message allows insertion of arbitrary data chunks.

The impact of this vulnerability depends on the permissions of the service the attacker is able to assemble requests for.

[1] https://i.blackhat.com/EU-22/Thursday-Briefings/EU-22-Tervoort-Breaking-Kerberos-RC4-Cipher-and-Spoofing-Windows-PACs-wp.pdf