[210] in Info-AFS_Redistribution
Everything you didn't want to know about Kerberos but asked
daemon@ATHENA.MIT.EDU (John Gardiner Myers)
Mon Jul 15 13:13:56 1991
Date: Mon, 15 Jul 1991 12:35:55 -0400 (EDT)
From: John Gardiner Myers <jm36+@andrew.cmu.edu>
To: Info-AFS@transarc.com
How the AFS and MIT implementations of Kerberos (version 4) relate and how
they can be made to interoperate is a rather complex issue.
The most important difference between the two implementations is the
fact that the "string to key" function used by each implementation is
different. This is the one-way function that converts a users
password (the "string") into a DES encryption key (the "key"). This
key is what is stored in the Kerberos server's database and is used in
the initial authentication protocol. Once the user has authenticated
to Kerberos, the string-to-key function is irrelevant.
The reason that the functions used by the two implementations are
different are mostly historical. When Kerberos authentication was
added to AFS (I believe it was the fifth authentication mechanism
used), there was an existing database of keys encrypted using the
string-to-key function of the previous authentication mechanism.
The AFS Kerberos implementation thus used the previous authentication
mechanism's string-to-key.
The AFS string-to-key does have an advantage over the MIT one in that
the name of the realm is used as an input--the same string converts to
different keys in different realms. This prevents someone with
access to the Kerberos database in one realm to use their knowledge of
a user's key in that realm to attack that user in a different realm,
even if the attacked user has the same password in both realms.
Another difference between the two implementation is support for long
ticket lifetimes. The stock MIT server and libraries can only handle
ticket lifetimes to up to 10 hours. The default ticket lifetime in
AFS Kerberos implementations is 25 hours. I modified the Kerberos
distribution to handle extended lifetimes (using code, data, and
assistance from Ted Anderson of Transarc) and submitted patches to the
Kerberos mailing list. I may still have them around--I would
certainly be able to regenerate them.
AFS Kerberos clients communicate with the AFS Kerberos server
(kaserver) using the "rx" remote procedure protocol, whereas MIT
Kerberos clients communicate with the MIT Kerberos server using an
ad-hoc protocol. Fortunately, the kaserver also supports the MIT
protocol on a read-only basis. MIT Kerberos clients can communicate
with an AFS Kerberos server to authenticate and obtain tickets, but
they may not add users, change passwords, etc. AFS Kerberos clients
cannot communicate with MIT Kerberos servers.
It is my opinion that, operationally, the kaserver is a much better
implementation than the MIT Kerberos server. Unlike the MIT server,
the kaserver allows deletion of users. Ticket expiration times are
specified in hours and minutes, not number of five-minute units. The
kaserver's database replication mechanisms are more robust in the face
of errors.
There are basically two approaches to making MIT Kerberos clients and
AFS coexist in a single cell. One approach is to run a kaserver, the
other to run an MIT Kerberos server. Which approach you use usually
depends on what your installed base is.
If you want to run a kaserver but have MIT clients work with it, here
are the things to do:
* Get the modifications to the MIT Kerberos distribution to handle
long ticket lifetimes. I should be able to find or recreate these
without much problem.
* Find some way to get an initial ticket. This involves one or more of:
- use klog -tmp
- Get the sources to the AFS string-to-key function(s) and modify
the MIT clients that get an initial ticket to try first one
function and then the next. The easiest way to get the AFS
string-to-key function would be to go through your customer
support person at Transarc.
- Modify the Transarc libraries to read and write MIT format ticket
files. Requires an AFS source license. I've done that here.
* Get a version of ksrvutil that uses the AFS string-to-key function
and uses the AFS libraries to change passwords. Available from me.
If you want to run a MIT Kerberos server, but have AFS work with it,
here's what you do:
* Put the entry for "afs" in the Kerberos server. (Should be obvious)
* Modify your kinit and kerberized login and su to grab a ticket for
"afs" and install it in the kernel.
* Throw away the Transarc programs that do authentication. (login, su,
kpasswd, klog, kas, ftpd, etc.)
* Accept the fact that clients in other AFS cells won't be able to
authenticate to your cell
The 'cs.cmu.edu' cell has done this latter, though they currently run
*both* a kaserver and a MIT Kerberos server.
--
_.John G. Myers Internet: John.G.Myers@andrew.cmu.edu
(412) 268-2314 LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up
