[[!template id="nav"]]
Monkeysphere Documentation
Dependencies
- Monkeysphere relies on GnuTLS version 2.4.0 or later.
References
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. A PKI becomes more useful the more people participate in
it, so widespread adoption is important.
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 significantly old; it doesn't appear to have been
maintained beyond OpenSSH 3.6p1. As of this writing, OpenSSH is on
version 5.1p1.
-
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 form
ssh://foo.example.net
to avoid collisions with existing use.
-
It's not clear that openssh-gpg acknowledges or respects the
usage flags on the host keys.
-
It requires patching OpenSSH.
Perspectives OpenSSH client
The Perspectives project at
CMU has released an openssh client that uses network
notaries to bolster
your confidence in new 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 is quite useful, but doesn't take the system as far as it could
go, and doesn't tie into the 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.
-
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 requires patching OpenSSH
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 before that).
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.
-
It requires patching OpenSSH.
|
