website/doc.mdwn

   1 [[!template id="nav"]]
   2
   3 # Monkeysphere Documentation #
   4
   5
   6 ## Dependencies ##
   7
   8  * Monkeysphere relies on [GnuTLS](http://gnutls.org/) version 2.4.0 or later.
   9
  10 ## Getting started ##
  11
  12  * Getting started as a [user](getting-started-user)
  13  * Getting started as a [server admin](getting-started-admin)
  14
  15 ## References ##
  16
  17  * [Initial specifications at CMRG](http://cmrg.fifthhorseman.net/wiki/OpenPGPandSSH)
  18  * [OpenPGP (RFC 4880)](http://tools.ietf.org/html/rfc4880)
  19  * [Secure Shell Authentication Protocol (RFC 4252)](http://tools.ietf.org/html/rfc4252)
  20    * [URI scheme for SSH, RFC draft](http://tools.ietf.org/wg/secsh/draft-ietf-secsh-scp-sftp-ssh-uri/)
  21
  22 ## Similar Projects ##
  23
  24 The monkeysphere isn't the only project intending to implement a PKI
  25 for OpenSSH.  We provide links to these other projects because they're
  26 interesting, though we have concerns with their approaches.
  27
  28 All of the other projects we've found so far require a patched version
  29 of OpenSSH, which makes adoption more difficult.  Most people don't
  30 build their own software, and simply overlaying a patched binary is
  31 associated with significant maintenance (and therefore security)
  32 problems.  A PKI becomes more useful the more people participate in
  33 it, so widespread adoption is important.
  34
  35 ### `openssh-gpg` ###
  36
  37 [openssh-gpg](http://www.red-bean.com/~nemo/openssh-gpg/) is a patch
  38 against OpenSSH to support OpenPGP certificates.  According to its
  39 documentation, it is intended to support [`pgp-sign-rsa` and
  40 `pgp-sign-dss` public key algorithms for hosts, as specified by the
  41 IETF](http://tools.ietf.org/html/rfc4253#section-6.6).
  42
  43 Some concerns with `openssh-gpg`:
  44
  45  * This patch is significantly old; it doesn't appear to have been
  46    maintained beyond OpenSSH 3.6p1.  As of this writing, OpenSSH is on
  47    version 5.1p1.
  48
  49  * It only provides infrastructure in one direction: the user
  50    authenticating the host by name.  There doesn't seem to be a
  51    mechanism for dealing with identifying users by name, or allowing
  52    users to globally revoke or update keys.
  53
  54  * The choice of User ID (`anything goes here (and here!)
  55    <ssh@foo.example.net>`) for host keys overlaps with the current use
  56    of the User ID space.  While it's unlikely that someone actually
  57    uses this e-mail address in the web of trust, it would be a nasty
  58    collision, as the holder of that key could impersonate the server
  59    in question.  The monkeysphere uses [User IDs of the form
  60    `ssh://foo.example.net`](http://tools.ietf.org/wg/secsh/draft-ietf-secsh-scp-sftp-ssh-uri/)
  61    to avoid collisions with existing use.
  62
  63  * It's not clear that `openssh-gpg` acknowledges or respects the
  64    usage flags on the host keys.
  65
  66  * It requires patching OpenSSH.
  67
  68
  69 ### Perspectives OpenSSH client ###
  70
  71 [The Perspectives project](http://www.cs.cmu.edu/~perspectives/) at
  72 CMU has released an [openssh client that uses network
  73 notaries](http://www.cs.cmu.edu/~perspectives/openssh.html) to bolster
  74 your confidence in new keys.  This offers a defense against a narrow
  75 MITM attack (e.g. by someone who controls your local gateway) by
  76 simply verifying that other machines from around the network see the
  77 same keys for the remote host that you're seeing.
  78
  79 This is quite useful, but doesn't take the system as far as it could
  80 go, and doesn't tie into the existing web of trust.
  81
  82 Some concerns with the Perspectives OpenSSH client:
  83
  84  * This client won't help if you are connecting to machines behind
  85    firewalls, on NAT'ed LANs, with source IP filtering, or otherwise
  86    in a restricted network state.
  87
  88  * There is still a question of why you should trust these particular
  89    notaries during your verification.  Who are the notaries?  How
  90    could they be compromised?
  91
  92  * It only provides infrastructure in one direction: the user
  93    authenticating the host by name.  There is no mechanism for dealing
  94    with identifying users by name, or allowing users to globally
  95    revoke or change keys.
  96
  97  * It requires patching OpenSSH
  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 before that).
 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  * It requires patching OpenSSH.