crypto/external/bsd/heimdal/dist/doc/whatis.texi

   1 @c Id
   2 @c $NetBSD: whatis.texi,v 1.1.1.3 2014/04/24 12:45:27 pettai Exp $
   3
   4 @node What is Kerberos?, Building and Installing, Introduction, Top
   5 @chapter What is Kerberos?
   6
   7 @quotation
   8 @flushleft
   9         Now this Cerberus had three heads of dogs,
  10         the tail of a dragon, and on his back the
  11         heads of all sorts of snakes.
  12         --- Pseudo-Apollodorus Library 2.5.12
  13 @end flushleft
  14 @end quotation
  15
  16 Kerberos is a system for authenticating users and services on a network.
  17 It is built upon the assumption that the network is ``unsafe''.  For
  18 example, data sent over the network can be eavesdropped and altered, and
  19 addresses can also be faked.  Therefore they cannot be used for
  20 authentication purposes.
  21 @cindex authentication
  22
  23 Kerberos is a trusted third-party service.  That means that there is a
  24 third party (the kerberos server) that is trusted by all the entities on
  25 the network (users and services, usually called @dfn{principals}).  All
  26 principals share a secret password (or key) with the kerberos server and
  27 this enables principals to verify that the messages from the kerberos
  28 server are authentic.  Thus trusting the kerberos server, users and
  29 services can authenticate each other.
  30
  31 @section Basic mechanism
  32
  33 @ifinfo
  34 @macro sub{arg}
  35 <\arg\>
  36 @end macro
  37 @end ifinfo
  38
  39 @iftex
  40 @macro sub{arg}
  41 @textsubscript{\arg\}
  42 @end macro
  43 @end iftex
  44
  45 @ifhtml
  46 @macro sub{arg}
  47
  48 @html
  49 <sub>\arg\</sub>
  50 @end html
  51
  52 @end macro
  53 @end ifhtml
  54
  55 @c ifdocbook
  56 @c macro sub{arg}
  57 @c docbook
  58 @c <subscript>\arg\</subscript>
  59 @c end docbook
  60 @c end macro
  61 @c end ifdocbook
  62
  63 @quotation
  64 @strong{Note} This discussion is about Kerberos version 4, but version
  65 5 works similarly.
  66 @end quotation
  67
  68 In Kerberos, principals use @dfn{tickets} to prove that they are who
  69 they claim to be. In the following example, @var{A} is the initiator of
  70 the authentication exchange, usually a user, and @var{B} is the service
  71 that @var{A} wishes to use.
  72
  73 To obtain a ticket for a specific service, @var{A} sends a ticket
  74 request to the kerberos server. The request contains @var{A}'s and
  75 @var{B}'s names (along with some other fields). The kerberos server
  76 checks that both @var{A} and @var{B} are valid principals.
  77
  78 Having verified the validity of the principals, it creates a packet
  79 containing @var{A}'s and @var{B}'s names, @var{A}'s network address
  80 (@var{A@sub{addr}}), the current time (@var{t@sub{issue}}), the lifetime
  81 of the ticket (@var{life}), and a secret @dfn{session key}
  82 @cindex session key
  83 (@var{K@sub{AB}}). This packet is encrypted with @var{B}'s secret key
  84 (@var{K@sub{B}}).  The actual ticket (@var{T@sub{AB}}) looks like this:
  85 (@{@var{A}, @var{B}, @var{A@sub{addr}}, @var{t@sub{issue}}, @var{life},
  86 @var{K@sub{AB}}@}@var{K@sub{B}}).
  87
  88 The reply to @var{A} consists of the ticket (@var{T@sub{AB}}), @var{B}'s
  89 name, the current time, the lifetime of the ticket, and the session key, all
  90 encrypted in @var{A}'s secret key (@{@var{B}, @var{t@sub{issue}},
  91 @var{life}, @var{K@sub{AB}}, @var{T@sub{AB}}@}@var{K@sub{A}}). @var{A}
  92 decrypts the reply and retains it for later use.
  93
  94 @sp 1
  95
  96 Before sending a message to @var{B}, @var{A} creates an authenticator
  97 consisting of @var{A}'s name, @var{A}'s address, the current time, and a
  98 ``checksum'' chosen by @var{A}, all encrypted with the secret session
  99 key (@{@var{A}, @var{A@sub{addr}}, @var{t@sub{current}},
 100 @var{checksum}@}@var{K@sub{AB}}). This is sent together with the ticket
 101 received from the kerberos server to @var{B}.  Upon reception, @var{B}
 102 decrypts the ticket using @var{B}'s secret key.  Since the ticket
 103 contains the session key that the authenticator was encrypted with,
 104 @var{B} can now also decrypt the authenticator. To verify that @var{A}
 105 really is @var{A}, @var{B} now has to compare the contents of the ticket
 106 with that of the authenticator. If everything matches, @var{B} now
 107 considers @var{A} as properly authenticated.
 108
 109 @c (here we should have some more explanations)
 110
 111 @section Different attacks
 112
 113 @subheading Impersonating A
 114
 115 An impostor, @var{C} could steal the authenticator and the ticket as it
 116 is transmitted across the network, and use them to impersonate
 117 @var{A}. The address in the ticket and the authenticator was added to
 118 make it more difficult to perform this attack.  To succeed @var{C} will
 119 have to either use the same machine as @var{A} or fake the source
 120 addresses of the packets. By including the time stamp in the
 121 authenticator, @var{C} does not have much time in which to mount the
 122 attack.
 123
 124 @subheading Impersonating B
 125
 126 @var{C} can hijack @var{B}'s network address, and when @var{A} sends
 127 her credentials, @var{C} just pretend to verify them. @var{C} can't
 128 be sure that she is talking to @var{A}.
 129
 130 @section Defence strategies
 131
 132 It would be possible to add a @dfn{replay cache}
 133 @cindex replay cache
 134 to the server side.  The idea is to save the authenticators sent during
 135 the last few minutes, so that @var{B} can detect when someone is trying
 136 to retransmit an already used message. This is somewhat impractical
 137 (mostly regarding efficiency), and is not part of Kerberos 4; MIT
 138 Kerberos 5 contains it.
 139
 140 To authenticate @var{B}, @var{A} might request that @var{B} sends
 141 something back that proves that @var{B} has access to the session
 142 key. An example of this is the checksum that @var{A} sent as part of the
 143 authenticator. One typical procedure is to add one to the checksum,
 144 encrypt it with the session key and send it back to @var{A}.  This is
 145 called @dfn{mutual authentication}.
 146
 147 The session key can also be used to add cryptographic checksums to the
 148 messages sent between @var{A} and @var{B} (known as @dfn{message
 149 integrity}).  Encryption can also be added (@dfn{message
 150 confidentiality}). This is probably the best approach in all cases.
 151 @cindex integrity
 152 @cindex confidentiality
 153
 154 @section Further reading
 155
 156 The original paper on Kerberos from 1988 is @cite{Kerberos: An
 157 Authentication Service for Open Network Systems}, by Jennifer Steiner,
 158 Clifford Neuman and Jeffrey I. Schiller.
 159
 160 A less technical description can be found in @cite{Designing an
 161 Authentication System: a Dialogue in Four Scenes} by Bill Bryant, also
 162 from 1988.
 163
 164 These documents can be found on our web-page at
 165 @url{http://www.pdc.kth.se/kth-krb/}.