25.02.2013 Views

TCP/IP Tutorial and Technical Overview - IBM Redbooks

TCP/IP Tutorial and Technical Overview - IBM Redbooks

TCP/IP Tutorial and Technical Overview - IBM Redbooks

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

After the server has validated a client, an option exists for the client to validate<br />

the server. This prevents an intruder from impersonating the server. The<br />

client requires then that the server sends back a message containing the time<br />

stamp (from the client's authenticator, with one added to the time stamp<br />

value). This message is enciphered using the session key that was passed<br />

from the client to the server.<br />

Let us summarize some of the central points in this scheme:<br />

► In order for the workstation to use any end server, a ticket is required. All<br />

tickets, other than the first ticket (also called the initial ticket), are obtained<br />

from the TGS. The first ticket is special; it is a ticket for the TGS itself <strong>and</strong> is<br />

obtained from the Kerberos authentication server.<br />

► Every ticket is associated with a session key that is assigned every time a<br />

ticket is allocated.<br />

► Tickets are reusable. Every ticket has a lifetime, typically eight hours. After a<br />

ticket has expired, you have to identify yourself to Kerberos again, entering<br />

your login name <strong>and</strong> password.<br />

► Unlike a ticket, which can be reused, a new authenticator is required every<br />

time the client initiates a new connection with a server. The authenticator<br />

carries a time stamp within it, <strong>and</strong> the authenticator expires a few minutes<br />

after it is issued. (This is the reason why clocks must be synchronized<br />

between clients <strong>and</strong> servers.)<br />

► A server maintains a history of previous client requests for which the time<br />

stamp in the authenticator is still valid. This way, a server can reject duplicate<br />

requests that might arise from a stolen ticket <strong>and</strong> authenticator.<br />

22.11.4 Kerberos database management<br />

Kerberos needs a record of each user <strong>and</strong> service in its realm <strong>and</strong> each record<br />

keeps only the needed information, as follows:<br />

► Principal identifier (c,s)<br />

► Private key for this principal (K c ,K s )<br />

► Date of expiration for this identity<br />

► Date of the last modification in this record<br />

► Identity of the principal that last modified this record (c,s)<br />

► Maximum lifetime of tickets to be given to this principal (lifetime)<br />

► Attributes (unused)<br />

► Implementation data (not visible externally)<br />

The private key field is enciphered using a master key so that removing the<br />

database will not cause any problem because the master key is not in it.<br />

870 <strong>TCP</strong>/<strong>IP</strong> <strong>Tutorial</strong> <strong>and</strong> <strong>Technical</strong> <strong>Overview</strong>

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!