[2124] in Kerberos_V5_Development
Re: [sci.crypt] Kerberos IVEC Attack
daemon@ATHENA.MIT.EDU (Theodore Y. Ts'o)
Thu Dec 19 13:16:23 1996
Date: Thu, 19 Dec 1996 13:16:07 -0500
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: "Barry Jaspan" <bjaspan@MIT.EDU>
Cc: krbdev@MIT.EDU
In-Reply-To: Barry Jaspan's message of Thu, 19 Dec 1996 16:52:04 GMT,
<199612191652.QAA17806@beeblebrox.MIT.EDU>
Here's a quick analysis of the proposed line of attack....
1) It's not as bad as one seems because you still have to do a chosen
plaintext attack; which is to say, after doing an active attack to
inject two ciphertext blocks into the stream, you have to retrieve the
decrypted plaintext somehow. It's possible that if the rlogin user has
an outbound, unencrypted connection, you might be able to recover the
plaintext. (David Wagner's suggestion of waiting to do this while the
user is sending e-mail is a bit more of a stretch, since the user is
likely to delete the garbage characters before sending the e-mail ---
assuming that the editor doesn't treat some of the characters as editing
commands or otherwise mangle the characters.)
2) Telnet does negotiate a new encryption key to use for the
encryption, for both V4 and V5.
3) V5 recvauth/sendauth *used* to automatically negotiate a new
encryption key. However, this feature was made optional when Chris
added the authentication context and moved the subkey processing into
the mk_req/rd_req functions. Most unfortunately, the appl/bsd suite
does *not* ask for subkey negotiation by default. Because we've done
the compatibility testing with older suites, it probably should be safe
to add AP_OPTS_USE_SUBKEY by default into the appl/bsd programs. But,
we should make sure that we really have interoperability. (This fix may
end up being in patchlevel 1 as well).
4) The encrypted rlogin protocols is not a simple "send 8 bytes";
there's a 4-byte length (ah, efficiency....) in there as well. So when
the attacker attempts to do the active attack and injects C[0] into the
stream, rlogind will interpret part C[0] as the length, get an
impossible length, and gunch the connection. This should protect us
for both V4 and V5.
5) Kerberos V5 DES-MD5 uses a zero ivec, so it is not vulernable to
this attack. HOWEVER, Kerberos V5 DES-CBC uses the key as the ivec,
because of backwards compatibility reasons. (The code I inherited from
way back when didn't follow RFC-1510, and it took a long time before
anyone noticed....)
6) The database currently has a bit to indicate whether or not DES-MD5
should be used; this again was because of backwards compatibility.
Given the known vulernabilities with DES-CBC mode at this point, it
seems that breaking backwards compatibility (in some kind of controlled
fashion) would be a good thing. We have a couple of options:
1) Remove DES-CBC entirely. (Users can do this by compiling
their KDC with the configure option --disable-des-cbc-crc)
2) Change the kadmin server to set the "can do des-md5 bit by
default"
3) Remove the "can do des-md5 bit from the database" (since
RFC1510bis will make des-md5 a requirement)
The bottom line is that while there's definitely no reason to panic,
there is a real, known weakness with Kerberos V4, and with supporting
backwards compatibility with DES-CBC w/ ivec=key. We will need to
consider what we want to do about this, while keeping in mind
compatibility concern with already deployed products, such as DCE.
Comments?
- Ted
