> 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?
AFS as transarc ships it _does_ try both string-to-key algorithms (now).
However, kas and Transarc kpasswd will use the Andrew s2k when setting
a _new_ password; if you want to use the MIT s2k for new passwords, then
these must be changed.
> 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
Actually, the MIT kerberos server does _not_ support the administrative
functions; those are handled by a separate server that runs on a
different port.
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.
I believe Andrew now has a daemon like this running as well - users can
use the MIT kpasswd to do password changes, but other administration
is done using kas.
> 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,
Actually, Transarc's login, klog, and so on _do_ try both - if the
authentication fails using one, it tries over using the other. A
bit slower, but not too bad if the one it tries first is what most
of your users are using.
> 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.
What Andrew did was to ship a version of kpasswd which would use
the new (MIT) s2k when setting new passwords. Thus, users' keys
were silently converted when they changed their passwords, over a
period of a year or so (I believe).
> 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++)
Hmmm... You're right; that is a bug. However, your fix is
also insufficient; you need to do memset(password, 0, 9).
I've made such a change to our source.
> 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.
In general, I don't think it's too much of a headache to convert to
using the MIT string-to-key. The main problem you'll have is that
the MIT password-changing clients can't be used without running a
helper daemon on your database servers, and the Transarc ones
won't use the MIT s2k on new passwords unless you recompile them,
which requires source.
For what it's worth, folks at Andrew have proposed a mechanism which
would allow these programs to query the kaserver to find out what the
"preferred" s2k function is for a given cell; I don't know whether
any patches were submitted to Transarc.
-- Jeffrey T. Hutzelman (N3NHS) <[EMAIL PROTECTED]>
Systems Programmer, CMU SCS Research Facility
Please send requests and problem reports to [EMAIL PROTECTED]
