SRS Ori

Kerberos Authentication System
CHAPTER 1
INTRODUCTION
Department of Information Technology, Vindhya Institute of Technology & Science, Indore Page 1
1.1 EVELUATION OF THE SYSTEM:
The Distributed network is an insecure place. Many of the protocols used in the Distributed
network do not provide any security. Tools to "sniff" passwords off of the network are in
common use by malicious hackers. Thus, applications which send an unencrypted password over
the network are open for attack. On other hand 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.
For that insecurity, a Kerberos are introducing. There are three main things in the distributed
network for which security are in working process i.e., I. Authentication. II. Accounting. III.
Audit. Only Authentication are in work for network security and rest of the two are drop for
future process.
1.1.1 AUTENTICATION:
Authentication is the process of determining if a user or entity is who he/she claims to be. As
mentioned there are principally three types of authentication and it is worth understanding the
two types and determining which you really need to be doing.
 One-way authentication:
One-way authentication refers to the authentication of only one end of a communication session.
For example, One-way authentication follows the flow: 1 message ( A->B) to establish identity
of A and that messages is from A, and the message is intended for B; finally the integrity &
originality of message is confirmed.
 Mutual Authentication:
The term ‘Mutual Authentication’ has been used in the literature to define where the parties
authenticate to each other within a single authentication process. Mutual authentication is
normally seen as two separate identity bindings within one authentication algorithm, but EAP
methods like AKA claim mutual authentication with a single identity binding based on joint state
held by both parties. IKE with pre-shared key also produces a mutual authentication within its
single exchange.
 Third-party authentication:
Third-party authentication allows users to log in to SGD if they have been authenticated by an
external mechanism. If you are using the SGD WebTop, the only form of third-party
authentication you can use is web server authentication. If you develop your own WebTop
applications using the SGD web services, you can use any third-party authentication mechanism.
Third-party authentication is disabled by default.
For the third party authentication in distributed network, MIT (Massachusetts Institute of
Technology) introduced Kerberos. Or can say that Kerberos is the authentication service
developed as a part of project Athena at MIT (Massachusetts Institute of Technology). In the
below section we describe about the Kerberos, how it works and all the information related to
Kerberos.
Kerberos:
Kerberos is a Greek word which means a multi headed dog, commonly three, perhaps with a
serpent’s tail, the guardian of the entrance of heads. Kerberos is a network authentication
protocol. It is designed to provide strong authentication for client/server applications by using
secret-key cryptography. A free implementation of this protocol is available from the
Massachusetts Institute of Technology. Kerberos was created by MIT as a solution to these
network security problems. The Kerberos protocol uses strong cryptography so that a client can
prove its identity to a server (and vice versa) across an insecure network connection. After a
client and server has 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. Kerberos is
a trusted third-party authentication service based on the model presented by Needham and
Schroeder. It is trusted in the sense that each of its clients believes Kerberos’ judgment as to the
identity of each of its other clients to be accurate. Timestamps (large numbers representing the
current date and time) have been added to the original model to aid in the detection of replay.
Replay occurs when a message is stolen off the network and resent later.
 Kerberos is authentication services designed for the use in a distributed environ-

ment.
 Kerberos makes use of a trusted third-part authentication service that enables client
and servers to establish authenticated and communication.
In any case, an authorized user may be able to gain access to services and data that he or she is
not authorized to access. Rather than building in elaborate authentication protocols at each
server, Kerberos provides a centralized authentication server whose function is to authenticate
user to servers and server to users. Kerberos relies exclusively on symmetric encryption, making
no use of public-key encryption.
If a set of users is provided with dedicated personal computers that have no network connections,
then a user's resources and files can be protected by physically securing each personal computer.
When these users instead are served by a centralized time-sharing system, the time-sharing
operating system must provide the security. The operating system can enforce access control
policies based on user identity and use the logon procedure to identify users. Today, neither of
these scenarios is typical. More common is a distributed architecture consisting of dedicated user
workstations (clients) and distributed or centralized servers. In this environment, three
approaches to security can be envisioned:
1. Rely on each individual client workstation to assure the identity of its user or users and rely on
each server to enforce a security policy based on user identification (ID).
2. Require that client systems authenticate themselves to servers, but trust the client system
concerning the identity of its user.
3. Require the user to prove his or her identity for each service invoked. Also require that servers
prove their identity to clients.
The first published report on Kerberos [STEI88] listed the following requirements:
• Secure: A network eavesdropper should not be able to obtain the necessary information
to impersonate a user. More generally, Kerberos should be strong enough that a potential
opponent does not find it to be the weak link.
• Reliable: For all services that rely on Kerberos for access control, lack of availability of
the Kerberos service means lack of availability of the supported services. Hence,
Kerberos should be highly reliable and should employ distributed server architecture,
with one system able to back up another.
• Transparent: Ideally, the user should not be aware that authentication is taking place,
beyond the requirement to enter a password.
Java Kerberos System consists of three different components: a Key Distribution Center (KDC),
Kerberos Client(s) and Application Server(s). The KDC represents the heart of the Kerberos
system. It maintains a database of Kerberos Clients and Application Servers within its realm, as
well as it issues Kerberos Ticket Granting Tickets (TGT) to its clients. It consists of an
Authentication Server (AS) and a Ticket Granting Server (TGS), which are both running on the
same machine, whereas the Kerberos Client(s) and the Application Server(s) could be distributed
across the network. The architecture of the Java Kerberos System is presented on Figure 1.
How does Kerberos work:
This part of the article will explain the mechanisms behind Kerberos: ticket exchange principles,
Key Distribution Center (termed KDC), and authentication mechanisms. Kerberos was
developed with authentication in mind, and not authorization (or accounting). In fact, Kerberos
could be compared to some supreme service that tells others: "yes, you can trust me, and this
person is the one she claims to be".
A commonly found description for Kerberos is "a secure, single sign on, trusted third party
mutual authentication service". It doesn't store any information about UIDs, GIDs, or home's
path. In order to propagate this information to hosts, you will eventually need yellow page
services: NIS, LDAP.
Getting the Initial Ticket
When the user walks up to a workstation, only one piece of information can prove her/his
identity: the user’s password. The initial exchange with the authentication server is designed to
minimize the chance that the password will be compromised, while at the same time not allowing
a user to properly authenticate her/himself without knowledge of that password. The process of
logging in appears to the user to be the same as logging in to a timesharing system. Behind the
scenes, though, it is quite different.
Figure 1.2. Getting the Initial Ticket.
The user is prompted for her/his username. Once it has been entered, a request is sent to the
authentication server containing the user’s name and the name of a special service known as the
ticket-granting service.
The authentication server checks that it knows about the client. If so, it generates a random
session key which will later be used between the client and the ticket-granting server. It then
creates a ticket for the ticket-granting server which contains the client’s name, the name of the
ticket-granting server, the current time, a lifetime for the ticket, the client’s IP address, and the
random session key just created. This is all encrypted in a key known only to the ticket granting
server and the authentication server. The authentication server then sends the ticket, along with a
copy of the random session key and some additional information, back to the client. This
response is encrypted in the client’s private key, known only to Kerberos and the client, which is
derived from the user’s password.
Once the response has been received by the client, the user is asked for her/his password. The
password is converted to a DES key and used to decrypt the response from the authentication
server. The ticket and the session key, along with some of the other information, are stored for
future use, and the user’s password and DES key are erased from memory. Once the exchange
has been completed, the workstation possesses information that it can use to prove the identity of
its user for the lifetime of the ticket-granting ticket. As long as the software on the workstation
had not been previously tampered with, no information exists that will allow someone else to
impersonate the user beyond the life of the ticket.
Requesting a Service:
For the moment, let us pretend that the user already has a ticket for the desired server. In order to
gain access to the server, the application builds an authenticator containing the client’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 in a manner defined by the individual application. Once the authenticator and
ticket have been received by the server, the server decrypts the ticket, uses the session key
included in the ticket to decrypt the authenticator, compares the information in the ticket with
that in the authenticator, the IP address from which the request was received, and the present
time. If everything Matches, it allows the request to proceed.
Figure 1.3. Requesting a Service.
It is assumed that clocks are synchronized to within several minutes. If the time in the request is
too far in the future or the past, the server treats the request as an attempt to replay a previous
request. The server is also allowed to keep track of all past requests with timestamps that are still
valid. In order to further foil replay attacks, a request received with the same ticket and
timestamp as one already received can be discarded.
Getting Server Tickets
Recall that a ticket is only good for a single server. As such, it is necessary to obtain a separate
ticket for each service the client wants to use. Tickets for individual servers can be obtained from
the ticket-granting service. Since the ticket-granting service is itself a service, it makes use of the
service access protocol. When a program requires a ticket that has not already been requested, it
sends a request to the ticket-granting server. The request contains the name of the server for
which a ticket is requested, along with the ticket-granting ticket and an authenticator built.
Figure 1.4. Getting a Server Ticket.
The ticket-granting server then checks the authenticator and ticket-granting ticket as described
above. If valid, the ticket-granting server generates a new random session key to be used
between the client and the new server. It then builds a ticket for the new server containing the
client’s name, the server name, the current time, the client’s IP address and the new session key
it just generated. The lifetime of the new ticket is the minimum of the remaining life for the
ticket-granting ticket and the default for the service. The ticket-granting server then sends the
ticket, along with the session key and other information, back to the client. This time, however,
the reply is encrypted in the session key that was part of the ticket-granting ticket. This way,
there is no need for the user to enter her/his password again
1. Request for TGS ticket

