[1231] in Kerberos_V5_Development
for Beta 6: new handling of checksums for mk_safe
daemon@ATHENA.MIT.EDU (Sam Hartman)
Fri May 24 00:16:29 1996
Date: Fri, 24 May 1996 00:16:25 -0400
From: Sam Hartman <hartmans@MIT.EDU>
To: krbdev@MIT.EDU
Richard and I were discussing issues involved in setting
default checksum types for various operations and came up with serious
concerns that several situations may use entirely inappropriate
checksum types with unpredictable behavior (Richard sort of thinks it
might accidentally work, but he needed to consider issues before
deciding for sure. Besides, I like to have a stronger confidence in
Kerberos than "It accidentally works.") Mor over, we realized that
changes in Beta 6 will make the problem harder to solve in the
future.
Therefore we propose the following change be made in Beta 6.
I realize this is not the best times to be propose a substansive
change to the internals of how libkrb5 decides what checksum type to
use, but in the interest of not maintaining compatability with broken
code, I think it is worth doing.
Currently, we allow the user to select a default kdc checksum
and to select a default checksum for mk_safe. I think the kdc
checksum applies to the TGS request and reply, and this proposal may
not apply well to the kdc checksum if it applies to the AS request.
However, at least in the case of krb5_mk_safe, the checksum
must be a keyed cryptographic checksum. Unfortunately, there is no
reasonable default keyed cryptographic checksum: keys are only
appropriate for some checksums. For example, using a DES key with a
DES3-SHA checksum will fail. By chance, using a DES3 key with a
DES-MD5 checksum may work, but it isn't clean and should be suspect
from a security standpoint.
So, how does this change Beta 6---we're only supporting DES in
Beta 6, not DES3, right? Well, yes, but configuration decisions in
Beta 6 will make it hard to support DES3 in the future.
It is silly to provide configuration options for keyed
checksums, when the key contains an enctype. You could justuse the
enctype to select the appropriate checksum for that cryptosystem. For
des-cbc-crc and des-cbc-md4, we simply select the keyed checksum used
prior to Beta 5. For DES-CBC-MD5, we use DES-MD5 as the keyed
checksum, etc.
This way, when DES3 comes along, we simply use DES3-SHA or
whatever as the keyed checksum.
In short, I'm trying to avoid giving users flexibility to
select a non-standard checksum for the cryptosystem they use. If we
provide this option, it will get significantly more complicated in the
future. It is inessential and confusing to give the user this
flexibility, and there really aren't good reasons for changing the
default.
All I propose to do for Beta 6 is to make enough changes so
that:
1) The mk_safe (and if appropriate kdc) checksums are chosen based on
the enctype of the session key being used to checksum data.
2) Fail predictably if a DES3-SHA (or other DES3 checksum--I don't
think there are any) is used with or verified against a single-DES
key. I realize we aren't trying to support DES3, but you may be able
to cause unpredictable failures--even in the KDC--by sending checksums
with the wrong type of key. This check may be present already, but
Richard didn't think it was.
I will give more details Friday after my final. This change
will not be included in the Beta6 sources without Ted's direct
approval.
--Sam
