From owner-freebsd-security Mon Jun 1 16:49:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA12934 for freebsd-security-outgoing; Mon, 1 Jun 1998 16:49:22 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from fledge.watson.org (root@COPLAND.CODA.CS.CMU.EDU [128.2.222.48]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA12905 for ; Mon, 1 Jun 1998 16:49:11 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id TAA07894; Mon, 1 Jun 1998 19:46:35 -0400 (EDT) Date: Mon, 1 Jun 1998 19:46:35 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Poul-Henning Kamp cc: Eivind Eklund , "J.A. Terranson" , "freebsd-security@FreeBSD.ORG" Subject: Re: MD5 v. DES? In-Reply-To: <5630.896731049@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 1 Jun 1998, Poul-Henning Kamp wrote: > >I personally dislike this idea -- where does this leave one-time-password > >users, etc? > > Perfectly safe as always. All it does is to make sure that you don't have > to modify, ftpd, telnetd, login, popper, and uhm... what is the last one, > I keep forgetting, Hmm..... This works fine for all authentication systems where username + something allows authentication. But I'd like to have a more extensible system that provides a context for challenge/response, if we are going to break from the pack of do-it-yourself-crypt-foo. I have problems with the implementation of linux-style PAM, but the general concept of having multiple authentication support with a series of challenges/responses does make sense. triple of (username,password,context) breaks down as soon as you need the s/key challenge from the auth module. It would also be nice to have the policy for authentication in a seperate independant location (as you hint with the context field). It would be cool to be able to have the following policies: Accept kerberosIV, local passwords, one-time-passwords when using ssh or kerberized rlogin. Accept one-time-passwords only when using telnet, ftp (and other unencrypted daemons). The "context" would probably be something a little more sophisticated -- perhaps a two part field, the first with the daemon name, and the second with a classifying field, such as telnetd/kerberized, or httpd/ssl or something. To allow a more flexible policy in the policy subsystem without it having to have more access to the daemon than necessary. For the sake of the library/etc, it might be nice to have the uid of the authenticating process be part of the context. In a nice modular environment, it might be desirable to have an "authentication daemon" that listens on a unix domain socket (or such). Daemons like CMU's imapd already make use of this so that the daemon itself can run non-root yet still take advantage of username/password authentication. The daemon might take into account the identity of the requestor, refusing to provide information about username/password authentication to normal user processes, but allowing it for the www user (or something like that). On should also be careful to not restrict oneself to nul-terminated strings -- allowing a kerberos authenticator in might be useful, and it can contain nuls. > Basically what I'm saying is that if all the places which have to > authenticate a user, had a call where they could say: > > "Is password acceptable for user in context " > > Then you can implement this function whichever way you want, rather than > have to modify twenty-odd programs which all do the > > wp = getpwbyname(...); > getpassword(buffer); > if (strcmp(pw->pw_passwd, crypt(pw->pw_password, buffer))) { > sorry... > } But I'm saying that when I add one-time-password support with challenge/response, I'm going to have to go modify all of those daemons again to do the challenge. This is a much harder problem that some people address (possibly badly) through PAM, and for which a better solution should be found. It might also be useful if the authentication system could pass back "tickets" or "tokens" that might be useful to the daemon, if the daemon chose to accept them (that is, it knew what to do with them). For samba, this would be useful in environments using Coda or AFS. For login, this would allow the acquisition of kerberos tickets, etc -- the authentication manager would return these as optional data to the authenticating process where it deemed appropriate. My feeling is that we might as well leave things as they are until a rigorous authentication management system is defined, and then use that. Of course, if you write the code you describe, I'll use it, but... :-) Robert N Watson ---- Carnegie Mellon University http://www.cmu.edu/ Trusted Information Systems http://www.tis.com/ 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 security" in the body of the message