[118] in pc-kerberos
Re: Upcoming potential changes in KRBV4*.DLL
daemon@ATHENA.MIT.EDU (Paul B. Hill )
Sat Jul 29 15:13:55 1995
To: John Gardiner Myers <jgm+@CMU.EDU>
Cc: pc-kerberos@MIT.EDU
Date: Sat, 29 Jul 95 15:11:39
From: pbh@MIT.EDU (Paul B. Hill )
Reply-To: pc-kerberos@MIT.EDU
>>> 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?
>>
...
>>
>>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.
We're aiming for the maximum amount of usability at this point. We're not
trying to force everyone in the world to change. I won't bother to talk
about how CMU is the source of all these problems in the first place. :)
My primary goal is to make sure that the DLL works in the existing MIT
environment because I work for MIT. The next most important goal is to make
the DLL work at a number of other sites that are currently using the
Transarc string to key algorithm. It turns out that more than one site has
set up a server that uses the MIT password changing protcol but uses the
Transarc string to key. To the best of my knowledge CMU is the only site
using both string to key algorithms depending which protocol is used to
change the password.
When you brought your problem to my attention I suggested a solution. Since
then you have not offered any counter proposal you have only suggested that
the rest of the world should be doing what CMU is doing. I don't think that
this is very constructive.
Rather than redesign Kerberos version 4 at this time why don't we agree on
solution that will accomodate the majority of sites that want to use
Kerberos version 4 on their Windows machines. Then we can get on to the
business of migrating to Kerberos version 5 much more rapidly.
Would a resource that can superseeded by an ini file registry entry be more
acceptable to you (and CMU) ?
Paul
