[kitten] Updating RFC 3961 to require deterministic checksums

Greg Hudson <ghudson@mit.edu> Tue, 26 September 2017 16:28 UTC

Return-Path: <ghudson@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 E6BB21342DD for <kitten@ietfa.amsl.com>; Tue, 26 Sep 2017 09:28:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 ajLmb5H6jMxJ for <kitten@ietfa.amsl.com>; Tue, 26 Sep 2017 09:28:23 -0700 (PDT)
Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 84A351330B3 for <kitten@ietf.org>; Tue, 26 Sep 2017 09:28:23 -0700 (PDT)
X-AuditID: 1209190d-95fff70000003123-f8-59ca80264b41
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-2.mit.edu (Symantec Messaging Gateway) with SMTP id 79.C7.12579.6208AC95; Tue, 26 Sep 2017 12:28:22 -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 v8QGSLoc005467 for <kitten@ietf.org>; Tue, 26 Sep 2017 12:28:22 -0400
Received: from localhost (EQUAL-RITES.MIT.EDU [10.18.1.59]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v8QGSKHZ019937 for <kitten@ietf.org>; Tue, 26 Sep 2017 12:28:21 -0400
From: Greg Hudson <ghudson@mit.edu>
To: kitten@ietf.org
Date: Tue, 26 Sep 2017 12:28:20 -0400
Message-ID: <x7dk20lxw4b.fsf@equal-rites.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUixCmqravWcCrS4MtfOYujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoEr4+nuv0wFx8Uq7p46ytjAOEeoi5GDQ0LARGLS/+AuRi4OIYHF TBLbPnxkhHCOM0p0Pb/DCuF0MEncPfOEuYuRk4NNQFli/f6tLCC2iICwxO6t78DiwgK2Eve/ /GcFmcoioCpxbYEdSJhXwFBi6ud/jBC2oMTJmU/AWpkFJCQOvnjBPIGRexaS1CwkqQWMTKsY ZVNyq3RzEzNzilOTdYuTE/PyUot0jfRyM0v0UlNKNzGCQ0CSdwfjv7tehxgFOBiVeHgZQk5F CrEmlhVX5h5ilORgUhLlVZQDCvEl5adUZiQWZ8QXleakFh9ilOBgVhLhTawFyvGmJFZWpRbl w6SkOViUxHm3Be2KFBJITyxJzU5NLUgtgsnKcHAoSfDW1gM1ChalpqdWpGXmlCCkmTg4QYbz AA1nAanhLS5IzC3OTIfIn2KUlBLn/VMHlBAASWSU5sH1vmIUB3pBmPcJSJYHGM9wXa+ABjIB DeydegJkYEkiQkqqgbFQKCHgxQTDgGe2/HmBJ44tv676eVHvLnfBiED2ZzuW/ZRUvirlUV7F sYtvq6Rs+q85/hINolZeiodUdk48pri95tfd7Xrv66/yK10L3KOe+3Wr6KydjT1GclrJV051 aD+/skNy8TG5pxuNU7wnrJHgsJZh2OLLFxSx5eIRje2pzzhNE9eu2aHEUpyRaKjFXFScCACk 9HdapAIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/_qFA58DAdp_iEXv6ypjTIga7A7A>
Subject: [kitten] Updating RFC 3961 to require deterministic 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, 26 Sep 2017 16:28:25 -0000

(I'm starting a new thread to emphasize what we're talking about doing,
for anyone who is interested in the cryptographic framework but perhaps
not as much in a specific new preauth mechanism.)

It looks like consensus on the SPAKE transcript checksum issue is
tending towards updating RFC 3961 to require deterministic checkums for
future mandatory-to-implement checksum types.  I propose the following
wording changes to the SPAKE draft:

1. Add a new section titled "Update to Checksum Specifications" just
before the "SPAKE Pre-Authentication Message Protocol" section.  It
reads:

   [RFC3961] section 4 specifies the Kerberos checksum algorithm
   profile.  It does not require checksums to be deterministic.  In
   practice, DES-based checksum types (deprecated by [RFC6649]) use a
   random confounder; all other current checksum types are
   deterministic.

   Future checksum types required by an encryption type MUST be
   deterministic.  All future checksum types SHOULD be deterministic.

   This mechanism requires a deterministic checksum type for the
   transcript checksum.  Therefore, a KDC MUST NOT offer this mechanism
   if the initial reply key is of type des-cbc-crc, des-cbc-md4, or des-
   cbc-md5.

2. Flesh out the description of the second optimization to describe
fallback to other preauth mechs with the following diff.  This case
already needed specifying because the KDC may not support any of the
client's groups, but it is also relevant to the case of a KDC refusing
SPAKE due to a single-DES initial reply key.

   <t>Second, clients MAY skip the first pass and send an AS-REQ with a
-  PA-SPAKE PA-DATA element using the support choice. The KDC MUST
-  include a PA-ETYPE-INFO2 value within the METHOD-DATA of the
+  PA-SPAKE PA-DATA element using the support choice. If the KDC accepts
+  the support message and generates a challenge, it MUST include a
+  PA-ETYPE-INFO2 value within the METHOD-DATA of the
   KDC_ERR_MORE_PREAUTH_DATA_REQUIRED error response, as the client may
-  not otherwise be able to compute the initial reply key. KDCs MUST
-  support this optimization.
+  not otherwise be able to compute the initial reply key. If the KDC
+  cannot continue with SPAKE (either because initial reply key type is
+  incompatible with SPAKE or because it does not support any of the
+  client's groups) but can offer other pre-authentication mechanisms, it
+  MUST respond with a KDC_ERR_PREAUTH_FAILED error containing
+  METHOD-DATA. A client supporting this optimization MUST continue after
+  a KDC_ERR_PREAUTH_FAILED error as described in [RFC6113] section 2.
+  KDCs MUST support this optimization.

3. For proper bookkeeping, add "Updates: RFC 3961" to the header, add
RFC 6649 as a non-normative reference, and add KDC_ERR_PREAUTH_FAILED as
one of the terms specified in RFC 6113.