[134] in pc-kerberos
Re: Upcoming potential changes in KRBV4*.DLL
daemon@ATHENA.MIT.EDU (Derrick J Brashear)
Thu Aug 3 11:29:03 1995
Date: Thu, 3 Aug 1995 11:23:01 -0400 (EDT)
From: Derrick J Brashear <shadow@DEMENTIA.ORG>
To: "Theodore Ts'o" <tytso@MIT.EDU>
Cc: "Paul B. Hill " <pbh@MIT.EDU>, pc-kerberos@MIT.EDU
In-Reply-To: <9508030233.AA17016@dcl.MIT.EDU>
On Wed, 2 Aug 1995, Theodore Ts'o wrote:
> 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.
Indeed it is simpler, as you say, but does it not violate the spirit of
change_pw2? More importantly, picture this:
Some vendor has shipped Kerberos based on v4p10, which has only the MIT
string_to_key in it. The kpasswd they ship uses change_pw2. I get my
hands on a kadmind and make it do this, telling it to use the Transarc
string_to_key. You change your password, generating an MIT key. kadmind
then generates a Transarc key and stores that. You try to authenticate.
You lose.
If you consider this to be a serious problem, then my solution would work
better. Not that I'm plugging my solution necessarily, just bringing up
this issue.
For what it's worth, I implemented the additional opcode. On it's command
line, kadmind takes the -s argument, where currently you can say:
-s mitv4 to get the MIT string_to_key
-s transarc (you get the idea)
pref_stk is initialized to KADM_NO_OPCODE. If you choose mitv4, it gets
set to MITV4_STK (1) and if you choose transarc, TRANSARC_STK (2).
The flaw in this is that you need to get changepw.kerberos (implicitly
this requires typing your password) so you can find out the preferred
string_to_key.
Both solutions have their flaws, I think...
-D
