From owner-freebsd-arch Sat Feb 17 6:56:27 2001 Delivered-To: freebsd-arch@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id A739137B491 for ; Sat, 17 Feb 2001 06:56:23 -0800 (PST) Received: by gw.nectar.com (Postfix, from userid 1001) id 92BFC18C97; Sat, 17 Feb 2001 08:56:22 -0600 (CST) Date: Sat, 17 Feb 2001 08:56:22 -0600 From: "Jacques A. Vidrine" To: Matt Dillon Cc: Cy Schubert - ITSD Open Systems Group , Dag-Erling Smorgrav , Mark Murray , arch@FreeBSD.ORG Subject: Re: Summary of List of things to move from main tree to ports Message-ID: <20010217085622.A37238@spawn.nectar.com> References: <200102170722.f1H7MHm20405@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102170722.f1H7MHm20405@earth.backplane.com>; from dillon@earth.backplane.com on Fri, Feb 16, 2001 at 11:22:17PM -0800 X-Url: http://www.nectar.com/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Feb 16, 2001 at 11:22:17PM -0800, Matt Dillon wrote: [snip] > Terry brings up a good point in regards to PAM. I feel that PAM > is the most likely future, but it can't be use to justify moving > 'older' pieces off the system until the newer pieces actually use > it in the proper way. That is, at the moment GSSAPI is more > proven then PAM, but PAM has the momentum and will likely be able > to take over completely sometime in the next few years. When > that occurs, anyone still using KRB4 is going to be faced with a > very tough decision. PAM does not and cannot provide the same functionality as the Kerberos API, GSS-API or SASL. PAM is targetted at interactive authentication -- give it a username and password, and return yes/no indicating authentication success or failure [1]. Once authentication is done, PAM is no longer involved (except for a possible clean-up when we log out -- though this is commonly not implemented). The other mechanisms (particularly Kerberos and GSS-API) do not concern themselves with initial authentication, but rather with handling the secure transfer of data between applications, including encryption and credential forwarding and such. So, to repeat: PAM and GSS-API are orthogonal. One is not going to ``take over completely'' at the expense of the other. Even SASL and GSS-API don't exactly compete -- to an extent, SASL is layered over GSS-API. > Highly Controversial: > > telnetd, rshd, rlogind, rexecd > rmt, rcp, rlogin, rsh > > A number of people favor removing the server side utils. Virtually > nobody favors removing the client side utils. [snip] > David O'Brien probably made the best argument, if you remove the > all-caps phrases from his posting. The all-caps should be retained. :-) Expect jihad if these are touched. Well, this _is_ the highly controversial section. > The daemons are turned off by default, keeping the binaries > around does not present a serious burden on the system. Yes, it > could be argued that this slows the adoption of protocols like > ssh, Some of us do not believe that ssh is the end-all and that slowing its adoption is a non-issue. > but the daemons are still used enough that we cannot justify > removing them from the system. And, despite being old, the > daemons do support kerberos connections as an option (though I > will add: Not very well. There are terrible bugs with regards > to streaming and EOF handling with the kerberized telnet, for > example. It's good enough for terminal sessions but I don't > trust them for anything else). If these problems exist, they are problems with the implementations in our base system and should be fixed like any other bug. I've used MIT's Kerberized versions of these utilities in the past with great success. I currently use the Heimdal versions, again with great success. Further, Kerberos is not the only way to get security and encryption with, say, TELNET. Other GSS-API implementations can be plugged in quite easily, such as X.509/SSL or DCE. (We have OpenSSL in the base now -- it probably makes sense to add this support to these daemons at some point.) Cheers, -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org [1] This isn't strictly true -- one isn't limited to just username/password. Stuff like S/Key can also be supported. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message