2. Ticket for TGS
3. Request for Server ticket

4. Ticket for Server
5. Request for service
Figure 1.5. Kerberos Authentication Protocols.
Software Components
The Athena implementation comprises several modules (see Figure 1). The Kerberos
applications library provides an interface for application clients and application servers. It
contains, among others, routines for creating or reading authentication requests, and the routines
for creating safe or private messages.
1. Kerberos applications library

2. encryption library
3. database library
4. database administration programs
5. administration server
6. authentication server
7. user programs
8. applications
Encryption in Kerberos is based on DES, the Data Encryption Standard. The encryption library
implements those routines. Several methods of encryption are provided, with tradeoffs between
speed and security. An extension to the DES Cypher Block Chaining (CBC) mode, called the
Propagating CBC mode, is also provided. In CBC, an error is propagated only through the
current block of the cipher, whereas in PCBC, the error is propagated throughout the message.
This renders the entire message useless if an error occurs, rather than just a portion of it. The
encryption library is an independent module, and may be replaced with other DES
implementations or a different encryption library. Another replaceable module is the database
management system. The current Athena implementation of the database library uses ndbm,
although Ingres was originally used. Other database management libraries could be used as well.
The Kerberos database needs are straightforward; a record is held for each principal, containing
the name, private key, and expiration date of the principal, along with some administrative
information. (The expiration date is the date after which an entry is no longer valid. It is usually
setto a few years into the future at registration.) Other user information, such as real name, phone
number, and so forth, is kept by another server, the Hesiod nameserver.6 This way, sensitive
information, namely passwords, can be handled by Kerberos, using fairly high security
measures; while the non-sensitive information kept by Hesiod is dealt with differently; it can, for
example, be sent unencrypted over the network. The Kerberos servers use the database library, as
do the tools for administering the database. The administration server (or KDBM server)
provides a read-write network interface to the database. The client side of the program may be
run on any machine on the network. The server side, however, must run on the machine housing
the Kerberos database in order to make changes to the database. The authentication server (or
Kerberos server), on the other hand, performs read-only operations on the Kerberos database,
namely, the authentication of principals, and generation of session keys. Since this server does
not modify the Kerberos database, it may run on a machine housing a read-only copy of the
master Kerberos database. Database propagation software manages replication of the Kerberos
database. It is possible to have copies of the database on several different machines, with a copy
of the authentication server running on each machine. Each of these slave machines receives an
update of the Kerberos database from the master machine at given intervals. Finally, there are
end-user programs for logging in to Kerberos, changing a Kerberos password, and displaying or
destroying Kerberos tickets.
As Kerberos is only dealing with Authentication, it does neither Authorization (the step of
granting or denying access to a service based on the user wishing to use it), nor Accounting
(account and session management, as well as logging): it delegates those to the services
requesting Kerberos' help for user's identification. Anyway, Kerberos being a "service" by itself,
it can partially provide such functionalities, but in a very limited range. Kerberos, being a
protocol, has many implementations, developed for different purposes:
• MIT Kerberos. The original one; comes from the Project Athena in early 90s. Due to
Exportation restrictions on cryptography technology, another implementation of Kerberos was
developed, in Sweden: Heimdal.
• Heimdal Kerberos. Is MIT Kerberos’ Swedish counterpart. Heimdal is not restricted by

