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