diff options
Diffstat (limited to 'website')
| -rw-r--r-- | website/index.mdwn | 13 | ||||
| -rw-r--r-- | website/why.mdwn | 126 |
2 files changed, 133 insertions, 6 deletions
diff --git a/website/index.mdwn b/website/index.mdwn index 853c75b..652f195 100644 --- a/website/index.mdwn +++ b/website/index.mdwn @@ -9,7 +9,7 @@ yourself and the servers you administer or connect to. OpenPGP keys are tracked via GnuPG, and managed in the `known_hosts` and `authorized_keys` files used by OpenSSH for connection authentication. -[[bugs]] | [[download]] | [[news]] | [[documentation|doc]] +[[bugs]] | [[download]] | [[news]] | [[documentation|doc]] | [[why should i be interested|why]] ## Conceptual overview ## @@ -26,13 +26,14 @@ keys for authenticating to a server (known as "`PubkeyAuthentication`"), rather than relying on a password exchange. But again, the public part of the key needs to be transmitted to the server through a secure out-of-band channel (usually via a separate -password-based SSH connection) in order for this type of -authentication to work +password-based SSH connection or a (hopefully signed) e-mail to the +system administrator) in order for this type of authentication to +work. [OpenSSH](http://openssh.com/) currently provides a functional way to -managing the RSA and DSA keys required for these interactions through -the `known_hosts` and `authorized_keys` files. However, it lacks -any type of [Public Key Infrastructure +manage the RSA and DSA keys required for these interactions through +the `known_hosts` and `authorized_keys` files. However, it lacks any +type of [Public Key Infrastructure (PKI)](http://en.wikipedia.org/wiki/Public_Key_Infrastructure) that can verify that the keys being used really are the one required or expected. diff --git a/website/why.mdwn b/website/why.mdwn new file mode 100644 index 0000000..7f69614 --- /dev/null +++ b/website/why.mdwn @@ -0,0 +1,126 @@ +[[meta title="Why should you be interested in the MonkeySphere?"]] + +# Why should you be interested in the MonkeySphere? # + +## 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 do +it? 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 +lose 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? + +## As an `sshd` administrator ## + +If you are a system administrator, have you ever tried to re-key an +SSH server? How did you ease the change along to your users? How did +you keep them from getting the big scary warning messages? + +Have you ever wanted to allow a 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 revoke the ability of a key to +authenticate across the entire infrastructure you manage, without +touching each host by hand? + +## What's the connection? ## + +These questions all stem from rough edges we run up against in regular +use of SSH that could be improved by a decent [Public Key +Infrastructure (or +PKI)](http://dictionary.die.net/public%20key%20infrastructure). A PKI +at its core is a mechanism to provide answers to a few basic +questions: + +* Do we know who 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! + +## 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 +<bob@example.net>` should have access to the `bob` account. + +Bob's first connection to his new `bob` account on `foo.example.org` +is seamless, because all the steps are already in place! 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), + +* strict centralized Certificate Authorities (much like proposed X.509 + models), and + +* 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". |