exportation rules. Originally developed in Sweden, it aims to be fully compatible with MIT
Kerberos. Since MIT export restrictions were lifted in 2000, both implementations tends to
coexist on a wider scale.
• Active Directory. Not a Kerberos implementation by itself, but kind of. It’s the Microsoft's
directory, that consist of a loose Kerberos implementation with some other
Services (LDAP). It's not directly compatible with MIT and Heimdal.
Kerberos Version 4
Version 4 of Kerberos makes use of DES, in a rather elaborate protocol, to provide the
authentication service. Viewing the protocol as a whole, it is difficult to see the need for the
many elements contained therein. Therefore, we adopt a strategy used by Bill Bryant of Project
Athena and build up to the full protocol by looking first at several hypothetical dialogues. Each
successive dialogue adds additional complexity to counter security vulnerabilities revealed in the
preceding dialogue. After examining the protocol, we look at some other aspects of version 4.
In an unprotected network environment, any client can apply to any server for service. The
Obvious security risk is that of impersonation. An opponent can pretend to be another client and
obtain unauthorized privileges on server machines. To counter this threat, servers must be able to
confirm the identities of clients who request service. Each server can be required to undertake
this task for each client/server interaction, but in an open environment, this places a substantial
burden on each server.
An alternative is to use an authentication server (AS) that knows the passwords of all users and
stores these in a centralized database. In addition, the AS shares a unique secret key with each
server. These keys have been distributed physically or in some other secure manner. Consider the
following hypothetical dialogue:
The portion to the left of the colon indicates the sender and receiver; the portion to the right
indicates the contents of the message, the symbol || indicates concatenation.
(1) C AS: IDC||PC||IDV
(2) AS C: Ticket
(3) C V: IDC||Ticket
Ticket = E (Kv, [IDC||ADC||IDV])
Where,
C = client
AS = authentication server
V =server
IDC = identifier of user on C
IDV = identifier of V
PC = password of user on C
ADC = network address of C
Kv = secret encryption key shared by AS and V
In this scenario, the user logs on to a workstation and requests access to server V. The client
module C in the user's workstation requests the user's password and then sends a message to the
AS that includes the user's ID, the server's ID, and the user's password. The AS checks its
database to see if the user has supplied the proper password for this user ID and whether this user
is permitted access to server V. If both tests are passed, the AS accepts the user as authentic and
must now convince the server that this user is authentic. To do so, the AS creates a ticket that
contains the user's ID and network address and the server's ID. This ticket is encrypted using the
secret key shared by the AS and this server. This ticket is then sent back to C. Because the ticket
is encrypted, it cannot be altered by C or by an opponent. With this ticket, C can now apply to V
for service. C sends a message to V containing C's ID and the ticket. V decrypts the ticket and
verifies that the user ID in the ticket is the same as the unencrypted user ID in the message. If
these two match, the server considers the user authenticated and grants the requested service.
The ticket is encrypted to prevent alteration or forgery. The server's ID (IDV) is included in the
ticket so that the server can verify that it has decrypted the ticket properly. IDC is included in the
ticket to indicate that this ticket has been issued on behalf of C. Finally, ADC serves to counter
the following threat. An opponent could capture the ticket transmitted in message (2), then use
the name IDC and transmit a message of form (3) from another workstation. The server would
receive a valid ticket that matches the user ID and grant access to the user on that other
workstation. To prevent this attack, the AS includes in the ticket the network address from which
the original request came. Now the ticket is valid only if it is transmitted from the same
workstation that initially requested the ticket.
A Detailed Architecture of Kerberos:
Fig 1.6. A Detailed Architecture of Kerberos

A More Secure Authentication Dialogue
Although the foregoing scenario solves some of the problems of authentication in an open
network environment, problems remain. Two in particular stand out. First, we would like to
minimize the number of times that a user has to enter a password. Suppose each ticket can be
used only once. If user C logs on to a workstation in the morning and wishes to check his or her
mail at a mail server, C must supply a password to get a ticket for the mail server. If C wishes to
check the mail several times during the day, each attempt requires reentering the password. We
can improve matters by saying that tickets are reusable. For a single logon session, the
workstation can store the mail server ticket after it is received and use it on behalf of the user for
multiple accesses to the mail server. However, under this scheme it remains the case that a user
would need a new ticket for every different service. If a user wished to access a print server, a
mail server, a file server, and so on, the first instance of each access would require a new ticket
and hence require the user to enter the password. The second problem is that the earlier scenario
involved a plaintext transmission of the password [message (1)]. An eavesdropper could capture
the password and use any service accessible to the victim. To solve these additional problems,
we introduce a scheme for avoiding plaintext passwords and a new server, known as the ticket-
granting server (TGS). The new but still hypothetical scenario is as follows:
Once per user logon session:
(1) C AS: IDC||IDtgs
(2) AS C: E(Kc, Tickettgs)
Once per type of service:
(3) C TGS: IDC||IDV||Tickettgs
(3) TGS C: Ticketv
Once per service session:

(5) C V: IDC||Ticketv
Tickettgs = E(Ktgs, [IDC||ADC||IDtgs||TS1||Lifetime1])
Ticketv = E(Kv, [IDC||ADC||IDv||TS2||Lifetime2])
The new service, TGS, issues tickets to users who have been authenticated to AS. Thus, the user
first requests a ticket-granting ticket (Tickettgs) from the AS. The client module in the user
workstation saves this ticket. Each time the user requires access to a new service, the client
applies to the TGS, using the ticket to authenticate itself. The TGS then grants a ticket for the
particular service. The client saves each service-granting ticket and uses it to authenticate its user
to a server each time a particular service is requested. Let us look at the details of this scheme:
1. The client requests a ticket-granting ticket on behalf of the user by sending its user's ID
and password to the AS, together with the TGS ID, indicating a request to use the TGS
service.
2. The AS responds with a ticket that is encrypted with a key that is derived from the user's
password. When this response arrives at the client, the client prompts the user for his or
her password, generates the key, and attempts to decrypt the incoming message. If the
correct password is supplied, the ticket is successfully recovered.
Because only the correct user should know the password, only the correct user can recover the
ticket. Thus, we have used the password to obtain credentials from Kerberos without having to
transmit the password in plaintext. The ticket itself consists of the ID and network address of the
user, and the ID of the TGS. This corresponds to the first scenario. The idea is that the client can
use this ticket to request multiple service-granting tickets. So the ticket-granting ticket is to be
reusable. However, we do not wish an opponent to be able to capture the ticket and use it.
Consider the following scenario: An opponent captures the login ticket and waits until the user
has logged off his or her workstation. Then the opponent either gains access to that workstation
or configures his workstation with the same network address as that of the victim. The opponent
would be able to reuse the ticket to spoof the TGS. To counter this, the ticket includes a
timestamp, indicating the date and time at which the ticket was issued, and a lifetime, indicating
the length of time for which the ticket is valid (e.g., eight hours). Thus, the client now has a
reusable ticket and need not bother the user for a password for each new service request. Finally,
note that the ticket-granting ticket is encrypted with a secret key known only to the AS and the
TGS. This prevents alteration of the ticket. The ticket is reencrypted with a key based on the
user's password. This assures that the ticket can be recovered only by the correct user, providing
the authentication.
Some explanation of the protocol, Here is an outline of how it works:
● Kerberos authenticates principals. The principal is either a user or a service.
● Each principal is required to have its key registered with the authentication server (AS). The
key is either a value derived from the user's password, or a random value stored in a key tab file.
● In order to get initially authenticated, the client uses an authentication program, such as kinit,
to exchanges some data with AS. The client principal's key is used as an encryption key in this
exchange. If the authentication succeeds, the clients obtain a ticketgranting ticket (TGT).
● The TGT usually remains valid for several hours and is stored in a credential cache. The actual
cache type (file or memory), its location, and the data format may vary among different
authentication programs and operating systems.
● Every time when the client is going to contact some remote service, it requests a ticket from
the ticket granting server (TGS) for that service principal, using the existing TGT.
● The local credentials can be forwarded to a remote host.
Kerberos Module Overview
Kerberos Module for Java supports the following functions:
● An automated credential discovery on multiple operating systems.
● Reading of memory credential caches;
● The key tab authentication of service principals without TGT requests.
● A simplified and uniform configuration procedure for applets, web startable applications, and
serverside components.
● A simplified API for sharing credentials between two peers.
● The web authentication framework.
● Integration with custom user and logging databases through pluggable modules.
1.2 PROBLEM DEFINITION:

