Article View: comp.client-server
Article #157Re: Authentication of Clients in a C/S environment
From: Jonathan I. Kamens
Date: Mon, 23 Nov 1992 01:06
Date: Mon, 23 Nov 1992 01:06
50 lines
3153 bytes
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!jikReferences:
<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