From owner-freebsd-stable Fri Apr 3 14:19:37 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA16575 for freebsd-stable-outgoing; Fri, 3 Apr 1998 14:19:37 -0800 (PST) (envelope-from owner-freebsd-stable@FreeBSD.ORG) Received: from xmission.xmission.com (softweyr@xmission.xmission.com [198.60.22.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA16492 for ; Fri, 3 Apr 1998 14:19:25 -0800 (PST) (envelope-from softweyr@xmission.xmission.com) Received: (from softweyr@localhost) by xmission.xmission.com (8.8.8/8.7.5) id PAA17773; Fri, 3 Apr 1998 15:19:16 -0700 (MST) From: Wes Peters - Softweyr LLC Message-Id: <199804032219.PAA17773@xmission.xmission.com> Subject: Re: Hesiod support on 2.2 To: robert+freebsd@cyrus.watson.org Date: Fri, 3 Apr 1998 15:19:15 -0700 (MST) Cc: stable@FreeBSD.ORG In-Reply-To: from "Robert Watson" at Apr 3, 98 02:17:40 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk Robert N Watson > ... Some have suggested using LDAP for > distributing this kind of information, but I personally like the idea of > DNS used in this manner -- with security, this becomes quite feasible. > There is significant oposition to storing this kind of information in DNS > in a number of the groups working with DNS. The feeling is that another > service should be used for this. I'm caught between agreeing that this > may be beyond the scope of DNS, and also noting that DNS provides an > excellent distribution mechanism, with security, etc, for this > information. Given that DNSsec provides an excellent public key > distribution system, I lean towards storing authentication-related data > there. DNS wasn't really designed with a highly volatile dataset in mind. If it takes a day or two for the existence of a new workstation to trickle across the net, that's generally not too bad, but if it takes a day or two for my new password to trickle across the net, I cannot reliably predict if I can login or not. You can, of course, fix this problem by using short expirations on the zone your login information is stored in, but that doesn't change the basic design limitation. I designed a system like this once for Raxco Software; it would allow you to define users and groups, and define any user account or group of users on domains of systems. I thought our design was pretty realistic, but they decided Novell NDS was going to win the world of directory services and canned the project. I quit, and 6 months later Novell canned NDS for Unix. You never know if a design will really work, but our flood-fill algorithmn designed back then still lives on in Axent Enterprise Security Manager, the one remaining product from that group. I still think it will work, and if you've got a couple hundred thousand dollars, I'll prove it. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.xmission.com/~softweyr softweyr@xmission.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message