Similar Projects
The monkeysphere isn't the only project intending to implement a PKI for OpenSSH. We provide links to these other projects because they're interesting, though we have concerns with their approaches.
All of the other projects we've found so far require a patched version of OpenSSH, which makes adoption more difficult. Most people don't build their own software, and simply overlaying a patched binary is associated with significant maintenance (and therefore security) problems.
While ultimately contributing a patch to OpenSSH (or any free SSH implementation) is not a bad thing, we hope to be able to better establish the use of a PKI without resorting to source modification.
openssh-gpg
openssh-gpg is a patch
against OpenSSH to support OpenPGP certificates. According to its
documentation, it is intended to support pgp-sign-rsa and
pgp-sign-dss public key algorithms for hosts, as specified by the
IETF.
Some concerns with openssh-gpg:
This patch is old; it doesn't appear to have been maintained beyond OpenSSH 3.6p1. As of this writing, OpenSSH 5.1p1 is current.
It only provides infrastructure in one direction: the user authenticating the host by name. There doesn't seem to be a mechanism for dealing with identifying users by name, or allowing users to globally revoke or update keys.
The choice of User ID (
anything goes here (and here!) <ssh@foo.example.net>) for host keys overlaps with the current use of the User ID space. While it's unlikely that someone actually uses this e-mail address in the web of trust, it would be a nasty collision, as the holder of that key could impersonate the server in question. The monkeysphere uses User IDs of the formssh://foo.example.netto avoid collisions with existing use.It's not clear that
openssh-gpgacknowledges or respects the usage flags on the host keys. This means that it could accept a "sign-only" key as suitable for authenticating a host, despite the clearly-marked intentions of the key-holder.
Perspectives OpenSSH client
The Perspectives project at CMU has released an openssh client that uses network notaries to bolster your confidence in newly-seen keys. This offers a defense against a narrow MITM attack (e.g. by someone who controls your local gateway) by simply verifying that other machines from around the network see the same keys for the remote host that you're seeing.
This tactic is quite useful, but doesn't take the system as far as it could go, and doesn't tie into any existing web of trust.
Some concerns with the Perspectives OpenSSH client:
This client won't help if you are connecting to machines behind firewalls, on NAT'ed LANs, with source IP filtering, or otherwise in a restricted network state, because the notaries won't be able to reach it.
There is still a question of why you should trust these particular notaries during your verification. Who are the notaries? How could they be compromised?
It only provides infrastructure in one direction: the user authenticating the host by name. There is no mechanism for dealing with identifying users by name, or allowing users to globally revoke or change keys.
It doesn't provide any mechanism for key rotation or revocation: Perspectives won't help you if you need to re-key your machine.
The most common threat which Perspectives protects against (a narrow MITM attack, e.g. the attacker controls your gateway) often coincides with the ability of the attacker to filter arbitrary traffic to your node. But in this case, the attacker could filter out your traffic to the notaries (or the responses from the notaries). Such filtering (rejecting unknown UDP traffic, as Perspectives appears to use UDP port 15217) is unfortunately common, particuarly on public networks, even when the gateway is not malicious. This reduces the utility of the Perspectives approach.
OpenSSH with X.509v3 certificates
Roumen Petrov maintains a patch to OpenSSH that works with the X.509 PKI model. This is the certificate hierarchy commonly used by TLS (and SSL).
Some concerns about OpenSSH with X.509v3:
the X.509 certificate specification itself encourages corporate consolidation and centralized global "trust" because of its single-issuer architectural limitation. This results in an expensive and cumbersome system for smaller players, and it also doesn't correspond to the true distributed nature of human-to-human trust. Furthermore, centralized global "trusted authorities" create a tempting target for attack, and a single-point-of-failure if an attack is successful.
Depending on how you declare your trust relationships, OpenPGP is capable of providing the same hierarchical structure as X.509, but it is not limited to such a structure. The OpenPGP Web of Trust model is more flexible and more adaptable to represent real-world trust than X.509's rigid hierarchy.
X.509 certificates can identify hosts by name, but not by individual service. This means that a compromised web or e-mail server with access to the X.509 key for that service could re-use its certificate as an SSH server, and it would be able to masquerade successfully.
The monkeysphere uses User IDs of the form
ssh://foo.example.net, so they are not by-default shared across services on the same host (you can still share a key across services on the same host if you like, but the service User IDs can be certified independently of one another).