Re: OpenSSH Certkey (PKI)

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