[122] in pc-kerberos
Re: Upcoming potential changes in KRBV4*.DLL
daemon@ATHENA.MIT.EDU (John Gardiner Myers)
Mon Jul 31 17:59:30 1995
Date: Mon, 31 Jul 1995 17:55:57 -0400 (EDT)
From: John Gardiner Myers <jgm+@CMU.EDU>
To: pc-kerberos@MIT.EDU
In-Reply-To: <9507291911.AA13079@MIT.EDU>
I have proposed a solution. It is to add to the MIT v4 password
changing protocol a new opcode to obtain the preferred string-to-key
algorithm for the realm. If the opcode is not supported by the
server, the client should use the MIT v4 string-to-key.
Sites running a Transarc kaserver are already in the position of
having to install an additional server in order to support the MIT v4
password changing protocol. It would not be too much of a burden on
those sites to have a version of the server that supports the
extension if they want to continue to use the Transarc string-to-key.
In informal discussions I've had with a Transarc developer, the "add
an opcode" approach is exactly what we came up with for having the
Transarc RX-based password changing clients support the MIT v4
string-to-key.
CMU is most certainly where the multiple string-to-key problem
started--at the time CMU adapted Kerberos for use with AFS, it had an
existing database of user keys from the previous authentication
mechanism. Having AFS authentication clients use the string-to-key
algorithm of the previous authentication mechanism made perfect sense
at the time.
My first project when I started working for CMU's Computing Services
division back in '91 was to start integrating the MIT and Transarc
implementations of Kerberos. Seeing the need to fix the string-to-key
mess back then, I took the first step of having the Transarc
authentication clients try both string-to-key algorithms and sent the
change to Transarc. Now that the change has popped out the other end
and has gotten wide deployment, we have deployed what we could of
changes to the Transarc password-changing programs to use the MIT
string-to-key and submitted them to Transarc. It now remains to be
seen what if anything pops out the other side.
So, CMU is trying to clean up the mess it made, but it can't do it
without the help of other developers.
--
_.John G. Myers Internet: jgm+@CMU.EDU
LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up
