Subject: [kitten] RFC8636 paChecksum Agility

From: Andrew Wiley <[email-masked]>
Date: Thu, 4 Feb 2021 23:28:31 +0000

Hello Kitten,

We’ve started work on PKINIT agility in RFC 8636 in the Windows stack and we’ve found one issue we’d like to raise.
Section 3 describes how the SHA-1 checksum in paChecksum binds the preauthentication data to the request body and that in DH key agreement, the KDF supplements it. However, the KDF does not bind the preauthentication data to the request body – it only binds the response to the full request including preauthentication data.

This is not a security issue per se, but it seems to be problematic. With all of RFC8636 in place, a malicious client could observe a PKINIT AS-REQ on the wire, put the preauthentication data into a separate AS-REQ, and replay it (against a different KDC in the same realm). This should not result in a response the malicious client can decrypt and use, but it allows the client to manipulate audit logs and lockout counters without real credentials. The malicious client can also manipulate the supported etypes in the AS-REQ to potentially force a downgrade that could allow the ticket to be used if an attack against the etype of the reply key is available.

These are definitely defense-in-depth measures and only expose serious threats against realms with weak etypes enabled, but we know historically that cryptographic changes are very slow and we believe these are worth mitigating. We’re considering extending the PKAuthenticator structure, probably with an octet string for a digest and an AlgorithmIdentifier to identify the algorithm used to generate it. There would be a matching KDC error to allow the KDC to reject weak digest algorithms.

Any thoughts?

Thanks,
Andrew

---

From: Greg Hudson <[email-masked]>
Date: Thu, 4 Feb 2021 19:46:24 -0500

> Section 3 describes how the SHA-1 checksum in paChecksum binds the preauthentication data to the request body and that in DH key agreement, the KDF supplements it. However, the KDF does not bind th…

This is stated in the security considerations:

   The paChecksum field, which binds the client pre-authentication data
   to the Kerberos request body, remains fixed at SHA-1.  If an attacker
   substitutes a different request body using an attack against SHA-1 (a
   second preimage attack is likely required as the attacker does not
   control any part of the legitimate request body), the KDC will not
   detect the substitution.  Instead, if a new KDF is negotiated, the
   client will detect the substitution by failing to decrypt the reply.

This choice of binding the reply key rather than the request padata
appears to date all the way back to the first draft in 2006 by Love and
Larry.  I can't find a working group archive going back that far, so I
don't know what their reasoning was.