If you have a distributed system with multiple services being offered, using the single sign-on
capability and security provided by Kerberos, then such services cannot be accessed securely
over theinternet.IIT system is Kerberized - print service, mail service, NFS An professor wants
to access tutorials on his NFS directory, set a question paper, and print it (and also check his mail
simultaneously) from outside the campus.
Allowing access to the Kerberized services directly over the internet will compromise the
security in Kerberos. SSL is almost universally used for secure web transactions. Hence we aim
to use SSL to provide secure web based access to Kerberized services.
We aim to provide support for secured Web-based access to Kerberized services, where SSL will
be used for secure connection between the client and the web server. However, SSL provides
authentication using public key credentials, while Kerberos utilizes tickets for the same Hence,
we need a bridge between the secure Web communication using SSL and the secure Intranet
authentication using Kerberos.
1.3 PROPOSED SYSTEM:

Kerberos was initially designed at MIT as a part of Project Athena . It has been successfully
deployed as a single sign-on protocol that is designed to authenticate clients to multiple different
network services. There have been two different versions of the protocol in widely used, known
as Kerberos 4 and 5. Kerberos 5 is the most recently proposed and is a trusted third-party
authentication mechanism designed for TCP/IP networks. It uses strong symmetric cryptography
to enable secure authentication in an insecure network. Currently it is available for all major
operating systems, e.g., Linux, Microsoft Windows as well as Apple's OS X.
Furthermore, Kerberos 5 has been improved as new functionalities are added to the basic
protocol and one of these results is known as PKINIT (Public-Key Cryptography for Initial
Authentication) which modifies the basic protocol to allow public-key authentication and it
causes considerable complexity to the protocol. Regarding the security issues of Kerberos, it has
been discussed in several papers which represents possible weak points including replay attacks,
password attack against Ticket-Granting tickets or pre-authentication data, attacks against
network time protocols (Kerberos requires time synchronization) and malicious client software.
Furthermore, a guessing attack and particularly man-in-the-middle attack in PKINIT have been
discovered.
Before discussing flaws and weakness of Kerberos, an analysis of the structure of Kerberos 5,
intra- and cross-realm authentication as well as a detailed description of PKINIT will be
reviewed. I discuss the flaws and attacks on Kerberos. I focus on the attacks on the basic
protocol, Kerberos 5 without PKINIT, such as the password attack, reply attack and guessing
attack. Firstly, regarding the reply attack, I reason that it is feasible by presenting attacks on both
SMB and LDAPv3. An attacker will be able to access file shares and modify directory entries
with the victim's credentials. Some server implementations have actual weaknesses, while others
have default configurations that make the attack possible. Secondly, I show that a password
attack is feasible, thus allowing the attacker to discover weak user passwords. Pre-authentication
data are used for this attack. A replay attack is presented with the SMB protocol. This allows an
attacker to access file shares with the victim's credentials without actually knowing the password.
Lastly, in many computer systems, users are authenticated via passwords which they choose.
Unfortunately, people tend to choose easy-to-remember passwords, which are vulnerable to

guessing attacks. A malicious attacker can guess such passwords using the words in a machine-
readable dictionary. I show that Kerberos is one of many existing authentication protocols which
are vulnerable to so-called off-line guessing attacks, and I will discuss some useful guidelines to
be secure against guessing attack as well as other attacks. Based on these guidelines, I will
discuss a possible solution to enhance Kerberos protocol so that it can resist the each of attacks. I
discuss the attack on PKINIT, particularly man-in-the-middle attack, which allows an attacker to
impersonate Kerberos administrative principals Key Distribution Center (KDC) and end-servers
to a client, therefore breaching the authentication guarantees of Kerberos. It also gives the
attacker the keys that the KDC would normally generate to encrypt the service requests of this
client, hence defeating confidentiality as well, I will discuss about the possible enhancement for
scalability and reliability issues in Kerberos cross-realm operation, I provide some concluding
remarks.
CHAPTER 2
LITERATURE
SURVEY
2.1 LITERATURE SURVEY I:
2.1.1 Author Name: William Stallings.
2.1.2 Name of Book: Cryptography and Network Security Principles and Practices, Fourth
Edition.
2.1.3 ISBN No.: ISBN -13: 978-0-13-187316-2
2.1.4 Conclusion:
Kerberos is an authentication service developed as part of Project Athena at MIT. The problem
that Kerberos addresses is this: Assume an open distributed environment in which users at
workstations wish to access services on servers distributed throughout the network. We would
like for servers to be able to restrict access to authorized users and to be able to authenticate
requests for service. In this environment, a workstation cannot be trusted to identify its users
correctly to network services.
If a set of users is provided with dedicated personal computers that have no network connections,
then a user's resources and files can be protected by physically securing each personal computer.
When these users instead are served by a centralized time-sharing system, the time-sharing
operating system must provide the security. The operating system can enforce access control
policies based on user identity and use the logon procedure to identify users. Today, neither of
these scenarios is typical. More common is a distributed architecture consisting of dedicated user
workstations (clients) and distributed or centralized servers. In this environment, three
approaches to security can be envisioned:
1. Rely on each individual client workstation to assure the identity of its user or users and
rely on each server to enforce a security Policy based on user identification (ID).
2. Require that client systems authenticate themselves to servers, but trust the client system
concerning the identity of its user.
3. Require the user to prove his or her identity for each service invoked. Also require that
servers prove their identity to clients.
In a small, closed environment, in which all systems are owned and operated by a single
organization, the first or perhaps the second strategy may suffice. But in a more open
environment, in which network connections to other machines are supported, the third approach
is needed to protect user information and resources housed at the server. Kerberos supports this
third approach. Kerberos assumes a distributed client/server architecture and employs one or
more Kerberos servers to provide an authentication service.
Overview of Kerberos:
Figure 2.1. Overview of Kerberos
Kerberos Realms and Multiple Kerberi:
A full-service Kerberos environment consisting of a Kerberos server, a number of clients, and a

