[kitten] SPAKE and weak checksum types

[Greg Hudson <[e-mail]>]

Currently the SPAKE draft says, in security considerations:

    Weak checksums present a risk to the transcript checksum. Any etype
    with a checksum based on one of the following algorithms MUST NOT be
    used:

    * CRC32
    * MD4
    * MD5

I have several problems with this clause.  The implementer doesn't get
to choose the transcript checksum type; it is specified as the required
checksum type of the initial reply key.  To conform to this clause, and
implementer must decline to offer SPAKE preauth if the initial reply key
uses RC4 or DES.  While those enctypes are problematic, I don't think
it's ideal for the KDC to throw up its hands and use encrypted timestamp
just because the SPAKE transcript checksum would be using MD5 (which is
still preimage-resistant as far as we know).

Also, this clause focuses on the transcript checksum, which seems like a
difficult attack vector as it is merely one component of key derivation,
while ignoring other possible weaknesses of the reply key encryption
type, such as the integrity tag on the key confirmation or the
confidentiality of second-factor data.

I propose to replace this clause with the following wording:

    This mechanism does not upgrade the encryption type of the initial
    reply key, and relies on that encryption type for confidentiality,
    integrity, and pseudo-random functions. If the client long-term key
    uses a weak encryption type, an attacker might be able to subvert
    the exchange, and the replaced reply key will also be of the same
    weak encryption type.

(During the design of the SPAKE preauth mechanism, I did consider the
possibility of upgrading the reply key encryption type, so that the
client long-term key is only used as a source of octets for the shared
secret input to the SPAKE algorithm.  Although that would be a neat
benefit for deployments with a lot of legacy DES or RC4 client keys, it
would significantly complicate the spec.  It would also introduce a risk
of a downgrade attack on the initial reply key enctype, e.g. if the KDC
could be fooled into thinking that DES is a better choice than AES by
altering the request enctype list.)