Date: Sat, 17 Feb 2001 19:08:00 -0600 From: "Jacques A. Vidrine" <n@nectar.com> To: Terry Lambert <tlambert@primenet.com> Cc: arch@freebsd.org Subject: Re: GSS-API and PAM (was list 'o things) Message-ID: <20010217190800.A38833@spawn.nectar.com> In-Reply-To: <200102172319.QAA11294@usr05.primenet.com>; from tlambert@primenet.com on Sat, Feb 17, 2001 at 11:19:46PM %2B0000 References: <20010217085622.A37238@spawn.nectar.com> <200102172319.QAA11294@usr05.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Feb 17, 2001 at 11:19:46PM +0000, Terry Lambert wrote: > Please see either of: > > http://www.opengroup.org/onlinepubs/008329799/ > http://www.kernel.org/pub/linux/libs/pam/pre/doc/xsso.ps.gz > > for the XSSO (X/Open Single Sign On service) PAM documentation. > In particular, please look at the PAM API and SPI, and at the > session management functions and session management module > functions. Thanks for these references. I wasn't aware of them -- I've been going back to Sun for the PAM stuff. > PAM concerns itself with five different types of service modules: > Authentication (which is the one you were talking about), account management, > session management, and mapping. > > It's true that Linux does not implement GSS-API and PAM integration, > but it _is_ possible to put one under the other. It _is_ possible to stick authorization data into an authentication system, too, but that doesn't mean that one should (hello, Microsoft!). I assume you mean, `layer GSS-API under PAM'. I don't see how one could do the converse; there is no `place' in GSS-API to establish/create new credentials, for example, or to do account management. Layering GSS-API under PAM, such that the application uses only PAM and is not `aware' of GSS-API is possible only in the narrowest technical sense. In practice, PAM comes a bit too late in the game. In the popular network virtual terminal applications TELNET and SSH, for example, PAM is invoked once a security context has already been negotiated -- typically by /usr/bin/login (in concept with sshd, in reality with telnetd). Even if PAM were invoked very early so that an SPI could muck about with the protocol stream and did manage to negotiate a security context, you are then stuck with no way to do real way data integrity checking or data privacy, without resorting to something outside the PAM API. > It was my impression that XSSO had extended PAM to the point > that it incorporates GSS-API functionality; yeah, I know it's > not RFC 15xx compliant, but it doesn't really matter: it's a > defacto standard. I don't see how you can make this claim in the context of this discussion. Please show me even one PAM implementation that supports something approximating GSS-API or SASL. And then note that `one' hardly makes a de facto standard. All of this is not to knock PAM -- it is a godsend for many tasks. But it doesn't cover everything. > > 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.) > > Yes. RSA is specifically mentioned as a Kerberos option for GSS-API, > in the original documents. I didn't mean to narrow that to GSS-API either -- there is also TLS and SASL and such. Cheers, -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org 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?20010217190800.A38833>