number of application servers requires the following:
1. The Kerberos server must have the user ID and hashed passwords of all participating users in
its database. All users are registered with the Kerberos server.
2.The Kerberos server must share a secret key with each server. All servers are registered with
the Kerberos server. Such an environment is referred to as a Kerberos realm. The concept of
realm can be explained as follows. A Kerberos realm is a set of managed nodes that share the
same Kerberos database. The Kerberos database resides on the Kerberos master computer
system, which should be kept in a physically secure room. A read-only copy of the Kerberos
database might also reside on other Kerberos computer systems. However, all changes to the
database must be made on the master computer system. Changing or accessing the contents of a
Kerberos database requires the Kerberos master password. A related concept is that of a
Kerberos principal, which is a service or user that is known to the Kerberos system. Each
Kerberos principal is identified by its principal name. Principal names consist of three parts: a
service or user name, an instance name, and a realm name Networks of clients and servers under
different administrative organizations typically constitute different realms. That is, it generally is
not practical, or does not conform to administrative policy, to have users and servers in one
administrative domain registered with a Kerberos server elsewhere. However, users in one realm
may need access to servers in other realms, and some servers may be willing to provide service
to users from other realms, provided that those users are authenticated. Kerberos provides a
mechanism for supporting such interrealm authentication. For two realms to support interrealm
authentication, a third requirement is added:
3. The Kerberos server in each interoperating realm shares a secret key with the server in the
other realm. The two Kerberos servers are registered with each other.
The scheme requires that the Kerberos server in one realm trust the Kerberos server in the other
realm to authenticate its users. Furthermore, the participating servers in the second realm must
also be willing to trust the Kerberos server in the first realm.
With these ground rules in place, we can describe the mechanism as follows (Figure 2.2): A user
wishing service on a server in another realm needs a ticket for that server. The user's client
follows the usual procedures to gain access to the local TGS and then requests a ticket-granting
ticket for a remote TGS (TGS in another realm). The client can then apply to the remote TGS for
a service-granting ticket for the desired server in the realm of the remote TGS.
The ticket presented to the remote server (Vrem) indicates the realm in which the user was
originally authenticated. The server chooses whether to honor the remote request. One problem
presented by the foregoing approach is that it does not scale well to many realms. If there are N
realms, then there must be N(N 1)/2 secure key exchanges so that each Kerberos realm can
interoperate with all other Kerberos realms.
Request for Service in Another Realm:
Fig 2.2 Request for Service in Another Realm.
The details of the exchanges illustrated in Figure 2.2 are as follows:
(1) C AS: IDc||IDtgs||TS1
(2) AS C: E(Kc, [Kc,tgs||IDtgs||TS2||Lifetime2||Tickettgs])
(3) C TGS: IDtgsrem||Tickettgs||Authenticatorc
(4) TGS C: E(Kc,tgs, [Kc,tgsrem||IDtgsrem||TS4||Tickettgsrem])
(5) C TGSrem: IDvrem||Tickettgsrem||Authenticatorc
(6) TGSrem C: E(Kc,tgsrem, [Kc,vrem||IDvrem||TS6||Ticketvrem])
(7) C Vrem: Ticketvrem||Authenticatorc

2.2 LITERATURE SURVEY II:
2.1.1 Name of website: The JAVA MONKEY
2.1.2 URL: http//:www.thejavamonkey.blogspot.com
2.1.2 Conclusion:
Client/Server Hello World in Kerberos
When I first started out with Kerberos and Java, time was running out on a project at work,
and it got thrown upon me out of the blue (dreaded scope creep!). At that point I didn't have a
clue about how even the Kerberos algorithm worked. The client put me on the spot and said
"Can you do Kerberos interop with .NET SOAP services?" - I never back down from a
challenge - in fact the satisfaction in completing something like that is one of the best parts of
my job. It was like "Yeah that should take 4-6 days. I'll just write it myself". Underneath this
calm exterior I was looking for a big hole to open up and swallow me!
Firstly, I checked the web services framework we were using and found that there was no
Kerberos support. The best answer I got from the Axis 2 community was "No, this is not
supported and we don't know of anyone doing it in Axis 2". So this meant doing everything
from the ground on up. The first step was to work out how the heck Kerberos worked, and
how to authenticate with it in Java. The first place people end up when on such a quest is
usually the Sun tutorial on JAAS and GSS. While this tutorial kind've explains the concepts
and how to do it, it is hard to get a complete picture of what you're doing. Secondly, the code
is a socket based client/server which is not useful at all, as only a lunatic would be writing
their own server communications layer in these days of NIO and SOA.
The second place is the Sun Java forum for Kerberos, which has a couple of smart people
who answer a lot of questions, but I found their responses more often. This article is my take
on a Kerberos "Hello World" client/server in a more applicable way to modern systems. I
changed the concept slightly to suit my needs - that is, it needed to be the foundation for a
SOAP inter-operable system. Instead of using socket communications, my code base-64
encodes the Kerberos service ticket and writes it to a file. Subsequently, when the server is
run, it opens that file, reads the base-64 string and decodes it to a service ticket which is then
used to initiate the Kerberos context/session. When sending Kerberos tickets over SOAP they
are base-64 encoded, hence my implementation. Once the security context has been
initialized, the server determines the client who made the request and prints "Hello World!”
An intended 'feature' of my blogs is that I will include fully working projects and code with
them that should run straight out of the box. Below you can find a downloadable source
distribution of my Net Beans project that includes compiled classes, and .bat files for running
the client and server. All that needs to be done before running is to re-configure the
properties files to work with your domain/KDC.
The code is fairly straight-forward, and I've commented it heavily. Points to note for newbie’s
are:
1. JSP is used to login at both the client and server sides. Once you have successfully logged in
via JSP, you get a subject which contains all your secret keys that the KDC gave you after
logging in. These keys are used to encrypt and decrypt tickets that are only meant for you. Only
you and the KDC know your secret keys, hence only you can decrypt tokens meant for you.
2. When the JSP login is performed in the client, the ticket that is retrieved (and placed into your
subject) is the TGT (ticket granting ticket). This is required to then subsequently request a
service ticket for accessing a service. Additionally, when the server logs in, it gets its own TGT
and a set of keys which are used to decode the incoming service ticket.
3. The call to initSecContext() in the Client is the act of requesting a service ticket. The raw byte
array that this returns is the service ticket. This contains the client principal user name and a
session key that only the client, server and KDC know about. The ticket is encrypted by the KDC
4. The security context initation and acceptance are privileged actions. This means that they can
only be performed by the identity with the correct credentials/keys to do so. In the examples, the
code subject.doAs() is how this is implemented. The subject that is passed in as a parameter is
used to decode whatever token is being accepted or used.
5. The Code
krb5Oid = new Oid( "1.2.840.113554.1.2.2");
Instructs the Java APIs that the security mechanism you are wanting to use is Kerberos version 5.
6. In my examples, request Mutual Auth is always turned off, so that there is only one token sent
from client to server to initiate and accept a security context. This is different from the Sun
tutorial in that many passes can be made. In web service security, it is a big hassle if more than
one pass is required to initiate the context, as the SOAP message may be asynchronous or
atomic.
7. The GSS API that you will often see mentioned is the best means of doing Kerberos
authentication in Java. GSS stands for Generic Security Services API. It provides a generic way
of performing security/authentication services that does not tie you down to a specific
implementation (e.g. Kerberos). The benefit of using it here, other than being able to use a
different security mechanism is that it makes interoperability with.
2.3 LITERATURE SURVEY III:
2.3.1 NAME OF WEBSITE: MIT KERBEROS

