[kitten] Updating RFC 3961 to require deterministic checksums

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[kitten] Updating RFC 3961 to require deterministic checksums

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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Benjamin Kaduk-2
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.

-Ben

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Greg Hudson
On 09/27/2017 10:15 PM, Benjamin Kaduk wrote:
> 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.

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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Benjamin Kaduk-2
On Fri, Sep 29, 2017 at 05:42:09PM -0400, Greg Hudson wrote:

> On 09/27/2017 10:15 PM, Benjamin Kaduk wrote:
> > 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.
>
> 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.)

Sounds good to me.

-Ben

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Henry B (Hank) Hotz, CISSP-2
Generally +1. Will want to proof the next draft of course.

> On Sep 30, 2017, at 10:12 AM, Benjamin Kaduk <[hidden email]> wrote:
>
> On Fri, Sep 29, 2017 at 05:42:09PM -0400, Greg Hudson wrote:
>> On 09/27/2017 10:15 PM, Benjamin Kaduk wrote:
>>> 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.
>>
>> 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.)
>
> Sounds good to me.
>
> -Ben
>
> _______________________________________________
> Kitten mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/kitten

Personal email.  [hidden email]



_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten