Subject: [kitten] SPAKE and weak checksum types

From: Greg Hudson <[email-masked]>
Date: Mon, 11 Sep 2017 12:01:01 -0400

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.)

---

From: Henry B Hotz <[email-masked]>
Date: Mon, 11 Sep 2017 12:35:12 -0700

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. [email-masked]

> On Sep 11, 2017, at 9:01 AM, Greg Hudson <[email-masked]> wrote:
> 
> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten

---

From: Greg Hudson <[email-masked]>
Date: Mon, 11 Sep 2017 16:38:38 -0400

> 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 downg…

If the KDC downgrades itself to encrypted timestamp for DES/RC4 keys,
only a passive attack is needed, versus an active attack to downgrade to
encrypted timestamp.

The KDC can't be responsible for preventing downgrades to encrypted
timestamp; the client has to refuse it (assuming no FAST or TLS
tunneling).  If a client allows it but the KDC does not, the AS request
will fail, so the attack will at least be visible, but the client has
already sent a ciphertext which can be dictionary attacked.  It will be
much easier to configure a client to refuse encrypted timestamp if it
doesn't have to worry about the KDC refusing SPAKE based on what
enctypes it has for the client long-term key.

---

From: Robbie Harwood <[email-masked]>
Date: Tue, 12 Sep 2017 12:47:21 -0400

Greg Hudson <[email-masked]> writes:

>> 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.
>
> only a passive attack is needed, versus an active attack to downgrade
> to encrypted timestamp.
>
> tunneling).

I think this is the important part for me: we tend to put the
responsibility on the client to ensure that it receives an adequate
level of protection.

> It will be much easier to configure a client to refuse encrypted
> timestamp if it doesn't have to worry about the KDC refusing SPAKE
> based on what enctypes it has for the client long-term key.

Agreed.

Thanks,
--Robbie

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 13 Sep 2017 20:36:25 -0500

> > only a passive attack is needed, versus an active attack to downgrade

I must still be foggy from recovering from being sick; could you walk
me through the passive attack a bit more slowly (or which scenarios are
being compared)?

> responsibility on the client to ensure that it receives an adequate

Yes, this seems like a key point.

> > based on what enctypes it has for the client long-term key.

Yup; I think you should go ahead and make this change.  We can (and
are!) work on deprecating weak enctypes independently of new preauth
mechanisms.

-Ben

---

From: Greg Hudson <[email-masked]>
Date: Thu, 14 Sep 2017 00:20:15 -0400

> me through the passive attack a bit more slowly (or which scenarios are

The particular scenario I was concerned about here (which should not be
an issue since we appear to have agreement on the text change) was: the
KDC and the client both permit SPAKE and encrypted timestamp.  The KDC
decides not to offer SPAKE because the initial reply key is an RC4 key
and therefore the transcript checksum would use HMAC-MD5.  The passive
attacker can simply dictionary attack the ciphertext from the client (or
the KDC).

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 14 Sep 2017 10:25:05 -0500

> attacker can simply dictionary attack the ciphertext from the client (or

Ah, the passive attack is limited to the case where the weak reply key
would be used, got it.

Thanks,

Ben

---

From: "Henry B (Hank) Hotz, CISSP" <[email-masked]>
Date: Thu, 14 Sep 2017 21:38:28 -0700

> On Sep 13, 2017, at 9:20 PM, Greg Hudson <[email-masked]> wrote:
> 

Wouldn’t the KDC have already sent a preuth-required message which prohibited that enctype? I thought the list of enctypes was separate from the list of PA types.

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 15 Sep 2017 19:08:51 -0500

> Wouldn’t the KDC have already sent a preuth-required message which prohibited that enctype? I thought the list of enctypes was separate from the list of PA types.

The spake draft requires that, if SPAKE is to be used/offered, a single
enctype must be in pa-etype-info2.  So the key decision here is at the
KDC, a combination of whether to offer SPAKE at all and what enctype(s)
to use.  But in this scenario, the KDC does not wholesale forbid HMAC-MD5,
it was just going to comply with the (old) draft text to forbid SPAKE
with MD5.  So, if the RC4 key was the initial choice for reply key,
that "compliant" KDC could not offer SPAKE and would have to only offer
encrypted-timestamp.  The client would then actually send the encrypted
timestamp, offering the ciphertext in question.  On the other hand, if
RC4 was not the initial choice for the reply key, then the KDC would
offer SPAKE with that other enctype.

-Ben