[123] in pc-kerberos
Re: Upcoming potential changes in KRBV4*.DLL
daemon@ATHENA.MIT.EDU (Paul B. Hill )
Mon Jul 31 21:10:01 1995
To: John Gardiner Myers <jgm+@CMU.EDU>
Cc: pc-kerberos@MIT.EDU
Date: Mon, 31 Jul 95 21:05:13
From: pbh@MIT.EDU (Paul B. Hill )
Reply-To: pc-kerberos@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.
Maybe I am slow but it looks like your proposed solution works for CMU and
MIT at no cost but screws UMich, Cornell and possibly other sites (I suspect
many from the Mandarin consortium.) By this I mean that they are running
Transarc style realms and have an existing server that supports the MIT
password changing protocol but which uses the Transarc string to key
algorithm. As I understand your proposed solution you want them to deploy
new servers to support the new opcode, other sites wouldn't have to since
the default is the MIT s-t-k. They would also have re-deploy any clients
that may support the password changing protocol to use the extended
protocol. I doubt that they would find this to be an acceptable solution.
Extending the protocol and changing the default to the Transarc s-t-k is
also unacceptable. In this case to MIT and the majority of sites running
MIT style realms.
At the moment it seems that CMU is the odd man out. You appear to be the
only site that is trying to use the MIT password changing protocol to
migrate its existing user base to a new string to key algorithm.
I'm looking for a solution that involves no cost to the majority of sites
and is still managable by CMU or any site that chooses to migrate in the
future.
It's possible that I have misunderstood the cost of your proposed solution.
If so I'm pretty sure I'm not the only one. Perhaps a restatement in more
detail would clarify matters if there has been an error on my part.
Paul
