From 2f9fe93b98ed32b662212899db6ba2174c1138d3 Mon Sep 17 00:00:00 2001 From: Matthew James Goins Date: Sat, 20 Mar 2010 15:07:30 -0400 Subject: Removed docs and website. They will now reside (for my repo) at git://lair.fifthhorseman.net/~mjgoins/monkeysphere.info/ --- website/why.mdwn | 182 ------------------------------------------------------- 1 file changed, 182 deletions(-) delete mode 100644 website/why.mdwn (limited to 'website/why.mdwn') diff --git a/website/why.mdwn b/website/why.mdwn deleted file mode 100644 index d1c15c2..0000000 --- a/website/why.mdwn +++ /dev/null @@ -1,182 +0,0 @@ -[[!meta title="Why should you be interested in the Monkeysphere?"]] - -# Why should you be interested in the Monkeysphere? # - -[[!toc levels=2]] - -## As an `ssh` user ## - -Do you use `ssh` to connect to remote machines? Are you tired of -seeing messages like this? - - The authenticity of host 'foo.example.org (192.0.2.3)' can't be established. - RSA key fingerprint is 17:f4:2b:22:90:d4:98:9a:a2:c5:95:4e:4a:89:be:90. - Are you sure you want to continue connecting (yes/no)? - -Do you actually tediously check the fingerprint against a -cryptographically-signed message from the admin, or do you just cross -your fingers and type "yes"? Do you wish there was a better way to -verify that the host you are connecting to actually is the host you -mean to connect to? Shouldn't our tools be able to figure this out -automatically? - -Do you use `ssh`'s public key authentication for convenience and/or -added security? Have you ever worried about what might happen if you -lost control of your key? (Or did you have a key that was compromised -by [the OpenSSL debacle](http://bugs.debian.org/363516)?) How many -accounts/machines would you need to clean up to ensure that your old, -bad key is no longer in use? - -Have you ever wished you could phase out an old key and start using a -new one without having to comb through every single account you have -ever connected to? - -[Get started with the monkeysphere as a user!](/getting-started-user) - -## As a system administrator ## - -As a system administrator, have you ever tried to re-key an SSH -server? How did you communicate the key change to your users? How -did you keep them from getting the big scary warning message that the -host key had changed? - -Have you ever wanted to allow a remote colleague key-based access to a -machine, *without* needing to have a copy of their public key on hand? - -Have you ever wanted to be able to add or revoke the ability of a -user's key to authenticate across an entire infrastructure you manage, -without touching each host by hand? - -[Get started with the monkeysphere as an administrator!](/getting-started-admin) - -## What's the connection? ## - -All of these issues are related to a lack of a [Public Key -Infrastructure (or -PKI)](http://dictionary.die.net/public%20key%20infrastructure) for -SSH. A PKI at its core is a mechanism to provide answers to a few -basic questions: - -* Do we know who (or what host) a key actually belongs to? How do we know? -* Is the key still valid for use? - -Given a clearly stated set of initial assumptions, functional -cryptographic tools, and a PKI, these questions can be clearly -answered in an automated fashion. We should not need to ask humans to -do complicated, error-prone things (e.g. checking host key -fingerprints) except in relatively rare situations (e.g. when two -people meet in person for the first time). - -The good news is that this is all possible, and available with free -tools: welcome to the Monkeysphere! - -## Examples ## - -Bob is an `ssh` user, and has just been given an account on -`foo.example.org` by Alice, the `example.org` system administrator, -who he knows. - -Bob already trusts Alice to properly identify all `example.org` -servers. Alice already knows who Bob is, and the new machine `foo` -knows that it can rely on Alice's certifications because Alice is its -administrator. - -Alice can set up the new `bob` account on `foo.example.org` without -needing to give Bob a new passphrase to remember, and without needing -to even know Bob's current SSH key. She simply tells `foo` that `Bob -` should have access to the `bob` account. The -Monkeysphere on `foo` then verifies Bob's identity through the OpenPGP -Web of Trust and automatically add's Bob's SSH key to the -authorized_keys file for the `bob` account. - -Bob's first connection to his new `bob` account on `foo.example.org` -is seamless, because the Monkeysphere on Bob's computer automatically -verifies the host key for `foo.example.org` for Bob. Using the -Monkeysphere, Bob never has to "accept" an unintelligible host key or -type a password. - -When Bob decides to change the key he uses for SSH authentication, he -can do so at once: he generates a new key, revokes his old key, and -publishes these changes to the public keyservers. The next time he's -ready to log into `foo.example.org`, it accepts his new key -- and it -*won't* accept his old key any longer. - -The same thing works for Alice when she decides to re-key -`foo.example.org` (let's say Alice learned that Eve has compromised -the old key). Alice generates a new key, revokes the old one, -publishes the changes, and the next time Bob connects, he connects as -smoothly as ever. And if Eve tries to use the old host key to -masquerade as `foo`, Bob's SSH client will refuse to let him connect! - -Alice can even quit as `example.org` system administrator, and revoke -her certifications of all `example.org` hosts. As long as Bob knows -and trusts the new `example.org` system administrator to identify -hosts in that domain, there's no problem. - -## Why OpenPGP? ## - -We believe that OpenPGP is the right PKI to use for this project. It -allows a very flexible trust model, ranging all over the map, at the -choice of the user: - -* individual per-host certifications by each client (much like the - stock OpenSSH behavior), or - -* strict centralized Certificate Authorities (much like proposed X.509 - models), or - -* a more human-centric model that recognizes individual differences in - ranges of trust and acceptance. - -Even if Bob *doesn't* trust Alice to identify *all* `example.org` -hosts, his first connection to `foo.example.org` should give him more -than an unintelligible string to accept or reject. It should also -give him the information that Alice (and perhaps her colleague -Charles) have certified the key. This is far more useful information -than the current infrastructure allows, and is more meaningful to -actual humans using these tools than some message like "Certified by -GloboTrust". - -You may also be interested in [some thoughts about alternate PKIs for -SSH](/similar). - -## Philosophy ## - -Humans (and -[monkeys](http://www.scottmccloud.com/comics/mi/mi-17/mi-17.html)) -have the innate capacity to keep track of the identities of only a -finite number of people. After our social sphere exceeds several dozen -or several hundred (depending on the individual), our ability to -remember and distinguish people begins to break down. In other words, -at a certain point, we can't know for sure that the person we ran into -in the produce aisle really is the same person who we met at the party -last week. - -For most of us, this limitation has not posed much of a problem in our -daily, off-line lives. With the Internet, however, we have an ability -to interact with vastly larger numbers of people than we had -before. In addition, on the Internet we lose many of our tricks for -remembering and identifying people (physical characteristics, sound of -the voice, etc.). - -Fortunately, with online communications we have easy access to tools -that can help us navigate these problems. -[OpenPGP](http://en.wikipedia.org/wiki/Openpgp) (a cryptographic -protocol commonly used for sending signed and encrypted email -messages) is one such tool. In its simplest form, it allows us to -sign our communication in such a way that the recipient can verify the -sender. - -OpenPGP goes beyond this simple use to implement a feature known as -the [web of trust](http://en.wikipedia.org/wiki/Web_of_trust). The web -of trust allows people who have never met in person to communicate -with a reasonable degree of certainty that they are who they say they -are. It works like this: Person A trusts Person B. Person B verifies -Person C's identity. Then, Person A can verify Person C's identity -because of their trust of Person B. - -The Monkeyshpere's broader goals are to extend the use of OpenPGP from -email communications to other activities, such as: - - * conclusively identifying the remote server in a remote login session - * granting access to servers to people we've never directly met -- cgit v1.2.3