From owner-freebsd-security Thu Jul 8 1:24:26 1999 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id B336E14F34 for ; Thu, 8 Jul 1999 01:24:13 -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 EAA17396; Thu, 8 Jul 1999 04:23:29 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Thu, 8 Jul 1999 04:23:29 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Kris Kennaway Cc: Ladavac Marino , "'Josef Karthauser'" , Brian Somers , Mark Thomas , freebsd-security@freebsd.org, Wayne Self Subject: Re: Credential storage (was RE: userland ppp - startup) In-Reply-To: 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 Thu, 8 Jul 1999, Kris Kennaway wrote: > You know, I wonder if it's time to look at providing a generic > credential storage registry; things like password hashes, PPP shared > secrets, etc, could be stored here instead of in lots of separate files. > > So user account passwords could point to a SHA-1 hash in the registry, > ppp shared secrets would point to an NT and/or LM hash, samba accounts > could have an associated NT/LM hash, etc. More than one hash could be > associated with any given entity. > > The modules which manipulate individual credentials (hashes) would be > pluggable along the lines of PAM. > > What do people think - is this worth pursuing? It is worth pursuing, but my feeling is that we should wait until IPSEC is integrated so we have some idea of the key management requirements there. I'm also tempted to say that this should not be just a system credential management, but part of a general key-management toolkit and authentication package, but that's fairly heavy-weight, and still a topic of open research. :-) The problem is of course that you need to express policies concerning key strength, provide key management functionality, and support more than just hashes and passwords: ideally also public/private key -- perhaps as a back end to sshd. Which brings up certificate management, ... My feeling is we should let all this stuff settle and work with an interim temporary solution without exerting too much effort. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Computing Laboratory at Cambridge University Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message