Re: [kitten] pkinit-alg-agility downgrade attack discussion

[Robbie Harwood <[e-mail]>]

Greg Hudson <[e-mail]> writes:

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

This all still sounds good.

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

(Added Eric to CC.)

Thanks,
--Robbie