[137] in pc-kerberos
Re: Upcoming potential changes in KRBV4*.DLL
daemon@ATHENA.MIT.EDU (Derrick J. Brashear)
Thu Aug 3 15:18:38 1995
Date: Thu, 3 Aug 1995 15:11:45 -0400 (EDT)
From: "Derrick J. Brashear" <db74+@andrew.cmu.edu>
To: pc-kerberos@MIT.EDU
Cc: "Theodore Ts'o" <tytso@MIT.EDU>
In-Reply-To: <9508031757.AA24188@dcl.MIT.EDU>
Excerpts from internet.computing.pc-kerberos: 3-Aug-95 Re: Upcoming
potential chan.. by "Theodore Ts'o"@MIT.EDU
> Err.... *why* would you ever want to make your kadmind only store the
> Transarc string_to_key()? The Transarc string_to_key() was, and is, a
> mistake. An understandable mistake, given the histories of Vice, AFS
> and CMU, perhaps, but a mistake nonetheless.
We don't, but if you go back in the discussion it appears that there are
some sites that do.
> * Use the text password passed by the kpasswd client to generate
> a DES key using the MIT string_to_key algorithm. (In
> the case where you are converting to the standard
> string_to_key algorithm.)
What's the point? Everything stock that speaks the kadm protocol already
uses the MIT string_to_key, and if you modified your client to use the
Transarc string_to_key it's reasonable to assume you knew what you were
doing....
>Hence, I continue to believe the solution which I outlined to be the
>cleaner way of accomplishing your goal.
This I have no arguments with. It is cleaner than adding a new opcode. I
just don't understand your comments from this message with respect to
what you said in the first message, which (I thought) made perfect sense
to me.
-D
