[1107] in Kerberos_V5_Development
Re: OV admin system integration plan
daemon@ATHENA.MIT.EDU (Richard Basch)
Sun May 5 17:53:52 1996
Date: Sun, 5 May 1996 17:53:01 -0400
To: Marc Horowitz <marc@MIT.EDU>
Cc: "Barry Jaspan" <bjaspan@MIT.EDU>, krbdev@MIT.EDU
In-Reply-To: <9605052019.AA04125@bart-savagewood.MIT.EDU>
From: "Richard Basch" <basch@lehman.com>
On Sun, 5-May-1996, "Marc Horowitz" wrote to "Barry Jaspan, krbdev@MIT.EDU" saying:
> First, a brief note on the session key PRNG (since that's what it is).
> I have this feeling that we're all wandering around in the dark
> hitting our heads on things. Oodles of stuff has been published on
> good PRNG's by people who know more about the subject than we ever
> will. Someone should pick up a copy of Schneier, read the section on
> PRNG's, and pick a good one for our purposes.
I didn't find much in Applied Cryptography (2nd edition), but I'll take
another look.
> Now, some comments on Barry's plan:
>
> >> The primary requirement for a V4 compatibility server comes from MIT
> >> itself; it is not critical for the public release to contain a
> >> fully-functional V4 compat server. I propose the following actions:
>
> Richard Basch claims to be using the v4kadmind. I'm curious why.
> Perhaps it's because of the current pitiful state of the kadmind5 :-)
A few reasons why I am using v4kadmind:
1. We still have a large V4 install base.
2. kadmind5 is pitiful doesn't buy much right now... it doesn't properly handle
multiple encryption types (eg. getting keytabs with all the enctypes,
adding/deleting enctypes for a given key). The random key features
are broken (add/change doesn't distill them into similar encryption
types -- I end up with multiple DES keys of differing salttypes,
sometimes with an unchanged kvno on top of that).
3. The V5 admin server/protocol is changing soon and I don't want
to build up an install base that I will have to convert. When
the final V5 admin protocol is done, I will consider deploying it.
> >> The KDC database is currently stored using DBM. The OV admin system
> >> uses DB for its own databases, and DBM to access the KDC database.
>
> "The kdb library currently uses the ndbm api. The OV admin system
> code uses the berkeley db api for its own databases, and the kdb
> library to access the KDC database." The rest of the paragraph
> follows more clearly from this.
Why doesn't the admin server use the kdb layer, instead of direct db/dbm
access? This would reduce the number of places that need to be changed
if a new db is chosen.
. . .
> There are currently a few programs which operate on the entire
> database as a unit. They create, convert, dump, load, and destroy the
> database. In krb4, there was a kdb_util program which performed all
> these operations based on a command-line argument. I think that this
> might be the right model for krb5, too, and we might merge the above
> functionality into a single kdb5_util program.
Actually, in V4, there were separate utilities to create and destroy the
database. kdb5_edit is somewhat analagous to the V4 kdb_util, with more
options for manipulating individual entries (such as extracting keytabs
or V4 srvtabs).
The part that actually needs work under the kadmin tree is ktutil.
There is no equivalent to the V4 ksrvutil (add/delete/change). However,
I must say that it provides a useful V4-V5 conversion feature.
(Btw, this is yet another reason why I still have v4kadmind - ksrvutil change).
> >> o Admin API. Rename the functions from ovsec_kadm_* to kadm_*....
>
> Convention in the tree would seem to indicate kadm5_* as a prefix, but
> I'm interested in others' opinions. This is also true of the other
> renamings you make.
I agree with Marc; we should use kadm5_*.
--
Richard Basch
Sr. Developer/Analyst URL: http://web.mit.edu/basch/www/home.html
Lehman Brothers, Inc. Email: basch@lehman.com, basch@mit.edu
101 Hudson St., 33rd Floor Fax: +1-201-524-5828
Jersey City, NJ 07302-3988 Voice: +1-201-524-5049
