Path: utzoo!utgpu!watserv1!watmath!att!linac!uwm.edu!bionet!agate!stanford.edu!ulysses.att.com!smb
From: smb@ulysses.att.com
Newsgroups: comp.protocols.kerberos
Subject: Re: srvtab on client machines
Message-ID: <9103050155.AA21158@ATHENA.MIT.EDU>
Date: 5 Mar 91 01:55:15 GMT
Sender: news@shelby.stanford.edu (USENET News System)
Organization: Internet-USENET Gateway at Stanford University
Lines: 58


	 Sorry for the previous append.  Ted, do you mean that each
	 user has to come do the database administrator and send srvtab
	 file to her/his machine?  Or does database administraotr has
	 to come to each user's machine to decrypt srvtab?

	 Thank you.
	 Galina..

I think we have a misunderstanding here.

In the environment for which Kerberos was designed, that's a
non-issue.  In general, workstations neither have nor need srvtab
files, because they do not provide any services to the user community.
In effect, they are very smart terminals (or interaction servers, if
you prefer), with a substantial amount of computing power.  A person
sitting at such a workstation may want to access files that are stored
remotely; for this, that person must somehow present credentials.  But
the workstation itself has no per-user files; it simply has the
skeleton of a system on its local disk.  And that local disk is, for
all practical purposes, read-only.  (For implementation reasons, it
probably is not physically read-only.)  When I visualize the Kerberos
model, I tend to think of a large room filled with keypunches.  (Yes, I
know; my age is showing....)  You, as a user, might prefer one keypunch
over another.  (Back when I used such things, I kept track of which
keypunches had all of their starwheels intact.)  But the ultimate host
neither knew nor cared which one I used.  Nor did I ever try to access
the keypunch's drum card from the host.

It's the same with Kerberos, at least as deployed at MIT.  Not only is
there no need to request services of a workstation, in general one
cannot -- remote access is turned off.  Thus, there are no services for
which access is mediated by /etc/srvtab.

The same reasoning explains why using /tmp for cached credentials is
not as serious as it might appear at first glance:  no one else has
access to live tickets and their associated session keys.  To be sure,
I'd still prefer a different mechanism, but Kerberos workstations -- in
their original environment -- minimize the exposure.

There are, I believe, some private workstations at MIT.  These may, if
the owners wish, have network services.  And there are certainly
workstations on the martket whose computing abilities far exceed that
of an overloaded central server; I can easily see why the owner of such
a beast would want the ability to log in remotely.  But if you want the
privileges of a host, you have to accept the responsibilities:  secure
administration of /etc/srvtab files.  (Note, too, that you have to deal
with the database administrator anyway, so that entries for each
service can be added to the Kerberos database.)

It may be that your particular environment differs from MIT's.  To the
extent that it does differ, Kerberos may not be as good a fit.  There
are a number of issues; the maintenance of /etc/srvtab is only one of
them.  At the risk of repeating myself redundantly, a number of such
issues are brought up in the Bellovin & Merritt Usenix paper; if you
can't ftp it from research.att.com, I'll be happy to mail you a copy.

		--Steve Bellovin