Discussion:
[kitten] SPAKE and weak checksum types
Greg Hudson
2017-09-11 16:01:01 UTC
Permalink
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.)
Henry B Hotz
2017-09-11 19:35:12 UTC
Permalink
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.
Post by Greg Hudson
Weak checksums present a risk to the transcript checksum. Any etype
with a checksum based on one of the following algorithms MUST NOT be
* 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.
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
https://www.ietf.org/mailman/listinfo/kitten
Greg Hudson
2017-09-11 20:38:38 UTC
Permalink
Post by Henry B Hotz
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.
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.
Robbie Harwood
2017-09-12 16:47:21 UTC
Permalink
Post by Greg Hudson
Post by Henry B Hotz
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.
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).
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.
Post by Greg Hudson
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
Benjamin Kaduk
2017-09-14 01:36:25 UTC
Permalink
Post by Robbie Harwood
Post by Greg Hudson
Post by Henry B Hotz
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.
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.
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)?
Post by Robbie Harwood
Post by Greg Hudson
The KDC can't be responsible for preventing downgrades to encrypted
timestamp; the client has to refuse it (assuming no FAST or TLS
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.
Yes, this seems like a key point.
Post by Robbie Harwood
Post by Greg Hudson
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.
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
Greg Hudson
2017-09-14 04:20:15 UTC
Permalink
Post by Benjamin Kaduk
Post by Greg Hudson
Post by Henry B Hotz
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.
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.
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)?
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).
Benjamin Kaduk
2017-09-14 15:25:05 UTC
Permalink
Post by Greg Hudson
Post by Benjamin Kaduk
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)?
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).
Ah, the passive attack is limited to the case where the weak reply key
would be used, got it.

Thanks,

Ben
Henry B (Hank) Hotz, CISSP
2017-09-15 04:38:28 UTC
Permalink
Post by Greg Hudson
Post by Benjamin Kaduk
Post by Greg Hudson
Post by Henry B Hotz
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.
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.
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)?
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).
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.
Post by Greg Hudson
_______________________________________________
Kitten mailing list
https://www.ietf.org/mailman/listinfo/kitten
Personal email. ***@oxy.edu
Benjamin Kaduk
2017-09-16 00:08:51 UTC
Permalink
Post by Henry B (Hank) Hotz, CISSP
Post by Greg Hudson
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).
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

Loading...