Date: Wed, 15 Nov 2006 15:52:20 +0100 From: Andre Oppermann <andre@freebsd.org> To: Daniel Hartmeier <daniel@benzedrine.cx> Cc: tech@openbsd.org, openssh-unix-dev@mindrot.org, markus@openbsd.org, freebsd-current@freebsd.org Subject: Re: OpenSSH Certkey (PKI) Message-ID: <455B29A4.3000601@freebsd.org> In-Reply-To: <20061115142820.GB14649@insomnia.benzedrine.cx> References: <20061115142820.GB14649@insomnia.benzedrine.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
Daniel Hartmeier wrote: > This patch against OpenBSD -current adds a simple form of PKI to > OpenSSH. We'll be using it at work. See README.certkey (the first chunk > of the patch) for details. > > Everything below is BSD licensed, sponsored by Allamanda Networks AG. As the one who assigned this work to Daniel Hartmeier I can add the rationale for this simple and easy PKI functionality in OpenSSH. Rationale for PKI in OpenSSH: Managing a large m:n relationship of users and hosts in OpenSSH is tedious and requires the use of scripting and rsync distribution methods for known_hosts and authorized_keys with all associated failure modes. Users tend not to verify server pubkey fingerprints out of band upon the first connection attempt which weakens the strong theoretic security of SSHs public key system. Known_hosts and authorized_keys do not contain any validity or expiration information. Reality shows that a lot of cruft and old information tends to remain. This tends to accidentally leave once granted privileges to users or hosts which should no longer posses them. It requires strict discipline to properly clean up and stay up to date on n hosts. What does OpenSSH PKI do: It does three things: a) It adds a certificate to the public key of a ssh server so the ssh client can verify the authenticity of a server pubkey without having to rely on other unspecified out of band methods (on first connection) or the known_hosts file (on subsequent connections). b) It adds a certificate to the public key of a ssh user so the ssh server can verify the authenticity of a users pubkey without having to have a pre-populated authorized_keys file in each users home directory on all machines this user has access to. c) It adds a number of optional fields in the certificate which can specify additional constrains on the hosts and users. The constrains include lists of IP addresses or networks which limit where the clients or server can connect to/from. This way hosts with a number of interfaces can be handled as one entity. Moving/copying of server pub/privkeys to a different IP address is prevented. Users may be restricted to be able to login only from defined list of IP addresses/networks specified in the certificate. What are the advantages: Only the CA's public key has to be distributed once to all hosts. -> Can be rolled into the host setup procedure/automation. The CA has to sign each host or user public key once. None of the user or host keys have to be distributed (copied) to all other hosts. -> Instant acceptance by all hosts with the same CA pubkey. The addition of any users or hosts is controlled by the CA. -> Single point of entry and control. The CA specifies the expiry date of any user and host certificate thus a policy can regularly timeout any of them. -> Any old cruft and temporary privileges expire by itself w/o having to individually check all hosts for them. Who is it for: Centrally managed organizations or collections of hosts which trust a single master role (the CA certification authority, a.k.a 'root'). Many real world deployments do resemble the single trust model of a CA. What are the risks: All trust and authentication/authorization is vested in the operator of the CA and the strength and secrecy of the CA private key. If the CA operator or the CA private key are compromised all doors are open. The CA operator is equal to 'root' which is trusted anyway. He can do everything root can do (that is reading/modifying each users private keys and authorized keys files). Less severe incidents include lost or compromised user keys. OpenSSH PKI gives two methods to deal with this. First it allows to specify an expiry date for all certificates. If set sufficiently short all certs lose their usefulness quickly. All users have to be re-certified in intervals and the re-certification can be tied to any number of administrative criteria. For immediate reactions any number of public key fingerprints can be blacklisted on the ssh server. This is a simple file based certificate revocation. Online revocation checks could optionally be implemented as well. The operator then has to specify whether to fail open or close depending on priorities and risk assessments. Why not implement/use X.509 or OpenPGP PKI methods: The goal is to use only basic and non-complex cryptographic methods which are widely available and do *not* require the installation of additional software libraries (eg. OpenPGP SDK or OpenSSL for OpenBSD) and a simple and modular certificate binary format (no ASN.1 or such). It should work out of the box on all currently supported OpenSSH platforms without any external dependencies. This OpenSSH PKI system is very simple and easy to use. All programs and functions necessary to use it to its full extent are included with the base OpenSSH distribution. -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?455B29A4.3000601>