Re: [kitten] SPAKE and weak checksum types

Robbie Harwood <rharwood@redhat.com> Tue, 12 September 2017 16:46 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 71E65132D96 for <kitten@ietfa.amsl.com>; Tue, 12 Sep 2017 09:46:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.921
X-Spam-Level:
X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 sA_yG8gj3Xh6 for <kitten@ietfa.amsl.com>; Tue, 12 Sep 2017 09:46:38 -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 3B04B132403 for <kitten@ietf.org>; Tue, 12 Sep 2017 09:46:38 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C4C7B72682; Tue, 12 Sep 2017 16:46:37 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com C4C7B72682
Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=rharwood@redhat.com
Received: from localhost (ovpn-66-194.rdu2.redhat.com [10.10.66.194]) by smtp.corp.redhat.com (Postfix) with ESMTP id 83E85179C8; Tue, 12 Sep 2017 16:46:37 +0000 (UTC)
From: Robbie Harwood <rharwood@redhat.com>
To: Greg Hudson <ghudson@mit.edu>, Henry B Hotz <hbhotz@oxy.edu>
Cc: kitten@ietf.org
In-Reply-To: <363e60be-b63d-3be4-dfdb-0f085480a98b@mit.edu>
References: <x7defrdz0le.fsf@equal-rites.mit.edu> <A374D6EA-9C58-4A8B-A68F-1CF9DE20669C@oxy.edu> <363e60be-b63d-3be4-dfdb-0f085480a98b@mit.edu>
Date: Tue, 12 Sep 2017 12:47:21 -0400
Message-ID: <jlgingn6ezq.fsf@redhat.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Tue, 12 Sep 2017 16:46:38 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/bHQ4vcmoSRkb2vJ5NQJ8B1wKUlg>
Subject: Re: [kitten] SPAKE and weak checksum types
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 12 Sep 2017 16:46:39 -0000

Greg Hudson <ghudson@mit.edu> writes:

> On 09/11/2017 03:35 PM, Henry B Hotz wrote:
>
>> IIUC you are concerned with the case that someone will stand up a kdc
>> which will opportunistically use SPAKE, but supports older/weaker
>> stuff. By its nature such a beast will be vulnerable to downgrade
>> attacks and you can't solve that in SPAKE.
>
> If the KDC downgrades itself to encrypted timestamp for DES/RC4 keys,
> only a passive attack is needed, versus an active attack to downgrade
> to encrypted timestamp.
>
> The KDC can't be responsible for preventing downgrades to encrypted
> timestamp; the client has to refuse it (assuming no FAST or TLS
> tunneling).

I think this is the important part for me: we tend to put the
responsibility on the client to ensure that it receives an adequate
level of protection.

> It will be much easier to configure a client to refuse encrypted
> timestamp if it doesn't have to worry about the KDC refusing SPAKE
> based on what enctypes it has for the client long-term key.

Agreed.

Thanks,
--Robbie