Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 22 Sep 2000 12:49:28 -0600
From:      Lyndon Nerenberg <lyndon@orthanc.ab.ca>
To:        Brett Glass <brett@lariat.org>
Cc:        Dave McKay <dave@mu.org>, Wes Peters <wes@softweyr.com>, nbm@mithrandr.moria.org, security@FreeBSD.ORG
Subject:   Re: sysinstall DOESN'T ASK, dangerous defaults! (Was: Re: wats so special about freeBSD?) 
Message-ID:  <200009221849.e8MInS116911@orthanc.ab.ca>
In-Reply-To: Your message of "Fri, 22 Sep 2000 12:11:25 MDT." <4.3.2.7.2.20000922120415.00c7bdc0@localhost> 

next in thread | previous in thread | raw e-mail | index | archive | help
>>>>> "Brett" == Brett Glass <brett@lariat.org> writes:

    Brett> It should not be. It sends passwords in the clear. This is
    Brett> not acceptable on today's Internet.

In certain situations. There is hardware (e.g. terminal servers, hubs) that
speak only telnet for remote configuration, and will never support
anything but telnet for remote configuration. Remote could mean it's three 
feet away but doesn't have a serial console. If these devices are accessed
from secure LANs where packets can't be sniffed then telnet is a
perfectly secure protocol in that context. In other cases, using
telnet in it's default mode is just silly from a security standpoint.

And you most certainly have options for securing telnet:

RFC1411: Telnet Authentication: Kerberos Version 4

RFC1416: Telnet Authentication Option
	 
	 * defines authentication methods for Kerberos IV and 5, and
	   an RSA based mechanism, among others)

RFC2289: A One-Time Password System

	 * Completely usable over telnet

Also, I believe Chris Newman is working on a SASL authentication
option for telnet.

Note that FreeBSD supports Kerberized telnet if you've built with
MAKE_KERBEROS4=yes (which also builds Kerberized rsh/rlogin).

The correct solution is to make sure we support current authentication
technologies where appropriate (ftp[d] lacks here as well), and provide
knobs to disable/enable the individual authentication mechanisms, and
ship with the insecure ones disabled. Simply throwing out a perfectly
useful tool is absurd.

--lyndon


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200009221849.e8MInS116911>