[231] in Info-AFS_Redistribution
Re: Everything you didn't want to know about Kerberos but asked
daemon@ATHENA.MIT.EDU (John Gardiner Myers)
Sat Jul 20 20:20:25 1991
Date: Sat, 20 Jul 1991 19:13:22 -0400 (EDT)
From: John Gardiner Myers <jm36+@andrew.cmu.edu>
To: Info-AFS@transarc.com
In-Reply-To: <9107160528.AA15041@hodge>
To clear up some minor points and point out an ommision I made in the
original posting:
Marc Horowitz <marc@ATHENA.MIT.EDU> writes:
> 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.
Actually, I don't consider a protocol's being ad-hoc as being a
disadvantage. In fact, I think rx is implemented so poorly it is a
disadvantage for the Transarc implementation.
Anyway, the kaserver implements the core MIT Kerberos protocol. It
does not implement the admin server interface, but few clients need to
use this.
> >> * 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. [[using cross-cell authentication]]
What we have here is a difference of philosophy between MIT and CMU.
MIT thinks you should authenticate to one cell and use that
authentication everywhere. CMU thinks you should be able to
authenticate to your identity in each of several cells and use the
apropriate identity for the apropriate cell.
What I said (or meant to say) is that, assuming I had an account
"myers@ATHENA.MIT.EDU" and the athena.mit.edu cell didn't run a
kaserver, I could not authenticate as that user in the athena.mit.edu
cell using standard Transarc programs (klog).
Now, if athena.mit.edu and andrew.cmu.edu traded keys, I could
authenticate as "jm36@ANDREW.CMU.EDU" (or "jm36.admin@ANDREW.CMU.EDU")
to the athena.mit.edu cell. (Yes, Transarc kaservers handle
cross-cell authentication.) Now, stock AFS fileservers won't do
anything with that authentication, but people are working on it. (MIT
seems to have made a fair amount of progress on this issue.)
> 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.
The problem is keeping the two Kerberos databases in sync. If a user
is in both databases, they have to change their password twice, once
in each database.
Anyway, one difference between the kaserver and the MIT Kerberos
server that I forgot to mention was that the kaserver (and the AFS
fileserver) ignores the "IP address" field of a ticket. The "IP
address" restriction of MIT Kerberos doesn't buy you that much in
security, but really takes away a bunch in functionality.
For example, I have modified MIT's kerberized rlogin/rsh
implementation to pass over the user's tgt (encrypted, of course) and
automatically authenticate the user on the remote machine. This
wouldn't be possible with the IP address restriction. Since in our
environment, users can't do much of anything useful without being
authenticated to AFS, this makes kerberized rlogin/rsh useful.
_.John
