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 ## As an `ssh` user ##
   6
   7 Do you use `ssh` to connect to remote machines?  Are you tired of
   8 seeing messages like this?
   9
  10         The authenticity of host 'foo.example.org (192.0.2.3)' can't be established.
  11         RSA key fingerprint is 17:f4:2b:22:90:d4:98:9a:a2:c5:95:4e:4a:89:be:90.
  12         Are you sure you want to continue connecting (yes/no)?
  13
  14 Do you actually tediously check the fingerprint against a
  15 cryptographically-signed message from the admin, or do you just cross
  16 your fingers and type "yes"?  Do you wish there was a better way to do
  17 it?  Shouldn't our tools be able to figure this out automatically?
  18
  19 Do you use `ssh`'s public key authentication for convenience and/or
  20 added security?  Have you ever worried about what might happen if you
  21 lose control of your key?  (Or did you have a key that was compromised
  22 by [the OpenSSL debacle](http://bugs.debian.org/363516)?)  How many
  23 accounts/machines would you need to clean up to ensure that your old,
  24 bad key is no longer in use?
  25
  26 Have you ever wished you could phase out an old key and start using a
  27 new one without having to comb through every single account you have
  28 ever connected to?
  29
  30 ## As an `sshd` administrator ##
  31
  32 If you are a system administrator, have you ever tried to re-key an
  33 SSH server?  How did you ease the change along to your users?  How did
  34 you keep them from getting the big scary warning messages?
  35
  36 Have you ever wanted to allow a colleague key-based access to a
  37 machine, *without* needing to have a copy of their public key on hand?
  38
  39 Have you ever wanted to be able to revoke the ability of a user's key
  40 to authenticate across the entire infrastructure you manage, without
  41 touching each host by hand?
  42
  43 ## What's the connection? ##
  44
  45 These questions all stem from rough edges we run up against in regular
  46 use of SSH that could be improved by a decent [Public Key
  47 Infrastructure (or
  48 PKI)](http://dictionary.die.net/public%20key%20infrastructure).  A PKI
  49 at its core is a mechanism to provide answers to a few basic
  50 questions:
  51
  52 * Do we know who a key actually belongs to?  How do we know?
  53 * Is the key still valid for use?
  54
  55 Given a clearly stated set of initial assumptions, functional
  56 cryptographic tools, and a PKI, these questions can be clearly
  57 answered in an automated fashion.  We should not need to ask humans to
  58 do complicated, error-prone things (e.g. checking host key
  59 fingerprints) except in relatively rare situations (e.g. when two
  60 people meet in person for the first time).
  61
  62 The good news is that this is all possible, and available with free
  63 tools!
  64
  65 ## Examples ##
  66
  67 Bob is an `ssh` user, and has just been given an account on
  68 `foo.example.org` by Alice, the `example.org` system administrator,
  69 who he knows.
  70
  71 Bob already trusts Alice to properly identify all `example.org`
  72 servers.  Alice already knows who Bob is, and the new machine `foo`
  73 knows that it can rely on Alice's certifications because Alice is its
  74 administrator.
  75
  76 Alice can set up the new `bob` account on `foo.example.org` without
  77 needing to give Bob a new passphrase to remember, and without needing
  78 to even know Bob's current SSH key.  She simply tells `foo` that `Bob
  79 <bob@example.net>` should have access to the `bob` account.
  80
  81 Bob's first connection to his new `bob` account on `foo.example.org`
  82 is seamless, because all the steps are already in place!  Using the
  83 MonkeySphere, Bob never has to "accept" an unintelligible host key or
  84 type a password.
  85
  86 When Bob decides to change the key he uses for SSH authentication, he
  87 can do so at once: he generates a new key, revokes his old key, and
  88 publishes these changes to the public keyservers.  The next time he's
  89 ready to log into `foo.example.org`, it accepts his new key -- and it
  90 *won't* accept his old key any longer.
  91
  92 The same thing works for Alice when she decides to re-key
  93 `foo.example.org` (let's say Alice learned that Eve has compromised
  94 the old key).  Alice generates a new key, revokes the old one,
  95 publishes the changes, and the next time Bob connects, he connects as
  96 smoothly as ever.  And if Eve tries to use the old host key to
  97 masquerade as `foo`, Bob's SSH client will refuse to let him connect!
  98
  99 Alice can even quit as `example.org` system administrator, and revoke
 100 her certifications of all `example.org` hosts.  As long as Bob knows
 101 and trusts the new `example.org` system administrator to identify
 102 hosts in that domain, there's no problem.
 103
 104 ## Why OpenPGP? ##
 105
 106 We believe that OpenPGP is the right PKI to use for this project.  It
 107 allows a very flexible trust model, ranging all over the map, at the
 108 choice of the user:
 109
 110 * individual per-host certifications by each client (much like the
 111   stock OpenSSH behavior),
 112
 113 * strict centralized Certificate Authorities (much like proposed X.509
 114   models), and
 115
 116 * a more human-centric model that recognizes individual differences in
 117   ranges of trust and acceptance.
 118
 119 Even if Bob *doesn't* trust Alice to identify *all* `example.org`
 120 hosts, his first connection to `foo.example.org` should give him more
 121 than an unintelligible string to accept or reject.  It should also
 122 give him the information that Alice (and perhaps her colleague
 123 Charles) have certified the key.  This is far more useful information
 124 than the current infrastructure allows, and is more meaningful to
 125 actual humans using these tools than some message like "Certified by
 126 GloboTrust".