10.0.0.21 Git - tlspool/blob - doc/kerberos.md

   1 # Kerberos and the TLS Pool
   2
   3 > *We have started to integrate Kerberos into the TLS Pool, but for now it is
   4 > a bit crude.  We haven't yet established how to distribute responsibilities.*
   5
   6 The integration of
   7 [TLS-KDH](https://tools.ietf.org/html/draft-vanrein-tls-kdh)
   8 into the TLS Pool is a major contribution towards a secure, yet fast
   9 Internet.  It combines fluently with our sub-projects on
  10 [realm crossover](http://realm-xover.arpa2.net/kerberos.html)
  11 and
  12 [bring your own identity](http://internetwide.org/blog/2015/04/22/id-2-byoid.html)
  13 combined with
  14 [authorisation](http://internetwide.org/blog/2015/04/25/id-5-ksaml.html)
  15 for privacy in spite of
  16 [hosting-market specialisation](http://internetwide.org/blog/2014/11/19/back-to-hosting.html).
  17 Yeah, we have a
  18 [pretty big plan](http://internetwide.org/blog/2016/06/24/iwo-phases.html)
  19 on where to take the Internet!
  20
  21 The matter with Kerberos is mainly who should hold the ticket cache being
  22 used.  There are two basic possibilities, it could be made internal to the
  23 TLS Pool, or it could be externally provided over a new API.
  24
  25 When we choose to use a new API for Kerberos it
  26 may or may not integrate with the user's desktop.  Very often, desktops
  27 can hold Kerberos credentials or they can easily have them added, sometimes
  28 even united with the desktop login (and screensaver-protected) session.
  29 Moreover, the desktop is the place where the user might switch the primary
  30 identity being used.
  31
  32 The alternative is to let the TLS Pool hold the Kerberos credentials for
  33 a user, and that would allow the integration of PKCS #11 in the sign-up
  34 process, which is specifically interesting in relation to PKINIT.
  35
  36 The matters that help to decide on this are:
  37
  38   * The desktop location would require the
  39     [new socket protocol](socketprotocol.rst)
  40     because Kerberos tickets can grow larger than what we have fixed-allocated.
  41   * Whether PKINIT is a good idea depends on what is the "security foundation";
  42     is it Kerberos, or is it PKCS #11 -- because each can cause the other to
  43     be created.  We should even ask ourselves if the TLS Pool should make this
  44     choice, or be supportive to both.  Desktops and mobile stations may need
  45     to make different choices, for example.
  46
  47 At present, the crude implementation of Kerberos involves using the PIN
  48 request to obtain a Kerberos password; this means that it must be entered
  49 manually *or* that the Kerberos password should match the configuration
  50 file's fixed PIN setting `pkcs11_pin`.  Clearly, the choice of layering
  51 one mechanism on top of the other has not yet been forced and so we are
  52 dealing with this kludge for now.
  53