CHAPTER-I INTRODUCTION

Kerberos gets its name from Greek mythology. Cerberus, also known as Kerberos, was a three headed beast that guarded the Underworld and kept the living from entering the world of the dead. Kerberos protocol design began in the late 1980s at the Massachusetts Institute of Technology (MIT), as part of project Athena. It is a secure authentication mechanism designed for distributed severs, which assumes the network is unsafe. It enables a client and a server to mutually authenticate before establishing a connection. The first public release was Kerberos version 4, which leads to the actual version (v5) in 1993 after a wide public review. It followed the IETF standard process and its specifications are defined in Internet RFC 1510. Originally designed for UNIX, it is now available for all major operating systems, freely from MIT or also through commercial versions. Kerberos is a computer network authentication protocol which works on the basis of "tickets" to allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner. Its designers aimed primarily at a clientserver model, and it provides mutual authenticationboth the user and the server verify each other's identity. Kerberos protocol messages are protected against eavesdropping and replay attacks. Kerberos builds on symmetric key cryptography and requires a trusted third party, and optionally may use public-key cryptography by utilizing asymmetric key cryptography during certain phases of authentication. Kerberos uses port 88 by default. "Kerberos" also refers to a suite of free software published by Massachusetts Institute of Technology (MIT) that implements the Kerberos protocol.

1.1 Motivation
If a set of users is provided with dedicated personal computers that have no network connections, then a users resources and files can be protected by physically securing each personal computer. When these users are served by a central time sharing system, the time sharing operation 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 work stations (clients) and distributed or centralized servers. In this environment, three approaches of security can be envisioned:

1. Rely on each individual client workstations 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. Requires that client systems authenticate themselves to servers, but trust the client system concerning the identity of the user. 3. Requires the user to prove identity fro each service invoked. Also requires that severs 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 by the server. The third approach is supported b Kerberos. Kerberos assumes distributed client/server architecture and employs one or more Kerberos servers to provide an authentication service.

The first published report on Kerberos [STEI88] listed the following requirements for Kerberos:

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 the 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. Scalable: The system should be capable of supporting large number of clients and servers. This suggests a modular, distributed architecture.

To support these requirements, the overall scheme of Kerberos is that of a trusted thirdparty authentication service that uses a protocol based on that proposed by Needham and Schroeder [NEED78]. It is trusted in the sense that clients and servers trust Kerberos to mediate their mutual authentication. Assuming the Kerberos protocol is well designed, then the authentication service is secure if the Kerberos server itself is secure.

1.2 How it works??:

The problem that the 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 restrict access to authorized users and to be able to authenticate requests for service. In this environment, a work station cannot be trusted to identify its users correctly to network services. In particular, the following three threats exist: A user may gain access to a particular workstation and pretend to be another user operating from that workstation. A user may alter the network address of a workstation so that the requests sent from the altered workstation appear to come from the impersonated workstation.

A user may eavesdrop on exchanges and use a reply attack to gain entrance to a server or to disrupt operations.

In any of these cases, an unauthorized 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 users to servers and servers to users. Unlike most other authentication schemes, Kerberos relies exclusively on symmetric encryption, making no use of public -key encryption. Two versions of Kerberos are in common use. Version 4 [MILL88,STEI88]is still widely used. Version 5[KOHL94] corrects some of the security deficiencies of version 4 and has been issued as a proposed Internet Standard (RFC 1510). Lets get into the working of Kerberos. The client authenticates itself to the Authentication Server (AS) which forwards the username to a Key Distribution Center (KDC). The KDC issues a Ticket Granting Ticket (TGT), which is time stamped, encrypts it using the user's password and returns the encrypted result to the user's workstation. If successful, this gives the user desktop access. When the client needs to communicate with another node ("principal" in Kerberos parlance) it sends the TGT to the Ticket Granting Service (TGS), which shares the same host as the KDC. After verifying the TGT is valid and the user is permitted to access the requested service, the TGS issues a Ticket and session keys, which are returned to the client. The client then sends the Ticket and keys to the service server (SS).

Here is another description. The client authenticates to the AS once using a long-term shared secret (e.g. a password) and receives a Ticket Granting Ticket (TGT) from the AS. Later, when the client wants to contact some SS, it can (re)use this ticket to get additional tickets from TGS, for SS, without resorting to using the shared secret. The latter tickets can be used to prove authentication to the SS. The phases are detailed below. User Client-based Logon 1. A user enters a username and password on the client machine. 2. The client performs a one-way function (hash usually) on the entered password, and this becomes the secret key of the client/user. Client Authentication 1. The client sends a clear text message of the user ID to the AS requesting services on behalf of the user. (Note: Neither the secret key nor the password is sent to the AS.) The AS generates the secret key by hashing the password of the user found at the database (e.g. Active Directory in Windows Server). 2. The AS checks to see if the client is in its database. If it is, the AS sends back the following two messages to the client:

Message A: Client/TGS Session Key encrypted using the secret key of the client/user. Message B: Ticket-Granting-Ticket (which includes the client ID, client network address, ticket validity period, and the client/TGS session key) encrypted using the secret key of the TGS.

3. Once the client receives messages A and B, it attempts to decrypt message A with the secret key generated from the password entered by the user. If the user entered password does not match the password in the AS database, the client's secret key will be different and thus unable to decrypt message A. With a valid password and secret key the client decrypts message A to obtain the Client/TGS Session Key. This session key is used for further communications with the TGS. (Note: The client cannot decrypt Message B, as it is encrypted using TGS's secret key.) At this point, the client has enough information to authenticate itself to the TGS.

