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 ============================================================-->
|