[1599] in Kerberos_V5_Development
Re: kadmin and md5
daemon@ATHENA.MIT.EDU (Sam Hartman)
Fri Aug 16 12:50:35 1996
To: "Barry Jaspan" <bjaspan@MIT.EDU>
Cc: krbdev@MIT.EDU
From: Sam Hartman <hartmans@MIT.EDU>
Date: 16 Aug 1996 12:50:24 -0400
In-Reply-To: "Barry Jaspan"'s message of Fri, 16 Aug 1996 11:26:46 -0400
>>>>> "Barry" == "Barry Jaspan" <bjaspan@MIT.EDU> writes:
Barry> Ergo, I'd suggest removing the special MD5 code and just
Barry> having all enctypes represented directly in the database,
Barry> even if they have the same actual key contents.
I think you will end up losing that argument. I certainly did
when I tried to make it a while back. So, while I agree with you, I'm
assuming that's not quite an option.
There are two levels of complexity with the md5 bit. In
addition to the md5 bit, there is the magic aliasing in
kdb5_dbe_find_enctype that says that all single-DES keys are basically
the same. If the KDC asks for des-cbc-md5 and there is a des-cbc-crc
or des-cbc-md4 key present, it will get that key. Woe to the
database entry that has both des-cbc-md5 and des-cbc-crc, for
confusion and randomness may happen. (Actually, I think it works out
OK and either always uses the last or first key, but would have to
meditate to be certain.)
So, the md5 bit only serves to determine whether/when the KDC
asks for a md5 key. Other encxryption types such as md4 and DES3 use
the variables in krb5.conf and kdc.conf to control which enctype is
allowed/used/asked for. I se no reason to special case md5 more than
anything else.
Honestly, both mechanisms (the md5 bit and the config file
variables) are the wrong way of looking at it. Basically, you are
using information in the KDC or on the client to determine what
enctypes a server process supports. Unfortunately, there isn't really
too much better we can do because we don't have a protocol between the
server and KDC.
Actually, I guess that's not completely true. If you manage
to win the argument of representing all enctypes as themselves in the
database, then you could specify the information about what enctypes a
particular server supports by what enctypes were in the database.
Yes, the rule of administrative simplicity would strongly encourage
users to choose a least-common-denominator, but phased upgrades could
be done on a host-by-host basis and not on a realm-by-realm basis.
Alternatively, we could add additional complexity, including a
set of supported enctypes in each principal entry in the databse as
well as providing an API to set this information. (Again, this could
go in the policy). This would basically be equivelent to having each
enctype represent itself in the databse. The only problem is that the
database isn't the only place where you have to deal with enctype
equivelences. I think you could get the keytabs and everything else
to work, although it would certainly be more complex than a one-to-one
correspondance.
--Sam
P.S. I copied krbdev not krbcore, as that's where I originally
intended to send the original message on this thread.
Barry> Barry
