Re: [kitten] Updating RFC 3961 to require deterministic checksums

Benjamin Kaduk <> Thu, 28 September 2017 02:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3436213525D for <>; Wed, 27 Sep 2017 19:15:43 -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 b3ZY4vo9tQUj for <>; Wed, 27 Sep 2017 19:15:41 -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 9C61C135259 for <>; Wed, 27 Sep 2017 19:15:41 -0700 (PDT)
X-AuditID: 1209190d-17fff70000005ec5-1b-59cc5b4c8970
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 85.8D.24261.C4B5CC95; Wed, 27 Sep 2017 22:15:40 -0400 (EDT)
Received: from (OUTGOING-AUTH-1.MIT.EDU []) by (8.13.8/8.9.2) with ESMTP id v8S2FdWm004987; Wed, 27 Sep 2017 22:15:39 -0400
Received: from ( []) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id v8S2FZjB008208 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 27 Sep 2017 22:15:38 -0400
Date: Wed, 27 Sep 2017 21:15:35 -0500
From: Benjamin Kaduk <>
To: Greg Hudson <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.8.3 (2017-05-23)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrAIsWRmVeSWpSXmKPExsUixCmqrOsTfSbSYGWTjMXRzatYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8fr4UZaCd5IVNxvb2BsYz4h0MXJySAiYSOz5eYuxi5GLQ0hg MZPE8iNfGUESQgIbGSWOPeaFSFxlkuj78IkZJMEioCrRsr2dHcRmE1CRaOi+DBYXEVCUeLZq LguIzSwgLLF8zVk2EFtYwEtiY+ssJhCbF2jbjs132SAWGErsfXCfDSIuKHFy5hOoXi2JG/9e AtVzANnSEsv/cYCEOQWMJLqWbAcbIyqgLDFv3yq2CYwCs5B0z0LSPQuhewEj8ypG2ZTcKt3c xMyc4tRk3eLkxLy81CJdI73czBK91JTSTYzggJTk3cH4767XIUYBDkYlHt4LC05HCrEmlhVX 5h5ilORgUhLlXeJ+JlKILyk/pTIjsTgjvqg0J7X4EKMEB7OSCO95ZqAcb0piZVVqUT5MSpqD RUmcd1vQrkghgfTEktTs1NSC1CKYrAwHh5IE788IoEbBotT01Iq0zJwShDQTByfIcB6Q4SA1 vMUFibnFmekQ+VOMilLivJpRQAkBkERGaR5cLyhhSGTvr3nFKA70ijDv9kigKh5gsoHrfgU0 mAlocO/UEyCDSxIRUlINjGslk7Zlvn/gYp0U+/nL9jP6tTcE5r4UW99Zt3rR/xevD+TpnWRY tkj3Y46BfH6d2lKDhpDwIvne1Wul+a/l3spc+s96skCRzPGf9q0qJ9t1mC76fNjzkmWnV8lB 004+7+33T53hfM24xXdOx3RrMaa1eXfPrAvTjLsy/0zY+zqhC8c5zWW4OZRYijMSDbWYi4oT Abhe0zzzAgAA
Archived-At: <>
Subject: Re: [kitten] Updating RFC 3961 to require deterministic checksums
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: Thu, 28 Sep 2017 02:15:43 -0000

On Tue, Sep 26, 2017 at 12:28:20PM -0400, Greg Hudson wrote:
> (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.

This looks good to me.

I think we also will need a

4. Include instructions in the IANA considerations section to update the
registration policy for the checksum type registry that notes the additional
constraint on checksum behavior.