[5349] in Kerberos
Re: Kerb V4-> Kerb V5 -> DCE Key Conversion?
daemon@ATHENA.MIT.EDU (Joe Kovara)
Thu Jun 8 02:21:21 1995
To: kerberos@MIT.EDU
Date: Wed, 7 Jun 1995 22:19:55 -0700
From: Joe Kovara <joek@CyberSAFE.COM>
On 7 Jun 1995, Nik Conwell wrote:
> Regarding the migratability (V4->V5->DCE) of kerberos key strings:
[...]
> The Kerberos FAQ (04/13/1995) indicates that Kerberos version 5 comes with a
> program to convert a version 4 database to version 5. Does this include the
> keys or would we have to select all new passwords? Would it be possible now,
> to save off just version 4 keys (and their associated login names) whenever we
> do a unix password change, and then convert that information into a version 4
> (or 5) database at a later date?
You can't convert a K4 key to a K5 key; you need the original password
(and salt) to generate the key. This generally requires that, when you
convert a K4 to a K5 DB, that everyone changes their password if you are
using V5 clients, because those K5 clients generate/require a K5 key.
This can be a major pain if you have a mixed K4/K5 client base, and K4/K5
clients are used at different times with the same principal. E.g., fred
uses a K5 kpasswd and the next day sits down at a workstation with K4
installed and does a kinit or a kpasswd, then the day after goes uses
another workstation that has K5 installed... (It's not a pain if your K5
client and kdc understand the problem and deal with it for you. :)
There are several issues with using the unix password as stored in the
password file: (1) Again, you can't convert an etc/passwd key to a K4/K5
key. (2) Even if you have the password as represented by the entry in
etc/passwd, would you want to use it? Do you really want to take the
security of Kerberos principal's passwords down to the level of etc/passwd
(at least for systems without a shadow password file)? The alternative
is, of course, to have an integrated login/single signon which doesn't
require the local password file for controlling login. (3) Yes, you can
save the principal/user id and password on a change password. Some sites
have taken this approach as a transition strategy. However, I'd suggest
that you generate the K4/K5 keys on-the-fly, and not store the clear-text
passwords.
Note that to get the keys/passwords securely from the local system to
whatever back-end you use to store/update these passwords, you'll need a
secure connection, which will require using an existing key. Example of
the problem: the user just changed their password and now you have
everything you need to generate/store the K4/K5 key. Now what? You have
get it to, e.g., the KDC, but you don't have a pre-existing key with
which to establish a secure connection. There are many possible solutions
to this problem (local daemon or using a key out of the srvtab; local
storage with batching using kerberized rcp or ftp; etc.) No rocket
science involved, just more work.
> How about DCE? It can serve a Kerberos V5 client. Is there a program to
> convert a Kerberos version 5 database to a DCE database? Again, if we just
> saved off the V5 keys (and login names), would it be possible to create a
> database?
I'm not aware of any off-the-shelf packages, although I know it's been
done (not terribly difficult). DCE keys are K5 keys, so you don't need to
play games as with K4/K5, and you don't need to save the passwords. The
rest is simply loading the DCE-specific information, which I assume you
have in some other form (e.g., group information)? Where this other
information comes from is very dependent on the site (e.g., existing host
accounting information; HR/personnel databases, etc.). Again, no rocket
science, just work--and it's typically a little different for every
organization.
Joe Kovara / Product Development Manager / CyberSAFE / joek@cybersafe.com
