Derrick said:
> The kaserver doesn;t care about string_to_key. The kauth client library
> stuff does. Actually, you need only modify kas and kpasswd to use the
> MIT Kerberos4 string_to_key instead of the icky AFS one. I did the work
> as a student employee; It's now deployed in general use here.
Jonathan says:
> My question is this... If 'kas' and 'kpasswd' are the only client programs within
> AFS which require modification to try both string to key functions, or perhaps to
> exclusively use the MIT K4 string to key function, why can't it be done?
kaserver supports two kinds of interfaces: "rx" and "udp". The "udp"
protocol is a compatible subset of what an MIT kerberos server would
support. I say "subset" because the "udp" interface doesn't support any
MIT administrative functions. In modern MIT servers, those are actually
done via TCP. It *is* possible to insert a "helper" daemon that
will support MIT style administrative functions (and translates
them into afs "rx" calls), and several sites (including umich.edu)
have done just that. The most common reason is to support kerberos
clients that support MIT style password changing, not as a
general replacement for "kas". You say you like "kas"'s style of
administration, though, so this seems to be out.
The "rx" interface requires that you know the string to key
function *in advance* of authentication. It sounds to me like
Derrick has *replaced* the authentication method, and is
not trying *both*. Using both with "rx" is a hard thing, and leads
to annoying performance issues. Switching over isn't so bad,
other than the conversion effort. If you have a small cell,
and don't mind telling *all* of your users that they have
to switch, this may be a doable thing. It will be a continual
support headache, though, for both you and transarc. You'll
need to ask transarc to build you a custom version of kpasswd
& kas, *and* you'll have to ask again each time you upgrade.
You might be able to arrange a sideways deal where you actually
get them from MIT with transarc's blessings. It will still
be a support headache, but if you're really keen on doing it,
this may be the best approach.
Another approach is to contact your terminal server vendor, and
try to twist their arms harder. You should be able to hand them
the string to key function at CMU (but note: there's a bug):
string_to_key.c 4.9.3.5
line#: text:
166 if (length <= 8) {
NEW memset(password, 0, 8); /* ADD THIS LINE */
167 strncpy(password, realm, 8);
168 for (i=0; i<8; i++)
[ Perhaps this can be regarded as a feature. Long passwords >8
characters are indeed a good idea. ]
There are enough AFS sites that presumably supporting the AFS
string to key function should have some attraction to them.
It's also indeed not *that* hard to support both with the "udp"
interface; & there is plenty of newer kerberos client code
that does just this, including authman and recent versions of MIT's
windows kerberos DLL.
-Marcus Watts
UM ITD PD&D Umich Systems Group
