[214] in Info-AFS_Redistribution
Re: Everything you didn't want to know about Kerberos but asked
daemon@ATHENA.MIT.EDU (Marc Horowitz)
Tue Jul 16 02:33:08 1991
To: John Gardiner Myers <jm36+@andrew.cmu.edu>
Cc: Info-AFS@transarc.com
In-Reply-To: [210] in Info-AFS_Redistribution
Reply-To: Marc Horowitz <marc@MIT.EDU>
Date: Tue, 16 Jul 91 01:28:44 EDT
From: Marc Horowitz <marc@athena.mit.edu>
The MIT and AFS implementations of kerberos indeed have differences.
However, I would like to present a few arguments in favor of the MIT
implementation:
MIT Kerberos is, IMHO, more standard than the AFS implementation.
There are dozens of kerberos realms, many of which interoperate with
each other. The protocol may be "ad-hoc", but many more people use it
than the (proprietary) AFS implementation.
Agreed, the AFS implementation does have some nicer features, such as
the long-lived tickets, and a more featureful admin interface.
>> If you want to run a MIT Kerberos server, but have AFS work with it,
>> here's what you do:
>> [...]
>> * Accept the fact that clients in other AFS cells won't be able to
>> authenticate to your cell
Well, you have obviously never seen what we do at MIT. We run an MIT
Kerberos server, and our login gets us an initial tgt. When the user
wants to authenticate to afs, we have a client which allows him to use
his tgt to get an AFS token. (I'm not sure of the technical details,
but it works.) This has the *significant* advantage that I can use
one tgt to get tokens for several cells (currently, I have tokens in
three cells). This means that an organization at MIT can set up a
cell of its own, and not force all the users in it to have to register
passwords individually. Under the AFS kerberos implementation, each
realm has it's own kaserver, and there is no facility for sharing
databases. I count five cells at MIT I can authenticate to with one
kerberos principal.
If you want to have clients with standard afs software able to
authenticate to your cell, you can create a kaserver, and users can
use klog, as they normally would. There is no loss of
interoperability. Unfortunately, due to fundamental problems in AFS,
it is impossible to use more than one realm at the same time in one
AFS cell. For example, I might want to have marc@ATHENA.MIT.EDU and
srz@LCS.MIT.EDU on an acl for a directory, but this is impossible. I
am told AFS 4 makes this possible. (But this is not an AFS vs MIT
issue.)
In short, it is possible to use AFS with MIT kerberos in a way which
is no more difficult for the users, and in some ways, easier. And
there is much software which builds on MIT kerberos. This is simply
not true of Transarc's implementation.
Marc
