Path: utzoo!attcan!uunet!husc6!rutgers!ucla-cs!admin.cognet.ucla.edu!casey
From: casey@admin.cognet.ucla.edu (Casey Leedom)
Newsgroups: comp.sys.apollo
Subject: Re: some questions for the gurus.
Message-ID: <15824@shemp.CS.UCLA.EDU>
Date: 8 Sep 88 02:51:31 GMT
References: <GBOPOLY1%NUSVM.BITNET.uucp@CUNYVM.CUNY.EDU> <8809051853.AA03917@mailgw.cc.umich.edu> <9136@elroy.Jpl.Nasa.Gov> <3e5437c2.13422@apollo.COM>
Sender: news@CS.UCLA.EDU
Reply-To: casey@cs.ucla.edu (Casey Leedom)
Organization: UCLA
Lines: 47

In article <3e5437c2.13422@apollo.COM> mishkin@apollo.com
 (Nathaniel Mishkin) writes:
> In a truly secure environment, no server machine does anything interesting
> for a client machine unless it has authenticated credentials from the
> client. ...  The problem with this model is that it doesn't simply
> accommodate the sort of "batch" processing that people want to use
> distributed systems for:  I'm on machine A and I want machine B to run
> some big "job" for me.  Therefore, B must be able to take on my identity
> so that it can issue secure network requests (e.g. back to some file
> server that's holding data for my job).  To do this, I must transmit my
> secret key (password) to B (encrypted using a session key -- some key
> that only B and I know, by virtue of having talked to an authentication
> server).  But now I'm starting to get unhappy -- I had to tell someone
> else my secret key.  Do I trust B enough to do that, or is someone right
> now sitting at B ready to crash it and stare at a core dump until he find
> my key sitting someplace in the clear?

  A standard model for doing this is to perform authentication negotiation
with your file server, and get a capability handle in response.  You then
pass that capability to machine B to use.  Unfortunately this requires
that capabilities be timed out or someone could still grope through B and
find the capability.  Another mechanism is to negotiate an authentication
capability with your batch processor and hand that off to the file
server, but this requires that the file server keep track of capabilities
which may or may not be used.  A third mechanism is to set up a
sub-authentication server on your protected machine and make the batch
server process negotiate through it for access to your files.

  This is a well studied field with no truly definitive answers and many
more cropping up all the time.  As always it's a trade off between cost
(performance, implementation complexity, maintenance) vs. security
(which is never truly total till you melt your disks down in a furnace,
and maybe not then) vs. usability (which is really just a special case
of cost, but useful to break out).

  But this isn't what we're really talking about here.  Or, rather, that
first paragraph isn't what we were talking about.  We're interested in
the pragmatic security issues under Aegis and Unix.  And again, one of
the biggest reasons that I and many others are interested in them is
simply system stability.  If your systems are down one out of every two
days because people are accidentally or maliciously wiping you out, they
aren't very usable to anyone.  One out of two days is a total
exaggeration, but I'm sure you get the point.

  Cost vs. security vs. usability.

Casey