From owner-freebsd-current@FreeBSD.ORG Thu Nov 16 21:03:57 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 89CD116A40F; Thu, 16 Nov 2006 21:03:57 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (insomnia.benzedrine.cx [62.65.145.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4364843D5D; Thu, 16 Nov 2006 21:03:56 +0000 (GMT) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (dhartmei@localhost [127.0.0.1]) by insomnia.benzedrine.cx (8.13.4/8.13.4) with ESMTP id kAGL3v0g012882 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Thu, 16 Nov 2006 22:03:57 +0100 (MET) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.13.4/8.12.10/Submit) id kAGL3vMR001938; Thu, 16 Nov 2006 22:03:57 +0100 (MET) Date: Thu, 16 Nov 2006 22:03:56 +0100 From: Daniel Hartmeier To: Andre Oppermann , tech@openbsd.org, openssh-unix-dev@mindrot.org, freebsd-current@freebsd.org, markus@openbsd.org Message-ID: <20061116210356.GL14649@insomnia.benzedrine.cx> References: <20061115142820.GB14649@insomnia.benzedrine.cx> <455B29A4.3000601@freebsd.org> <20061115174747.GE26418@bofh.cns.ualberta.ca> <20061116180141.GH14649@insomnia.benzedrine.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061116180141.GH14649@insomnia.benzedrine.cx> User-Agent: Mutt/1.5.10i Cc: Subject: Re: OpenSSH Certkey (PKI) adding CAL (online verification) 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 21:03:57 -0000 On Thu, Nov 16, 2006 at 07:01:41PM +0100, Daniel Hartmeier wrote: > +When Certkey user authentication fails either because no CAL server can be > +reached or because one CAL server delivers a valid reply marking the user key > +as invalid, the user key can still be used with other authentication methods > +(publickey) to gain access (if found in authorized_keys). Maybe it should be possible to enable CAL even for the traditional publickey authentication. That would enforce an online check even if Certkey isn't used. You could then revoke user keys and they wouldn't work even if they're present in the traditional authorized_keys files. Of course, if you do that and the CALs go down, the only way to login is using passwords. You don't expect CALs to disable these, too, I hope ;) Daniel