From this answer:
However, that wasn't the only situation they had in mind; they also considered the case where someone implemented 2 key 3DES in hardware (which the first and last subkeys were constrained to be the same)
Why are the first and last keys constrained to be the same?
In two key 3DES two keys are equal so that key size is only 112 bits, compared to the 168 bits of full 3DES. The advantage is a smaller key size without a correspondingly large loss in security: both two and three key 3DES can be attacked in about $2^{112}$ time.
With the encrypt-decrypt-encrypt construction it clearly must be the first and last key that are equal, since having two adjacent keys equal would make the decryption and encryption cancel out. Even with EEE it would have been weak to have equal keys adjacent: it would effectively be a cascade of two 56-bit strength ciphers (DES and double-DES), which a standard meet-in-the-middle attack breaks in roughly $2^{56}$ time.
So having the first and last keys equal is the only option that makes sense.
If we want to make three successive DES encryptions or decryption using 2 secret keys K1, K2 at least one time, and possibly a public constant C0 used as key, we are bound to chose among the following six possibilities (listed by alphabetical order, ignoring configurations equivalent by exchange of K1 and K2); all except number 5 are vulnerable to a basic meet-in-the-middle attack, at the meeting point indicated by . (the condition for a meeting point being that there is only one unknown key on each side):
C0 K1 . K2K1 C0 . K2K1 K1 . K2K1 . K2 C0K1 K2 K1K1 . K2 K2Hence K1 K2 K1 is the only choice to keep 3DES with two keys safe from the basic meet-in-the-middle attack.
That reasoning works regardless of if we use the keys in an Encrypt-Decrypt-Encrypt mode (as we do, making choices 3 and 6 unsuitable), or Encrypt-Encrypt-Encrypt mode (which as pointed by poncho would not allow a fall-back to simple-DES from two-key TDES with K1 K2 K1 schedule).
