Re: [kitten] SPAKE and weak checksum types

IIUC you are concerned with the case that someone will stand up a kdc which will opportunistically use SPAKE, but supports older/weaker stuff. By its nature such a beast will be vulnerable to downgrade attacks and you can't solve that in SPAKE. 

That said, I'm OK with your proposed change.  It does point the finger in the right direction. 

Personal email. hbhotz@oxy.edu

> On Sep 11, 2017, at 9:01 AM, Greg Hudson <ghudson@mit.edu> wrote:
> 
> 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.)
> 
> _______________________________________________
> Kitten mailing list
> Kitten@ietf.org
> https://www.ietf.org/mailman/listinfo/kitten