From owner-freebsd-current@FreeBSD.ORG Thu Nov 16 18:50:58 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED96616A403 for ; Thu, 16 Nov 2006 18:50:58 +0000 (UTC) (envelope-from lamont@scriptkiddie.org) Received: from sploit.scriptkiddie.org (sploit.scriptkiddie.org [216.231.47.214]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E82843D58 for ; Thu, 16 Nov 2006 18:50:56 +0000 (GMT) (envelope-from lamont@scriptkiddie.org) Received: from sploit (sploit [216.231.47.214]) by sploit.scriptkiddie.org (8.12.11/8.12.11) with ESMTP id kAGIos8T017647; Thu, 16 Nov 2006 10:50:54 -0800 (PST) Date: Thu, 16 Nov 2006 10:50:53 -0800 (PST) From: Lamont Granquist To: "Wolfgang S. Rupprecht" In-Reply-To: <87ac2rjqaf.fsf@arbol.wsrcc.com> Message-ID: References: <20061115142820.GB14649@insomnia.benzedrine.cx> <87odr8i53w.fsf@arbol.wsrcc.com> <20061116135627.GA26343@tortuga.leo.org> <87ac2rjqaf.fsf@arbol.wsrcc.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, openssh-unix-dev@mindrot.org, tech@openbsd.org Subject: Re: OpenSSH Certkey (PKI) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2006 18:50:59 -0000 On Thu, 16 Nov 2006, Wolfgang S. Rupprecht wrote: > +A user certificate is an authorization made by the CA that the > +holder of a specific private key may login to the server as a > +specific user, without the need of an authorized_keys file being > +present. The CA gains the power to grant individual users access > +to the server, and users do no longer need to maintain > +authorized_keys files of their own. User-maintained authorized_keys files tend to be SOX auditing violations (anyone with access to the account can grant anyone else access with any notification or audit trail). It also lends itself to abuses where software/generic accounts tend to accumulate the public keys of all the developers desktop accounts. The kerberos .k5login file is similarly problematic. I would love to see a CA-based approach which would solve both the authentication and authorization pieces in a way that could be wrapped with proper auditing on the granting of privs, particularly if it was simple enough that it was widely adopted instead of authorized_keys even at very small sites.