🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.client-server
Article #157

Re: Authentication of Clients in a C/S environment

#157
From: Jonathan I. Kamens
Date: Mon, 23 Nov 1992 01:06
50 lines
3153 bytes
(A preliminary note: Please, PLEASE follow the guidelines in
news.announce.newusers which state that postings to the Usenet should not
contain lines longer than 80 characters, and in fact recommend limiting line
length to 72 characters.)

In article <1992Nov20.032345.18307@kodak.kodak.com>, deal@tempus.Kodak.Com (Stephen M. Deal) writes:

|> How do you authorize a client? Can you even trust a client? Perhaps those
|> clients executing on a node that has password protection (e.g. UNIX, VAX/VMS)
|> can be trusted

The problem with assuming that "nodes that have password protection" are
trustable is that you are therefore assuming that those nodes have not had
their security breached in any way.  You are relying on node security in order
to guarantee your network security.  That is a bad idea.

The company for which I work (Aktis, Inc., a.k.a. Geer Zolot Associates) does
a lot of security analyses for sites with large networks.  Invariably, those
sites make assumptions about the security of individual machines on the
network when constructing their network security framework.  And invariably,
the security of individual machines on the network is compromisable and
therefore leads to compromises in network security as well.

Unless your physical network is completely secured, so that people cannot put
their own machines on it, your machines on the network are all physically
secure, so that people are not able to break into them using physical means,
and you have direct administration over all the machines on the network so
that you can guarantee that they do not have software security holes on all of
them, you cannot safely trust ANY machine on the network.

If you want network security, you need some sort of network security tool.
|> Kerberos (from MIT's Project Athena) provides a glimmer of hope but I have not
|> seen any C/S vendor embrace this approach.

This is changing.

First of all, the fact that OSF's DCE has embraced Kerberos implies that
vendors who wish to be DCE-compliant are going to have to start supporting
Kerberos.

Tivoli/WORKS, the OSF DME distributed management environment, allows (although
it does not require) the use of Kerberos for the authentication of
individuals' access to the Tivoli environment.

Several of the network RDMS vendors are currently investigating adding
Kerberos support to their products.

-- 
Jonathan Kamens                                         jik@MIT.Edu
MIT Information Systems/Athena              Moderator, news.answers
Technical Details
Message-ID: <1epaqeINNs9f@senator-bedfellow.MIT.EDU>
Path: arc1-ca.pugleaf.net!sparky!uunet!cs.utexas.edu!tamsun.tamu.edu!snorkelwacker.mit.edu!bloom-picayune.mit.edu!senator-bedfellow.mit.edu!athena.mit.edu!jik
References: <1992Nov20.032345.18307@kodak.kodak.com>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!cs.utexas.edu!tamsun.tamu.edu!snorkelwacker.mit.edu!bloom-picayune.mit.edu!senator-bedfellow.mit.edu!athena.mit.edu!jik
From: jik@athena.mit.edu (Jonathan I. Kamens)
Newsgroups: comp.client-server
Subject: Re: Authentication of Clients in a C/S environment
Date: 23 Nov 1992 01:06:22 GMT
Organization: Massachusetts Institute of Technology
Lines: 50
Distribution: na
Message-ID: <1epaqeINNs9f@senator-bedfellow.MIT.EDU>
References: <1992Nov20.032345.18307@kodak.kodak.com>
NNTP-Posting-Host: pit-manager.mit.edu
Keywords: Kerberos, Trusted Hosts, Food for Thought