341 lines
22 KiB
HTML
341 lines
22 KiB
HTML
<!--startcut ==============================================-->
|
||
<!-- *** BEGIN HTML header *** -->
|
||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
||
<HTML><HEAD>
|
||
<title>Kerberos: The watchdog of the Ether LG #82</title>
|
||
</HEAD>
|
||
<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#0000AF"
|
||
ALINK="#FF0000">
|
||
<!-- *** END HTML header *** -->
|
||
|
||
<!-- *** BEGIN navbar *** -->
|
||
<IMG ALT="" SRC="../gx/navbar/left.jpg" WIDTH="14" HEIGHT="45" BORDER="0" ALIGN="bottom"><A HREF="raghu.html"><IMG ALT="[ Prev ]" SRC="../gx/navbar/prev.jpg" WIDTH="16" HEIGHT="45" BORDER="0" ALIGN="bottom"></A><A HREF="index.html"><IMG ALT="[ Table of Contents ]" SRC="../gx/navbar/toc.jpg" WIDTH="220" HEIGHT="45" BORDER="0" ALIGN="bottom" ></A><A HREF="../index.html"><IMG ALT="[ Front Page ]" SRC="../gx/navbar/frontpage.jpg" WIDTH="137" HEIGHT="45" BORDER="0" ALIGN="bottom"></A><A HREF="http://www.linuxgazette.com/cgi-bin/talkback/all.py?site=LG&article=http://www.linuxgazette.com/issue82/shekhar.html"><IMG ALT="[ Talkback ]" SRC="../gx/navbar/talkback.jpg" WIDTH="121" HEIGHT="45" BORDER="0" ALIGN="bottom" ></A><A HREF="../lg_faq.html"><IMG ALT="[ FAQ ]" SRC="./../gx/navbar/faq.jpg"WIDTH="62" HEIGHT="45" BORDER="0" ALIGN="bottom"></A><A HREF="tougher.html"><IMG ALT="[ Next ]" SRC="../gx/navbar/next.jpg" WIDTH="15" HEIGHT="45" BORDER="0" ALIGN="bottom" ></A><IMG ALT="" SRC="../gx/navbar/right.jpg" WIDTH="15" HEIGHT="45" ALIGN="bottom">
|
||
<!-- *** END navbar *** -->
|
||
|
||
<!--endcut ============================================================-->
|
||
|
||
<TABLE BORDER><TR><TD WIDTH="200">
|
||
<A HREF="http://www.linuxgazette.com/">
|
||
<IMG ALT="LINUX GAZETTE" SRC="../gx/2002/lglogo_200x41.png"
|
||
WIDTH="200" HEIGHT="41" border="0"></A>
|
||
<BR CLEAR="all">
|
||
<SMALL>...<I>making Linux just a little more fun!</I></SMALL>
|
||
</TD><TD WIDTH="380">
|
||
|
||
|
||
<center>
|
||
<BIG><BIG><STRONG><FONT COLOR="maroon">Kerberos: The watchdog of the Ether</FONT></STRONG></BIG></BIG><BR>
|
||
<STRONG>By <A HREF="mailto:rajshekhar3007@yahoo.co.in">Raj Shekhar</A></STRONG></BIG>
|
||
|
||
</TD></TR>
|
||
</TABLE>
|
||
<P>
|
||
|
||
<!-- END header -->
|
||
|
||
|
||
|
||
|
||
<h2>Introduction</h2>
|
||
<p>The first computer networks were used to send e-mails and share files and printers
|
||
between researchers and corporate employees. In such a scenario security was
|
||
not given much thought. Now the computer networks (especially the Internet)
|
||
are used by millions for banking, shopping and filing their tax returns, and
|
||
network security has become a major problem. Network security can be divided
|
||
into four areas.
|
||
<dl>
|
||
<dt><STRONG>Secrecy</STRONG> </dt>
|
||
<dd>Secrecy has to do with keeping information out of the reach of nosy unauthorized
|
||
people. </dd>
|
||
<dt><STRONG>Authentication</STRONG></dt>
|
||
<dd>Authentication deals with determining the identity of the communication
|
||
partner, whether it/he/she is an impostor or the real thing. </dd>
|
||
<dt><STRONG>Non repudiation</STRONG></dt>
|
||
<dd>Non repudiation deals with signatures: it uniquely identifies the sender
|
||
of a message or file. How can you prove that the order for "10 million left
|
||
shoes only" came from your customer when he claims he ordered "10 right shoes
|
||
only". </dd>
|
||
<dt><STRONG>Integrity control</STRONG></dt>
|
||
<dd>Integrity control assures that vital data has not been modified. Integrity
|
||
is critical for conducting commerce over the Internet. Without assured integrity,
|
||
purchase orders, contracts, specifications, or stock purchase orders could
|
||
be modified with devastating effects. </dd>
|
||
</dl>
|
||
<h2>Need for Authentication</h2>
|
||
<p> Why do we need an authentication service? An authentication service verifies
|
||
the identity of the communication partner. Authentication is a fundamental building
|
||
block of a secure network environment. If a server knows for certain the identity
|
||
of its client, it can decide whether to provide it a particular service (for
|
||
example.. printing facility) or not, whether to give the user special privileges etc. As
|
||
an aside authentication and <em>authorization</em> are different. If user Foo
|
||
says <em> "delete file bar"</em>, then the problem of verifying whether the
|
||
command came from Foo is authentication. The problem of verifying whether Foo
|
||
has permission to delete file bar is authorization. </p>
|
||
<p> Let's take an example of Alice, who wishes to deal with Bob, her banker. In real
|
||
life Bob and Alice can authenticate each other by recognizing each others faces,
|
||
voices or handwriting . However if they wish to transact over network none of
|
||
these options are available. How can Bob be sure that the request to transfer
|
||
all of Alice's money to a secret Swiss bank account came from Alice and not
|
||
from Eve? </p>
|
||
<p>This is where an authentication service comes in. Alice starts by sending out
|
||
a message to Bob. As these messages are being sent, we have Eve, an intruder,
|
||
who may intercept, modify or replay the messages to trick Alice and Bob or just
|
||
to throw a spanner in the works. Nevertheless when the authentication is
|
||
complete, Alice
|
||
is sure she is talking to Bob and Bob is sure that he is talking to Alice. </p>
|
||
<h2>Enter Kerberos</h2>
|
||
<p>Kerberos was created by MIT as a solution to network security problems. It
|
||
has its roots in Project Athena, started in 1983. The aim of Project Athena
|
||
was to create an educational computing environment built around high-performance
|
||
graphic workstations, high speed networking, and servers of various types. Project
|
||
Athena used Kerberos as its authentication system. The name Kerberos comes from
|
||
Greek mythology; it is the three-headed dog that guarded the entrance to Hades.
|
||
The Kerberos protocol uses strong cryptography so that a client can prove its
|
||
identity to a server (and vice verse) across an insecure network connection.
|
||
After a client and server have used Kerberos to prove their identity, they can
|
||
also encrypt all of their communications to assure privacy and data integrity
|
||
as they go about their business. </p>
|
||
<p>From
|
||
<a title="http://web.mit.edu/Kerberos/www/ " href="http://web.mit.edu/Kerberos/www/">
|
||
http://web.mit.edu/Kerberos/www/</a>
|
||
<blockquote><em>
|
||
Many of the protocols used in the Internet do not provide any security.
|
||
Tools to "sniff" passwords off the network are in common use by systems crackers.
|
||
Thus, applications which send an unencrypted password over the network are extremely
|
||
vulnerable. Worse yet, other client/server applications rely on the client program
|
||
to be "honest" about the identity of the user who is using it .Other applications
|
||
rely on the client to restrict its activities to those which it is allowed to
|
||
do, with no other enforcement by the server.</em> </blockquote>
|
||
|
||
<p> The original design and implementation of Kerberos Versions 1 through 4 was
|
||
the work of two former Project Athena staff members, Steve Miller of Digital
|
||
Equipment Corporation and Clifford Neuman (now at the Information Sciences Institute
|
||
of the University of Southern California), along with Jerome Saltzer, Technical
|
||
Director of Project Athena, and Jeffrey Schiller, MIT Campus Network Manager.
|
||
Many other members of Project Athena have also contributed to the work on Kerberos.
|
||
The latest version of Kerberos 4 from MIT is patch level 10.It is officially
|
||
considered "dead" by MIT; all current development is concentrated on Kerberos
|
||
5. The latest version of Kerberos 5 is 1.2.1. </p>
|
||
<h2>Some Keywords First </h2>
|
||
<p> The art of devising ciphers is known as <strong>cryptography</strong> and
|
||
breaking them is known as <strong>cryptanalysis</strong>; together they are
|
||
known as <strong>cryptology </strong>. The message to be encrypted is known
|
||
as <strong>plaintext</strong> or <strong>cleartext</strong>. The plaintext is
|
||
encrypted by using a function, which takes as a parameter a <strong>key</strong>.
|
||
The output of the encryption process is known as <strong>ciphertext </strong>.When
|
||
ciphertext is put through a <strong> decryption function</strong>, we get back
|
||
the plaintext. Going back to our story of Alice and Bob, they (Alice and Bob)
|
||
are sometimes referred to as <strong>principals</strong>, the main characters
|
||
of the story. </p>
|
||
<p> Traditionally, the encryption key is same as the decryption key. The key is
|
||
known only to the principals. Such a key is known as <strong>shared secret
|
||
key</strong>. However in a cypto system proposed by Diffie and Hellman
|
||
(researchers
|
||
at Stanford University) in 1976, the encryption and decryption keys are
|
||
different. The
|
||
key to be used for encryption is made public so that messages to be sent to
|
||
that user can be encrypted using the publicly available key. This key is known
|
||
as the <strong> public key</strong>. Each user also has a <strong>private key
|
||
</strong>,known only to the user, which is used for decrypting messages sent
|
||
to the user. This system is known as <strong>public-key cryptography </strong>,
|
||
to contrast with shared-key cryptography. The RSA algorithm is an example of
|
||
public-key cryptography. </p>
|
||
<h2>And Some More ...</h2>
|
||
<p> Before describing the authentication process, it is important to remove ambiguities
|
||
in the terms to be used. </p>
|
||
<p> Often network applications are made of two parts,
|
||
<ul>
|
||
<li>the part which requests a service, called the client side of the application
|
||
</li>
|
||
<li>the part which provides the service, called the server side of the application
|
||
</li>
|
||
</ul>
|
||
In a sense, every entity that uses the Kerberos system is a client. To distinguish
|
||
between the Kerberos client and the client of a service, the client using the
|
||
Kerberos service is known as a <strong>Kerberos client</strong>. The term <strong>application
|
||
server</strong> refers to the server part of the application, that the clients
|
||
communicate with using Kerberos for authentication.
|
||
<p></p>
|
||
<p> Kerberos is a trusted <strong>third party authentication system</strong>. It
|
||
is trusted in the sense that each of its client believes the judgment of the
|
||
Kerberos' as to the identity of each of its other client to be accurate. To
|
||
prove to the application server that it (Kerberos client) is trusted by the
|
||
Kerberos server, it uses a <strong>ticket </strong>.In order for the Kerberos
|
||
client to use any application server, a ticket is required. The server examines
|
||
the ticket to verify the identity of the user. If all checks out, then the client
|
||
is accepted. Along with a ticket an <strong>authenticator</strong> is also used
|
||
by a Kerberos client to prove its identity. The authenticator contains the additional
|
||
information which, when compared against that in the ticket proves that the
|
||
client presenting the ticket is the same one to which the ticket was issued.
|
||
</p>
|
||
<p>Kerberos maintains a database of its clients and their private keys for authentication.
|
||
Because Kerberos knows these private keys, it can create messages which convince
|
||
one client that another is really who it claims to be. The designers did not
|
||
expect the entire world to trust a single database, so they made provision for
|
||
having different <strong>realms</strong>. The realm is an administrative entity
|
||
that maintains authentication data. Each organization wishing to run a Kerberos
|
||
server establishes its own "realm". </p>
|
||
<h2>And Now the Details </h2>
|
||
<p> Kerberos assumes that the Kerberos clients are not trustworthy and requires
|
||
the client to identify itself every time a service is requested from some other
|
||
Kerberos client. The technique used by Kerberos are unobtrusive. Kerberos follows
|
||
the following guidelines:
|
||
<ul>
|
||
<li>Passwords are never sent across the network in cleartext. They are always
|
||
encrypted. Additionally, passwords are never stored on Kerberos clients or
|
||
server in cleartext.</li>
|
||
<li>Every client has a password i.e. every application server, user, Kerberos client
|
||
has a password.</li>
|
||
<li>The <em>only </em> entity that knows all the password is the Kerberos server
|
||
and it operates under considerable physical security. </li>
|
||
</ul>
|
||
<p> Both the client and the application server are required to have keys registered
|
||
with the authentication server (AS). If the client is a user, his key is derived
|
||
from a password that he chooses; the key for a service (for example. a printing daemon)
|
||
is a randomly selected key. These keys are negotiated during the registration
|
||
of the clients. </p>
|
||
The authentication process proceeds as follows:
|
||
<ol>
|
||
<li>A client sends a request to the authentication server requesting "credentials"
|
||
for a given application server. The credentials consist of a ticket for the
|
||
server and a session key. The ticket contains, along with other fields, the
|
||
name of the server, the name of the client, the Internet address of the client,
|
||
a timestamp, a lifetime, and session key. This information (the ticket) is
|
||
encrypted using the key of the server for which the ticket will be used.
|
||
Once the ticket has been issued, it may be used multiple times by the named client
|
||
to gain access to the named server, until the ticket expires.
|
||
<blockquote><em> Why is a timestamp included? The timestamp is put to prevent
|
||
someone else from copying the ticket and using it to impersonate the Kerberos
|
||
client at a later time. This type of attack is known as a r<strong>eplay</strong>.
|
||
Because
|
||
clocks don't always work in perfect synchrony, a small amount of leeway
|
||
(about five minutes is typical) is given between the timestamp and the current
|
||
time. </em> </blockquote>
|
||
</li>
|
||
<li>The AS responds with these credentials (the ticket and the session key),
|
||
encrypted in the client's key. The AS also includes its name in the credentials
|
||
to convince the Kerberos client that the decryption by the server was
|
||
successful
|
||
and the message came from the server.
|
||
<blockquote><em> The AS does not know whether the client is actually the principal
|
||
which initiated the request for a the ticket. It simply sends a reply without
|
||
knowing or caring whether they are the same. This is acceptable because
|
||
nobody but the Kerberos client whose identity was given in the request will
|
||
be able to use the reply. Its critical information is encrypted in that
|
||
principal's key. </em> </blockquote>
|
||
</li>
|
||
<li>The Kerberos client decrypts the credentials using its key to extract the
|
||
session key. Note that because the ticket is encrypted in the key of the application
|
||
server, a Kerberos client cannot decrypt it.</li>
|
||
<li>In order to gain access to the application server, the Kerberos client builds
|
||
an authenticator containing the client<6E>s name and IP address, and the current
|
||
time. The authenticator is then encrypted in the session key that was received
|
||
with the ticket for the server. The client then sends the authenticator along
|
||
with the ticket to the server. </li>
|
||
<li> The service decrypts the ticket with its own key, extracting the session
|
||
key and the identity of the Kerberos client which the server sent it inside
|
||
the ticket. It then opens the authenticator with the session key. The authenticator
|
||
and the ticket demonstrate the identity of the client. </li>
|
||
<li> The session key (now shared by the client and application server) is used
|
||
to authenticate the client, and may optionally be used to authenticate the
|
||
server. It may also be used to encrypt further communication between the two
|
||
parties or to exchange a separate sub-session key to be used to encrypt further
|
||
communication. </li>
|
||
</ol>
|
||
<h3>The Ticket Granting Ticket</h3>
|
||
<p>One of the goals of the Kerberos system is to remain as unobtrusive as
|
||
possible. In the above exchange, the Kerberos client has to enter in a password every time
|
||
it has to decrypt the credentials passed to it by the AS . If the Kerberos client
|
||
is a user it becomes quite irritating to enter his password to have a file
|
||
printed or whenever he wants modify a file on the network (remember that the
|
||
key is derived from the user's password). The obvious way around this is to
|
||
cache the key derived from the password. But caching the key is dangerous. With
|
||
a copy of this key, an attacker could impersonate the user at any time (until
|
||
the password is next changed). </p>
|
||
<p>Kerberos resolves this problem by introducing a new agent, called the ticket
|
||
granting server (TGS). The TGS is logically distinct from the AS, although they
|
||
may reside on the same physical machine. (They are often referred to collectively
|
||
as the KDC--the Key Distribution Center). The function of the TGS is as follows.
|
||
Before accessing any regular service, the user requests a ticket to contact
|
||
the TGS, just as if it were any other service. This usually occurs when the
|
||
user first logins into the system. This ticket is called the ticket granting
|
||
ticket (TGT). After receiving the TGT, any time that the user wishes to contact
|
||
a service, he requests a ticket not from the AS, but from the TGS. Furthermore,
|
||
the reply is encrypted not with the user's secret key, but with the session
|
||
key that the AS provided for use with the TGS. Inside that reply is the new
|
||
session key for use with the regular service. The rest of the exchange now continues
|
||
as described above. The TGT is good only for a fairly short period, typically
|
||
eight hours. </p>
|
||
<h3>Cross Realm Authentication</h3>
|
||
<p>
|
||
The Kerberos protocol is designed to operate across organizational
|
||
boundaries. A client in one organization can be authenticated to a
|
||
server in another. Each organization wishing to run a Kerberos
|
||
server establishes its own "realm". The name of the realm in which a
|
||
client is registered is part of the client's name, and can be used by
|
||
the application server to decide whether to honor a request.
|
||
</p>
|
||
<p> By establishing "inter-realm" keys, the administrators of two realms can allow
|
||
a client authenticated in the local realm to use its authentication remotely
|
||
The exchange of inter-realm keys registers the ticket-granting service of each
|
||
realm as a principal in the other realm. A client is then able to obtain a ticket-granting
|
||
ticket for the other realm's ticket-granting service from its local realm. When
|
||
that ticket-granting ticket is used, the other ticket-granting service uses
|
||
the inter-realm key (which usually differs from its own normal TGS key) to decrypt
|
||
the ticket-granting ticket, and is thus certain that it was issued by the client's
|
||
own TGS. Tickets issued by the remote ticket- granting service will indicate
|
||
to the end-service that the client was authenticated from another realm.
|
||
</p>
|
||
<h2>Conclusion</h2>
|
||
<p>Kerberos is not a one-shot solution to the network security problem.Trust is inherent
|
||
throughout the system: the client trusts Kerberos, if it correctly provides the client's
|
||
encryption key.The application trusts the client if the client successfully provides a
|
||
ticket that is encrypted using the server's key.In this trust lies the weakness of the system.
|
||
|
||
<p>Specifically speaking, secret keys should be kept just that, secret. If an intruder somehow
|
||
steals a principal's key, it will be able to impersonate the principal. "Password guessing"
|
||
attacks are not solved by Kerberos. If a user chooses a poor password, it is possible for an
|
||
attacker to successfully mount an dictionary attack.Kerberos makes no provisions for client's
|
||
security; it assumes that it is running on trusted clients with an untrusted network. If the
|
||
client's security is compromised, then Kerberos is compromised as well. However, the degree to
|
||
which Kerberos is compromised depends on the host that is compromised. If an attacker breaks
|
||
into a multi-user machine and steals all of the tickets stored on that machine, he can
|
||
impersonate the users who have tickets stored on that machine .... but only until those
|
||
tickets expire.
|
||
</p>
|
||
|
||
|
||
|
||
|
||
<!-- *** BEGIN bio *** -->
|
||
<P>
|
||
<H4><IMG ALIGN=BOTTOM ALT="" SRC="../gx/note.gif">Raj Shekha</H4>
|
||
<EM>I have completed my Bachelor in Information Technology from University
|
||
of Delhi. I have been a Linux fan since the time I read "Unix Network
|
||
Programming" by Richard Stevens and started programming in Linux in my seventh
|
||
semaster . I have been trying to convert people right,left and center ever
|
||
since. I live at
|
||
<A HREF="http://geocities.com/lunatech3007">http://geocities.com/lunatech3007</A>.</EM>
|
||
|
||
<!-- *** END bio *** -->
|
||
|
||
<!-- *** BEGIN copyright *** -->
|
||
<hr>
|
||
<CENTER><SMALL><STRONG>
|
||
|
||
Copyright © 2002, Raj Shekhar.
|
||
Copying license <A HREF="../copying.html">http://www.linuxgazette.com/copying.html</A><BR>
|
||
Published in Issue 82 of <i>Linux Gazette</i>, September 2002</H5>
|
||
</STRONG></SMALL></CENTER>
|
||
<!-- *** END copyright *** -->
|
||
<HR>
|
||
|
||
<!--startcut ==========================================================-->
|
||
<CENTER>
|
||
<!-- *** BEGIN navbar *** -->
|
||
<IMG ALT="" SRC="../gx/navbar/left.jpg" WIDTH="14" HEIGHT="45" BORDER="0" ALIGN="bottom"><A HREF="raghu.html"><IMG ALT="[ Prev ]" SRC="../gx/navbar/prev.jpg" WIDTH="16" HEIGHT="45" BORDER="0" ALIGN="bottom"></A><A HREF="index.html"><IMG ALT="[ Table of Contents ]" SRC="../gx/navbar/toc.jpg" WIDTH="220" HEIGHT="45" BORDER="0" ALIGN="bottom" ></A><A HREF="../index.html"><IMG ALT="[ Front Page ]" SRC="../gx/navbar/frontpage.jpg" WIDTH="137" HEIGHT="45" BORDER="0" ALIGN="bottom"></A><A HREF="http://www.linuxgazette.com/cgi-bin/talkback/all.py?site=LG&article=http://www.linuxgazette.com/issue82/shekhar.html"><IMG ALT="[ Talkback ]" SRC="../gx/navbar/talkback.jpg" WIDTH="121" HEIGHT="45" BORDER="0" ALIGN="bottom" ></A><A HREF="../lg_faq.html"><IMG ALT="[ FAQ ]" SRC="./../gx/navbar/faq.jpg"WIDTH="62" HEIGHT="45" BORDER="0" ALIGN="bottom"></A><A HREF="tougher.html"><IMG ALT="[ Next ]" SRC="../gx/navbar/next.jpg" WIDTH="15" HEIGHT="45" BORDER="0" ALIGN="bottom" ></A><IMG ALT="" SRC="../gx/navbar/right.jpg" WIDTH="15" HEIGHT="45" ALIGN="bottom">
|
||
<!-- *** END navbar *** -->
|
||
</CENTER>
|
||
</BODY></HTML>
|
||
<!--endcut ============================================================-->
|