[1238] in Kerberos_V5_Development
Re: [lots of stuff]
daemon@ATHENA.MIT.EDU (Marc Horowitz)
Fri May 24 23:19:53 1996
To: krbdev@MIT.EDU
Date: Fri, 24 May 1996 23:19:38 EDT
From: Marc Horowitz <marc@MIT.EDU>
>>> Barry says:
>> I imagine there could be all kinds of kadm5 clients interested in
>> storing their own per-principal tagged data.
I have a few in mind. I'd very much like to see kadm5 functions to
manipulate tl_data.
>> It seems much less sensible for kadm5 to export the e_data (and
>> e_length) fields. These two fields are very specific to the
>> libkdb-on-db(m) implementation. The kadm5 interface is supposed to be
>> independent of the database layer; that is why it has its own
>> principal type instead of using krb5_db_entry directly.
We have two different methods for extending the database. One is a
reasonably generic extension mechanism. One is a crock. As far as I
know, nothing uses the e_data extension mechanism. If we ever need to
extend the database, we can add entries on the end, and bump the
version number to indicate that they are there. The dump version
number will indicate to the loader what fields are present.
Therefore, I propose we end-run around the problem and just drop
e_data on the floor now, before someone starts to use it.
>>> Richard says:
>> However we should deal with applications like ftp that have
>> both a clear and safe mode. I realize GSSAPI does not use the mk_safe
>> or mk_priv code, but does it use the session key both for signing and
>> for encryption?
GSSAPI uses the session key for signing, and various reversible
manipulations of the session key for encrypting, keyed hashing, etc.
This is all detailed in the rfc/i-d's.
>>> Sam says:
>> <stuff about cryptosystem and checksum compatibility>
This same argument applies to cryptosystem and salt compatibility.
This code appears in several places right now:
switch (ktype) {
case ENCTYPE_DES_CBC_MD4:
case ENCTYPE_DES_CBC_MD5:
case ENCTYPE_DES_CBC_RAW:
ktype = ENCTYPE_DES_CBC_CRC;
break;
default:
break;
}
This is a crock. I believe that the encryption types (and probably
the salt types, too) should have an associated key type. This key
type never traverses the net, so it's only an implementation aid.
This allows code which needs to do stuff which is based on the key
*only* to check for compatibility directly, instead of having lists
like the one above. In the example of checksums, the code would
simply compare the key types associated with the enctype and the
cksum, and if they were different, return an error.
>>> Barry says:
>> I have started porting OV's test system so that we can use all the
>> tests that are already written. The scripts make all sorts of changes
>> to system configuration files. They *shouldn't* prevent anyone from
>> logging in, and the *should* restore everything when they are
>> done... but just in case, you've been warned.
The current MIT system is set up so that *everything* (config files,
port numbers, etc) can be specified by either environment variables or
command line flags (/etc/passwd is one of a few exceptions). This
allows the tests to run without affecting the system for the most
part. Clearly, you want to get the system as is working first, but I
think that adding support for this sort of run-time configuration
would be a good thing in the long term.
Marc
P.S. I can't telnet into beeblebrox :-)
