Date: Tue, 10 Mar 1998 20:38:38 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: Mike Smith <mike@smith.net.au> Cc: 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: <Pine.BSF.3.96.980310202622.17362K-100000@trojanhorse.pr.watson.org> In-Reply-To: <199803110117.RAA20969@dingo.cdrom.com>
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. 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. 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. It's a hack, but so is PAM. > Pam is, as its name suggests, a standardised modular framework within > an application which allows the use of multiple authentication > techniques, one of which may be Kerberos. Yes. Similarly, Kerberos can be used to carry other so-called authentication mechanisms. Kerberos is really just a key distribution system supporting session keys, etc. To "authenticate" using kerberos, you merely have to prove that your secret can retrieve tickets in your name. We can substitute whatever we want for the password as long as it has the property of being a shared secret. This is, of course, the clinch, as many authentication mechanisms don't rely on shared secrets (PK asymetric keys, for example). 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. 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. > One of the features of the framework is that it separates the > configuration of authentication policy from the implementation. Thus, > it is practical to 'stack' authentications in a primitive fashion. See ftp://ftp.ietf.org/internet-drafts/draft-ietf-dnssec-ar-00.txt for some discussion of authentication policy and stacking (well, specifically, forwarding of authentication from DNSsec identities to elsewhere). This isn't so much an OS issue as a network issue, but it's probably related if 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. The problem with abstracting all of the authentication types is that you really lose a lot of features. You can, of course, have your pam_afs module that does token-gathering magic, but you do lose a lot. Different authentication systems offer many different services, and I am not sure that PAM offers a sufficiently general solution. > On the other hand, PAM has a numer of serious drawbacks in the design of > the interface between the application and the framework, which make > generalised PAMification of many common applications extremely tedious. > At least part of the problem is that PAM was meant to be integrated in > the perimeter security of the XSSO model, rather than in the piecemeal > fashion it is currently deployed. For network protocols, use of SASL-style libraries might provide some answers. I generally disapprove of SASL as a network protocol "Security" solution -- it brings to mind the whole pixie-dust problem, but from a programmers perspective it can make a lot of sense. For doing things with users directly, it isn't a solution. :) Authentication sucks, I guess we just have to deal with it. Or something. Robert N Watson Carnegie Mellon University http://www.cmu.edu/ SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org http://www.watson.org/~robert/ 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?Pine.BSF.3.96.980310202622.17362K-100000>