Subject: Re: [kitten] Eric Rescorla's No Objection on draft-ietf-kitten-pkinit-alg-agility-06: (with COMMENT)

From: Robbie Harwood <[email-masked]>
Date: Thu, 18 Apr 2019 15:35:08 -0400

Eric Rescorla via Datatracker <[email-masked]> writes:

> IMPORTANT
>
> I think this document would benefit greatly from describing the
> downgrade properties of each of the axes on which algorithms can be
> negotiated against various forms of compromise in the digest function.
>
> The relevant case is one in which the client and KDC both support one
> weak and one strong algorithm. Can the attacker either
>
> (1) force them to complete a handshake with a weak algorithm
> or
> (2) convince one side that the other side supports a weak algorithm
> and then interpose itself as that side.
>
> Specifically it would be useful to know which attacks are possible
> with a collision attack versus a preimage attack (though this can
> sometimes be hard to know).
>
>
> Here is one case of a potential real downgrade attack (though not a
> very powerful one).
>
> The client sends a KRB-REQ signed with algorithm A, the attacker
> forges KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED listing anly some
> weaker algorithm. This causes the client to retry with that weaker
> algorithm. Is this attack detectable? It's not clear to me how (though
> it maybe could be if the message were folded into the transcript).
>
> OTOH, I don't think that the equivalent attack on the cert signer
> algorithms is necessarily very useful because presumably the certs are
> public already. OTOH, it might force the client into using some weaker
> key.

Hi,

Greg has been kind enough to provide us with a -07 of this document that
should address these concerns in the "Security Considerations" section.

> I'm having a little trouble following the point in S 3. Is the idea
> that the paChecksum is always SHA-1 and you don't add a way to
> negotiate it, so you are instead folding the information into the KDF?
> If so, I think we need to work through the chain of logic here. As I
> understand it, the paRequest is included in the AuthPack, which is
> signed. So presumably the idea is that the AuthPack is signed with
> SHA-256 but because paChecksum is SHA-1, the binding is weak, right?
> But can you safely send a SHA-256 signature to a KDC which you have
> never talked to before? Can't you just get downgraded by the attack I
> describe above? Can you help unpack this for me?

Copying Greg's response from the other thread for completeness:

(I assume "paRequest" is a typo for "paChecksum".)

I don't understand the last part of this question.  If an attacker
substitutes an altered KDC-REQ-BODY via an attack on SHA-1 (either on
the paChecksum itself or on the CMS signature of the SignedAuthPack
containing the checksum), the KDC won't detect the substitution, but the
client will fail to decrypt the reply because the KDC will derive the
reply key with the altered KDC-REQ-BODY and the client will derive the
reply key with the original one.  This protection does not apply if the
attacker manages to downgrade the exchange to the old KDF, of course.

> MINOR
>
> I wish you were using HKDF, but I don't think this is a dealbreaker.

Yeah, bit hard to change that now.

Thanks,
--Robbie