[128] in pc-kerberos
Re: Upcoming potential changes in KRBV4*.DLL
daemon@ATHENA.MIT.EDU (Paul B. Hill )
Wed Aug 2 10:45:29 1995
To: John Gardiner Myers <jgm+@CMU.EDU>
Cc: pc-kerberos@MIT.EDU
Date: Wed, 2 Aug 95 10:40:58
From: pbh@MIT.EDU (Paul B. Hill )
Reply-To: pc-kerberos@MIT.EDU
>UMich and Cornell would have to deploy changes to their MIT password
>changing proxy server to support the new opcode. They would *not* be
>required to re-deploy any clients--those clients will continue to work
>as they did before.
>
>I don't consider this to be a significant, much less unacceptable,
>cost on their part.
I guess I must be missing something once again. Suppose you actually got the
world to start using your new kadmind. According to Derrick's message:
>b) add an opcode to kadmin to allow "what is the preferred string_to_key"
>where a reply of KADM_NO_OPCODE is the MIT s_t_k, and one of 0 (KSUCCESS)
>is Transarc's. This is to allow a cheat. If kadmind doesn't allow the new
>opcode, you get the MIT s_t_k, assuming your client supports both and
>this sort of query. Otherwise, you get what your client supports or
>defaults to.
[pbh - It looks like the author has missed the point that some
clients default to the Transarc s-t-k when using the MIT password changing
protocol ]
> (I'll of course add this opcode to what I roll into the kaserver)
Note the part about "assuming your client ..." The point is UMich, Cornell,
and others have clients that default to using the Transarc string to key
algorithm on various platforms.
So I don't understand how you can say that they would not be required to
re-deploy any clients.
It seems to me like you want your kadmind modifications to be a little more
flexible. The kadmin would query for the preferred string to key. The
responses could be KADM_NO_OPCODE, MIT, TRANSARC. If the client responds
with MIT or TRANSARC clearly the right thing could happen. If KADM_NO_OPCODE
is returned then the result would be up to the site adminstrator. AT UMich
and Cornell the correct action would be for the server to use the Transarc
string to key. At CMU you would configure the server to use the MIT string
to key.
Existing clients that don't support the new query would use their current
default behaivor of knowing which s-t-k succeded when doing the initial
authentication and then using the same algorithm when changing the password.
New clients would also know which string to key succeeded, if they got
a KADM_NO_OPCODE they would use the same string to key method when changing
the password. If they got MIT or TRANSARC they would override the
information about which method was used for the initial authentication and
then use the method that the server indicated.
New clients going against servers that don't suppor the new opcode would
also use the same s-t-k method that was used during the initial
authentication.
Does anyone see a fault in this line of reasoning?
Will CMU be willing to support three possible opcodes in the modified
kadmin?
Will CMU be ready supply MIT with diffs before the end of this week?
Paul
