From 640c122ce3bbd25139fb39cdd1312ac4c842665f Mon Sep 17 00:00:00 2001 From: Daniel Kahn Gillmor Date: Tue, 2 Sep 2008 00:29:30 -0400 Subject: broke out similar projects to separate page. --- website/similar.mdwn | 121 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 121 insertions(+) create mode 100644 website/similar.mdwn (limited to 'website/similar.mdwn') diff --git a/website/similar.mdwn b/website/similar.mdwn new file mode 100644 index 0000000..5bfd4b2 --- /dev/null +++ b/website/similar.mdwn @@ -0,0 +1,121 @@ +[[!template id="nav"]] +[[meta title="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](http://openssh.com/) (or any +[free](http://www.chiark.greenend.org.uk/~sgtatham/putty/) +[SSH](http://www.lysator.liu.se/~nisse/lsh/) +[implementation](http://matt.ucc.asn.au/dropbear/dropbear.html)) 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](http://www.red-bean.com/~nemo/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](http://tools.ietf.org/html/rfc4253#section-6.6). + +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!) + `) 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`](http://tools.ietf.org/wg/secsh/draft-ietf-secsh-scp-sftp-ssh-uri/) + to avoid collisions with existing use. + + * It's not clear that `openssh-gpg` acknowledges or respects the + [usage flags](http://tools.ietf.org/html/rfc4880#section-5.2.3.21) + 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](http://www.cs.cmu.edu/~perspectives/) at +CMU has released an [openssh client that uses network +notaries](http://www.cs.cmu.edu/~perspectives/openssh.html) 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. + + * 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. + +## OpenSSH with X.509v3 certificates ## + +Roumen Petrov [maintains a patch to OpenSSH that works with the X.509 +PKI model](http://www.roumenpetrov.info/openssh/). 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](http://lair.fifthhorseman.net/~dkg/tls-centralization/). + 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`](http://tools.ietf.org/wg/secsh/draft-ietf-secsh-scp-sftp-ssh-uri/), + 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). -- cgit v1.2.3 From 7dfc00c5e8f11b0513d6d842196c6f43046f5309 Mon Sep 17 00:00:00 2001 From: Daniel Kahn Gillmor Date: Tue, 2 Sep 2008 00:30:52 -0400 Subject: more documentation cleanup. --- website/doc.mdwn | 2 +- website/similar.mdwn | 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) (limited to 'website/similar.mdwn') diff --git a/website/doc.mdwn b/website/doc.mdwn index cec29ec..e3f8854 100644 --- a/website/doc.mdwn +++ b/website/doc.mdwn @@ -22,4 +22,4 @@ Monkeysphere relies on: ## Other ## - * [Similar Projects](/similar) + * [Similar Projects](/similar) (other attempts at a PKI for SSH) diff --git a/website/similar.mdwn b/website/similar.mdwn index 5bfd4b2..1a33b06 100644 --- a/website/similar.mdwn +++ b/website/similar.mdwn @@ -5,6 +5,8 @@ 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. +[[toc ]] + 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 -- cgit v1.2.3