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