[133] in pc-kerberos
Re: Upcoming potential changes in KRBV4*.DLL
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Wed Aug 2 22:40:50 1995
Date: Wed, 2 Aug 1995 22:33:49 -0400
From: Theodore Ts'o <tytso@MIT.EDU>
To: pbh@MIT.EDU (Paul B. Hill )
Cc: "Derrick J. Brashear" <db74+@andrew.cmu.edu>, pc-kerberos@MIT.EDU
In-Reply-To: "[132] in pc-kerberos"
Actually, let me suggest an entirely new solution, which is actually
much cleaner. (My apologies for joining this discussion late, but I
only read this mailing list via the discuss meeting.)
One of the things that was added relatively late to the Kerberos kadmin
protocol was that in the change password request, not only is the new
DES key sent to the kadmin server, but the ASCII text password can be
sent as well. This text password is needed for some of the password
quality checking routines. The way this extension was added was fully
backwards and forwards compatible; old kadmind's ignored the extra text
password, and if an old client didn't send the text password to a new
kadmind, the new kadmind simply skipped the extra password quality
checks. (However, if you did send a text password, the kadmind *did*
check to make sure that the text password matched the DES key.)
This code is in the patchlevel 10 release, as well as the CNS sources.
I believe it already exists in the Kerberos V4 DLL, although the clients
may or may not be using it --- you need to call kadm_change_pw2()
instead of kadm_change_pw() in order to pass the text password. If the
PC clients are doing the right thing, then no changes will be required
at all! If they aren't, then the only work which is necessary is
updating them to pass the text password as well as the DES key to the
change PW request. This has the added benefit that kadmind's with the
password quality check code turned on can do a better job.
Once the kadmind has the text password as well as the DES key, it can
use the text password to use an alternative string_to_key algorithm (and
ignoring the passed-in DES key) if it so chooses. This has the
advantage that *server* makes the determination of what string_to_key
algorithm it wishes to use, not the client. Hence, you don't need a lot
of extra complexity in the client; you don't need an extra kadmind
opcode; and sites who want to put this into effect merely have to
reconfigure and/or recompile their kadmind to change which string_to_key
algorithm the kadmind uses when processing the text password which is
passed along in the request.
I think this is a much simpler, and easier to implement solution. If
the existing clients are using the correct version of the
change_password routines, it might not require changing the clients at
all!!
- Ted