Client Service Authorization 1. When requesting services, the client sends the following two messages to the TGS:

Message C: Composed of the TGT from message B and the ID of the requested service.

Message D: Authenticator (which is composed of the client ID and the timestamp), encrypted using the Client/TGS Session Key.

2. Upon receiving messages C and D, the TGS retrieves message B out of message C. It decrypts message B using the TGS secret key. This gives it the "client/TGS session key". Using this key, the TGS decrypts message D (Authenticator) and sends the following two messages to the client:

Message E: Client-to-server ticket (which includes the client ID, client network address, validity period and Client/Server Session Key) encrypted using the service's secret key.

Message F: Client/Server Session Key encrypted with the Client/TGS Session Key.

Client Service Request 1. Upon receiving messages E and F from TGS, the client has enough information to authenticate itself to the SS. The client connects to the SS and sends the following two messages:

Message E from the previous step (the client-to-server ticket, encrypted using service's secret key).

Message G: a new Authenticator, which includes the client ID, timestamp and is encrypted using Client/Server Session Key.

2. The SS decrypts the ticket using its own secret key to retrieve the Client/Server Session Key. Using the sessions key, SS decrypts the Authenticator and sends the following message to the client to confirm its true identity and willingness to serve the client:

Message H: the timestamp found in client's Authenticator plus 1, encrypted using the Client/Server Session Key.

3. The client decrypts the confirmation using the Client/Server Session Key and checks whether the timestamp is correctly updated. If so, then the client can trust the server and can start issuing service requests to the server. 4. The server provides the requested services to the client.

1.3 Example:
Lets take a look at how Kerberos goes about things. Both the user and the service are required to have keys registered with the Authentication Server. The user's key is derived from a password that he chooses; the service key is a randomly selected key (since no person is available to type in a password). Let us imagine that messages are written on paper (instead of being electronic), and are ``encrypted'' by being locked in a strongbox by means of a key. In this ``box world,'' principals are initialized by making a physical key and registering a copy of the key with the AS. 1. First the user sends a message to the AS: ``I, Samit Mehra User, would like to talk to Yahoo Server.'' 2. When the AS receives this message, it makes up two copies of a brand new key. This is called the session key. It will be used in the direct exchange between user and service. 3. It puts one of the session keys in Box 1, along with a piece of paper with the name ``Yahoo Server'' written on it. It locks this box with the user's key. Why is this piece of paper here? Let us recall that this box is really just an encrypted message, and that the session key is really just a sequence of random bytes. If Box 1 only contained the session key, then the user wouldn't be able to tell whether the response came back from the AS, or whether the decryption was successful. By putting in ``Yahoo Server,'' the user (or more precisely, the user's program) will be able to verify both that the box comes from the AS, and that the decryption was successful. 4. It puts the other session key in a Box 2, along with a piece of paper with the name ``Samit Mehra User'' written on it. It locks this box with the service's key. 5. It returns both boxes to the user. 6. The user unlocks Box 1 with his key, extracting the session key and the paper with ``Yahoo Server'' written on it.

7. The user can't open Box 2 (since it's locked with the service's key). Instead, he puts a piece of paper with the current time written on it in Box 3, and locks it with the session key. He then hands both boxes to the service. 8. The service opens the Box 2 with its own key, extracting the session key and the paper with ``Samit Mehra User'' written on it. It then opens Box 3 with the session key to extract the piece of paper with the current time on it. These items demonstrate the identity of the user. The timestamp is put in Box 3 to prevent someone else from copying Box 2 and using it to impersonate the user at a later time. Because clocks don't always work in perfect synchrony, a small amount of leeway (about five minutes is typical) is given between the timestamp and the current time. In addition, the service maintains a list of recently sent authenticators, to make sure that they aren't resent in quick order. It is wondered how the service is able to open Box 2, if there isn't anyone ``back there'' to type in a password. Well, the service key isn't derived from a password. Instead, it's randomly generated, then stored in a special file called a service key file. This file is assumed to be secure, so that no one can copy the file and impersonate the service to a legitimate user. In Kerberos parlance, Box 2 is called the ticket, and Box 3 is called the authenticator. The authenticator typically contains more information than what is listed here. Some of this added information arises from the fact that this is an electronic message (for example, there is a checksum). There may also be an encryption key in the authenticator to provide for privacy in future communications between the user and the service. Service Authentication Sometimes, the user may want the service to be authenticated in return. To do so, the service takes the timestamp from the authenticator (Box 3), places it in Box 4, along with a piece of paper with ``Yahoo Server'' written on it, locks it with the session key, and returns it to the user. (Clearly, it must include something with the timestamp; otherwise, it could simply return Box 3!)

The Ticket Granting Server There is a subtle problem with the above exchange. It is used every time a user wants to contact a service. But notice that he then has to enter in a password (unlock Box 1 with the key) each time. The obvious way around this is to cache the key derived from the password. But caching the key is dangerous. With a copy of this key, an attacker could impersonate the user at any time (until the password is next changed). Kerberos resolves this problem by introducing a new agent, called the ticket granting server (TGS). The TGS is logically distinct from the AS, although they may reside on the same physical machine. (They are often referred to collectively as the KDC--the Key Distribution Center. The function of the TGS is as follows. Before accessing any regular service, the user requests a ticket to contact the TGS, just as if it were any other service. This ticket is called the ticket granting ticket (TGT).

After receiving the TGT, any time that the user wishes to contact a service, he requests a ticket not from the AS, but from the TGS. Furthermore, the reply is encrypted not with the user's secret key, but with the session key that the AS provided for use with the TGS. Inside that reply is the new session key for use with the regular service. The rest of the exchange now continues as described above.

It's sort of like when you visit some workplaces. You show your regular ID to get a guest ID for the workplace. Now, when you want to enter various rooms in the workplace, instead of showing your regular ID over and over again, which might make it vulnerable to being dropped or stolen, you show your guest ID, which is only valid for a short time anyway. If it were stolen, you could get it invalidated and be issued a new one quickly and easily, something that you couldn't do with your regular ID. The advantage this provides is that while passwords usually remain valid for months at a time, the TGT is good only for a fairly short period, typically eight hours. Afterwards, the TGT is not usable by anyone, including the user or any attacker. This TGT, as well as any tickets that you obtain using it, are stored in the credentials cache. There are a number of commands that you can use to manipulate your own credentials cache, which we'll get to in a moment.

CHAPTER II LITERATURE SURVEY 2.1 History & Development:

MIT developed Kerberos to protect network services provided by Project Athena. The protocol was named after the character Kerberos (or Cerberus) from Greek mythology which was a monstrous three-headed guard dog of Hades. Several versions of the protocol exist; versions 13 occurred only internally at MIT. Steve Miller and Clifford Neuman, the primary designers of Kerberos version 4, published that version in the late 1980s, although they had targeted it primarily for Project Athena. Version 5, designed by John Kohl and Clifford Neuman, appeared as RFC 1510 in 1993 (made obsolete by RFC 4120 in 2005), with the intention of overcoming the limitations and security problems of version 4. MIT makes an implementation of Kerberos freely available, under copyright permissions similar to those used for BSD. In 2007, MIT formed the Kerberos Consortium to foster continued development. Founding sponsors include vendors such as Oracle, Apple

Inc., Google, Microsoft, Centrify Corporation and TeamF1 Inc., and academic institutions such as KTH-Royal Institute of Technology, Stanford University, MIT and vendors such as CyberSafe offering commercially supported versions. Authorities in the United States classified Kerberos as auxiliary military technology and banned its export because it used the DES encryption algorithm (with 56-bit keys). A non-US Kerberos 4 implementation, KTH-KRB developed at the Royal Institute of

Technology in Sweden, made the system available outside the US before the US changed its cryptography export regulations (circa2000). The Swedish implementation was based on a limited version called eBones. eBones was based on the exported MIT Bones release (stripped of both the encryption functions and the calls to them) based on version Kerberos 4 patch-level 9. Windows 2000 and later use Kerberos as their default authentication method. Some Microsoft additions to the Kerberos suite of protocols are documented in RFC

3244 "Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols". RFC 4757 documents Microsoft's use of the RC4 cipher. While Microsoft uses the Kerberos protocol, it does not use the MIT software. Many UNIX and UNIX-like operating systems, including FreeBSD, Apple's Mac OS X, Red Hat Enterprise Linux, Oracle's Solaris, IBM's AIX, HP's OpenVMS, and others, include software for Kerberos authentication of users or services. Embedded implementation of the Kerberos V authentication protocol for client agents and network services running on embedded platforms is also available from companies such as TeamF1, Inc. As of 2005, the IETF Kerberos working group is updating the specifications. Recent updates include:

Encryption and Checksum Specifications" (RFC 3961). Advanced Encryption Standard (AES) Encryption for Kerberos 5 (RFC 3962). A new edition of the Kerberos V5 specification "The Kerberos Network Authentication Service (V5)" (RFC 4120). This version obsoletes RFC 1510, clarifies aspects of the protocol and intended use in a more detailed and clearer explanation.

A new edition of the GSS-API specification "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2." (RFC 4121).

New protocol features in Version 5 In addition to the changes discussed above, several new features are supported in Version 5. Tickets Version 5 tickets contain several additional timestamps and a flags field. These changes allow greater flexibility in the use of tickets than was available in Version 4. Each ticket issued by the KDC using the initial ticket exchange is flagged as such. This allows servers such as a password changing server to require that a client present a ticket obtained by direct use of the clients secret key Kc instead of one obtained using a TGT. Such a requirement prevents an attacker from walking up to an unattended but logged in workstation and changing another users password. Tickets may be issued as renewable tickets with two expiration times, one for a time in the near future, and one later. The ticket expires as usual at the earlier time, but

if it is presented to the KDC in a renewal request before this earlier expiration time, a replacement ticket is returned which is valid for an additional period of time. The KDC will not renew a ticket beyond the second expiration indicated in the ticket. This mechanism has the advantage that although the credentials can be used for long periods of time, the KDC may refuse to renew tickets which are reported as stolen and thereby thwart their continued use. A similar mechanism is available to assist authentication during batch processing. A ticket issued as postdated and invalid will not be valid until its post-dated starting time passes and it is replaced with a validated ticket. The client validates the ticket by presenting it to the KDC as described above for renewable tickets. Authentication forwarding can be implemented by contacting the KDC with the additional ticket exchange and requesting a ticket valid for a different set of addresses than the TGT used in the request. The KDC will not issue such tickets unless the presented TGT has a flag set indicating that this is a permissible use of the ticket. When the entity on the remote host is granted only limited rights to use the authentication, the forwarded credentials are referred to as a proxy (after the proxy used in legal and financial affairs). Proxies are handled similarly to forwarded tickets, except that new proxy tickets will not be issued for a ticket granting service; they will only be issued for application server tickets. In certain situations, an application server (such as an X Window System server) will not have reliable, protected access to an encryption key necessary for normal participation as a server in the authentication exchanges. In such cases, if the server has access to a users ticket-granting ticket and associated session key (which in the case of single-user workstations may well be the case), it can send this ticket-granting ticket to the client, who presents it and the users own ticket-granting ticket to the KDC. The KDC then issues a ticket encrypted in the session key from the servers ticket-granting ticket; the application server has the proper key to decrypt and process this ticket. The details of such an exchange are presented in [Dav90].

Authorization data Kerberos is concerned primarily with authentication; it is not directly concerned with the related security functions of authorization and accounting. To support the implementation of these related functions by other services, Version 5 of Kerberos provides a mechanism for the tamperproof transmission of authorization and accounting information as part of a ticket. This information takes the form of restrictions on the use of a ticket. The encoding of each restriction

is not a concern of the Kerberos protocol, but is instead defined by the authorization or accounting mechanism in use. Restrictions are carried in the authorization data field of the ticket. When a ticket is requested, restrictions are sent to the KDC where they are inserted into the ticket, encrypted, and thus protected from tampering. In the protocols most general form, a client may request that the KDC include or add such data to a new ticket. The KDC does not remove any authorization data from a ticket; the TGS always copies it from the TGT into the new ticket, and then adds any requested additional authorization data. Upon decryption of a ticket, the authorization data is available to the application server. While Kerberos makes no interpretation of the data, the application server is expected to use the authorization data to appropriately restrict the clients access to its resources. Among other uses, the authorization data field can be used in a proxy ticket to create a capability. The client requesting the proxy from the KDC specifies any authorization restrictions in the authorization data, then securely transmits the proxy and session key to another party, which uses the ticket to obtain limited service from an application server. Neuman [Neu91] discusses possible uses of the authorization data field in detail. The Open Software Foundations Distributed Computing Environment uses the authorization data field for the generation of privilege attribute certificates (PACs). Privilege information is maintained by a privilege server. When a PAC is requested by a client the privilege server requests a Kerberos ticket identifying the privilege server itself, but restricting the groups to which the client belongs and specifying a DCE specific user ID. The ticket is then returned to the client which uses it to assert its DCE user ID and prove membership in the listed groups. In essence, the privilege server grants the client a proxy authorizing the client to act as the privilege server to assert the listed DCE user ID and membership in the listed groups. If the ticket did not include restrictions, it would indicate that the client was the privilege server, allowing the client to assert any user ID and membership in any group. Pre-authentication data In an effort to complicate the theft of passwords, the Kerberos Version 5 protocol provides fields in the initial- and additional-ticket exchanges to support password alternatives such as hand-held authenticators (devices which have internal circuitry used to generate a continually changing password). In the initial ticket exchange, these fields can be used to alter the key Kc in which the

reply is encrypted. This makes a stolen password useless since fresh information from a physical device is needed to decrypt a response. The field can also be used to prove the clients identity to the KDC before any ticket is issued. Doing this makes it a little more difficult for an attacker to obtain a message that can be used to verify password guesses. This pre-authentication data field is used by the client in the additional ticket exchange to pass the ticket granting ticket to the KDC; since it is a variable-length array, other values may be sent in the additionalticket exchange.

Subsession key negotiation Tickets are cached by clients for later use. To avoid problems caused by the reuse of a tickets session key across multiple connections, a server and client can cooperate to choose a new subsession key which is used to protect a single connection. This subsession key is discarded once the connection is closed. Negotiation of subsession keys allows an application to protect the privacy of messages broadcast to several recipients. The application can individually negotiate with each recipient to use a common subsession key before beginning the broadcasts.

Sequence numbers Kerberos provides two message formats for applications to protect their communications. The KRB_SAFE message uses a cryptographic checksum to insure data integrity. The KRB_PRIV message uses encryption to insure integrity and privacy. In Version 4 these messages included as control information a timestamp and the senders network address. With Version 5, an application may elect to use a timestamp (as before) or a sequence number. If the timestamp is used, the receiver must record the known timestamps to avoid replay attacks; if a sequence number is used the receiver must verify that the messages arrive in the proper order without gaps. There are situations where one choice makes applications simpler (or even possible) to implement; see the discussions in [Koh92].

Implementation features The base implementation The MIT implementation of the Version 5 protocols is composed of several run-time libraries with which a program may link. The core library functions will probably be used by all applications; other libraries or subsystems may be replaced or omitted as needed by an application programmer. All code is currently written in "C." The base functions: The core Kerberos library contains the routines which assemble, disassemble and interpret the network messages. This includes ASN.1 encoding and decoding functions which convert from a machines native format to the network encoding (currently based on the ISODE package, but another ASN.1 support package may be substituted), routines which verify that requests are answered as expected, and routines to determine which messages are necessary. This core set of routines calls out to the remaining portions of the library as required. A programmer may replace those portions at certain specified interfaces. Encryption routines: Since multiple encryption types may be in use simultaneously, the core functions call encryption routines through a function table which has entries provided by each encryption system implementation. The core library provides a default cryptosystem table, initialized to list the known encryption types. A programmer may load his own cryptosystem table to replace the default table and avoid linking with the default encryption libraries. In an attempt to alleviate some possible export restrictions, MITs implementation distributes its encryption systems separately from the remainder of the system. Only DES is currently available from MIT. Checksum routines: In a similar fashion to the encryption routines, the core routines call any needed checksum functions through a function table, and compute any necessary sizes based on the information in the table. Certain applications of checksum technology require that the checksum have certain properties. The table entry indicates whether the checksum is keyed (its algorithm is perturbed by an encryption key which cannot be discovered with knowledge only of the algorithm and the checksummed text) and whether the checksum is collision proof (it is computationally infeasible to discover a different checksum text which has the same checksum). The core library provides a replaceable default checksum table.

Four checksums are currently available from MIT: the CRC-32, which is neither keyed nor collision proof (but it is useful for integrity checks within encryption systems); the DES message authentication code (MAC), which is both keyed and collision proof, and MD4 [Riv92a] and MD5 [Riv92b], both of which are collision proof but not keyed. Credentials cache and key table routines: When clients store tickets and credentials in a cache, the core routines call out through a credentials cache table entry to a separate library module which implements the storing and searching routines for credentials caches. An environment variable can be used to specify the default type and location of a credentials cache, so a user can switch between different types and locations of caches as needed (perhaps to keep the credentials for two roles separate). MITs implementation provides two credentials cache implementations, one built on C.

Kerberos has been using secret key Cryptography ever since its inception. Although public key crypto-system requires calculations that are computationally expensive, it can eliminate some of Kerberos protocol limitations. First of all there is a need to maintain the secret key between every user and the KDC, between every KDC and KDC and between the Application server and the KDC . The Ticket given by the TGS is encrypted by the users Secret key. So, the KDC needs to remember every users secret key, which is a problem and has an impact on Kerberos scalability. Adding Public Key cryptography will add a completely new dimension to Kerberos scalability as it eliminates the need to establish a large number of shared secrets. Secondly, if there is an unauthorized entry into the KDCs database, even if it is a read-only access, the privacy of the users secret and the security of the KDC will be compromised. But with public key cryptography to violate the security one has to obtain the write access to the database. Different Public Key Extensions to Kerberos: There are 3 major proposals to add Public Key Cryptography to Kerberos: Public key Cryptography for Initial Authentication in Kerberos (PKINIT). Public Key Cryptography for Cross Realm Authentication in Kerberos (PKCROSS). Public Key Utilizing Tickets for Application Servers (PKTAPP).

PKINIT: PKINIT describes how Public Key Cryptography can be added to Kerberos in the Initial Authentication stages. Microsoft, Cyber safe and Heimdal adopted it in their implementations of Kerberos [5]. Figure 1 illustrates the flow of the PKINIT protocol. PKINIT requires the verification of the initial request message sent by the client to the local KDC. Any authentication requests made by intruders masquerading as legitimate users will be denied. PKINIT also requires that the TGT and the session key be encrypted so that the users credentials will remain confidential. Also, PKINIT suggests the storage of the users secret key in the KDC so as to allow the user to generate its own session key, which decreases the load on the KDC considerably.

PKCROSS: PKCROSS is a logical extension of PKINIT. If a client wants certain services form a server, which is located remotely, then there has to be an authentication procedure, which relates the KDC of the client (Local KDC) with the KDC of the server (remote KDC). The primary reason why PKCROSS is used is to manage the Cross Realm Authentication. It simplifies the multiple realm authentications. PKTAPP: The PKTAPP scheme is the one that looks into the performance aspects. The main aspect that can be observed from the previous two schemes is the role played by the KDC. The KDC issues all TGT and server tickets to the local KDC and also to the remote KDC. Most of the authentication transactions have to transit the KDC [1]. This creates a performance bottleneck at the KDC. PKTAPP provides a scheme where there is only one path of communication i.e. between the client and the server. The client sends the request message that consists of the clients certificate chain and the identity of the service ticket. The server immediately responds to the request with the response signal that consists of the servers chain and Figure 2 illustrates the flow of PKCROSS authentication. The user needs to request a cross realm TGT request from its Local KDC so that it can access the remote server. The messages exchanged between local and remote KDC is similar to PKINIT. Here the local KDC acts as a client. The local KDC sends a request comprising of the PKCROSS flag set to the remote KDC. The remote KDC replies with a PKCROSS ticket and trusts the local KDC to issue the remote realm TGT to its client on behalf of the remote KDC. the session key that is encrypted with the servers private key. The PKTAPP authentication scheme mainly reduces the number of authentication steps. Figure 3 illustrates the PKTAPP authentication message exchange. IV. Performance Analysis of Different Protocol:

The main performance comparison is observed between PKCROSS and PKTAPP. Closed, classswitching queuing models are used to demonstrate the quantitative performance which compares

the response time performance. Close queuing networks represent each system resource with a queuing discipline and a stochastic service distribution.

Authentication Process Initial secret key-based TGT request to KDC Request a ticket to the remote TGS Public key authentication between KDCS to establish a session key Request a ticket to the remote application server (all secret key encryption) Authenticate to the remote application server (all secret key encryption)

A multi-realm Kerberos environment is modeled to observed how the following parameters affected the throughput and response times of public key based authentication transactions [5]: Number of realms in the Kerberos environment, Number of application servers per realm, Loads on application servers and key distribution centers, and Network delay.

Two assumptions were taken before all operations. Firstly, the client and KDC must present certificates for authentication. Secondly, the remote server must validate the certificate signed by the local CA and certificate signed by the remote CA. All encryption operations are configured with 1024-bit RSA keys or standard DES. Table 1 shows the summary of encryption operations performed for PKCROSS and PKTAPP authentication transactions:

CHAPTER III EXISTING WORK IN THE FIELD 3.1 Application:

Single Sign On The most visible benefit to Kerberos for end users is single sign-on. The user need not sign onto each application but instead can sign onto their computer once. Kerberos accomplishes single sign-on by storing credentials that typically last approximately one work day. When the user signs onto the computer, the local Kerberos implementation contacts the Key Distribution Center (KDC) to authenticate the user to the KDC. When authentication succeeds, the KDC issues a ticket. The ticket is a time-limited message from the KDC to itself attesting to successful authentication. This ticket along with a session key known only to the local computer and the KDC forms a credential that can be used to sign onto applications. When Kerberos wishes to contact an application, it presents the ticket along with proof that the session key is known by the client to the KDC and receives a new service ticket for the application that is being contacted. This ticket along with an application-specific session key is used to securely contact the application. The KDC serves as a central point to enforce the organizations authentication policy and to enforce general policies about account management.

Security Services An effective access control policy relies on a number of security services. This section discusses the services that Kerberos provides and how these fit into application access control. Providing these services is an important goal of integrating Kerberos into an application. As such, a plan for integrating Kerberos into an application should carefully consider how these services are provided. Validating that these services are provided is essential to validating the integration of Kerberos into an application.

Authentication Authentication is the process of verifying to a sufficient degree of confidence claims about a party or message. Typically a network application needs to know some attributes, such as the name, about the party sending it messages.

Kerberos separates authentication into two phases. Initial authentication takes place between the Kerberos client and the KDC. The mechanisms used will be set by site policy; typical examples include pre-shared secrets (passwords) or smart cards. Later, though, the client authenticates to the application. As a side effect of this exchange, the client and application share a session key that may be used in subsequent, cryptographically-protected communications. Todays network applications require that both sides of a connection be authenticated in order to prevent phishing and other malicious attacks. It is just as important that a server authenticate to its clients so their access control can be maintained as it is for the clients to authenticate to the server. Fortunately, Kerberos makes mutual authentication easy. Kerberos is symmetric; any two parties that can authenticate in one way can also authenticate in the other direction.

Confidentiality and Integrity Authentication of the parties to a network exchange is not sufficient to enforce reasonable access control objectives. The contents of the message themselves need to be protected. If the messages are not protected then an attacker could modify the messages, defeating the access control policy. Kerberos provides facilities to make sure that messages are not changed as they travel across the network. The messages can optionally be encrypted so only the parties that know the session key can examine their contents.

Some applications already have a protocol layer responsible for message security. For example, applications may use Transport Layer Security (TLS, the successor to SSL) or IPsec
2

to provide message security. A technique called channel binding can be used to tie the Kerberos authentication to the message security layer so that the application has confidence that the messages are transported between the same parties that are authenticated by Kerberos.

Authorization Once Kerberos has successfully authenticated the client to the service and once appropriate security services are put in place, the client and service still need to make authorization decisions in order to meet access control objectives. What objects should the client be allowed to access? What permissions should the client have? Is the service the one that the client expected to talk to? To what extent is the service trusted by the client? All these questions are part of the authorization that the client and service need to perform.

Kerberos authenticates the client and service. In some environments, Kerberos also provides information on group membership of the client. The rest of authorization is a matter for the platform and application. The Role of Kerberos paper describes how Kerberos fits into the platforms authorization function. This paper discusses some specific issues where authorization touches on how Kerberos is integrated into the application. The section on Federation and Client Names discusses issues surrounding matching Kerberos names to application names. The section on SIDs and the PAC discusses how Microsofts Active Directory conveys group membership to a service.

Protocol Facilities for Integrating Kerberos There are two important axes that describe the approaches for integrating Kerberos. The first is the protocol facility or network messages that are used. The second is the Kerberos implementation that is used. Not all combinations are possible: not all implementations provide access to all protocol facilities. This section describes the first axis and the next section describes the implementation axis. Kerberos provides applications the flexibility to determine what network-level messages to adopt. There is very broad consistency in how applications interact with the KDC and in the initial messages a client uses to authenticate to a service. However even the message that a client uses to authenticate to a service needs to be transported in some application-specific framing. In addition, applications can adopt multiple
3

different approaches for integrity and confidentiality of user data. This section describes the three most common approaches. Raw Kerberos messages are described to establish context. They should not generally be used in new applications. The GSS-API Kerberos mechanism is the preferred way to integrate Kerberos into applications. SASL is also described because it provides a simple way to integrate GSS-API mechanisms into an application, assuming that the application fits within the constraints imposed by SASL.

Raw Kerberos The base Kerberos specification (RFC 4120) defines the underlying Kerberos message exchanges. All Kerberos applications rely on the KDC message exchanges defined in RFC 4120. Furthermore, the application authentication messages specified in this RFC are used in some form by almost all Kerberos applications. RFC 4120 also defines two messages for integrity and confidentiality of user data. The KRB_SAFE message provides an integrityprotected wrapper around user data. The KRB_PRIV message encrypts and integrity protects user data. However, outside of some special applications these messages are rarely usedbest practice is to use alternatives based on GSS-API rather than the KRB_PRIV or KRB_SAFE messages. The KRB_SAFE message is particularly problematic. A bug in early versions of MIT Kerberos produced an incorrectly formatted KRB_SAFE message. Some

implementations expect the version of the message produced by MIT Kerberos; others expect the version in the standard. As a result, KRB_SAFE interoperability is limited. Since the message is so rarely used, it has not been widely tested. In addition, there are no standard APIs for accessing these messages. As of Windows Vista, Microsoft does not provide a mechanism for user applications to produce KRB_PRIV or KRB_SAFE messages. Solaris prior to version 10 update 3 did not provide access to the raw Kerberos API, which is required to use these messages. The raw Kerberos messages do provide some flexibility that is not present in other interfaces. Applications that need to directly access Kerberos keys, or add fields not found in other interfaces may need to use the raw messages. GSS-API Mechanisms: the GSS-API and SSPI The GSS-API (RFC 2743) is a mechanism-independent facility for allowing applications to request security services such as authentication, integrity and confidentiality. The GSS-API
4

specifications focus on an API that applications can use. However, there is also a series of network protocols associated with GSS-API. Each mechanism has an associated network protocol. The Kerberos GSS-API mechanism (RFC 4121) describes messages that realize the GSS-API security services with Kerberos infrastructure. The GSS-API mechanism uses the RFC 4120 application authentication exchange with some additional framing to indicate it is a Kerberos message and to provide for some GSS-API specific options. The Kerberos GSS-API mechanism provides services similar to KRB_SAFE and KRB_PRIV, but the message formats over the network are completely different.

The GSS-API is available on most platforms today. However, even if the GSS-API is not available, GSS-API mechanisms can still be used. The message formats from the Kerberos mechanism could be built into a small, embedded system without the complexity and code space of the complete GSS-API. There are several advantages to using the GSS-API Kerberos mechanism: Good cross-platform availability, including Windows, Mac OS, Java, and most Unix variants Good interoperability between implementations Support for future extensibility within Kerberos and for other security technologies

GSS-API supports security mechanisms that take an arbitrary number of round trips for authentication of a client to a service. This allows support for negotiation of which security service to use as well as future extensibility as options are added to mechanisms. As a result, GSS-API applications exhibit a characteristic loop for the application authentication. The client generates the first message by calling GSS_Init_sec_context. The client sends this message to the server, which calls GSS_Accept_sec_context. Both GSS_Init_sec_context and GSS_Accept_sec_context provide a return value in the form of a major status. This major status instructs the application what to do next. If the function returns

GSS_S_CONTINUE_NEEDED, then the other side of the connection is expected to return another message and the loop should continue. Otherwise, the loop ends; depending on whether the status is successful or noti.e., the authentication succeeds or fails. Even if an authentication function does not return, continue needed, it may still output a message to be sent to the other party.
5

Some application protocols depend on knowing the number of round-trips authentication and security setup will take. GSS-API should still be used in these applications, but the application should restrict the set of mechanisms that are supported. The Kerberos mechanism always takes one round trip with mutual authentication enabled. If future extension to the Kerberos mechanism increase the number of round trips, then either the mechanism object identifier (OID) will change (creating a new mechanism), or extra round trips will only be used when a new optional feature is enabled. Once initial authentication succeeds, GSS-API applications can use GSS_Wrap to request integrity or confidentiality for user data. The GSS_GetMIC function requests a message integrity code that can be transported to provide integrity for data sent in application framing. As mentioned, GSS-API mechanisms can be used without the GSS-API. The Windows SSPI is a widely deployed example of this. Windows SSPI provides a Microsoft-specific API for security services. However, the Kerberos SSPI mechanism is the same as the Kerberos GSS-API mechanism. Applications that will use both the SSPI and GSS-API should avoid depending on GSS-APIs gap or duplicate token errors unless a skipped or duplicate message will be considered a fatal error. Most GSS-API implementations provide the Simple and Protected Negotiation (SPNEGO) mechanism (RFC 4178) in order to allow applications to select what security mechanism they wish to use. In order to use the SPNEGO mechanism, an application passes the object identifier naming the SPNEGO mechanism into GSS_Init_sec_context instead of the object identifier for Kerberos or the default mechanism. The GSS-API implementation will include a list of available mechanisms in the token the application sends to the service. This first token also includes a message from the mechanism that the client would prefer to use. If that mechanism is also selected by the service, the negotiation does not introduce any round trips. If the service does not select the clients preferred mechanism, then the client and service exchange a message integrity code after authentication succeeds. This protects both parties against an attacker who tries to force them to select a different security mechanism that is easier to attack. SPNEGO is available on the Windows platform via the SSPI. Callers should use the negotiate security package in order to use SPNEGO.
6

SASL SASL (RFC 4422) provides facilities for negotiating security mechanisms, authentication, and optional integrity and confidentiality. SASL works for streamoriented applications that send only one stream of bytes in each direction. For example, SASL works well for applications that send a stream of bytes over one TCP connection. It does not work well for applications that need to deal with out-of-order delivery or lost data. Many internet applications use SASL. SASL and GSS-API are complimentary technologies that work together: SASLs Kerberos support uses the GSS-API. There are actually multiple SASL mechanism families for supporting GSS-API. The oldest and most commonly used (RFC 4752) is widely implemented. A newer family (GS2) supports channel binding (see Kerberos and Other Authentication Mechanisms) but is not widely implemented. Applications that need channel binding in order to provide adequate mutual authentication should plan for an upgrade to GS2 when it becomes more readily available.

Comparing SASL and GSS-API Mechanisms Because SASL uses GSS-API to provide higher-level Kerberos support, SASL is preferable to GSS-API mechanisms as a network protocol, but only when it meets the needs of an application. The primary advantage of SASL is that it provides more structure than GSS-API and leaves fewer details to the application. For example, SASL presents a stream abstraction rather than a message abstraction and the SASL specifications provide more detail on what an application needs to do to properly use SASL. However, SASL APIs are not as well standardized as the GSS-API, and some application developers have encountered problems with generic SASL framework implementations. A good rule of thumb is, if using the GSSAPI makes more sense than using SASL for implementation reasons, then use the GSS-API. The following table provides a summary list of factors to consider when deciding which API mechanism provides the most appropriate protocol facility for a given application. Factor SASL GSS-API Mechanisms Network Profile Applications with a single stream of datae.g., one TCP connection Provides per-message services allowing applications to have multiple streams or to use datagram protocols Abstract interface Application reads and writes data similar to TCP or TLS
7

Application requests message protection and handles the details of sending data over the network Non-Kerberos mechanism support Simple passwords, challenge/response, onetimepassword .Limited availability of nonKerberos mechanisms in widelydeployed platforms API Standardization Cross-platform APIs are available and used for some applications, though standardized APIs are still evolving Widely-available standardized API

SASL and TLS SASL is often used along side TLS (or SSLv3). Many SASL mechanisms, such as simple passwords (the plain mechanism), do not provide adequate security alone. Other SASL mechanisms provide authentication but do not provide confidentiality or integrity services. In this usage pattern, the application makes both SASL and TLS available at the beginning of the connection. Only SASL mechanisms that provide appropriate security to meet access control policies are made available outside of TLS. If TLS is selected, then SASL is also available as an option after TLS completes session establishment. Typically, a larger set of mechanisms is available at this point. GSS-API mechanisms such as Kerberos that provide confidentiality and integrity should be offered before TLS session initiation. Applications should support using both a SASL security layer (integrity or confidentiality provided by SASL) at the same time as TLS. Application developers have found it challenging to support both TLS and SASL security layers in the same application. How data is written to the network depends on what security services are used. Sometimes, the data goes through TLS, sometimes through SASL and sometimes both. Several applications do not support SASL security layers as a result. When used with Kerberos and other strong mechanisms, these applications do not provide mutual authentication. For this reason, best practice today is to support SASL security layers even though there is extra complexity. As channel binding becomes more widely available, best practice will likely evolve to use channel binding and not to use SASL security layers in applications that also support TLS.

Protocols that Already Support Kerberos The goal of networking is to be able to communicate. This communication is facilitated by similar applications making the same decision about matters such as how to integrate security.
8

The following table describes several common internet protocols and how they can be integrated with Kerberos. It also gives pointers to the specification that describes how security is integrated into the protocol; in many cases, the specification is not Kerberos specific, but instead points to a description of how the GSS-API or SASL is used to secure the protocol.

Protocol Integration Strategy Specification Many protocols are described as having the SASL+TLS integration strategy. This means that the protocol supports both SASL and TLS. As discussed above, the best strategy for using such an application with Kerberos is to use the GSS-API SASL mechanism and to use that mechanisms security layers. Doing so achieves the mutual authentication benefits of Kerberos. TLS, while available, is not needed in this situation. TLS is useful with other SASL mechanisms besides GSS-API. Also, some applications do not support SASL security layers; see the example section on SASL in Thunderbird for an example. Using TLS for integrity and GSS-API for authentication with such applications is better than no integrity protection at all. Once channel binding is available, this option may be even more attractive.

CHAPTER IV CONCLUSION & BENEFITS 4.1 Conclusion:

Authentication is critical for the security of computer systems. Without knowledge of the identity of a principal requesting an operation, it's difficult to decide whether the operation should be allowed. Traditional authentication methods are not suitable for use in computer networks where attackers monitor network traffic to intercept passwords. The use of strong authentication methods that do not disclose passwords is imperative. The Kerberos authentication system is well suited for authentication of users in such environments

4.2 Benefits:
Nothing is easier today than to catch credentials over a network. If we try to run a sniffer in our environment we will see that we certainly get a login/password combination within a few minutes. This could lead to an unauthorized use of our network services and would certainly compromise all data present in our environment; even protected confidential data, as most users are using only one password for every application. Authentication is critical to security. Too many applications use a weak authentication mechanism, like clear text passwords or, even worse, rely on the honesty of client applications, known as authentication by assertion. However, it is not the primary role of an application to manage security. Consider a mail server: its role is to deliver email messages over the network to the appropriate recipients, but not to verify the users identity! This is where Kerberos comes in. It has the advantage to manage secure authentication from a central location, and for many applications. For each application that requires this service, it is a reliable, simple and easy to manage solution to use Kerberos. Furthermore, it unloads application servers from this time consuming authentication task and allows concentrating on their primary function.

10

REFERENCES
1. ^ RFC 4556, abstract Notes:

SDK Team. "Microsoft Kerberos (Windows)". MSDN Library. B. Clifford Neuman and Theodore Ts'o (September 1994). "Kerberos: An Authentication Service for Computer Networks". IEEE Communications 32 (9):33

8. doi:10.1109/35.312841.

John T. Kohl, B. Clifford Neuman, and Theodore Y. T'so (1994). "The Evolution of the Kerberos Authentication System". In Johansen, D.; Brazier, F. M. T. (Postscript). Distributed open systems. Washington: IEEE Computer Society Press. pp. 7894. ISBN 0-8186-4292-0.

Cisco Systems Kerberos Overview- An Authentication Service for Open Network Systems

http://www.faqs.org/faqs/computer-security/ssl-talk-faq

11