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

Benjamin Kaduk <kaduk@mit.edu> Sat, 23 September 2017 19:05 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 310E313295C for <kitten@ietfa.amsl.com>; Sat, 23 Sep 2017 12:05:35 -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 P6mfr00C2CKC for <kitten@ietfa.amsl.com>; Sat, 23 Sep 2017 12:05:33 -0700 (PDT)
Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (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 9AF2613214D for <kitten@ietf.org>; Sat, 23 Sep 2017 12:05:33 -0700 (PDT)
X-AuditID: 1209190c-343ff70000006f84-90-59c6b07c9bba
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 92.41.28548.C70B6C95; Sat, 23 Sep 2017 15:05:32 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id v8NJ5Vhd019979; Sat, 23 Sep 2017 15:05:31 -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 v8NJ5Rce028828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 23 Sep 2017 15:05:30 -0400
Date: Sat, 23 Sep 2017 14:05:27 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Simo Sorce <simo@redhat.com>
Cc: Greg Hudson <ghudson@mit.edu>, kitten@ietf.org
Message-ID: <20170923190527.GU96685@kduck.kaduk.org>
References: <x7d1sn5zyl8.fsf@equal-rites.mit.edu> <20170919015937.GN96685@kduck.kaduk.org> <1505920169.1143.15.camel@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1505920169.1143.15.camel@redhat.com>
User-Agent: Mutt/1.8.3 (2017-05-23)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKKsWRmVeSWpSXmKPExsUixG6noluz4VikQU+bvMXRzatYLH7MXcTq wOSxZMlPJo/3+66yBTBFcdmkpOZklqUW6dslcGX0TJnHWDBTpeLj/XVMDYzLZboYOTkkBEwk Xmy7ztzFyMUhJLCYSeLXnw5GCGcjo8SJXb1QmatMEq8X3WQCaWERUJVYN2MZI4jNJqAi0dB9 mRnEFhFQkFjQf4cFxGYWMJLY2naUDcQWFnCROPthKVgvL9C6h/O3sYLYQgItjBKf/qtAxAUl Ts58AtWrI7Fz6x2gXg4gW1pi+T8OiLC8RPPW2WCrOIHGT9t8BewEUQFliXn7VrFNYBSchWTS LCSTZiFMmoVk0gJGllWMsim5Vbq5iZk5xanJusXJiXl5qUW6hnq5mSV6qSmlmxhBYc0pybOD 8cwbr0OMAhyMSjy8ExyPRgqxJpYVV+YeYpTkYFIS5V235likEF9SfkplRmJxRnxRaU5q8SFG CQ5mJRHefw1AOd6UxMqq1KJ8mJQ0B4uSOO+2oF2RQgLpiSWp2ampBalFMFkZDg4lCV6v9UCN gkWp6akVaZk5JQhpJg5OkOE8QMO7QGp4iwsSc4sz0yHypxiNOTbdvPuHiWPD9wd/mIRY8vLz UqXEeblASgVASjNK8+CmgVKTRPb+mleM4kDPCfOuBKniAaY1uHmvgFYxAa0qX30EZFVJIkJK qoHR8/fXQx5bNOfM1GG4dOf/LM0paT+feZgu/pp7Zq+BYOtpqf3505If3fhZHD15ttul4GWH Zy7R3H5NNVDxyMfH4o73bFJ6blneOSR931bTkHHHmwV1pW/EL192+Pl+v8HxPAnnPx6rjqem HrhqnFzE8vvwU1+LKaev8V9vV7l4+5K4qVZhJffJUiWW4oxEQy3mouJEAO257m8oAwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/gwLBd569rCjwO5MofsEuzfSPS4Y>
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: Sat, 23 Sep 2017 19:05:35 -0000

On Wed, Sep 20, 2017 at 11:09:29AM -0400, Simo Sorce wrote:
> On Mon, 2017-09-18 at 20:59 -0500, Benjamin Kaduk wrote:
> > On Sun, Sep 17, 2017 at 01:24:51AM -0400, Greg Hudson wrote:
> > > 
> > > 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(+)).
> 
> Why is this more appealing than just saying no to DES ?
> Do we have any concern we may get future enc types that have non-
> deterministic checksums ?

There's two aspects that push me this way: first, from a standards process
point of view, now we have to also Update a core protocol spec and hope
that people remember to check our new document whenver they try to make
a new enctype/checksum type.  While it's unlikely that a hyptoehtical
future document would actually get through the full process with such an
error, it does add to the burden on future work in this space.  The second
concern relates to implementations, in that there will need to be some sort
of logic to handle the interaction of single-DES and SPAKE preauth.  If
we were in a place where implementations were actively removing the code
for single-DES support, I would not see this as an issue, but my understanding
is that we're still several years (at least!) away from completely removing
the code (as opposed to just not using it by default).  Even though we
know that no one ought to be using the two things together, our code still
has to come up with something to do in that case, and if we get the logic
wrong things could break badly.

> > > 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).
> 
> The nice thing about using the enctypes is that as new ones will come
> out with new, stronger checksums, we'll get those automatically,
> without adding a new thing to negotiate ...

That is a good point, about the required checksum being matched in
perceived strength, and that holding as an invariant in the future.

> > > 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.
> 
> I have to say that between PRF and a separate Hash I would rather use a
> separate hash.

Hmm, so no we have a split on 2 vs. 3, unless we can somehow make 1 more
appetizing.  Do we have the collective will to make single-DES actually
go away entirely and force any continued users to either run custom solutions
or stay on old software?

-Ben