Re: [kitten] SPAKE and non-deterministic RFC 3961 checksums

Benjamin Kaduk <kaduk@mit.edu> Tue, 19 September 2017 01:59 UTC

Return-Path: <kaduk@mit.edu>
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 543B5132FA7 for <kitten@ietfa.amsl.com>; Mon, 18 Sep 2017 18:59:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RN-MD7E6U3e8 for <kitten@ietfa.amsl.com>; Mon, 18 Sep 2017 18:59:44 -0700 (PDT)
Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (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 CE2A113243A for <kitten@ietf.org>; Mon, 18 Sep 2017 18:59:43 -0700 (PDT)
X-AuditID: 12074422-077ff70000001d12-5e-59c07a0ea581
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 4D.C3.07442.E0A70C95; Mon, 18 Sep 2017 21:59:42 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id v8J1xfTE015236; Mon, 18 Sep 2017 21:59:42 -0400
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v8J1xcIq026957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 18 Sep 2017 21:59:40 -0400
Date: Mon, 18 Sep 2017 20:59:38 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Greg Hudson <ghudson@mit.edu>
Cc: kitten@ietf.org
Message-ID: <20170919015937.GN96685@kduck.kaduk.org>
References: <x7d1sn5zyl8.fsf@equal-rites.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <x7d1sn5zyl8.fsf@equal-rites.mit.edu>
User-Agent: Mutt/1.8.3 (2017-05-23)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrIIsWRmVeSWpSXmKPExsUixCmqrctXdSDS4M40I4ujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoEr41D/dpaCf+IVx24vZ29gXCHcxcjJISFgIrHuzh/GLkYuDiGB xUwS8749ZIJwNjJKvGr4wAzhXGWSODinkxmkhUVAVeLBwtuMIDabgIpEQ/dlsLiIgKLEs1Vz WUBsZgFhieVrzrKB2MICLhJnPyxlArF5gdbNabrICmILCRhKXJi9jxUiLihxcuYTqF4tiRv/ XgLVcwDZ0hLL/3GAhDkFjCQu9v0AWysqoCwxb98qtgmMArOQdM9C0j0LoXsBI/MqRtmU3Crd 3MTMnOLUZN3i5MS8vNQiXVO93MwSvdSU0k2MoJBkd1HawTjxn9chRgEORiUeXoFr+yOFWBPL iitzDzFKcjApifKurTgQKcSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmE1z4GKMebklhZlVqUD5OS 5mBREufdFrQrUkggPbEkNTs1tSC1CCYrw8GhJMH7F2SoYFFqempFWmZOCUKaiYMTZDgP0PAq kBre4oLE3OLMdIj8KUZFKXFe40qghABIIqM0D64XlDIksvfXvGIUB3pFmFcCpIoHmG7gul8B DWYCGtyyYw/I4JJEhJRUA2Oej3SsiEW1598jOoJ2fycGKv+YUeVhw2d0UfAej0GWwDtH2XXT r1qKvp+dwnjg8HzpWY+en2NzbJsZJ/pl4vHw+GcnCyKbYj9I9Egft2DkL1dZc/pnR37UZwd2 H6u7rtefOZjE+l/c43zV5t+fg2n1+w4WBE8M6HmyanWqzyrJz+anXMJzfiixFGckGmoxFxUn AgAoRiAl9AIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/xAMaR3sHVpIfU58pbPa_CyY7L0c>
Subject: Re: [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: Tue, 19 Sep 2017 01:59:45 -0000

On Sun, Sep 17, 2017 at 01:24:51AM -0400, Greg Hudson wrote:
> 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
> more.

This is probably the most appealing option, provided we can accurately
state which properties we need (and they are provided by PRF(+)).

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

The hash algorithm could also be negotiated independently (so that in
practice, e.g., sha256 is always used, at least in the initial deployments).
For the rejected-optimistic case there is still an issue, but if the KDC
only supports O(2) hash algorithms during a hash transition, then the
amount of state needed in the cookie is bounded by a number that might
be smaller than the number of supported groups (but then again, might
not).

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

I agree that we are likely to end up with something resembling a
"transcript hash", even if it does not directly use a hash primitve.

-Ben