[246] in Info-AFS_Redistribution
Re: MIT kerberos <-> kaserver interworking
daemon@ATHENA.MIT.EDU (John Gardiner Myers)
Wed Jul 24 10:58:25 1991
Date: Wed, 24 Jul 1991 10:31:03 -0400 (EDT)
From: John Gardiner Myers <jm36+@andrew.cmu.edu>
To: Info-AFS@transarc.com, Mike Gahan <ccaamrg@ucl.ac.uk>
In-Reply-To: <101935.9107241234@uk.ac.bcc.ts>
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.
> 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.
> 3) Does kaserver understand the concept of a TGT
> (presumably, I can register a principal krbtgt.UPPER.CASE.CELL, and get
> tickets for it, but can I then use the ticket to get other service
> tickets without the need for a password )
Yes. However, you as the administrator can mark specific service
tickets as not being obtainable from a TGT. The "AuthServer.Admin"
principal is usually marked this way (so a user must type in their
password in order to change their password)
> 4) Can I register specific instances in the kas database.
> (kas create does not seem to give this)
Yes you can. Just give a name with a period in it to "kas create".
> 5) Is the kas db the same as the MIT kerberos db (can I run either server
> against the same db)
No.
> 6) Is there any documentation on the ka_ routines (what do they do, how do
> I call them, with what parameters, what are structures like, what libraries
> do the routines reside in, blah blah... )
Well, there's the source...
I believe Transarc is working on documenting the programming
interface. I don't know what the status of this is at present.
> 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.
_.John
