Re: [kitten] SPAKE and weak checksum types

Benjamin Kaduk <> Sat, 16 September 2017 00:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C86741321A7 for <>; Fri, 15 Sep 2017 17:08:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id twhEGtzTkZJn for <>; Fri, 15 Sep 2017 17:08:57 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 827951200F3 for <>; Fri, 15 Sep 2017 17:08:57 -0700 (PDT)
X-AuditID: 12074423-b13ff70000000510-dd-59bc6b981eca
Received: from ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 8C.15.01296.89B6CB95; Fri, 15 Sep 2017 20:08:56 -0400 (EDT)
Received: from (OUTGOING-AUTH-1.MIT.EDU []) by (8.13.8/8.9.2) with ESMTP id v8G08sHM028155; Fri, 15 Sep 2017 20:08:55 -0400
Received: from ( []) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id v8G08oA3017893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 15 Sep 2017 20:08:53 -0400
Date: Fri, 15 Sep 2017 19:08:51 -0500
From: Benjamin Kaduk <>
To: "Henry B (Hank) Hotz, CISSP" <>
Cc: Greg Hudson <>,
Message-ID: <>
References: <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
User-Agent: Mutt/1.8.3 (2017-05-23)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpileLIzCtJLcpLzFFi42IR4hTV1p2RvSfSoGs7t8XHewtZLI5uXsXi wOSxZMlPJo+tTX+ZA5iiuGxSUnMyy1KL9O0SuDIu9r5kKVjOUzF32U+mBsZnnF2MHBwSAiYS s+ZLdTFycQgJLGaS6H9/kq2LkRPI2cgo0bWcDyJxlUnizeQzjCAJFgFVibaODcwgNpuAikRD 92UwW0TAUGL6yomsIDazgJHE1rajYIOEBYwl9vT/YQexeYGWHZzZxwoxdD+TxN4br6ESghIn Zz5hgWhWl/gz7xIzyHXMAtISy/9xQITlJZq3zgbbxSlgLbF+5XSwVlEBZYl5+1axTWAUnIVk 0iwkk2YhTJqFZNICRpZVjLIpuVW6uYmZOcWpybrFyYl5ealFumZ6uZkleqkppZsYQUHN7qK8 g/Fln/chRgEORiUe3obLuyOFWBPLiitzDzFKcjApifJa+e2JFOJLyk+pzEgszogvKs1JLT7E KMHBrCTC25oMlONNSaysSi3Kh0lJc7AoifNuC9oVKSSQnliSmp2aWpBaBJOV4eBQkuA1zgJq FCxKTU+tSMvMKUFIM3FwggznARp+EKSGt7ggMbc4Mx0if4pRUUqcd18mUEIAJJFRmgfXC0o6 Etn7a14xigO9Isx7GqSdB5iw4LpfAQ1mAhp85vQOkMEliQgpqQZGgfZy+Y3nVlxujX/2QlHp 7d43L07PCz9emht+N/XfjZiN4u9OfZhfMqMwZCtX0EOGTXsf1K/1d2VZvuBCrF9PqdcOvf+J 5y4sOXe6+KNKgcX9jKdPrp1xUIg6utnG6fbhli9uCbUqD+JFJaXtthTz6aqWTqq+feKuR/xW +0cKW+7pOv2/LvElUImlOCPRUIu5qDgRAO+O/2IVAwAA
Archived-At: <>
Subject: Re: [kitten] SPAKE and weak checksum types
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 16 Sep 2017 00:08:59 -0000

On Thu, Sep 14, 2017 at 09:38:28PM -0700, Henry B (Hank) Hotz, CISSP wrote:
> > On Sep 13, 2017, at 9:20 PM, Greg Hudson <ghudson@MIT.EDU>; wrote:
> > 
> > The particular scenario I was concerned about here (which should not be
> > an issue since we appear to have agreement on the text change) was: the
> > KDC and the client both permit SPAKE and encrypted timestamp.  The KDC
> > decides not to offer SPAKE because the initial reply key is an RC4 key
> > and therefore the transcript checksum would use HMAC-MD5.  The passive
> > attacker can simply dictionary attack the ciphertext from the client (or
> > the KDC).
> Wouldn’t the KDC have already sent a preuth-required message which prohibited that enctype? I thought the list of enctypes was separate from the list of PA types.

The spake draft requires that, if SPAKE is to be used/offered, a single
enctype must be in pa-etype-info2.  So the key decision here is at the
KDC, a combination of whether to offer SPAKE at all and what enctype(s)
to use.  But in this scenario, the KDC does not wholesale forbid HMAC-MD5,
it was just going to comply with the (old) draft text to forbid SPAKE
with MD5.  So, if the RC4 key was the initial choice for reply key,
that "compliant" KDC could not offer SPAKE and would have to only offer
encrypted-timestamp.  The client would then actually send the encrypted
timestamp, offering the ciphertext in question.  On the other hand, if
RC4 was not the initial choice for the reply key, then the KDC would
offer SPAKE with that other enctype.