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