[kitten] SPAKE and non-deterministic RFC 3961 checksums

Greg Hudson <ghudson@mit.edu> Sun, 17 September 2017 05:24 UTC

Return-Path: <ghudson@mit.edu>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 39AD5132198 for <kitten@ietfa.amsl.com>; Sat, 16 Sep 2017 22:24:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 6yD64dKI8sI3 for <kitten@ietfa.amsl.com>; Sat, 16 Sep 2017 22:24:55 -0700 (PDT)
Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D52E21243F6 for <kitten@ietf.org>; Sat, 16 Sep 2017 22:24:54 -0700 (PDT)
X-AuditID: 12074423-8ddff700000028c4-98-59be0725aa27
Received: from mailhub-auth-4.mit.edu ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id F8.64.10436.5270EB95; Sun, 17 Sep 2017 01:24:53 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU []) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id v8H5Orev007842 for <kitten@ietf.org>; Sun, 17 Sep 2017 01:24:53 -0400
Received: from localhost (EQUAL-RITES.MIT.EDU []) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v8H5OprY018034 for <kitten@ietf.org>; Sun, 17 Sep 2017 01:24:52 -0400
From: Greg Hudson <ghudson@mit.edu>
To: kitten@ietf.org
Date: Sun, 17 Sep 2017 01:24:51 -0400
Message-ID: <x7d1sn5zyl8.fsf@equal-rites.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUixG6nrqvKvi/S4OQBbYujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoErY2vrbfaC6YIVu88dY29gbOTrYuTgkBAwkdi+LqmLkYtDSGAx k8ScfSfZIJzjjBLTdhxihXA6mCQu/OgBynBysAkoS6zfv5UFxBYREJbYvfUdM4gtLGAu8eT/ HUaQqSwCqhKHLqaChHkFDCUWvv/MBGELSpyc+QSslVlAQuLgixfMExi5ZyFJzUKSWsDItIpR NiW3Sjc3MTOnODVZtzg5MS8vtUjXTC83s0QvNaV0EyM4BFyUdzC+7PM+xCjAwajEw7uhZG+k EGtiWXFl7iFGSQ4mJVFeK789kUJ8SfkplRmJxRnxRaU5qcWHGCU4mJVEeOvY9kUK8aYkVlal FuXDpKQ5WJTEebcF7YoUEkhPLEnNTk0tSC2CycpwcChJ8PKCNAoWpaanVqRl5pQgpJk4OEGG 8wANlwUbXlyQmFucmQ6RP8UoKSXO+4kVKCEAksgozYPrfcUoDvSCMK8wSBsPMJ7hul4BDWQC GtiyYw/IwJJEhJRUA2Ni770bVcs2um7IuqtzLe+tuuDemKDCTakHfpsfDV7NOy1144MDzHos tSZFq+KW7rn3I6l/d+TXuH7OYs+znX6CT37ODDP9xlSVaC0lbtknlJgkyLn6zdzj3P9jDOZP nGG6tvzas171i9ZsOtM4tb7zh+iwfn93U5SBK2BSyKT10w5n5NofWqHEUpyRaKjFXFScCAAv EpuApAIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/g1tTYuAq7DK1KrGBdvBE2sx5HNI>
Subject: [kitten] SPAKE and non-deterministic RFC 3961 checksums
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: Sun, 17 Sep 2017 05:24:56 -0000

RFC 3961 says about the checksum profile get_mic operation: "This
function is not required to return the same deterministic result for
each use; it need only generate a token that the verify_mic routine can
check."  In practice, only the oldest checksum types (used with
single-DES keys) are non-deterministic.

The SPAKE preauth transcript checksum is computed independently by the
client and KDC using the RFC 3961 checksum operation (iterated several
times).  In hindsight, this design obviously requires a deterministic
checksum operation, so the pieces don't currently fit.  I unfortunately
only realized this mismatch today when I started doing integration tests
using DES keys in a prototype implementation.

The potential remedies I can think of fall into these bins:

1. Don't change the SPAKE design.  Instead, update RFC 3961 to specify
that new checksum types must be deterministic, and specify that SPAKE
preauth can't be used with single-DES keys.  Aside from the
standards-space cost of pushing our problem down into a lower layer, the
prohibition against using SPAKE with single-DES keys could make it
harder for clients to be configured to refuse encrypted timestamp
preauth on a pre-realm basis.  That is perhaps not a large cost as
Kerberos implementations are moving away from single-DES support anyway.

2. A relatively quick fix: use PRF instead of checksum.  (Or PRF+, in
which case we have to decide how much length of output we want.)  I
think PRF has the requisite properties, but I would want to think on it

3. We could use a hash (it doesn't need to be keyed) independent of RFC
3961.  The hash algorithm could be specified in the group profile,
perhaps, but I believe the rejected-optimistic-challenge case poses a
difficulty for that design.

4. The most open-ended option is to back up and reconsider the purpose
of the transcript checksum, which is to bind at least the public keys
into key derivation.  The current transcript also binds in group
negotiation and the initial factor challenge.  I can't immediately think
of an alternative design which doesn't require the KDC to store a lot of
information in the cookie.