[245] in Info-AFS_Redistribution
MIT kerberos <-> kaserver interworking
daemon@ATHENA.MIT.EDU (Mike Gahan)
Wed Jul 24 08:39:26 1991
From: Mike Gahan <ccaamrg@ucl.ac.uk>
To: afshelp@transarc.com, info-afs@transarc.com
Date: Wed, 24 Jul 91 12:34:48 +0000
I have been reading the recent correspondence on Info-AFS on the
subject of kaserver <-> MIT kerberos interoperability.
We are currently in the process of installing AFS as our primary
distributed file system, and have an existing user base which uses
NFS.
We have many ps2 workstations (aix 1.2) for which AFS is not available,
and which therefore must use AFS/NFS translation facilities.
We do not have any kerberos user base, but may wish to install kerberos
authenticated services from third parties, and possibly develop our own.
I have got kerberos source, and have built the libraries etc.
We have an AFS source license.
So much for scene setting. Now here are some principals to which I would
like to adhere:
1) Users should only have to type their password once per session
2) There should be only one (possibly replicated) authentication database
3) There should be only one (possibly slaved) authentication server
4) User visible procedures should be identical on all platforms (ie whether
or not AFS is directly available on the platform)
5) Arbitrary service tickets should be acquirable at any time in a session,
after initial authentication, without further password typing.
My reading of the correspondance leads me to believe that MIT kerberos and
Transarc kaserver will operate happily together, so long as they agree on
string_to_key, and that the kaserver is to be preferred on the grounds of
reliability (especially where slaves are concerned), and improved
administrative interface (including USS).
The scheme I would like to implement is as follows:
Run Transarc kaserver.
Initial authenticate gets a TGT from kaserver, using MIT kinit built with
Transarc string_to_key. User types password to decrypt ticket.
THEN:
Use TGT to get afs service ticket from kaserver
(if desired, authentication in foreign cells could take place at this
juncture, either using the TGT, or by brute password typing)
if (machine is NFS client) {
Use TGT to get "rcmd" ticket for AFS/NFS translator machine
rpc (as yet unwritten) to AFS/NFS sending:
{
local UID
[afs service ticket]*
} sealed with rcmd session key
{
standard kerberos authenticator for rcmd service
}
The receiving part of the rpc cracks the authenticator using the rcmd
service key, then uses the session key to get the UID and afs ticket.
Then it does a modified knfs to make the ticket known to the cache manager
(with setpag() ).
}
The TGT is, of course, still around for future use.
As regards authenticating in different cells, I personally favour the MIT
theological position, ie you should authenticate in the local cell only, and
have your cell as part of the user specification in ACLs. This avoids the
burdensome typing of passwords, which are either insecurely all the same,
stored in potentially insecure files, or written on the insecure backs of
insecure envelopes.
A number of questions result from the above scheme:
0) Is it feasible, are there gaping holes ?
1) Has anyone out there implemented it, or anything like?
2) More specifically, has anyone built MIT kerberos with transarc string_to_key
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 )
4) Can I register specific instances in the kas database.
(kas create does not seem to give this)
5) Is the kas db the same as the MIT kerberos db (can I run either server
against the same db)
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... )
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 ?
Answers to any or all of these would be much appreciated.
Mike Gahan, Bloomsbury
