Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!ulysses!smb
From: smb@ulysses.homer.nj.att.com (Steven M. Bellovin)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: IP based authentication of hosts
Message-ID: <11436@ulysses.homer.nj.att.com>
Date: 15 Apr 89 18:21:50 GMT
References: <376@ists.ists.ca> <29416@bu-cs.BU.EDU> <29624@bu-cs.BU.EDU>
Organization: AT&T Bell Laboratories, Murray Hill
Lines: 42

In article <29624@bu-cs.BU.EDU>, kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) writes:
> I put it to you that this objection that "security" without total
> "security" is no security is a way to do nothing, when something needs
> to be done.
....
> 	I should say that one of the things we don't mention often
> enough is that any discussion of security needs to talk specifically
> about the threat that is being countered.  I am as guilty as anyone in
> not explicitly defining the threats I think need to be countered.

Kent refers to two crucial points:  that network security is just one
aspect, and that one must assess the threats before doing anything.
Let me add a few more points from a canned security lecture I give on
occasion:  levels of security should be consistent, and that security
is always a tradeoff with convenience.

In my environment -- a research-oriented department within AT&T Bell
Laboratories -- I'm primarily concerned with intrusions from the
outside.  More specifically, I'm concerned with preventing initial
break-ins, and with containing an intruder within a single compromised
machine, and preventing the infection from spreading.  Consequently,
physical security -- i.e., keeping curious fingers away from our
Ethernets -- is a rather minor concern.  Anyone inside who is intent on
doing damage could do far more, far more easily, than by adding yet
another tap.  But networks and password capture are great ways for an
intruder to take over more machines; consequently, I'm concerned about
IP security -- and as I've said, I feel it provides none -- and about
host-based security measures such as login-spoofers and easily-guessed
passwords.  A corollary to this is that I need to keep cleartext passwords
off of the Ethernet because of the existence of programs like etherfind.
(There are other, more subtle, ways to spy on network connections; they're
outlined in my paper.)

Other environments -- i.e., universities, or high-security military
places -- need to pay far more attention to physical security issues.
But that doesn't mean that they can neglect the others.

Kerberos is a very good start, though I have serious reservations about
some aspects of it.  (For example, I think too little consideration is
given to fake login programs building a collection of passwords.)  And
the (current) inability to forward a ticket is inconvenient at times
when one is rlogin'ed to a host and wishes to do a network operation.