[1236] in Kerberos_V5_Development
Re: for Beta 6: new handling of checksums for mk_safe
daemon@ATHENA.MIT.EDU (Sam Hartman)
Fri May 24 17:08:26 1996
To: Sam Hartman <hartmans@MIT.EDU>
Cc: krbdev@MIT.EDU
From: Sam Hartman <hartmans@MIT.EDU>
Date: 24 May 1996 17:08:07 -0400
In-Reply-To: Sam Hartman's message of Fri, 24 May 1996 00:16:25 -0400
After examining the code involved in the checksums as it
evolved through various Kerberos betas, I see insufficient
justification to make a change in the way checksums are handled in
Beta6. Effectively, this means that we know that DES3 will not work
in a forward-compatible manner, but we already suspected this might be
the case.
By removing configuration options I had hoped to simplify the
logic required to decide whether a checksum received in a mk_safe or
KDC request was reasonable. I cannot do this because Beta 5 will
generate md5 checksums with DES-CBC-CRC keys, so we will have to
accept both MD4 and MD5 checksums with both DES-CBC-CRC keys and
DES-CBC-MD5 keys.
My only concern is that I do not think offering the checksum
related configuration options is a resonable long-term solution. We
can use the enctype of the key to determine appropriate checksums,
even if we maintain compatability with older versions of DCE. This
can be done by using md4 checksums with DES-CBC-CRC keys and MD5
checksums with DES-CBC-MD5 keys.
I propose that instead of making a last minute change to
remove these options and replacethem with functions that are dependent
on encryption type, we simply document that these options
(kdc_req_checksum, safe_checksum, ap_req_checksum) may be replaced
with a automatic mechanism in the future. We should also stress that
users should only use MD4 or MD5 for these checksums at the present
time.
We may actually keep the kdc_req_checksum and app_req_checksum
in the future. These are not keyed checksums, so there isn't a strong
reason to tie them to the cryptosystem. However, it would be nice if
Kerberos automatically used SHA as an app_req_checksum when the ticket
had a DES3 session key, and preferred MD5 over MD4 when the ticket had
a DES-CBC-MD5 key.
I feel comfortable committing documentation changes indicating
these options *may* be temporary, although I will send Ted a patch so
he can back out my changes easily.
I may also write code to determine these checksum options not
to be included in Beta6. I think it would solve some problems for
Richard and I with regard to DES3. If I do write this code, I'll
create a release branch for Beta6 and then commit my change on the
mainline after the Beta6 branch. I received reluctant approval from
Ted before he left to create a release branch if it was necessary. If
I create a release branch, I will send detailed instructions with
examples on how to update a tree to the release, how to commit to the
release branch, and how to merge changes both ways.
--Sam
