[248] in Info-AFS_Redistribution

home help back first fref pref prev next nref lref last post

Re: MIT kerberos <-> kaserver interworking

daemon@ATHENA.MIT.EDU (Richard Basch)
Wed Jul 24 20:39:26 1991

Date: Wed, 24 Jul 91 11:16:36 -0400
To: John Gardiner Myers <jm36+@andrew.cmu.edu>
Cc: Mike Gahan <ccaamrg@ucl.ac.uk>
Cc: info-afs@transarc.com
In-Reply-To: John Gardiner Myers's message of Wed, 24 Jul 1991 10:31:03 -0400 (EDT),
From: Richard Basch <basch@MIT.EDU>


   Date: Wed, 24 Jul 1991 10:31:03 -0400 (EDT)
   From: John Gardiner Myers <jm36+@andrew.cmu.edu>
   References: <101935.9107241234@uk.ac.bcc.ts>
   Beak: Is

   Mike Gahan <ccaamrg@ucl.ac.uk> writes:
   > A number of questions result from the above scheme:
   > 
   > 0) Is it feasible, are there gaping holes ?

   I see no obviously gaping holes.

Ditto.

   > 2) More specifically, has anyone built MIT kerberos with transarc string_to_key

   It's not trivial, due to the way the DES library interface is
   designed.  It's been done for individual programs.

I know Univ. of Mich. has a modified string_to_key.  I believe I
also have a copy, but I have to experiment a bit more.  It can be done
as a change to the library, without much difficulty.  I do not like the
internals of the library, either.

   > 5) Is the kas db the same as the MIT kerberos db (can I run either server 
   >    against the same db)

   No.

More specifically, Kerberos uses dbm.  Transarc uses their own
distributed database, Ubik.

   > 7) Is my assumption that kerberos mediated services from third party vendors
   >    will happily cope with kas generated tickets, so long as the des key
   >    known to the server has been generated using Transarc string_to_key, 
   >    correct ?

   Yes, assuming the tickets have a lifetime of no more than about 10
   hours, or the services have been linked against a kerberos library
   modified to handle long ticket lifetimes.

   I'm not sure, but I think tickets with long lifetimes might work with
   stock MIT-kerberos-mediated servers--the tickets just work for a
   shorter lifetime than they should.  I haven't done a whole bunch of
   experimentation in this area.

The problem is that the lifetime field (0-255) is considered as 5 minute
interval steps, so any application that may have linked against a
Kerberos library that you have gotten in binary form may have shorter
lifetimes.  I forgot how the kaserver returns lifetimes when using its
Kerberos mode.  When talking to the kaserver using rx, I know that you
use a table of lifetimes, roughly exponential, giving up to a 30 day
lifetime.

-R

home help back first fref pref prev next nref lref last post