[114] in pc-kerberos

home help back first fref pref prev next nref lref last post

Re: Upcoming potential changes in KRBV4*.DLL

daemon@ATHENA.MIT.EDU (John Gardiner Myers)
Thu Jul 27 20:04:52 1995

Date: Thu, 27 Jul 1995 19:58:58 -0400 (EDT)
From: John Gardiner Myers <jgm+@CMU.EDU>
To: pc-kerberos@MIT.EDU
In-Reply-To: <199507262131.RAA12592@ccs.itd.umich.edu>

Robert John Churchill <rjc@monet.ccs.itd.umich.edu> writes:
> U of M, along with running a kaserver, also runs a daemon on them which
> speaks the MIT v4 password changing protocol.

So Umich has done development to do part of what is needed to support
MIT v4 clients, but doesn't want to do the rest?  They want to keep
MIT v4 string-to-key encoded passwords out of the database, making an
eventual transition to Kerberos v5 much more painful?

Even if there are some sites which want to keep using the Transarc
string-to-key for whatever reason, this shouldn't be the default
distributed with the PC client libraries.  In the long term,
perpetuating the use of two different v4 string-to-key algorithms is
going to keep causing more work and more problems for people.  If
anything should be "facilitated", it should be the eventual phase-out
of the Transarc string-to-key.

Anyway, a resource on the client is the wrong place to put this
information.  The preferred string-to-key algorithm is a feature of
the realm, not of the client.  The correct way to do this would be to
extend the MIT v4 password changing protocol to permit the client to
query for the preferred string-to-key.  If the server does not support
the extension, the client would know to use the MIT v4 string-to-key.

-- 
_.John G. Myers		Internet: jgm+@CMU.EDU
			LoseNet:  ...!seismo!ihnp4!wiscvm.wisc.edu!give!up

home help back first fref pref prev next nref lref last post