1178825Sdfr@c $Id: whatis.texi 16769 2006-02-27 12:26:50Z joda $ 272445Sassar 355682Smarkm@node What is Kerberos?, Building and Installing, Introduction, Top 455682Smarkm@chapter What is Kerberos? 555682Smarkm 655682Smarkm@quotation 755682Smarkm@flushleft 855682Smarkm Now this Cerberus had three heads of dogs, 955682Smarkm the tail of a dragon, and on his back the 1055682Smarkm heads of all sorts of snakes. 1155682Smarkm --- Pseudo-Apollodorus Library 2.5.12 1255682Smarkm@end flushleft 1355682Smarkm@end quotation 1455682Smarkm 1555682SmarkmKerberos is a system for authenticating users and services on a network. 1655682SmarkmIt is built upon the assumption that the network is ``unsafe''. For 1755682Smarkmexample, data sent over the network can be eavesdropped and altered, and 1855682Smarkmaddresses can also be faked. Therefore they cannot be used for 1955682Smarkmauthentication purposes. 2055682Smarkm@cindex authentication 2155682Smarkm 2255682SmarkmKerberos is a trusted third-party service. That means that there is a 2355682Smarkmthird party (the kerberos server) that is trusted by all the entities on 2455682Smarkmthe network (users and services, usually called @dfn{principals}). All 2555682Smarkmprincipals share a secret password (or key) with the kerberos server and 2655682Smarkmthis enables principals to verify that the messages from the kerberos 2755682Smarkmserver are authentic. Thus trusting the kerberos server, users and 2855682Smarkmservices can authenticate each other. 2955682Smarkm 3055682Smarkm@section Basic mechanism 3155682Smarkm 3255682Smarkm@ifinfo 3355682Smarkm@macro sub{arg} 3455682Smarkm<\arg\> 3555682Smarkm@end macro 3655682Smarkm@end ifinfo 3755682Smarkm 3855682Smarkm@tex 3955682Smarkm@def@xsub#1{$_{#1}$} 4055682Smarkm@global@let@sub=@xsub 4155682Smarkm@end tex 4255682Smarkm 4355682Smarkm@ifhtml 4455682Smarkm@macro sub{arg} 45178825Sdfr@html 46178825Sdfr<sub>\arg\</sub> 47178825Sdfr@end html 4855682Smarkm@end macro 4955682Smarkm@end ifhtml 5055682Smarkm 51178825Sdfr@c ifdocbook 52178825Sdfr@c macro sub{arg} 53178825Sdfr@c docbook 54178825Sdfr@c <subscript>\arg\</subscript> 55178825Sdfr@c end docbook 56178825Sdfr@c end macro 57178825Sdfr@c end ifdocbook 58178825Sdfr 5955682Smarkm@quotation 60178825Sdfr@strong{Note} This discussion is about Kerberos version 4, but version 6155682Smarkm5 works similarly. 6255682Smarkm@end quotation 6355682Smarkm 6455682SmarkmIn Kerberos, principals use @dfn{tickets} to prove that they are who 6555682Smarkmthey claim to be. In the following example, @var{A} is the initiator of 6655682Smarkmthe authentication exchange, usually a user, and @var{B} is the service 6755682Smarkmthat @var{A} wishes to use. 6855682Smarkm 6955682SmarkmTo obtain a ticket for a specific service, @var{A} sends a ticket 7055682Smarkmrequest to the kerberos server. The request contains @var{A}'s and 7155682Smarkm@var{B}'s names (along with some other fields). The kerberos server 7255682Smarkmchecks that both @var{A} and @var{B} are valid principals. 7355682Smarkm 7455682SmarkmHaving verified the validity of the principals, it creates a packet 7555682Smarkmcontaining @var{A}'s and @var{B}'s names, @var{A}'s network address 7655682Smarkm(@var{A@sub{addr}}), the current time (@var{t@sub{issue}}), the lifetime 7755682Smarkmof the ticket (@var{life}), and a secret @dfn{session key} 7855682Smarkm@cindex session key 7955682Smarkm(@var{K@sub{AB}}). This packet is encrypted with @var{B}'s secret key 8055682Smarkm(@var{K@sub{B}}). The actual ticket (@var{T@sub{AB}}) looks like this: 8155682Smarkm(@{@var{A}, @var{B}, @var{A@sub{addr}}, @var{t@sub{issue}}, @var{life}, 8255682Smarkm@var{K@sub{AB}}@}@var{K@sub{B}}). 8355682Smarkm 8455682SmarkmThe reply to @var{A} consists of the ticket (@var{T@sub{AB}}), @var{B}'s 8555682Smarkmname, the current time, the lifetime of the ticket, and the session key, all 8655682Smarkmencrypted in @var{A}'s secret key (@{@var{B}, @var{t@sub{issue}}, 8755682Smarkm@var{life}, @var{K@sub{AB}}, @var{T@sub{AB}}@}@var{K@sub{A}}). @var{A} 8855682Smarkmdecrypts the reply and retains it for later use. 8955682Smarkm 9055682Smarkm@sp 1 9155682Smarkm 9255682SmarkmBefore sending a message to @var{B}, @var{A} creates an authenticator 9355682Smarkmconsisting of @var{A}'s name, @var{A}'s address, the current time, and a 9455682Smarkm``checksum'' chosen by @var{A}, all encrypted with the secret session 9555682Smarkmkey (@{@var{A}, @var{A@sub{addr}}, @var{t@sub{current}}, 9655682Smarkm@var{checksum}@}@var{K@sub{AB}}). This is sent together with the ticket 9755682Smarkmreceived from the kerberos server to @var{B}. Upon reception, @var{B} 9855682Smarkmdecrypts the ticket using @var{B}'s secret key. Since the ticket 9955682Smarkmcontains the session key that the authenticator was encrypted with, 10055682Smarkm@var{B} can now also decrypt the authenticator. To verify that @var{A} 10155682Smarkmreally is @var{A}, @var{B} now has to compare the contents of the ticket 10255682Smarkmwith that of the authenticator. If everything matches, @var{B} now 10355682Smarkmconsiders @var{A} as properly authenticated. 10455682Smarkm 10555682Smarkm@c (here we should have some more explanations) 10655682Smarkm 10755682Smarkm@section Different attacks 10855682Smarkm 10955682Smarkm@subheading Impersonating A 11055682Smarkm 11155682SmarkmAn impostor, @var{C} could steal the authenticator and the ticket as it 11255682Smarkmis transmitted across the network, and use them to impersonate 11355682Smarkm@var{A}. The address in the ticket and the authenticator was added to 11455682Smarkmmake it more difficult to perform this attack. To succeed @var{C} will 11555682Smarkmhave to either use the same machine as @var{A} or fake the source 11655682Smarkmaddresses of the packets. By including the time stamp in the 11755682Smarkmauthenticator, @var{C} does not have much time in which to mount the 11855682Smarkmattack. 11955682Smarkm 12055682Smarkm@subheading Impersonating B 12155682Smarkm 12255682Smarkm@var{C} can hijack @var{B}'s network address, and when @var{A} sends 12355682Smarkmher credentials, @var{C} just pretend to verify them. @var{C} can't 12455682Smarkmbe sure that she is talking to @var{A}. 12555682Smarkm 126178825Sdfr@section Defence strategies 12755682Smarkm 12855682SmarkmIt would be possible to add a @dfn{replay cache} 12955682Smarkm@cindex replay cache 13055682Smarkmto the server side. The idea is to save the authenticators sent during 13155682Smarkmthe last few minutes, so that @var{B} can detect when someone is trying 13255682Smarkmto retransmit an already used message. This is somewhat impractical 13355682Smarkm(mostly regarding efficiency), and is not part of Kerberos 4; MIT 13455682SmarkmKerberos 5 contains it. 13555682Smarkm 13655682SmarkmTo authenticate @var{B}, @var{A} might request that @var{B} sends 13755682Smarkmsomething back that proves that @var{B} has access to the session 13855682Smarkmkey. An example of this is the checksum that @var{A} sent as part of the 13955682Smarkmauthenticator. One typical procedure is to add one to the checksum, 14055682Smarkmencrypt it with the session key and send it back to @var{A}. This is 14155682Smarkmcalled @dfn{mutual authentication}. 14255682Smarkm 14355682SmarkmThe session key can also be used to add cryptographic checksums to the 14455682Smarkmmessages sent between @var{A} and @var{B} (known as @dfn{message 14555682Smarkmintegrity}). Encryption can also be added (@dfn{message 14655682Smarkmconfidentiality}). This is probably the best approach in all cases. 14755682Smarkm@cindex integrity 14855682Smarkm@cindex confidentiality 14955682Smarkm 15055682Smarkm@section Further reading 15155682Smarkm 15255682SmarkmThe original paper on Kerberos from 1988 is @cite{Kerberos: An 15355682SmarkmAuthentication Service for Open Network Systems}, by Jennifer Steiner, 15455682SmarkmClifford Neuman and Jeffrey I. Schiller. 15555682Smarkm 15655682SmarkmA less technical description can be found in @cite{Designing an 15755682SmarkmAuthentication System: a Dialogue in Four Scenes} by Bill Bryant, also 15855682Smarkmfrom 1988. 15955682Smarkm 16055682SmarkmThese documents can be found on our web-page at 16155682Smarkm@url{http://www.pdc.kth.se/kth-krb/}. 162