From owner-freebsd-security Mon Jun 1 12:50:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA15825 for freebsd-security-outgoing; Mon, 1 Jun 1998 12:50:52 -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 MAA15812 for ; Mon, 1 Jun 1998 12:50:43 -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 PAA05127; Mon, 1 Jun 1998 15:47:38 -0400 (EDT) Date: Mon, 1 Jun 1998 15:47:38 -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: <20473.896555907@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 Sat, 30 May 1998, Poul-Henning Kamp wrote: > I have been considering if we shouldn't introduce a > > int checkuserpassword(char *user, char *password); > > in some library, rather than having all these programs know that > you should strcmp after calling crypt(). This would allow us to > do what you propose or RADIUS authentication for that matter... I personally dislike this idea -- where does this leave one-time-password users, etc? Authentication really occurs through negotiation, and may involve challenges, as well as arbitrary chunks of data, etc (for pk-authentication). I'd like to see a nice API and text-based protocol (maybe SASL fits the bill?) to all authentication between an authentication API bottom and an end-agent, possibly a user. This way a an arrangement such as: user <-KEYBOARD-> Netscape <-IMAP-> Mail Server <-API-> Authentication Module could occur. But it would not suffer from PAM's opaqueness, so Netscape (if it understood the auth type) could cache, etc. If done correctly, you would be able to have larger number of hops along the way: user <-KEYBOARD-> Netscape <-IMAP-> Firewall <-IMAP-> Firewall <-IMAP-> Mail Server <-API-> Authentication Library <-MYSPIFFYPROTOCOL-> Auth Server Or something. It would have to fit into a general architecture for authentication services between a number of types of clients, servers, whatever. Also, one would avoid opaque strings (such as used by PAM) to allow more easy automated authentication (i.e., server-server authentication on a daily event). 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