[1590] in Kerberos_V5_Development
kadmin and md5
daemon@ATHENA.MIT.EDU (Sam Hartman)
Thu Aug 15 20:22:11 1996
Date: Thu, 15 Aug 1996 20:22:06 -0400
From: Sam Hartman <hartmans@MIT.EDU>
To: krbcore@MIT.EDU
I am under the impression that Beta 6 should support md5, and
that for this reason, Beta 7 should also support md5. If we didn't
officially support md5 in Beta 6, then the simplest solution to this
problem may be to do nothing and leave it broken.
In Beta 6, there was a principal supports md5 bit on each
principal that you had to set in order for MD5 to be used either to
encrypt server tickets, or to choose session keys.
The current kadmin doesn't provide a way to set this bit.
Honestly, I found the entire md5 mechanism overly confusing and am not
convinced that was the best way of handling things, so my preferred
solution to this entire problem is to remove the logic that handles
the md5 bit and simply to treat keys of type des-cbc-crc the same as
those of type des-cbc-md5. This has the following implications:
* If des-cbc-md5 is specified in kdc.conf's supported enctypes line
instead of des-cbc-crc, then server tickets for single-DES keys would
be encrypted in des-cbc-md5. It is the setting of the kdc.conf
variable when the principal is created that matters; a site could have
a mixed database if they really wanted to. Honestly, though, I know
of no services that are unable to decrypt a MD5 service key and that
use a modern libkrb5.a. This would simply mean that sites using
services with old libkrb5.a or with broken MIT or non-MIT Kerberos
implementations would not want to change the kdc.conf to specifically
enable MD5.
Because of a wonderful bug in MIT Kerberos previous to Beta 6,
you don't want to enable encryption of server tickets in md5 until all
your clients are upgraded. There is absolutely no reason why a client
should ever care what enctype is used to encrypt the encrypted part of
the ticket, but instead of using the enctype associated with the
session key to determine what encryption system to use for the session
key, clients previous to Beta 6 used the enctype (then ktype) of the
encrypted part of the ticket. Because it worked (all ktypes were
des-cbc-crc back then), no one noticed and no one fiex the bug.
* if des-cbc-md5 appeared before des-cbc-crc in the
default_tgs_enctypes line in krb5.conf, then MD5 keys would be used
for session keys whenever a database entry had any form of a
single-DES key. Since even Richard and I aren't brave enough to only
use DES3, it is reasonable to assume that all database entries have at
least one single-DES key at the current time. This use of session
keys would happen for all applications that do not specifically
overide the key they desire. At the current time, GSSAPI, krb524 and
telnet specifically request a DES-CBC-CRC key. This would mean that a
site using new clients to talk to old servers would not want to put
des-cbc-md5 before des-cbc-crc in krb5.conf.
So what about sites with old clients talking to new servers?
It turns out this works regardless of what's in krb5.conf, because the
old clients aren't smart enough to even try to ask for MD5, so the KDC
will not use it for sesssion keys.
OK, so why am I rattling on about this confusing complex
garbage when it's clear that you basically can't use md5 in any
environment where you might have to talk to someone before Beta 6?
Well, basically, it's just as complex and broken if you have an md5
bit zon each principal. However, instead of following the semantics
of the mildly-understandable configuration file, you have to get the
database attributes right as well. O, yes, and if you get the config
files wrong and the database right, there are still situations in
which you don't get what you expect. For example, if
supported_enctypes includes des-cbc-md5 before des--cbc-crc, you'll
end up using md5 to encrypt server tickets *regardless* of the setting
of the md5 bit. Remember, this is sufficient to break
interoperability with clients previous to Beta 6 in some situations,
or at least I think so.
I checked the facts in this message before writing it, but
reflections over a few things have caused me to wonder why we don't
see more complaints about interoperability, so I'm going to check
things over again. My only certain conclusion at this point is that
the Beta 7 default configuration probably doesn't want to enable MD5.
Somewhat less certain, although something I'm still moderatly
comfortable asserting is that the md5 bit doesn't actually help things
and should be discarded.
--Sam
