From owner-freebsd-isp@FreeBSD.ORG Tue Oct 18 15:09:12 2005 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B328916A420 for ; Tue, 18 Oct 2005 15:09:12 +0000 (GMT) (envelope-from tillman@seekingfire.com) Received: from mail.seekingfire.com (caliban.seekingfire.com [24.72.123.45]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2716A43D48 for ; Tue, 18 Oct 2005 15:09:08 +0000 (GMT) (envelope-from tillman@seekingfire.com) Received: by mail.seekingfire.com (Postfix, from userid 500) id 7B9C01A7; Tue, 18 Oct 2005 09:09:06 -0600 (CST) Date: Tue, 18 Oct 2005 09:09:06 -0600 From: Tillman Hodgson To: Francisco Message-ID: <20051018150906.GJ33270@seekingfire.com> References: <20051012234337.K63956@zoraida.natserv.net> <57416b300510142221r2c3da329o65d54cb0aa04fc73@mail.gmail.com> <20051015133148.P97899@zoraida.natserv.net> <18f601940510151547ka3573f8v2f0633010ad2874f@mail.gmail.com> <20051016010251.R90770@zoraida.natserv.net> <20051017203353.GF33270@seekingfire.com> <20051018103540.K28109@zoraida.natserv.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051018103540.K28109@zoraida.natserv.net> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . X-GPG-Key-ID: 828AFC7B X-GPG-Fingerprint: 5584 14BA C9EB 1524 0E68 F543 0F0A 7FBC 828A FC7B X-GPG-Key: http://www.seekingfire.com/personal/gpg_key.asc X-Urban-Legend: There is lots of hidden information in headers X-Tillman-rules: yes he does User-Agent: Mutt/1.5.11 Cc: freebsd-isp@freebsd.org Subject: Re: Distributed authentication. Which one? X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2005 15:09:12 -0000 On Tue, Oct 18, 2005 at 10:37:53AM -0400, Francisco wrote: > On Mon, 17 Oct 2005, Tillman Hodgson wrote: > > >It has some interoperability and security issues. They're solvable, IMO. > > Thanks for the feedback. > > I guess a good test is to ask.. what would you use? :-) On a meta-network (http://metanetwork.seekingfire.com/wiki.pl) we've used Kerberos with cross-realm trusts in combination with NIS providing the meta information (preferred shell, etc) for "users in common" (non-local). It maps well to multiple administrative domains. On purely local networks where the number of users are low (a few dozen at most), I like using something like cfengine to simply keep all local user databases in sync. I then use Kerberos (preferred) or sudo to break out root-like powers in an auditable way. I'm a fan of IPsec transport mode with the blowfish algorithm and compression turned on -- it's "good enough" security for my needs and can actually /increase/ the effective bandwidth (I've posted the results of a Sun Ultra5 and a few Intel box to FreeBSD mailing lists in the past, ithe archives should have them somewhere). The fact that it makes using traditional RPC services a bit more secure is merely a bonus :-) > >For example, most of the security concerns can be addressed with a > >combination of transport-mode IPsec and Kerberos and I avoid inter- > >operability issues by avoiding weird implementations of NIS ;-) > > Sounds like more trouble than it's worth. You'll likely find that there's similar issues for any cross-platform solution with decent security. I'd use whatever you can best understand, since anything security related that works but isn't well understood can be a source of future problems. If you grok LDAP, then use LDAP :-) > Right now I am leaning towards Kerberos or LDAP. They're differnet things. Kerberos *and* LDAP is a nice combination. Kerberos is for /authentication/, and authentication only. It doesn't handle meta data (like home dir, shell, group information, etc) and it handles authorization only in passing and not in a finely-grained manner (via .k5login, basically). It does authentication exceedingly well and that's what I consider its prime attraction. So when considering Kerberos it generally makes sense to design the user management system to be Kerberos + $somthing_else. The $something_else provides the meta-data, group information and authorization pieces of the puzzle. This isn't as convoluted as it sounds. Take web services for example -- the required meta data is often different than for local users, but the concept of secure authentication remains the same. Think of it as flexibility rather than complexity. > Need to learn more about them to see their strengths and weaknesses and > how it would fit into our existing extructure. I have a very basic (albeit somewhat old) presentation on Kerberos up at http://www.seekingfire.com/documents/presentations/kerberos_presentation/kerberos.pdf, and a collection of useful links at http://www.seekingfire.com/projects/kerberos/. There's a variety of HOWTOs floating around the net on combining Kerberos with local passwd files, NIS, LDAP, and other user database technologies. There's also the O'Reilly book, which is handy but not as comprehensive as I'd like (http://slashdot.org/comments.pl?sid=139450&cid=11672353 has my original comments archived). -T -- "What are the facts, and to how many decimal places? You pilot always into an unknown future; facts are your only clue. Get the facts!" -- Lazarus Long (_Time Enough for Love_, Robert Heinlein)