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

Robbie Harwood <rharwood@redhat.com> Thu, 18 April 2019 19:35 UTC

Return-Path: <rharwood@redhat.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6FE012036D; Thu, 18 Apr 2019 12:35:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWZIpvj9iz5l; Thu, 18 Apr 2019 12:35:09 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CEE1120346; Thu, 18 Apr 2019 12:35:09 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DD25DC069B2C; Thu, 18 Apr 2019 19:35:08 +0000 (UTC)
Received: from localhost (ovpn-112-28.rdu2.redhat.com [10.10.112.28]) by smtp.corp.redhat.com (Postfix) with ESMTP id 6FBBC60856; Thu, 18 Apr 2019 19:35:08 +0000 (UTC)
From: Robbie Harwood <rharwood@redhat.com>
To: Eric Rescorla <ekr@rtfm.com>, The IESG <iesg@ietf.org>, Benjamin Kaduk <kaduk@mit.edu>
Cc: draft-ietf-kitten-pkinit-alg-agility@ietf.org, kitten-chairs@ietf.org, kitten@ietf.org
In-Reply-To: <155253481198.24861.15849658500473174931.idtracker@ietfa.amsl.com>
References: <155253481198.24861.15849658500473174931.idtracker@ietfa.amsl.com>
Date: Thu, 18 Apr 2019 15:35:08 -0400
Message-ID: <jlgzhon85ub.fsf@redhat.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Thu, 18 Apr 2019 19:35:09 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/ethxF9oMguQ9tIZI7n_tlbKp_PY>
Subject: Re: [kitten] Eric Rescorla's No Objection on draft-ietf-kitten-pkinit-alg-agility-06: (with COMMENT)
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Apr 2019 19:35:12 -0000

Eric Rescorla via Datatracker <noreply@ietf.org> 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