2.3.2 URL: http://www.mit.edu/kerberos/survey;
2.3.3 CONCLUSION:
The Kerberos protocol is designed to provide reliable authentication over open and insecure
networks where communications between the hosts belonging to it may be intercepted. However,
one should be aware that Kerberos does not provide any guarantees if the computers are being
used are vulnerable: the authentication servers, application servers and clients must be kept
constantly updated so that the authenticity of the requesting users and service providers can be
guaranteed.
The above points justify the sentence: "Kerberos is an authentication protocol for trusted hosts
on entrusted networks". By way of example, and to reiterate the concept: Kerberos' strategies are
useless if someone who obtains privileged access to a server, can copy the file containing the
secret key. Indeed, the intruder will put this key on another machine, and will only have to obtain
a simple spoof DNS or IP address for that server to appear to clients as the authentic server.
Before describing the elements that make up the Kerberos authentication system and looking at
its operation, some of the aims the protocol wishes to achieve are listed below:
• The user's password must never travel over the network;

• The user's password must never be stored in any form on the client machine: it must be
immediately discarded after being used;
• The user's password should never be stored in an unencrypted form even in the
authentication server database;
• The user is asked to enter a password only once per work session. Therefore users can
transparently access all the services they are authorized for without having to re-enter the
password during this session. This characteristic is known as Single Sign-On;
• Authentication information management is centralized and resides on the authentication
server. The application servers must not contain the authentication information for their
users. This is essential for obtaining the following results:
1. The administrator can disable the account of any user by acting in a single
location without having to act on the several application servers providing the
various services;
2. When a user changes its password, it is changed for all services at the same time;
3. There is no redundancy of authentication information which would otherwise
have to be safeguarded in various places;
• Not only do the users have to demonstrate that they are who they say, but, when
requested, the application servers must prove their authenticity to the client as well. This
characteristic is known as Mutual authentication;
• Following the completion of authentication and authorization, the client and server must
be able to establish an encrypted connection, if required. For this purpose, Kerberos
provides support for the generation and exchange of an encryption key to be used to
encrypt data.
Ticket:
A ticket is something a client presents to an application server to demonstrate the authenticity of

its identity. Tickets are issued by the authentication server and are encrypted using the secret key
of the service they are intended for. Since this key is a secret shared only between the
authentication server and the server providing the service, not even the client which requested
the ticket can know it or change its contents. The main information contained in a ticket
includes:
• The requesting user's principal (generally the username);

• The principal of the service it is intended for;
• The IP address of the client machine from which the ticket can be used. In Kerberos 5
this field is optional and may also be multiple in order to be able to run clients under
NAT or multihomed.
• The date and time (in timestamp format) when the tickets validity commences;
• The ticket's maximum lifetime
• The session key (this has a fundamental role which is described below);
Each ticket has an expiration (generally 10 hours). This is essential since the authentication
server no longer has any control over an already issued ticket. Even though the realm
administrator can prevent the issuing of new tickets for a certain user at any time, it cannot
prevent users from using the tickets they already possess. This is the reason for limiting the
lifetime of the tickets in order to limit any abuse over time.
Tickets contain a lot of other information and flags which characterize their behavior, but we
won't go into that here. We'll discuss tickets and flags again after seeing how the authentication
system works.
Encryption:
As you can see Kerberos often needs to encrypt and decrypt the messages (tickets and
authenticators) passing between the various participants in the authentication. It is important to
note that Kerberos uses only symmetrical key encryption (in other words the same key is used to
encrypt and decrypt). Certain projects (e.g. pkinit) are active for introducing a public key system
in order to obtain the initial user authentication through the presentation of a private key
corresponding to a certified public key, but since there is no standard we'll skip this discussion
for now.
Encryption type:
Kerberos 4 implements a single type of encryption which is DES at 56 bits. The weaknesses of
this encryption plus other protocol vulnerabilities have made Kerberos 4 obsolete. Version 5 of
Kerberos, however, does not predetermine the number or type of encryption methodologies
supported. It is the task of each specific implementation to support and best negotiate the various
types of encryption. However, this flexibility and expandability of the protocol has accentuated
interoperability problems between the various implementations of Kerberos 5. In order for
clients and application and authentication servers using different implementations to

interoperate, they must have at least one encryption type in common. The difficulty related to the
interoperability between Unix implementations of Kerberos 5 and the one present in the Active
Directory of Windows is a classic example of this. Indeed, Windows Active Directory supports a
limited number of encryptions and only had DES at 56 bits in common with Unix. This required
keeping the latter enabled, despite the risks being well known, if interoperability had to be
guaranteed. The problem was subsequently solved with version 1.3 of MIT Kerberos 5. This
version introduced RC4-HMAC support, which is also present in Windows and is more secure
than DES. Among the supported encryptions (but not by Windows) the triple DES (3DES) and
newer AES128 and AES256 are worth mentioning.
Encryption key:
As stated above, one of the aims of the Kerberos protocol is to prevent the user's password from
being stored in its unencrypted form, even in the authentication server database. Considering that
each encryption algorithm uses its own key length, it is clear that, if the user is not to be forced to
use a different password of a fixed size for each encryption method supported, the encryption
keys cannot be the passwords. For these reasons the string2key function has been introduced,
which transforms an unencrypted password into an encryption key suitable for the type of
encryption to be used. This function is called each time a user changes password or enters it for
authentication. The string2key is called a hash function, meaning that it is irreversible: given that
an encryption key cannot determine the password which generated it (unless by brute force).
Famous hashing algorithms are MD5 and CRC32.
Key Distribution Center (KDC):
We have spoken generically about the authentication server. Since it is the fundamental object
involved in the authentication of users and services, we will now take a more in-depth look at it
without going into all the details of its operation. The authentication server in a Kerberos
environment, based on its ticket distribution function for access to the services, is called Key
Distribution Center or more briefly KDC. Since it resides entirely on a single physical server (it
often coincides with a single process) it can be logically considered divided into three parts:
Database, Authentication Server (AS) and Ticket Granting Server (TGS).
Database:
The database is the container for entries associated with users and services. We refer to an entry
by using the principal (i.e. the name of the entry) even if often the term principal is used as a
synonym for entry. Each entry contains the following information:
• The principal to which the entry is associated;

• The encryption key and related kvno;
• The maximum validity duration for a ticket associated to the principal;
• The maximum time a ticket associated to the principal may be renewed (only Kerberos
5);
• The attributes or flags characterizing the behavior of the tickets;
• The password expiration date;

