website/why.mdwn

   1 [[!meta title="Why should you be interested in the Monkeysphere?"]]
   2
   3 # Why should you be interested in the Monkeysphere? #
   4
   5 [[!toc levels=2]]
   6
   7 ## As an `ssh` user ##
   8
   9 Do you use `ssh` to connect to remote machines?  Are you tired of
  10 seeing messages like this?
  11
  12         The authenticity of host 'foo.example.org (192.0.2.3)' can't be established.
  13         RSA key fingerprint is 17:f4:2b:22:90:d4:98:9a:a2:c5:95:4e:4a:89:be:90.
  14         Are you sure you want to continue connecting (yes/no)?
  15
  16 Do you actually tediously check the fingerprint against a
  17 cryptographically-signed message from the admin, or do you just cross
  18 your fingers and type "yes"?  Do you wish there was a better way to
  19 verify that the host you are connecting to actually is the host you
  20 mean to connect to?  Shouldn't our tools be able to figure this out
  21 automatically?
  22
  23 Do you use `ssh`'s public key authentication for convenience and/or
  24 added security?  Have you ever worried about what might happen if you
  25 lost control of your key?  (Or did you have a key that was compromised
  26 by [the OpenSSL debacle](http://bugs.debian.org/363516)?)  How many
  27 accounts/machines would you need to clean up to ensure that your old,
  28 bad key is no longer in use?
  29
  30 Have you ever wished you could phase out an old key and start using a
  31 new one without having to comb through every single account you have
  32 ever connected to?
  33
  34 [Get started with the monkeysphere as a user!](/getting-started-user)
  35
  36 ## As a system administrator ##
  37
  38 As a system administrator, have you ever tried to re-key an SSH
  39 server?  How did you communicate the key change to your users?  How
  40 did you keep them from getting the big scary warning message that the
  41 host key had changed?
  42
  43 Have you ever wanted to allow a remote colleague key-based access to a
  44 machine, *without* needing to have a copy of their public key on hand?
  45
  46 Have you ever wanted to be able to add or revoke the ability of a
  47 user's key to authenticate across an entire infrastructure you manage,
  48 without touching each host by hand?
  49
  50 [Get started with the monkeysphere as an administrator!](/getting-started-admin)
  51
  52 ## What's the connection? ##
  53
  54 All of these issues are related to a lack of a [Public Key
  55 Infrastructure (or
  56 PKI)](http://dictionary.die.net/public%20key%20infrastructure) for
  57 SSH.  A PKI at its core is a mechanism to provide answers to a few
  58 basic questions:
  59
  60 * Do we know who (or what host) a key actually belongs to?  How do we know?
  61 * Is the key still valid for use?
  62
  63 Given a clearly stated set of initial assumptions, functional
  64 cryptographic tools, and a PKI, these questions can be clearly
  65 answered in an automated fashion.  We should not need to ask humans to
  66 do complicated, error-prone things (e.g. checking host key
  67 fingerprints) except in relatively rare situations (e.g. when two
  68 people meet in person for the first time).
  69
  70 The good news is that this is all possible, and available with free
  71 tools: welcome to the Monkeysphere!
  72
  73 ## Examples ##
  74
  75 Bob is an `ssh` user, and has just been given an account on
  76 `foo.example.org` by Alice, the `example.org` system administrator,
  77 who he knows.
  78
  79 Bob already trusts Alice to properly identify all `example.org`
  80 servers.  Alice already knows who Bob is, and the new machine `foo`
  81 knows that it can rely on Alice's certifications because Alice is its
  82 administrator.
  83
  84 Alice can set up the new `bob` account on `foo.example.org` without
  85 needing to give Bob a new passphrase to remember, and without needing
  86 to even know Bob's current SSH key.  She simply tells `foo` that `Bob
  87 <bob@example.net>` should have access to the `bob` account.  The
  88 Monkeysphere on `foo` then verifies Bob's identity through the OpenPGP
  89 Web of Trust and automatically add's Bob's SSH key to the
  90 authorized_keys file for the `bob` account.
  91
  92 Bob's first connection to his new `bob` account on `foo.example.org`
  93 is seamless, because the Monkeysphere on Bob's computer automatically
  94 verifies the host key for `foo.example.org` for Bob.  Using the
  95 Monkeysphere, Bob never has to "accept" an unintelligible host key or
  96 type a password.
  97
  98 When Bob decides to change the key he uses for SSH authentication, he
  99 can do so at once: he generates a new key, revokes his old key, and
 100 publishes these changes to the public keyservers.  The next time he's
 101 ready to log into `foo.example.org`, it accepts his new key -- and it
 102 *won't* accept his old key any longer.
 103
 104 The same thing works for Alice when she decides to re-key
 105 `foo.example.org` (let's say Alice learned that Eve has compromised
 106 the old key).  Alice generates a new key, revokes the old one,
 107 publishes the changes, and the next time Bob connects, he connects as
 108 smoothly as ever.  And if Eve tries to use the old host key to
 109 masquerade as `foo`, Bob's SSH client will refuse to let him connect!
 110
 111 Alice can even quit as `example.org` system administrator, and revoke
 112 her certifications of all `example.org` hosts.  As long as Bob knows
 113 and trusts the new `example.org` system administrator to identify
 114 hosts in that domain, there's no problem.
 115
 116 ## Why OpenPGP? ##
 117
 118 We believe that OpenPGP is the right PKI to use for this project.  It
 119 allows a very flexible trust model, ranging all over the map, at the
 120 choice of the user:
 121
 122 * individual per-host certifications by each client (much like the
 123   stock OpenSSH behavior), or
 124
 125 * strict centralized Certificate Authorities (much like proposed X.509
 126   models), or
 127
 128 * a more human-centric model that recognizes individual differences in
 129   ranges of trust and acceptance.
 130
 131 Even if Bob *doesn't* trust Alice to identify *all* `example.org`
 132 hosts, his first connection to `foo.example.org` should give him more
 133 than an unintelligible string to accept or reject.  It should also
 134 give him the information that Alice (and perhaps her colleague
 135 Charles) have certified the key.  This is far more useful information
 136 than the current infrastructure allows, and is more meaningful to
 137 actual humans using these tools than some message like "Certified by
 138 GloboTrust".
 139
 140 You may also be interested in [some thoughts about alternate PKIs for
 141 SSH](/similar).
 142
 143 ## Philosophy ##
 144
 145 Humans (and
 146 [monkeys](http://www.scottmccloud.com/comics/mi/mi-17/mi-17.html))
 147 have the innate capacity to keep track of the identities of only a
 148 finite number of people. After our social sphere exceeds several dozen
 149 or several hundred (depending on the individual), our ability to
 150 remember and distinguish people begins to break down. In other words,
 151 at a certain point, we can't know for sure that the person we ran into
 152 in the produce aisle really is the same person who we met at the party
 153 last week.
 154
 155 For most of us, this limitation has not posed much of a problem in our
 156 daily, off-line lives.  With the Internet, however, we have an ability
 157 to interact with vastly larger numbers of people than we had
 158 before. In addition, on the Internet we lose many of our tricks for
 159 remembering and identifying people (physical characteristics, sound of
 160 the voice, etc.).
 161
 162 Fortunately, with online communications we have easy access to tools
 163 that can help us navigate these problems.
 164 [OpenPGP](http://en.wikipedia.org/wiki/Openpgp) (a cryptographic
 165 protocol commonly used for sending signed and encrypted email
 166 messages) is one such tool. In its simplest form, it allows us to
 167 sign our communication in such a way that the recipient can verify the
 168 sender.
 169
 170 OpenPGP goes beyond this simple use to implement a feature known as
 171 the [web of trust](http://en.wikipedia.org/wiki/Web_of_trust). The web
 172 of trust allows people who have never met in person to communicate
 173 with a reasonable degree of certainty that they are who they say they
 174 are. It works like this: Person A trusts Person B. Person B verifies
 175 Person C's identity.  Then, Person A can verify Person C's identity
 176 because of their trust of Person B.
 177
 178 The Monkeyshpere's broader goals are to extend the use of OpenPGP from
 179 email communications to other activities, such as:
 180
 181  * conclusively identifying the remote server in a remote login session
 182  * granting access to servers to people we've never directly met