Subject: Re: comments on draft-ietf-krb-wg-crypto-02.txt

From: [email-masked]
Date: Tue, 19 Nov 2002 15:25:50 -0600 (CST)

using -f
To: [email-masked]
Subject: comments on draft-ietf-krb-wg-crypto-02.txt
From: assar <[email-masked]>
Date: 19 Nov 2002 15:58:20 -0500
Lines: 100
Sender: [email-masked]

> 5.2.1. DES with MD5

>     random-to-key            copy input, then fix parity bits (discards
>                              low bit of each input byte)

What about weak keys?  I assume that this function 'fixes' them,
thereby mapping more inputs to the same key?

> 5.3. Triple-DES Encryption with Key Derivation

>                            des3-cbc-hmac-sha1-kd
>               ------------------------------------------------
>               protocol key format     24 bytes, parity in low
>                                       bit of each
> 
>               key-generation seed     21 bytes
>               length

why is this 21 as opposed to single DES being 8?

> 5.3.1. Triple DES Key Production (random-to-key, string-to-key)

>    No weak-key checking is performed.

Why is this?

> 6.1.4. The RSA MD4 Checksum
> 
>    The RSA-MD4 checksum calculates a checksum using the RSA MD4
>    algorithm [MD4-92].  The algorithm takes as input an input message of
>    arbitrary length and produces as output a 128-bit (16 octet)
>    checksum.  RSA-MD4 is believed to be collision-proof.

It should also be noted here that this checksum should not be used
(same as with rsa-md5, but worse).

> 6.2. CRC-32 Checksum

>    The use of collision-proof checksums is recommended for environments
>    where such attacks represent a significant threat.

Remove this superflous sentence.

> 7. Use of Kerberos encryption outside this specification

>    Some problematic assumptions we've seen (and sometimes made) include:
>    that a random bitstring is always valid as a key (not true for DES
>    keys with parity);

or useful as a key (weak keys)

> 8. Assigned Numbers

Are/should negative numbers reserved for unregistered use?

>    Checksum type             sumtype         checksum          section
>                                value             size
>    ----------------------------------------------------------------------
>    CRC32                           1                4            6.2
>    rsa-md4                         2               16           6.1.4
>    rsa-md4-des                     3               24           6.1.1
>    des-mac                         4               16           6.3.1
>    des-mac-k                       5                8           6.3.2
>    rsa-md4-des-k                   6               16           6.1.5
>    rsa-md5                         7               16           6.1.2
>    rsa-md5-des                     8               24           6.1.3
>    rsa-md5-des3                    9               24
>    hmac-sha1-des3-kd              12               20            6.4
>    hmac-sha1-des3                 13               20
>    sha1 (unkeyed)                 14               20

10 seems to also have been used for this

> 9. Implementation Notes
> 
>    The "interface" described here is the minimal information that must
>    be defined to make a cryptosystem useful within Kerberos in an
>    interoperable fashion.  It is not an attempt to define a complete API
>    for cryptographic functionality within Kerberos.

'complete API' ?  I thought it didn't define any API at all.

> 10. Security Considerations

>    The use of triple-DES in Kerberos makes no effort to avoid these
>    keys.  The nature of the weak keys is such that it is extremely
>    unlikely that they will weaken the triple-DES encryption -- only
>    slightly more likely than having the middle of the three sub-keys
>    match one of the other two, which effectively converts the encryption
>    to single-DES, which is another case we make no effort to avoid.

I disagree, by comparison to single DES, weak keys should be avoid in 3DES.

>    The true CRC-32 checksum is not collision-proof; an attacker could
>    use a probabilistic chosen-plaintext attack to generate a valid
>    message even if a confounder is used [SG92].  The use of collision-
>    proof checksums is of course recommended for environments where such
>    attacks represent a significant threat.

Not recommended at all.

---

From: Ken Raeburn <[email-masked]>
Date: Tue, 19 Nov 2002 23:48:25 -0500

> thereby mapping more inputs to the same key?

That's already been pointed out, and is one of the reasons an -03
draft will be needed.

> why is this 21 as opposed to single DES being 8?

Because no bits are discarded, they're all used, and parity bits are
inserted to make 24 bytes.

We're looking at changing DES to do likewise.  I *think* it's safe,
but if there's some use of random-to-key for DES that I'm failing to
remember, this would be an incompatible change.

>>    No weak-key checking is performed.

"Because."

That's the way the triple-DES support was defined.  And I think I
mentioned in the security considerations section, it doesn't seem like
a real weakness.

> Remove this superflous sentence.

These look reasonable....

> or useful as a key (weak keys)

Right.

> Are/should negative numbers reserved for unregistered use?

Yes.  If it's not explicit, it should be.

> 10 seems to also have been used for this

Interesting.  By whom?

> 'complete API' ?  I thought it didn't define any API at all.

True, but even if you fashion an API loosely on the operations defined
here, it will not supply all the functionality you will need.

> I disagree, by comparison to single DES, weak keys should be avoid in 3DES.

Why?  Do you think the particular weakness of these keys still applies
in the 3DES case?

I'm not convinced it's all that important to us in the single-DES
case, either, but the existing code base is what it is.

In any case, that change could break existing deployments.  (With very
low probabilities for any individual key generation, but non-zero.)

>>    attacks represent a significant threat.

Collision-proof checksums are recommended.  CRC-32 is not one, and
therefore is not recommended.