[kitten] pkinit-alg-agility downgrade attack discussion

[Greg Hudson <[e-mail]>]

Eric Rescorla wrote about draft-ietf-kitten-pkinit-alg-agility:

   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).

along with some discussion of specifics.

I propose to address this feedback by adding security considerations
text:

   The discovery method described in Section 4 uses a Kerberos error
   message, which is unauthenticated in a typical exchange.  An attacker
   may attempt to downgrade a client to a weaker CMS type by forging a
   KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error.  It is a matter of
   local policy whether a client accepts a downgrade to a weaker CMS
   type.  A client may reasonably assume that the real KDC implements
   all hash functions used in the client's X.509 certificate, and refuse
   attempts to downgrade to weaker hash functions.

   The discovery method described in Section 5 also uses a Kerberos
   error message.  An attacker may attempt to downgrade a client to a
   certificate using a weaker signing algorithm by forging a
   KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED error.  It is a matter of local
   policy whether a client accepts a downgrade to a weaker certificate.
   This attack is only possible if the client device possesses multiple
   client certificates of varying strength.

   In the KDF negotiation method described in Section 6, the client
   supportedKDFs value is protected by the signature on the
   signedAuthPack field in the request.  If this signature algorithm is
   weak to collision attacks, an attacker may attempt to downgrade the
   negotiation by substituting an AuthPack with a different or absent
   supportedKDFs value, using a PKINIT freshness token [RFC8070] to
   partially control the legitimate AuthPack value.  A client performing
   anonymous PKINIT [RFC8062] does not sign the AuthPack, so an attacker
   can easily remove the supportedKDFs value in this case.  Finally, the
   kdf field in the DHRepInfo of the KDC response is unauthenticated, so
   could be altered or removed by an attacker, although this alteration
   will likely result in a decryption failure by the client rather than
   a successful downgrade.  It is a matter of local policy whether a
   client accepts a downgrade to the old KDF.

Eric also wrote:

   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?

(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.