RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 3 records.

Status: Verified (1)

RFC 3961, "Encryption and Checksum Specifications for Kerberos 5", February 2005

Note: This RFC has been updated by RFC 8429

Source of RFC: krb-wg (sec)

Errata ID: 207
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Weijun Wang
Date Reported: 2006-04-05
Verifier Name: Tim Polk
Date Verified: 2010-07-20

The Unicode character g-clef used throughout the document says:

           "g-clef    U+1011E   F0 9D 84 9E"

It should say:

           "g-clef    U+1D11E   F0 9D 84 9E"

Status: Held for Document Update (1)

RFC 3961, "Encryption and Checksum Specifications for Kerberos 5", February 2005

Note: This RFC has been updated by RFC 8429

Source of RFC: krb-wg (sec)

Errata ID: 6973
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Paul Miller
Date Reported: 2022-05-12
Held for Document Update by: Paul Wouters
Date Held: 2024-01-16

Section 6.2 says:

6.2.1:

   key-generation seed      8 bytes
   length

   random-to-key            des_random_to_key

6.2.2:

   key-generation seed      8 bytes
   length

   random-to-key            copy input, then fix parity bits

6.2.3:

   key-generation seed      8 bytes
   length

   random-to-key            copy input, then fix parity bits

It should say:

All sections:

   key-generation seed      7 bytes
   length

   random-to-key            des_random_to_key

Notes:

Section 6.2 describes the random-to-key operation as:

For generation of a key from a random bitstring, we start with a 56-
bit string and, as with the string-to-key operation above, insert
parity bits. If the result is a weak or semi-weak key, we modify it
by eXclusive-OR with the constant 0x00000000000000F0:

des_random_to_key(bitstring) {
return key_correction(add_parity_bits(bitstring));
}

For 6.2.1, the input should be 56-bits, not 64.
For 6.2.2 and 6.2.3, the random-to-key must also correct weak keys and not just the parity as currently described.

Of course, this is all purely of academic interest as the 10-year anniversary of RFC6649 deprecating single DES is coming up in a couple of weeks. The distinction between a "weak" single DES key and a correctly generated random key only matters if your adversary is restricted to using graphing calculators.

Status: Rejected (1)

RFC 3961, "Encryption and Checksum Specifications for Kerberos 5", February 2005

Note: This RFC has been updated by RFC 8429

Source of RFC: krb-wg (sec)

Errata ID: 5522
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Wrong required required checksum mechanism for des-cbc-crc
Date Reported: 2018-10-12
Rejected by: Benjamin Kaduk
Date Rejected: 2018-10-15

Section 6.2.3 says:

                               des-cbc-crc
   --------------------------------------------------------------------
   protocol key format      8 bytes, parity in low bit of each

   specific key structure   copy of original key

   required checksum        rsa-md5-des
   mechanism

It should say:

                               des-cbc-crc
   --------------------------------------------------------------------
   protocol key format      8 bytes, parity in low bit of each

   specific key structure   copy of original key

   required checksum        CRC32
   mechanism

Notes:

des-cbc-crc is using the modified crc32 checksum, its required checksum should be CRC32, constant defined in section 8
--VERIFIER NOTES--
Rejected per submitter request; the required Checksum is a distinct operation, not a subset of the encryption operation.

Report New Errata



Advanced Search