The string_to_key function is performed on the client, not the server.
The server is irrelevant, except in that v5 servers will give v5
clients hints as to which of several possible string_to_key function
they should use.
V5 clients generally don't know about the AFS string_to_key, so using
the AFS string_to_key with V5 clients is impractical.
What we have done at andrew.cmu.edu is modify the AFS kpasswd and kas
clients to use the MIT v4 string_to_key for new passwords. AFS klog
and login already try both string_to_key functions. As our users
change their passwords, our kaserver database will gradually have an
increasing number of entries using the MIT v4 string_to_key.
At some point we will install a server for the MIT v4 admin server
protocol which will in turn change passwords through the kaserver.
This will allow the MIT v4 kpasswd and similar programs to work.
>From that point, we will have a number of options. We could put a
limited v5 UDP server into the kaserver. We could migrate to an MIT
v5 or DCE server.
As of now, the v4 compatibility side of the beta MIT v5 server gets
long lifetimes wrong in a very dangerous way. Last I heard, the OSF
wasn't interested in getting the v4 compatibility code put into the
DCE server at all.
--
_.John G. Myers Internet: [EMAIL PROTECTED]
LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up
