Path: utzoo!attcan!uunet!husc6!rutgers!tut.cis.ohio-state.edu!bloom-beacon!athena.mit.edu!jfc
From: jfc@athena.mit.edu (John F Carr)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: An Obvious Security Problem?
Message-ID: <8132@bloom-beacon.MIT.EDU>
Date: 23 Nov 88 09:59:03 GMT
References: <8811162311.AA09389@vax.ftp.com>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: jfc@athena.mit.edu (John F Carr)
Organization: Massachusetts Institute of Technology
Lines: 30

In article <8811162311.AA09389@vax.ftp.com> stev@VAX.FTP.COM writes:

>yep. even on a single ethernet someone could use a lan monitor to catch
>your passwords as they fly over the net. i believe the Athena people
>use Kerberos (sorry about butchering the spelling) to deal with some
>of this. (or at least they could . . . . .)

Kerberos does provide for encrypted connections (the Kerberos server 
generates a random session key for use by the client-service pair
[this key is encrypted using the user and/or service key when it is
sent over the net]).  To the best of my knowledge, there is only
one program that uses it (an encrypted version of rlogin).  Kerberos
authenticated login cuts down on the need to type passwords over the 
net.  As long as the remote host accepts authenticated rlogin AND you 
do not need a set of tickets on that host, your initial tickets are 
sufficient.  There are some cases when Kerberos is insufficient (the 
issue of ticket forwarding [getting tickets valid on a remote host 
without entering a password] is not yet solved; the security tradeoffs 
are a problem).

>i would think that we would
>want to use diffrent "well known ports" for the new secure versions.

That is what is done with Kerberos.

--
   John Carr             "When they turn the pages of history,
   jfc@Athena.mit.edu     When these days have passed long ago,
   bloom-beacon!          Will they read of us with sadness
   athena.mit.edu!jfc     For the seeds that we let grow?"  --Neil Peart