2 [[meta title="Similar Projects"]]
4 The monkeysphere isn't the only project intending to implement a PKI
5 for OpenSSH. We provide links to these other projects because they're
6 interesting, though we have concerns with their approaches.
8 All of the other projects we've found so far require a patched version
9 of OpenSSH, which makes adoption more difficult. Most people don't
10 build their own software, and simply overlaying a patched binary is
11 associated with significant maintenance (and therefore security)
14 While ultimately contributing a patch to
15 [OpenSSH](http://openssh.com/) (or any
16 [free](http://www.chiark.greenend.org.uk/~sgtatham/putty/)
17 [SSH](http://www.lysator.liu.se/~nisse/lsh/)
18 [implementation](http://matt.ucc.asn.au/dropbear/dropbear.html)) is
19 not a bad thing, we hope to be able to better establish the use of a
20 PKI without resorting to source modification.
24 [openssh-gpg](http://www.red-bean.com/~nemo/openssh-gpg/) is a patch
25 against OpenSSH to support OpenPGP certificates. According to its
26 documentation, it is intended to support [`pgp-sign-rsa` and
27 `pgp-sign-dss` public key algorithms for hosts, as specified by the
28 IETF](http://tools.ietf.org/html/rfc4253#section-6.6).
30 Some concerns with `openssh-gpg`:
32 * This patch is old; it doesn't appear to have been maintained beyond
33 OpenSSH 3.6p1. As of this writing, OpenSSH 5.1p1 is current.
35 * It only provides infrastructure in one direction: the user
36 authenticating the host by name. There doesn't seem to be a
37 mechanism for dealing with identifying users by name, or allowing
38 users to globally revoke or update keys.
40 * The choice of User ID (`anything goes here (and here!)
41 <ssh@foo.example.net>`) for host keys overlaps with the current use
42 of the User ID space. While it's unlikely that someone actually
43 uses this e-mail address in the web of trust, it would be a nasty
44 collision, as the holder of that key could impersonate the server
45 in question. The monkeysphere uses [User IDs of the form
46 `ssh://foo.example.net`](http://tools.ietf.org/wg/secsh/draft-ietf-secsh-scp-sftp-ssh-uri/)
47 to avoid collisions with existing use.
49 * It's not clear that `openssh-gpg` acknowledges or respects the
50 [usage flags](http://tools.ietf.org/html/rfc4880#section-5.2.3.21)
51 on the host keys. This means that it could accept a "sign-only"
52 key as suitable for authenticating a host, despite the
53 clearly-marked intentions of the key-holder.
55 ## Perspectives OpenSSH client ##
57 [The Perspectives project](http://www.cs.cmu.edu/~perspectives/) at
58 CMU has released an [openssh client that uses network
59 notaries](http://www.cs.cmu.edu/~perspectives/openssh.html) to bolster
60 your confidence in newly-seen keys. This offers a defense against a
61 narrow MITM attack (e.g. by someone who controls your local gateway)
62 by simply verifying that other machines from around the network see
63 the same keys for the remote host that you're seeing.
65 This tactic is quite useful, but doesn't take the system as far as it
66 could go, and doesn't tie into any existing web of trust.
68 Some concerns with the Perspectives OpenSSH client:
70 * This client won't help if you are connecting to machines behind
71 firewalls, on NAT'ed LANs, with source IP filtering, or otherwise
72 in a restricted network state.
74 * There is still a question of why you should trust these particular
75 notaries during your verification. Who are the notaries? How
76 could they be compromised?
78 * It only provides infrastructure in one direction: the user
79 authenticating the host by name. There is no mechanism for dealing
80 with identifying users by name, or allowing users to globally
81 revoke or change keys.
83 * It doesn't provide any mechanism for key rotation or revocation:
84 Perspectives won't help you if you need to re-key your machine.
86 ## OpenSSH with X.509v3 certificates ##
88 Roumen Petrov [maintains a patch to OpenSSH that works with the X.509
89 PKI model](http://www.roumenpetrov.info/openssh/). This is the
90 certificate hierarchy commonly used by TLS (and SSL).
92 Some concerns about OpenSSH with X.509v3:
94 * the X.509 certificate specification itself [encourages corporate
95 consolidation and centralized global "trust" because of its
96 single-issuer architectural
97 limitation](http://lair.fifthhorseman.net/~dkg/tls-centralization/).
98 This results in an expensive and cumbersome system for smaller
99 players, and it also doesn't correspond to the true distributed
100 nature of human-to-human trust. Furthermore, centralized global
101 "trusted authorities" create a tempting target for attack, and a
102 single-point-of-failure if an attack is successful.
104 Depending on how you declare your trust relationships, OpenPGP is
105 capable of providing the same hierarchical structure as X.509, but
106 it is not limited to such a structure. The OpenPGP Web of Trust
107 model is more flexible and more adaptable to represent real-world
108 trust than X.509's rigid hierarchy.
110 * X.509 certificates can identify hosts by name, but not by
111 individual service. This means that a compromised web or e-mail
112 server with access to the X.509 key for that service could re-use
113 its certificate as an SSH server, and it would be able to
114 masquerade successfully.
116 The monkeysphere uses [User IDs of the form
117 `ssh://foo.example.net`](http://tools.ietf.org/wg/secsh/draft-ietf-secsh-scp-sftp-ssh-uri/),
118 so they are not by-default shared across services on the same host
119 (you can still share a key across services on the same host if you
120 like, but the service User IDs can be certified independently of