Date: Tue, 10 Mar 1998 17:52:56 -0800 From: Mike Smith <mike@smith.net.au> To: Robert Watson <robert+freebsd@cyrus.watson.org> Cc: Mike Smith <mike@smith.net.au>, Mark Mayo <mark@vmunix.com>, Andrzej Bialecki <abial@nask.pl>, tcobb@staff.circle.net, hackers@FreeBSD.ORG, msmith@FreeBSD.ORG Subject: Re: PAM? Message-ID: <199803110152.RAA21109@dingo.cdrom.com> In-Reply-To: Your message of "Tue, 10 Mar 1998 20:38:38 EST." <Pine.BSF.3.96.980310202622.17362K-100000@trojanhorse.pr.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Tue, 10 Mar 1998, Mike Smith wrote: > > > > One possibility is to use Kerberos as a possible alternative to PAM itself > > > -- any authentication system that uses a shared secret (SecurID might fit > > > into that if the server can predict the secret ahead of time -- I'm not > > > familiar with SecurID) can be patched into the Kerberos server. Now any > > > code compiled to support Kerberos supports (shared secret authentication > > > method of choice). > > > > Actually, that's not where PAM fits in at all. > > Ah, but it is! To support PAM, you have to modify your authenticating > servers to support PAM. Many servers shipped with FreeBSD already support > Kerberos due to the eBones and KTH distribution inclusion. If the goal is > to support shared secret cards, then Kerberos can be used as a mechanism > to carry the authentication request, and have tickets to carry around with > you. No, it's not, and no, it can't. As I said, PAM lives in the client application. It does this because of the way that the application and the PAM system interact. This interaction is not trivially transportable. > Kerberos does not support challenge/response, as I note, but if it's > just a simple shared secret arrangement, that is what the password in > Kerberos does. Again, no. PAM provides a scripted, authenticator-driven conversation mechanism. The nature of the conversation depends on the locally-configured policy for the application, but it's generally not transportable. > A minor modification to the Kerberos servers to support > the card would be needed, but the numerous authenticating daemons would > not need to be changed. Don't confuse PAM and SecurID. The two have almost nothing in common, other than that it is relatively trivial to use PAM to support the challenge-response technique used by SecurID. > PAM is an attempt to provide a single interface to a variety of > authentication mechanisms so that daemons (etc) can easily authenticate > without knowing about the details (as you know, as you hacked it for > FreeBSD). Likewise, Kerberos can act as a carrier mechanism, and is > already in many of these applications. Actually, PAM's design is about as poor as it can get for any server-style authentication. Tokens are requested by the authenticators on an as-required basis and the authenticators run in the same process context as the rest of the server. > It was a suggestion for a quick hack. I have been thinking about adding > some sort of time-based password support into my kerberos server here so > that administration accounts don't have a single secret that lasts a long > time. Kerberos already provides us with ticket expiration; I also want > secret expiration. If you are using a platform where SecurID's server side is supported, you'd be well advised to consider it. S/Key and OPIE are other candidates worth looking at. > you're interested. Clearly, seperation of authentication and > authorization is desirable; what I would like is a good mechanism for > supporting various authentication mechanisms, and a language for mapping > various authenticated identities into local identities. I think a lot of people would like this. I don't think I've seen one yet that provides a workable answer for multiple authentication techniques and legacy protocols. > Authentication sucks, I guess we just have to deal with it. Or something. Barcodes. On the forehead. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199803110152.RAA21109>