Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-alg-agility-07.txt

[Greg Hudson <[e-mail]>]

On 4/18/19 11:27 PM, Benjamin Kaduk wrote:
> Before I push this off for publication, I just wanted to check whether KDC
> policy had a role in providing downgrade protection in the discovery
> methods from Sections 4 and 5 -- would there be a case where the KDC knows
> to require the stronger CMS type/signing algorithm for a specific
> principal, so that even if the client is tricked into downgrade by an
> attacker, the exchange would still fail?

In any of the three downgrade scenarios the KDC could refuse the use of
the weak hash function as well.  I can add clauses about that:

   It is a matter of local policy whether a client accepts a downgrade
   to a weaker CMS type, and whether the KDC accepts the weaker CMS
   type.

   It is a matter of local policy whether a client accepts a downgrade
   to a weaker certificate, and whether the KDC accepts the weaker
   certificate.

   It is a matter of local policy whether a client accepts a downgrade
   to the old KDF, and whether the KDC allows the use of the old KDF.

Independent of anything described in the draft, an attacker could try to
impersonate the KDC to the client by forging the dhSignedData signature
using a weak hash algorithm, if the client allows that algorithm when
verifying the KDC signature.  Even if the client insists on a newer KDF
using a strong hash function, the attacker could do the key derivation
step using SHA-256 and the new KDF, and just sign the KDCDHKeyInfo with
SHA-1.  An attacker could conceivably do this via a SHA-1 collision (in
order to get the legitimate KDC to sign the same hash as the forged
reply) because KDCDHKeyInfo contains a nonce controlled by the client
when DH keys are not reused--but in that case the legitimate KDC places
a random subjectPublicKey into KDCDHKeyInfo, which might make the attack
impractical.