Date: Sat, 17 Feb 2001 08:56:22 -0600 From: "Jacques A. Vidrine" <n@nectar.com> To: Matt Dillon <dillon@earth.backplane.com> Cc: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca>, Dag-Erling Smorgrav <des@ofug.org>, Mark Murray <mark@grondar.za>, arch@FreeBSD.ORG Subject: Re: Summary of List of things to move from main tree to ports Message-ID: <20010217085622.A37238@spawn.nectar.com> In-Reply-To: <200102170722.f1H7MHm20405@earth.backplane.com>; from dillon@earth.backplane.com on Fri, Feb 16, 2001 at 11:22:17PM -0800 References: <200102170722.f1H7MHm20405@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010217085622.A37238>