Path: utzoo!attcan!uunet!peregrine!elroy!ames!necntc!necis!mrst!apollo!mishkin
From: mishkin@apollo.COM (Nathaniel Mishkin)
Newsgroups: comp.sys.apollo
Subject: Re: some questions for the gurus.
Message-ID: <3e5437c2.13422@apollo.COM>
Date: 7 Sep 88 18:03:00 GMT
References: <GBOPOLY1%NUSVM.BITNET.uucp@CUNYVM.CUNY.EDU> <8809051853.AA03917@mailgw.cc.umich.edu> <9136@elroy.Jpl.Nasa.Gov>
Reply-To: mishkin@apollo.com (Nathaniel Mishkin)
Organization: Apollo Computer, Chelmsford, MA
Lines: 44

In article <9136@elroy.Jpl.Nasa.Gov> dave@jplopto.UUCP (Dave Hayes) writes:
>> A timesharing system is different.  If you screw that up, you screw
>> everyone. But workstations are supposed to put the power into individual
>> people's hands. I think that's an important distinction.  
>
>Well what do you have to say about the soon-to-be-released capability
>(I believe it's NCS) to distribute large computing jobs over large APOLLO
>networks? This amounts to timesharing. ...

There are some subtle issues here, not all of which I will claim we have
addressed.  The fundamental issue is whether you'll allow processing
on behalf of different users to occur simultaneously on the same machine.
I think that unless the machine is in a locked room accessible only by
trusted parties, you really can't with complete safety allow multiple
users to use the same machine at the same time.  (If pressed, I can
[probably] elaborate on why this is the case.)

In a truly secure environment, no server machine does anything interesting
for a client machine unless it has authenticated credentials from the
client.  Once the server knows who the client is, it applies whatever
decision procedure it choses to decide whether it will execute the client's
request.  The problem with this model is that it doesn't simply accomodate
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?

It's really sort of an unhappy state of affairs and one that most systems
have essentially punted on, but we shouldn't kid ourselves into thinking
that (say) rlogin'ing into some random remote system is actually safe
(either for the person doing the rlogin'ing or the system being rlogin'd
into).

-- 
                    -- Nat Mishkin
                       Apollo Computer Inc., Chelmsford, MA
                       mishkin@apollo.com