• The expiration date of the principal, after which no tickets will be issued.
In order to make it more difficult to steal the keys present in the database, the implementations
encrypt the database using the master key, which is associated with the principal K/M@REALM.
Even any database dumps, used as backups or for propagation from the KDC master towards the
slave, are encrypted using this key, which it is necessary to know in order to reload them.
Authentication Server (AS):
The Authentication Server is the part of the KDC which replies to the initial authentication
request from the client, when the user, not yet authenticated, must enter the password. In
response to an authentication request, the AS issues a special ticket known as the Ticket Granting
Ticket, or more briefly TGT, the principal associated with which is krbtgt/REALM@REALM. If
the users are actually who they say they are (and we'll see later how they demonstrate this) they
can use the TGT to obtain other service tickets, without having to re-enter their password.
Ticket Granting Server (TGS)
The Ticket Granting Server is the KDC component which distributes service tickets to clients
with a valid TGT, guaranteeing the authenticity of the identity for obtaining the requested
resource on the application servers. The TGS can be considered as an application server (given
that to access it it is necessary to present the TGT) which provides the issuing of service tickets
as a service. It is important not to confuse the abbreviations TGT and TGS: the first indicates a
ticket and the second a service.
Session Key:
As we have seen, the users and services share a secret with the KDC. For users, this secret is the
key derived from their password, while for services, it is their secret key (set by the
administrator). These keys are called long term, since they do not change when the work session
changes. However, it is necessary that the user also shares a secret with the service, at least for
the time in which a client has a work session open on a server: this key, generated by the KDC
when a ticket is issued, is called the Session Key. The copy intended for the service is enveloped
by the KDC in the ticket (in any case their application server knows the long term key and can
decode it and extract the session key), while the copy intended for the user is encapsulated in an
encrypted packet with the user long term key. The session key plays a fundamental role in
demonstrating the authenticity of the user which we will see in the following paragraph.
Authenticator:
Even if the user principal is present in a ticket and only the application server can extract and
possibly manage such information (since the ticket is encrypted with the secret key of the
service), this is not enough to guarantee the authenticity of the client. An impostor could capture
(remember the hypothesis of an open and insecure network) the ticket when it is sent by a
legitimate client to the application server, and at an opportune time, send it to illegitimately
obtain the service. On the other hand, including the IP addresses of the machine from where it is
possible to use it is not very useful: it is known that in an open and insecure network addresses
are easily falsified. To solve the problem, one has to exploit the fact that the client and server, at
least during a session have the session key in common that only they know (also the KDC knows
it since it generated it, but it is trusted by definition!!!). Thus the following strategy is applied:
along with the request containing the ticket, the client adds another packet (the authenticator)
where the user principal and time stamp (its at that time) are included and encrypts it with the
session key; the server which must offer the service, upon receiving this request, unpacks the
first ticket, extracts the session key and, if the user is actually who he/she says, the server is able
to unencrypt the authenticator extracting the timestamp. If the latter differs from the server time
by less than 2 minutes (but the tolerance can be configured) then the authentication is successful.
This underlines the criticality of synchronization between machines belonging to the same realm.
Kerberos Operation
Finally, having acquired the concepts described in the preceding paragraphs, it is possible to
discuss how Kerberos operates. We'll do this by listing and describing each of the packets which
go between the client and KDC and between client and application server during authentication.
At this point, it is important to underline that an application server never communicates directly
with the Key Distribution Center: the service tickets, even if packeted by TGS, reach the service
only through the client wishing to access them. The messages we will discuss are listed below-
• AS_REQ is the initial user authentication request (i.e. made with kinit) This message is
directed to the KDC component known as Authentication Server (AS);
• AS_REP is the reply of the Authentication Server to the previous request. Basically it
contains the TGT (encrypted using the TGS secret key) and the session key (encrypted
using the secret key of the requesting user);
• TGS_REQ is the request from the client to the Ticket Granting Server (TGS) for a
service ticket. This packet includes the TGT obtained from the previous message and an
authenticator generated by the client and encrypted with the session key;
• TGS_REP is the reply of the Ticket Granting Server to the previous request. Located
inside is the requested service ticket (encrypted with the secret key of the service) and a
service session key generated by TGS and encrypted using the previous session key
generated by the AS;
• AP_REQ is the request that the client sends to an application server to access a service.
The components are the service ticket obtained from TGS with the previous reply and an
authenticator again generated by the client, but this time encrypted using the service
session key (generated by TGS);
• AP_REP is the reply that the application server gives to the client to prove it really is the
server the client is expecting. This packet is not always requested. The client requests the
server for it only when mutual authentication is necessary.
STRUCTURE OF KERBEROS:
Fig 2.3.1 Structure of Kerberos
Now each of the previous phases is described in greater detail with reference to Kerberos 5, but
pointing out the differences with version 4. Nevertheless, it should be borne in mind that the
Kerberos protocol is rather complicated and this document is not intended as a guide for those
who wish to know the exact operating details (in any case, these are already written up in
RFC1510). The discussion below has been left intentionally abstract, but sufficient for those who
examine the KDC logs to understand the various authentication transitions and any problems
which occur.
2.4 LITERATURE SURVEY IV:
2.4.1 AUTHER NAME: Atul Kahate.
2.4.2 NAME OF BOOK: Cryptography and Network Security, second edition.
2.4.3 ISBN No.: ISBN-13: 978-0-07-064823-4
2.4.4 CONCLUSION:
Many real life systems use an authentication protocol called as Kerberos. The basis for is another
protocol, called as Needham-Shroeder. Version 4 of Kerberos is found in most practical. There
are 4 parties involved in Kerberos protocol:
1. Alice: The client workstation.

2. Authentication Server(AS): Verifies (authenticates) the user during login.
3. Ticker Granting Server (TGS) : Issue tickets to certify proof of identity.
4. Bob: The server offering services such as network printing, file sharing, or an application
program.
There are 3 primary steps in the Kerberos protocol. We shall study them one by one now.
Step 1: Login To start with, Alice, the user, sits down at an arbitary public workstation and
enters her name. The work station sends her name in plain text to the AS, as shown in Fig 2.4.1.
In response, the AS performs several actions. It first creates a package of the user name (Alice)
and randomly generated session key (KS). It encrypts this package with the symmetric key that
the AS shares with the Ticket Granting Server (TGS). The output of this step is called as the
Ticket Granting Ticket (TGT).
The AS then combines the TGT with the session key (KS), and encrypts the two together using a
symmetric key derived from the password of Alice (KA).The final output can, therefore, be
opened only by Alice.
Fig 2.4.1 Alice sends a login request to AS
Fig 2.4.2 AS sends back encrypted session key and TGT to Alice
After this message is received, Alice’s workstation asks her for password. When the Alice enters
it, the workstation generate the symmetric key(KA) derived from the password and uses that key
to extract the session key (KS) and Ticket Granting Ticket (TGT). The workstation destroy the
password of Alice from it’s memory immediately, to prevent to an attacker from stealing it.
Step 2: Obtaining a service granting ticket (SGT) Now, let us assume that after a successful
login, Alice wants to make use of Bob- the email server, for some email communication. For
this, Alice would inform her workstation that she needs to contact Bob. Therefore , Alice needs a
ticket to communicate with Bob. At this juncture, Alice’s workstation creates a message intended
for the Ticket Granting Server (TGS), which contains the following items:
• The TGT as in step 1
• The id of the server (Bob) whose services Alice is interested in
The current timestamp, encrypted with the same session key (KS)
Fig 2.4.3 Alice sends a request for a SGT to the TGS
Fig 2.4.4 TGS sends response back to Alice
Step 3: User contacts Bob for accessing the server Alice can now send KAB to Bob in order
to enter into a session with him. Since this exchange is also desired to be secure, Alice can
simply forward KAB encrypted with Bob’s secret key (which she had received from the TGS in
the previous step) to Bob. This will ensure that only Bob can access KAB. Furthermore, to guard
against replay attacks, Alice also sends the timestamp, encrypted with KAB to Bob. This is
shown in fig 2.4.5.
Since only Bob has his secret key, he uses it to first obtain information (Alice + KAB). From
this, it gets the key KAB, which he uses to decrypt the encrypted timestamp value.
Now how would Alice know if Bob received KAB correctly or not? In order to satisfy this
querry, Bob now adds 1 to timestamp sent by Alice, encrypts the result with KAB and sends it
back to Alice. This is shown in fig 2.4.6. Since only Alice and Bob know KAB, Alice can open
this packet and verify that the timestamp incremented by Bob was indeed the ont sent by her to
Bob in the first place.
Now, Alice and Bob cam communicate securely with each other. They would use the shared
secret key KAB to encrypt message before sending and also to decrypt messages received from
each other.
Fig 2.4.5 Alice sends KAB securely to Bob
Fig 2.4.6 Bob acknowledges the receipt of KAB
CHAPTER 3
ANALYSIS
3.1 REQUIREMENT ANALYSIS:
3.2 USE-CASE DIAGRAM:
USE-CASE DIAGRAM I:
Fig. Interactive Domain Logon use case diagram
USE-CASE DIAGRAM II:
Fig. HTTP Access Authentication - Server use case diagram
3.3 USE-CASE DESCRIPTION: In this use case diagram the user is initiating the
Interactive Domain Logon. The client computer has been successfully authenticated and joined
to the domain infrastructure that is provided by the domain controller. After the user initiates
Interactive Domain Logon, authentication of the user's credentials takes place and, upon success,
user information is supplied. The user is initiating the task with the goal of access to local and
network resources authorized to the user. The user will provide credential material to initiate this
action, which will provide identification and proof of that identification. The domain controller
authenticates the user credentials and, if authentication is successful and the user is authorized,
user interactive domain logon will be permitted.
3.4 ACTIVITY DIAGRAM:
Activity Diagram 1:
Activity Diagram 2:
3.5 SEQUENCE DIAGRAM:
Sequence Diagram1:
Plain authentication simply compares the client ‘s password with the server’s password for
given username.
CHAPTER 4
DESIGN
4.1 SYSTEM FLOW DIAGRAM:
4.2 DATA MODEL:
4.2.1 DATA FLOW DIAGRAM (DFD):
CHAPTER 5
REFERANCES &
BIBLIOGRAPHY
CHAPTER 6
APPENDIX A (SRS)
CHAPTER 7
APPENDIX B (SDS)

SRS Ori

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

SRS Ori

Hochgeladen von

Copyright:

Verfügbare Formate

Kerberos Authentication System

1.1 EVELUATION OF THE SYSTEM:

 Kerberos is authentication services designed for the use in a distributed environ-

How does Kerberos work:

Getting the Initial Ticket

Figure 1.2. Getting the Initial Ticket.

Figure 1.3. Requesting a Service.

Getting Server Tickets

Figure 1.4. Getting a Server Ticket.

1. Request for TGS ticket

3. Request for Server ticket

Figure 1.5. Kerberos Authentication Protocols.

1. Kerberos applications library

• Heimdal Kerberos. Is MIT Kerberos’ Swedish counterpart. Heimdal is not restricted by

(1) C AS: IDC||PC||IDV

Ticket = E (Kv, [IDC||ADC||IDV])

IDC = identifier of user on C

ADC = network address of C

Kv = secret encryption key shared by AS and V

A Detailed Architecture of Kerberos:

Fig 1.6. A Detailed Architecture of Kerberos

Once per user logon session:

(1) C AS: IDC||IDtgs

(2) AS C: E(Kc, Tickettgs)

Once per type of service:

(3) C TGS: IDC||IDV||Tickettgs

(3) TGS C: Ticketv

Once per service session:

Tickettgs = E(Ktgs, [IDC||ADC||IDtgs||TS1||Lifetime1])

Ticketv = E(Kv, [IDC||ADC||IDv||TS2||Lifetime2])

Some explanation of the protocol, Here is an outline of how it works:

● Kerberos authenticates principals. The principal is either a user or a service.

● The local credentials can be forwarded to a remote host.

Kerberos Module Overview

Kerberos Module for Java supports the following functions:

● An automated credential discovery on multiple operating systems.

● Reading of memory credential caches;

● The key tab authentication of service principals without TGT requests.

● A simplified API for sharing credentials between two peers.

● The web authentication framework.

1.2 PROBLEM DEFINITION:

1.3 PROPOSED SYSTEM:

Unfortunately, people tend to choose easy-to-remember passwords, which are vulnerable to

2.1 LITERATURE SURVEY I:

2.1.1 Author Name: William Stallings.

2.1.3 ISBN No.: ISBN -13: 978-0-13-187316-2

Figure 2.1. Overview of Kerberos

Kerberos Realms and Multiple Kerberi:

A full-service Kerberos environment consisting of a Kerberos server, a number of clients, and a

Fig 2.2 Request for Service in Another Realm.

The details of the exchanges illustrated in Figure 2.2 are as follows:

(1) C AS: IDc||IDtgs||TS1

(2) AS C: E(Kc, [Kc,tgs||IDtgs||TS2||Lifetime2||Tickettgs])

(3) C TGS: IDtgsrem||Tickettgs||Authenticatorc

(4) TGS C: E(Kc,tgs, [Kc,tgsrem||IDtgsrem||TS4||Tickettgsrem])

(5) C TGSrem: IDvrem||Tickettgsrem||Authenticatorc

(6) TGSrem C: E(Kc,tgsrem, [Kc,vrem||IDvrem||TS6||Ticketvrem])

(7) C Vrem: Ticketvrem||Authenticatorc

2.1.1 Name of website: The JAVA MONKEY

2.1.2 URL: http//:www.thejavamonkey.blogspot.com

Client/Server Hello World in Kerberos

krb5Oid = new Oid( "1.2.840.113554.1.2.2");