Path: utzoo!attcan!uunet!ncrlnk!ncr-sd!hp-sdd!hplabs!decwrl!labrea!rutgers!tut.cis.ohio-state.edu!bloom-beacon!bu-cs!kwe
From: kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
Newsgroups: comp.protocols.tcp-ip
Subject: Re: An Obvious Security Problem?
Summary: You need trusted routers
Message-ID: <26199@bu-cs.BU.EDU>
Date: 22 Nov 88 19:17:46 GMT
References: <881109143927.20402284@Csa3.LBL.Gov> <2215@cuuxb.ATT.COM>
Reply-To: kwe@bu-it.bu.edu (Kent England)
Followup-To: comp.protocols.tcp-ip
Organization: Boston Univ. Information Tech. Dept.
Lines: 22

In article <2215@cuuxb.ATT.COM> dlm@cuuxb.UUCP (Dennis L. Mumaugh) writes:
>In article <881109143927.20402284@Csa3.LBL.Gov> forrest@CSA3.LBL.GOV writes:
>    (Node M is actually one or more gateways.) Couldn't a bad guy
>    on   M   monitor   the  TCP/IP  traffic  looking  for  Telnet
>    connections and then follow through  the  exchange  of  login
>    names  and  passwords,  thereby  capturing  a  node/login and
>    password pair? (I realize that  the  path  from  A  to  Z  is
>    dynamic and that this might not always be possible.)
>
>The DoD people have a solution: encrypt the comm-line.  There  is
>a  secure  version  on  the  Internet  that does just that.  Even
>better is to use end-to-end encryption  for  each  communications
>circuit.  The  basic  problem  with all of this is the encryption
>overhead and the key and authentication problems.

	Link encryption won't solve this problem.  The two links are
encrypted independently and someone with access to the system M could
still pick up traffic and snoop ids and passwords.
	You need either a trusted router (trusted network actually); or
application layer encryption, which is not part of telnet, to avoid
snooping from inside the network.
	Secure networks or secure applications.  Better both.