Subject: [Ietf-krb-wg] resolving KRB-FX-CF2 and DES random-to-key ambiguities

From: Tom Yu <[email-masked]>
Date: Thu, 30 Sep 2010 18:56:00 -0400

There continue to be some ambiguities regarding the specification of
the DES random-to-key operation, particularly as applied in the
KRB-FX-CF2 operation in the preauth framework.  I have investigated
these ambiguities and now recommend that we add clarifying text to the
preauth framework document to align with the deployed running code.

Thanks to investigations by Yi Zeng (Microsoft), we have good evidence
that neither of the reasonable interpretations of the single-DES
random-to-key operations specified in RFC 3961 would interoperate with
the MIT Kerberos implementation.  I have included suggested textual
changes below.

In draft-ietf-krb-wg-preauth-framework-17, Section 5.1, insert after
the text:

   corresponding input key; the random-to-key() operation is the RFC
   3961 random-to-key operation for the resulting key.

the following new text:

   For the single-DES enctypes (des-cbc-md5, des-cbc-md4,
   des-cbc-crc), the random-to-key operation as specified in RFC 3961
   is ambiguous, and is updated as follows:

      The key generation seed length for des-cbc-md5, des-cbc-md4, and
      des-cbc-crc is 7 bytes.  The random-to-key operation for these
      enctypes is to apply the transformation that Section 6.3.1 of
      RFC 3961 specifies for expanding a group of 56 bits into 64
      bits.  (This transformation is one third of the triple DES
      random-to-key operation.)  The operation called
      des_random_to_key() in RFC 3961 remains unchanged, because it is
      required for single-DES string-to-key interoperability.

In Appendix A, replace:

   The random-to-key operation is assumed
   to be distribute 56 bits into high-7-bits of 8 octets and generate
   parity.

with:

   The DES random-to-key operation of RFC 3961 is updated as described
   in Section 5.1 to resolve these ambiguities.

Also add to the header: "Updates: 3961".

Further details and background are below, for anyone who is interested.

                         ====================

Descriptions of the various single-DES random-to-key operations are
below, for the sake of comparison.

RFC 3961, des-cbc-md5:

    Treating the bits of the corrected 7 input octets (in MSB-first
    order) as a concatenation of 8 substrings of 7 bits each, append a
    parity bit to each of these 7-bit substrings to form the output
    octets.  Correct for weak keys.

RFC 3961, des-cbc-md4 and des-cbc-crc:

    Copy 8 input octets to the output and correct the parity.

MIT Kerberos, all single-DES:

    Copy 7 input octets into the first 7 octets of the output.  Take
    the LSB of each octet, and put them into the high 7 bits of the
    8th octet, but in reversed order.  Correct the parity.  (This is
    actually one-third of the triple-DES random-to-key operation.)

Some additional observations: RFC 3961 is internally inconsistent
about the des-cbc-md5 random-to-key operation (des_random_to_key())
because in Section 6.2.1, it specifies 8 input octets as the
key-generation seed length, despite des_random_to_key() taking only 7
octets.  The des_random_to_key() operation seems to be described in
RFC 3961 as an application of the add_parity_bits() operation used by
mit_des_string_to_key(), and some search-and-replace changes for the
specification of the single DES enctypes were incomplete.

Due to implementation details of mit_des_string_to_key(), the
add_parity_bits() operation (used by des_random_to_key()) is easier to
implement than its abstract description would imply:
mit_des_string_to_key() represents the intermediate 56-bit strings as
8 octets where only 7 bits are significant, because the fan-folding of
the string ignores the MSB of each input byte (eventually shifting the
"holes" into the LSBs).  The add_parity_bits() operation simply
corrects the parity of these 8 octets in place.  The general case of
starting with 7 octets where all bits are significant and spreading
their bits into the 7 most significant bits of 8 octets is somewhat
harder to implement.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg