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.


http://docs.sun.com/source/820-2550/webserver_auth.html


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 environment.

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).


http://web.mit.edu/


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 ticket2. Ticket for TGS3. Request for Server ticket4. Ticket for Server5. 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 library2. encryption library3. database library4. database administration programs5. administration server6. authentication server7. user programs8. 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 otherServices (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 KerberosA 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 2LITERATURE

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||Authenticatorc2.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.


http://forum.java.sun.com/forum.jspa?forumID=545

http://java.sun.com/j2se/1.5.0/docs/guide/security/jgss/tutorials/index.html


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 5REFERANCES & BIBLIOGRAPHY



CHAPTER 6APPENDIX A (SRS)



CHAPTER 7APPENDIX B (SDS)


Documents

SRS ori