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

[Benjamin Kaduk <[e-mail]>]

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