Path: utzoo!utgpu!water!watmath!clyde!att!rutgers!apple!bionet!agate!saturn!mcvax!cwi.nl!guido@uunet.UU.NET
From: mcvax!cwi.nl!guido@uunet.UU.NET (Guido van Rossum)
Newsgroups: comp.os.research
Subject: Re: Non-secure workstations (long) (Was: The NeXT Problem)
Message-ID: <5236@saturn.ucsc.edu>
Date: 24 Oct 88 13:03:08 GMT
Sender: usenet@saturn.ucsc.edu
Organization: The Royal Society for Prevention of Cruelty to Amoebae
Lines: 51
Approved: comp-os-research@jupiter.ucsc.edu


In article <5198@saturn.ucsc.edu> fouts@lemming. (Marty Fouts) writes:
>
>[...]  However, in a truely hostile
>environment the underlying assumption of hostility makes the idea of
>trusting *some* machines seem rather silly.  What systems like
>Kerberos do (besides giving their users a false sense of security) is
>change the problem from faking one user to faking both the user and
>the authentication system.
>
>Kerberos increases my confidence that you are the authentication
>server but it doesn't guarentee that you are.  If I'm willing to
>accept the level of confidence that it provides, than I can claim to
>be 'reasonably secure' or 'adequately secure' for my needs.  It still
>doesn't make me 'secure.'

Under these definitions, nothing in the world can "make you secure".
You are as secure as you trust the manager of the authentication
service.  In the end it boils down to trusting other human beings, and
you know what a tricky business *that* is... 

What Kerberos does for you is to provide you with a tool where the
presence of insecure networks between you and a trusted (physically
secure!) authentication service doesn't prevent you from having the same
level of trust in it as when you were in the same room with it (and
disconnected from the outside world).  Not something to skimp on
lightly, and certainly not "giving users a false sense of security".

Unlike what you seem to think, dependence on machines locked away in
physically protected rooms is not a weakness of the system -- it is the
ultimate operational condition of any authentication service.  There is no
reason why an authentication service could not be distributed -- but all
the machines holding sensitive data (user's private keys) should be
physically protected.  Users may trust their local authentication server
more than they trust a remote one -- they might know its manager
personally, for instance -- and adapt their level of trust accordingly
(e.g., you may be willing to exchange mail with a machine authenticated
through a remote authentication server, but you may not trust it to hold
your program sources).

But what if the manager of the authentication service cheats, you may
ask?  The real world has responses to this problem, and they do not
differ from responses to other forms of breach of contract.  You may
call the police, beat him up, sue him, and occasionally you will have to
accept your losses.  You can pay for insurance or live dangerously.  But
don't frustrate the discussion by requesting absolute security.  There
is no such thing (and I didn't write this, either :-).

--
Guido van Rossum, Centre for Mathematics and Computer Science (CWI), Amsterdam
guido@piring.cwi.nl or mcvax!piring!guido or guido%piring.cwi.nl@uunet.uu.net