doc/conferences/lca2010/outline

   1
   2
   3
   4 The presentation is in three parts:
   5
   6 Background
   7 ----------
   8
   9  * Why authentication using asymmetric crypto (as opposed to shared
  10    secrets) is important on today's network.
  11
  12  * Overview of how ssh uses asymmetric crypto authentication (user ->
  13    host, host -> user)
  14
  15  * Overview of relevant bits of OpenPGP (key -> User ID bindings,
  16    certifications, usage flags, key -> subkey bindings)
  17
  18  * Overview of keyservers (the idea of gossip, One Big Network,
  19    propagation, issues around redundancy, logging, private access)
  20
  21
  22 How
  23 ---
  24
  25  * How does the monkeysphere do it?  (very brief under-the-hood)
  26
  27  * How does a server administrator publish a host's ssh key to the Web
  28    of Trust?  How do they maintain it?
  29
  30  * How does a user incorporate WoT-based host-key checking into their
  31    regular ssh usage?
  32
  33  * How does a user publish their own ssh identity to the WoT for hosts
  34    to find it?  How do they maintain it?
  35
  36  * How does a server administrator tell a server to admit certain
  37    people (as identified by the WoT) to certain accounts?  How do they
  38    tell the server which certifications are trustworthy?
  39
  40 Possible Futures
  41 ----------------
  42
  43  * Use the Monkeysphere with ssh implementations other than OpenSSH
  44    (dropbear, lsh, putty, etc)
  45
  46  * Expansion of the Monkeysphere's out-of-band PKI mechanism for
  47    authentication in protocols other than SSH (TLS, HTTPS) without
  48    protocol modification.
  49
  50  * Use of OpenPGP certificates directly in SSH.  OpenPGP is referenced
  51    in RFC 4253 already: optional, rarely implemented, and deliberately
  52    ambiguous about how to calculate key->identity bindings.
  53
  54  * Use of OpenPGP certificates for authentication directly in
  55    protocols.  RFC 5081 provides a mechanism for OpenPGP certificates
  56    in TLS, but is similarly ambiguous about certificate verification.
  57
  58  * Better end-user control over verification: Who or what are you
  59    really connecting to?  How do you know?  How can this information
  60    be effectively and intuitively displayed to a typical user?
  61
  62  * What would you like to see?