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

From: Greg Hudson <[email-masked]>
Date: Tue, 26 Sep 2017 12:28:20 -0400

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 27 Sep 2017 21:15:35 -0500

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

-Ben

---

From: Greg Hudson <[email-masked]>
Date: Fri, 29 Sep 2017 17:42:09 -0400

> constraint on checksum behavior.

Proposed wording (at the beginning of the IANA considerations section):

   The notes for the "Kerberos Checksum Type Numbers" registry should be
   updated with the following addition: "If the checksum algorithm is
   non-deterministic, see [this document] Section 4".

(where "Section 4" is an xref to the new "Update to Checksum
Specifications" section from my previous message in this thread.)

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 30 Sep 2017 12:12:04 -0500

> Specifications" section from my previous message in this thread.)

Sounds good to me.

-Ben