From owner-freebsd-security Fri Sep 22 11:50:34 2000 Delivered-To: freebsd-security@freebsd.org Received: from orthanc.ab.ca (207-167-15-66.dsl.worldgate.ca [207.167.15.66]) by hub.freebsd.org (Postfix) with ESMTP id CDFE537B424 for ; Fri, 22 Sep 2000 11:50:31 -0700 (PDT) Received: from orthanc.ab.ca (localhost [127.0.0.1]) by orthanc.ab.ca (8.11.0.Beta3/8.11.0.Beta3) with ESMTP id e8MInS116911; Fri, 22 Sep 2000 12:49:28 -0600 (MDT) Message-Id: <200009221849.e8MInS116911@orthanc.ab.ca> To: Brett Glass Cc: Dave McKay , Wes Peters , nbm@mithrandr.moria.org, security@FreeBSD.ORG Subject: Re: sysinstall DOESN'T ASK, dangerous defaults! (Was: Re: wats so special about freeBSD?) In-reply-to: Your message of "Fri, 22 Sep 2000 12:11:25 MDT." <4.3.2.7.2.20000922120415.00c7bdc0@localhost> Date: Fri, 22 Sep 2000 12:49:28 -0600 From: Lyndon Nerenberg Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >>>>> "Brett" == Brett Glass 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